#就地避難在家鍛鍊寫作能力
軟體工程師系統設計面試準備指南
當你有了幾年的工作經驗以後,在找工作時一定會遇到系統設計的面試,有鑒於大部分的面試心得都是針對演算法以及資料結構的程式面試 (包括我之前寫的美國軟體工程師求職心得),對於系統設計的準備資源還真的不多,本篇要來剖析系統設計面試,介紹面試的流程、正確的心態以及準備的方向,讓大家再也不怕系統設計面試!
Medium 好讀版:https://medium.com/jktech/%E8%BB%9F%E9%AB%94%E5%B7%A5%E7%A8%8B%E5%B8%AB%E7%B3%BB%E7%B5%B1%E8%A8%AD%E8%A8%88%E6%BA%96%E5%82%99%E6%8C%87%E5%8D%97-acf6ab1f502f?source=friends_link&sk=ca40acf60b749cb1b32c17a868b0c1a3
#為什麼系統設計很重要?
在程式面試表現優異,可以讓你順利拿到 Offer;但是系統設計會決定你加入公司的職等!這也就是為什麼有些人有十年經驗只能拿到 Mid-Level (L4) 的 Offer,而有些人只有五年經驗卻可以拿到資深工程師以上 (L5+) 的 Offer。
另外,如果你是面試 Staff 或是 Principal 級別以上的話,除了系統設計以外,有些公司還會有 Technical Leadership 的面試,來判斷你是否有能力可以跟不同的部門合作、解決問題的不確定性、帶領資淺的人然後推動並且完成一個跨部門的大型技術專案。
簡單來說,系統設計用來判斷你是 L4 或是 L5+,Technical Leadership 面試用來判斷是 L5 或是 L6+。
#為什麼系統設計很難準備?
大多數應徵者在準備的時候會過度偏重於程式面試,原因也不難理解,程式問題的定義很清楚,有給定的輸入以及預期的輸出,就算你真的想不出來,LeetCode 上的討論區也有參考答案;這種有考古題可以參考的面試,對於台灣教育出來的人來說相對好準備,隨著你解的問題多了,你也會更有信心,不知不覺甚至還會刷上癮了呢!但系統設計卻非如此。
系統設計面試的問題描述通常很模糊 (這是刻意的),沒有給定的輸入與輸出,比較沒有既定規則可以遵循,然後也沒有一個標準答案,針對不同系統你需要提出不同的解法然後分析優缺點,一樣的問題,面試官也會針對你過去經驗往不同的方向問,有些問題你工作上沒有碰過還真的回答不出來,這也就是為什麼很多人看到系統面試就怕了。
#到底要怎麼準備?
首先我們要先建立一個觀念:沒有任何一個人可以知道所有的技術細節
不管你的面試官有多少年經驗,不管他們再怎麼資深,在變化快速的軟體產業,沒有人可以知道所有事情,一定有你知道而他們沒聽過的事情!
請把系統設計當成分享你過去所學的面試,這個面試的目的在於展示你對於軟體架構能力的廣度跟深度,你必須可以給出大方向的架構,知道有哪些元件 (廣度),同時針對你熟悉的領域深入探討更多細節 (深度),並且提出幾個解決方案,分析優缺點,並且針對系統需求選擇合適的解法。
大方承認自己對某些領域的細節不熟,也是完全沒問題的,只要讓面試官了解你知道這個東西,如果要深入了解的話你知道有哪些方向要努力,這樣就夠了,因為在大型的軟體專案裡,一定是高度分工的,不會有人同時精通手機端、前端、後端、Infra 以及嵌入式或是硬體的。
講到這裡,相信你也知道如果真的要準備是準備不完的,這些知識是透過平常工作以及閱讀技術文章長期累積的成果,比較沒辦法臨時抱佛腳。
#具體來說會問什麼問題
舉例來說,一個系統設計的問題會像是這樣:如何設計 Facebook?
這類問題的描述通常會很大而且模糊,面試官不預期而且你也不可能在 45 分鐘內就設計出這些公司花了好幾年這麼多人力設計出來的產品,所以第一步要做的事情是確認需求:是要設計動態牆、Messenger、廣告系統還是推薦系統?流量跟資料量為多少?需要支援全球的使用者嗎?
確認完需求以後,會針對最重要的幾個使用場景設計你的 Data model 以及 API,接著畫出大的系統架構圖,大致上會包含客戶端 (手機版/桌面版)、Load Balancer (Reverse Proxy)、App Servers 以及資料庫,接著可以針對細節下去討論,這邊開始就很自由了。
如果你是專精在資料庫,可以討論要用什麼資料庫以及資料要怎麼存可以讓特定使用場景的讀取以及寫入效能比較好,要怎麼做資料庫的 Replication 跟 Sharding 來服務更多的使用者?
如果講到快取,哪些地方可以加快取呢 (瀏覽器前端, CDN, App Server, 資料庫)?具體來說寫入快取有哪些方式以及優缺點 (write-through, write-around, write-back)?什麼時候要失效?要讓哪些資料失效?
如果聊到微服務器架構跟 Service Mesh,不同的服務怎麼跟其他的服務溝通? control plane 要怎麼更新 data plane 的設定?如果 control plane 掛了怎麼辦?要怎麼做 service discovery? 哪一種 Load Balancing 策略比較好 (round robin, random, least connection, ring hash, or maglev)?有些服務掛了影響到整個系統怎麼辦?什麼時候需要 circuit breaker ?
如果你是手機開發者,怎麼實現離線瀏覽?手機要有資料庫嗎?要怎麼以及多常跟伺服器同步?API 要怎麼設計?如何實現 Infinite Loading?剛 Po 文以後要怎麼樣在自己手機上馬上看到?
這些問題真的列舉不完,總之看到這裡你會了解為什麼我說這個面試是沒有範圍而且也準備不完的,重點應該放在跟面試官的討論,展現你在技術方面的廣度跟深度,讓面試結束的時候能夠有一個你們兩個人都同意的設計!
#準備材料
系統設計的資源比較分散,以下是我篩選過後覺得有用的資料,按照素材的類型作分類,也歡迎大家留言補充!
#入門影片
針對完全沒有概念的新手,我建議可以先從哈佛的 CS75 Lecture 9 Scalability 開始,裡面講到的很多基礎觀念都相當重要,值得一再複習,這些概念先有了以後再閱讀其他的材料會比較有感覺:
如果你看完這篇文章後還想再多了解系統面試的形式,也可以看一個前 Facebook 工程師分享的影片:
Distributed Systems in One Lesson 也很推,裡面提到不少業界在使用的設計模式:
有一個需要付費的資源是 SystemsExpert,每個影片會講解一個系統設計重要的概念,我個人覺得內容有點淺所以沒有買,但是整理地還算不錯,如果你看完他們免費的影片有興趣還是可以參考一下。
#閱讀文章
影片是一個讓你很好理解大方向概念的方式,但是如果你要深入理解背後的原理還有怎麼運作的細節,還是得透過大量以及深度的閱讀來吸收呀!
system design primer 整理了很多系統設計的資源,資料量很夠, 個人的建議是先快速過一遍,不要細讀,先知道總共有哪些元件,大概是做什麼用的就好,接著針對有興趣的部分在深入研究,建立自己的知識庫。
Grokking the System Design Interview 也是很多人推薦的材料,主要是針對系統設計的問題提供範例解答,他們的答案可以當作一個參考,但面試的時候不要完全照著回答,還是得看跟面試官討論的結果來進行,但這個是需要付費的,有興趣可以用我的推薦碼註冊購買。
如果你不想花錢或是不確定 Grokking 的文章你喜不喜歡,有一個類似的網站 Crack the System Design Interview 整理得也還不錯。
#書籍
唸書是一個有系統性學習的方法,如果你只想選一本書來看,就選這本大家都推的系統設計聖經 — Designing Data-Intensive Applications,簡稱 DDIA,這本書適合的對象是想要長期準備系統設計或是分散式系統的人,裡面舉的例子都是實際上業界遇到的問題,不會有以前讀教科書那種工作又用不到的感覺;但也因為是書,花了一些篇幅在講解背景知識,包含以前的系統是怎麼設計的以及如何演進到現在,對短期要準備面試的人效率會有點低,所以不適合有時間壓力的人。
這本書我目前讀了一半,最大的收獲是它解釋了很多為什麼現代的系統要做這樣的設計,我們針對不同的系統要求可以有哪些解法,這些解法各有什麼優缺點,總之分散式系統就是我們解決了一個問題,但又會產生更多要考量的點,一切都是 trade-off。
但這本書也不是沒有缺點的,首先我覺得是本書的英文沒有很好讀,我常常一段看了好幾遍才知道他想表達的重點是什麼,而且,有些很重要的觀念常常藏在一段文字裡用一句話帶過,但是不太重要的觀念卻使用 Bullet Point 表達;另外這本書話常常講一半,一些觀念提到了一點卻說我們後面再聊,也因為這樣,我在考慮要不要幫大家整理每一個章節的重點,翻成中文分享給大家,有興趣的朋友麻煩拍手留言告訴我!
除此之外,Google 的 SRE Books 內容也很實在,但是每一個章節的內容是獨立的,建議大家選擇想研究的章節跳著看就好。
最後,Distributed systems for fun and profit 的內容也很好,以分散式系統的理論為主,比較沒那麼針對系統設計面試。
#還想閱讀更多嗎?
我知道光是上面的資源就已經讀不完了,但是行有餘力的話,平時也可以多看看各大公司的技術部落格或是訂閱技術週刊如 TechBridge (台灣) 、HackerNews 以及 InfoQ 等等。
此外,參考別人的經驗也是很好的方式,最近剛好幾個朋友剛找完工作,他們分享的矽谷找資深工程師工作心得分享以及2020 上半年軟工找工經驗分享也都很值得看!
最後,在工作上使用到的技術,除了會用以外,最好也要花時間去研讀技術文件,了解他們設計的考量以及支援的場景,大部分這類型針對開發者的文件寫得會比較深入,所以也是相當好的學習素材;我自己過去一年因為工作上需要整合 Envoy 到我們公司的 Traffic Infrastructure,從他們的文件中學到很多 Service Mesh 跟微服務器的重要概念,學習的深度都是其他資源無法提供的。
#總結
這篇文章我們整理了很豐富的系統設計資源,希望大家不要被這滿滿的資訊量嚇跑。
請記得,我們永遠有各種方法在短期內針對面試做準備,提升面試的表現,但這都只是一時的,沒辦法讓你一夕之間就成為專家;如果想要追求長期的持續成長,那麼沒有捷徑 — 就是養成每天學習以及閱讀的習慣,一開始真的很難看到效果,但是當你持續一週、一個月甚至是一年以後,你會明顯感受到自己的成長,這些投入的時間都是騙不了人的。
如果這篇文章對你有幫助,請拍手留言加訂閱,並且分享給更多有需要的人知道!
微服務 資料 同步 在 台灣物聯網實驗室 IOT Labs Facebook 八卦
國泰金控終於發布第一個區塊鏈應用,首推電動車車聯網區塊鏈金融平臺
國泰金控數數發對外發表首個區塊鏈計畫「電動車車聯網區塊鏈金融平臺」,透過與電動車充電站服務平臺ChargeSmith與區塊鏈新創BSOS共同合作,採用超級帳本開發框架,要把電動車行車電腦資料上鏈,規劃先應用在集團旗下銀行與產險的業務場景。數數發區塊鏈團隊更首度揭露採用超級帳本自行建鏈的關鍵。
文/李靜宜 | 2020-06-04發表
早在2年前,國泰金控就開始發展區塊鏈技術,不過,在全球區塊鏈最火紅的這兩年間,國泰金遲遲沒有出手,直到最近,終於揭露了第一個區塊鏈應用,率先鎖定的就是電動車車聯網新型態應用。
國泰金控數位數據暨科技發展中心(簡稱數數發中心)近期對外發表第一個區塊鏈計畫「電動車車聯網區塊鏈金融平臺」,找來電動車充電站服務平臺宅電(ChargeSmith)與區塊鏈新創BSOS合作,採用超級帳本(Hyperledger Fabric)區塊鏈框架,要把電動車行車電腦資料上鏈。國泰金控計畫先用於銀行與產險業務場景,將規畫提供電動車車主融資申貸、保險理賠、個人化商品推薦等金融服務。
數數發中心區塊鏈技術發展科資深工程師楊俊書表示,目前鎖定特斯拉電動車的行車電腦資料,臺灣現有約8,000臺,7~8成車主會使用宅電充電站查詢App。國泰這個車聯網平臺,會在車主授權後取得電動車行車數據,包括開車時間、時段、時速、里程數、煞車、充電電池的電量、車門有沒有關好等駕駛行為,再將這些數據加密存證並上到部署在宅電公司的區塊鏈節點,再與國泰旗下子公司的其他區塊鏈節點同步資料。
在作法上,楊俊書解釋,特斯拉原本就建置了一個Data Hub平臺,會定期搜集每一臺特斯拉汽車的行車電腦資料,也對外釋出了官方開放API。數數發區塊鏈團隊自行寫了DApp與智能合約,而BSOS協助宅電建立節點,並確保資料來自特斯拉原廠的原始資料,車主授權後直接串接官方API後,將指定電動車行車電腦資料直接放入DApp,DApp再依據智能合約,將資料上鏈到宅電節點。這個作法的好處是,「可以將特斯拉電動車車主第一手行車電腦資料,直接上到國泰的區塊鏈。」他強調。
目前,國泰先找來4位特斯拉車主,進行為期3個月的PoC驗證,來證明整套資料流運作模式的可行性之後,就會開始大量招募電動車車主。同時,也透過PoC讓集團子公司了解運作模式,以利後續發展其他應用。國泰金控預估,正式服務將在今年底陸續上線。
靠排除法找出合適區塊鏈應用場景,國泰每次先問這3個問題
數數發中心早在2018年9月就先成立了區塊鏈小組,後來進一步轉為正式編制,成立了區塊鏈技術發展科,隸屬於數數發數位架構發展部,目前共有9名團隊成員。
成立初期,這個團隊花了很長的時間,先研究不同區塊鏈技術的底層架構,多方評估後最後決定採用超級帳本技術框架,而且決定要自行建鏈。2019下半年,區塊鏈團隊開始與金控旗下子公司合作,正式展開區塊鏈產品研發。
楊俊書表示,國泰區塊鏈團隊的目的是,要將區塊鏈價值落實應用到子公司,甚至是子公司的顧客。為了找出合適的應用場景,國泰後來發展出了一套排除法策略,「與子公司合作時,透過3個問題,先排除不需用區塊鏈的業務。」楊俊書解釋,一是,這個業務能否想出可以和哪一家公司分享資料?如果找不到可成為節點的合作夥伴,這個業務可能就不適合區塊鏈。第二個問題,即便有了分享資料的合作夥伴,還需評估雙方應用區塊鏈是不是有必要性?比如,這個資料分享若不透過區塊鏈便永遠拿不到,就有必要性。
找出了非用區塊鏈不可的場景還不夠,楊俊書強調,國泰區塊鏈應用的原則是個資不上鏈,還會詢問子公司是否同意這個作法?若對方也同意,區塊鏈團隊才會開始建鏈。他解釋,國泰未來可能需要做國際生意,若是合作對象是歐洲公司,就得遵循歐盟GDPR個資保護規範,就算在臺灣,也逐漸開始注重個資,為了避免外界對個資洩露的疑慮,國泰才決定個資不上鏈,只讓一些公開資料或半公開資料上鏈。
主流區塊鏈技術比較,採用超級帳本自行建鏈關鍵
楊俊書更回顧了1年前,數數發區塊鏈團隊在國際幾個主流區塊鏈底層架構,選擇超級帳本開發框架,並決定自行建鏈的關鍵原因。「因為,金融業最在意的是資料隱密性。」
他進一步指出,以太坊(Ethereum)是一般區塊鏈團隊採用的首選,因為以太坊的資料最多,很容易就能建立以太坊私有鏈。國泰區塊鏈團隊在去年做了一個物流鏈POC,就是在私有鏈上採用權威證明(Proof-of-Authority,PoA)共識演算法。而PoA共識的運作是有授權的節點,才有產生區塊鏈網路中下一個區塊的權限。
楊俊書透露,在以太坊私有鏈採用PoA共識機制雖然好用,不過,在資料的隱密性上有些麻煩。他解釋,所有參與方都在同一條鏈上,若要對部分參與方屏蔽資料時,需要另外開發屏蔽資料的功能。
不過,像超級帳本就採取許可制區塊鏈架構,能夠指定特定節點參與及共同維護運作,並預設提供Channel功能可確保資料隱密性。他提到,該功能像是資料通道的概念,比如,A、B、C、D四家參與方在同一鏈上,普遍性資料開放給所有人瀏覽,若A與B有一天想單獨做生意,不想讓其他兩家知道,就能用Channel功能建立一個通道,A與B雙方合作的特定生意的資料,只會在這個通道進行。而且,當第三家公司有一天要加入這場私下交易時,依然能看到過去A與B雙方的歷史資料。
「這樣隨時可加入新業務的彈性作法,可讓鏈上多家參與方未來能做的生意更為多樣化。」楊俊書說。
其實,摩根大通使用以太坊開發的Quorum區塊鏈平臺,也有類似通道的概念來確保資料隱密性,當其中兩家公司進行私下交易時,雙方可以透過一個private data小池區,來存取僅有彼此才能看到的資料。缺點是,雖然第三家公司後續也可以再加入該通道,但卻看不到原本兩家先前的歷史資料。
楊俊書指出,這也是為何他們選擇超級帳本的原因,因為曾合作的歷史資料,對金融業展開另一場合作來說至關重要,這是可供後續合作對象評估的一項指標。
他進一步比較,主打金融專屬設計的R3區塊鏈平臺,重頭到尾都採一對一通道,其實也可以做到資料隱密性。但,國泰考量到數位轉型不只要做子公司內部擁有的生意,未來更可能進一步與外部夥伴做生意來擴大生態圈,這時,R3一對一的通道設計,會導致通道數呈現指數性成長,會大大降低效率,或有管理平臺維運難度較高的問題。
國泰金控數數發中心區塊鏈團隊,選擇了超級帳本作為開發框架,主因是超級帳本有預設的Channel功能,能夠確保資料隱密性,且通道能彈性加入新參與方,並能瀏覽先前的歷史資料。(圖片來源/國泰金控提供)
自行建鏈踩過的坑,未來計畫建立自家的共識演算法
用了一整年超級帳本的數數發區塊鏈團隊,其實在剛開始建鏈時,也踩了不少坑。楊俊書舉例,超級帳本使用Kafka訊息佇列來進行共識演算法,對所有交易資訊進行排序。然而,他坦言,Kafka是一門新技術,仍有一些小臭蟲,有時太多資料要上鏈,可能會發生交易順序錯誤的問題。
或是,有時,鏈上四個節點,其中一個節點當機要重開時,得利用其他三個資料完成的節點,來回復資料,但曾發生過,回復後的資料版本,跟其他三個節點不同。楊俊書提到,這也跟交易順序有關,後來找出一些解方,比如為每個節點做備援,或是把某項元件跟節點拆開來運作,一旦有節點故障重啟時,就能透過正常運作的某項元件將資料同步回來。
他更透露,未來,國泰區塊鏈團隊也不一定堅持使用超級帳本,而更希望能建立自己的共識演算法,比如用開源的實用拜占庭容錯演算法(Practical Byzantine Fault Tolerance,PBFT)來修改。主要原因是,國泰現在有些業務場景,需要高速度交易或高安全性等不同需求,「若未來建立自家的共識演算法,只要修改底層,用共識演算法調參數,就能符合集團不同業務需求。」
國泰自建的區塊鏈,在架構也有不少長期發展的設計考量,例如,區塊鏈團隊也從一開始打造區塊鏈時,就遵循數數發的企業基礎架構與技術。楊俊書表示,例如建置超級帳本時就直接採用微服務,未來,若需要將區塊鏈變成一個基礎架構模組時,較容易整合到數數發的整套基礎架構中。
另外,國泰區塊鏈也採雲端原生(Cloud-Native)設計,國泰日後若需要與外部公司合作,可以直接在雲端部署對方所需的節點。不過,金融業上雲還有許多法遵考量和設計要求,數數發數位架構發展部的雲端團隊,也會來支援這個區塊鏈平臺的雲端架構與維運。
區塊鏈技術發展科另一位資深工程師李肇筌提到,他們使用Docker容器技術,將程式碼與執行環境打包成一個映像檔,只需要1到2天時間,就能快速在子公司或是外部公司建置一個區塊鏈節點。他提到,目前盡量採取容器化的方式來部署,後續處理問題較為方便。
國泰不只把區塊鏈作為發展數位金融的新興技術,更考慮把區塊鏈變成未來金融各領域可共用的架構,之後就能快速發展其他應用,只是目前尚未揭露太多細節。
電動車車聯網區塊鏈金融平臺先聚焦銀行、產險應用
最新發布的電動車車聯網區塊鏈金融平臺,未來應用將分為兩階段。楊俊書表示,第一階段是跟國泰產險與國泰世華銀行合作;第二階段則計畫找到更多節點,比如修車廠,透過修車廠的ERP,或是維修記錄的資料庫成為一個節點,再與國泰的節點同步資料。
在產險的應用,國泰產險可針對車主的行車習慣或駕駛行為,評估規畫發送行車安全提醒簡訊,或是推薦合適的個人化保險商品。同時,也正在研究當車主發生交通事故時,運用區塊鏈資料不可竄改的特性,優化理賠審核流程。
銀行的部分,目前則規畫用在融資申貸。楊俊書提到,比較簡單的應用是,未來當車主要用車體履歷申請融資時,國泰世華銀行的評估人員可透過區塊鏈來獲取車主行車資訊如里程數,以及維修記錄等來評估車況,像是用維修記錄判斷車子有無撞過,藉此減少車主與銀行一來一往的時間,加快核貸速度。不過,融資申貸這塊目前尚未設計完成,像是在融資額度的部分,因涉及審查單位,所以還要進行規畫。
國泰金控也透露,除了電動車車聯網區塊鏈金融平臺,目前,國泰產險與數數發中心也正透過技術架構重整中後臺,不久後就會推出全新的科技金融應用。
附圖:國泰金控推出電動車車聯網區塊鏈金融平臺,目前鎖定特斯拉電動車的行車電腦資料先進行3個月的POC,正式服務預計年底陸續上線。(圖片來源/ChargeSmith)
國泰金控2年前成立區塊鏈團隊,後來更在正式編制中設計了數數發數位架構發展部區塊鏈技術發展科,目前共有9名團隊成員。(攝影/洪政偉)
資料來源:https://www.ithome.com.tw/news/138049?fbclid=IwAR1WQhs37BNwHPNWaCu35pp0vdxa-sBWoXeXgMF-AN3Kaf2Xo2eZd7sd67g
微服務 資料 同步 在 軟體開發學習資訊分享 Facebook 八卦
學習如何開發 Spring Boot Microservices 並使用 Spring Cloud 佈署它們!
傳統上,大型企業級應用程式是作為大型單體式應用程式( monolithic application )開發的。
Spring 框架最初是作為 J2EE (現在是 JEE)的替代品,用於建構這些大型單體式企業應用程式。
然而,這個產業已經發展到有利於微服務。 使用微型服務有很多好處。 在本課程中,你將學習到驅使公司採用微型服務的好處。
隨著產業的發展,Spring 框架也在不斷演進。
Spring Boot 和 Spring Cloud 是專門用於開發微服務的工具。
Java 仍然是公司使用的最流行的程式語言。 Spring 是建構微服務的最流行的框架。
Spring Boot 本身帶來了幫助你快速建立微服務的工具。 你將學習產業中的最佳實踐,以快速發展企業級微型服務。
微服務不僅僅是擁有一組 RESTFul APIs。 微服務( Microservices )經常使用非同步訊息傳遞系統,本文對此進行了完整的介紹。
在本課程中,你還將學習使用基於微服務的架構時所面臨的獨特挑戰。
在學習了基於雲端的環境中微服務架構的基本資訊之後,你將學習傳統的單體式應用程式。
然後透過一系列練習將整個範例單體解構為一組微服務。
✅ 微服務可以共享資料庫嗎?
✅ 如何跨一系列微服務協調業務邏輯?
✅ 如何使用不同的資料庫管理跨多個微服務交易?
在引導你將傳統的單體式應用程式解構為微服務架構時,所有這些問題都得到了解答。
你將在單體式應用程式中看到我們認為理所當然的事情。 在分散式架構中,諸如交易之類的任務構成了巨大的挑戰。
在課程中,對單體( monolith )的解構是一個主要的練習。 對於公司來說,將單體架構解構為微服務是非常普遍的。 這個練習為你提供了一個真實世界中的範例。
https://softnshare.com/spring-boot-microservices-with-spring-cloud-beginner-to-guru/