關注我，持續(xù)分享邏輯思維&管理思維； 可提供大廠面試輔導、及定制化求職/在職/管理/技術輔導；
有意找工作的同學，請參考博主的原創(chuàng)：《面試官心得--面試前應該如何準備》，《面試官心得--面試時如何進行自我介紹》。

博主其它經(jīng)典原創(chuàng)：《管理心得--工作目標應該是解決業(yè)務問題，而非感動自己》，《管理心得--如何高效進行跨部門合作》，《管理心得--員工最容易犯的錯誤：以錯誤去掩蓋錯誤》，歡迎大家閱讀。

--------------------------------------正文----------------------------------------------

大家去面試時，相信都能隨口說出，架構設計要考慮性能、可靠性、可擴展性?？墒?#xff0c;針對項目中的細節(jié)一問，架構設計怎么考慮可靠性、性能等，很多同學都回答不好，甚至針對自己的項目，也講得不清不楚。下面我說下在騰訊等大廠帶團隊做架構設計的幾個原則（以我做的海量存儲為示例來講解。該存儲量級為千萬億條kv記錄的量級）：

?一、關鍵路徑一定要短。數(shù)據(jù)從入口處，到落盤，這里能短就短。經(jīng)過的節(jié)點越多，出問題的概率越大。以存儲為例：接口層Proxy(緩存了路由)，直接把數(shù)據(jù)路由到應該落地的存儲節(jié)點。關鍵路徑就2個模塊。其它作為非關鍵路徑，即使掛了也沒事，比如放全量路由的管理節(jié)點、比如數(shù)據(jù)異常時的遷移節(jié)點。當然，如果Proxy和管理節(jié)點同時出問題，會有一定的影響，但這個概率很底，而且管理節(jié)點邏輯比較簡單，并且可以雙機熱備。

?二、非實時功能，不要集成到關鍵路徑中。比如數(shù)據(jù)有過期功能，很多人會把刪除過期數(shù)據(jù)的邏輯放到存儲節(jié)點中。但當這個邏輯代碼出問題的時候，或者這塊邏輯需要做功能升級的時候，都需要修改存儲節(jié)點。存儲節(jié)點發(fā)版本越多，越容易影響現(xiàn)網(wǎng)。建議有一個外圍模塊，不斷地去掃描過期數(shù)據(jù)并刪除（或給存儲節(jié)點發(fā)刪除命令，直接刪除擔心數(shù)據(jù)多處寫有一致性問題）。這樣，刪除邏輯即使有問題，可以讓運維臨時擴容解決，當然，這個模塊需要重點監(jiān)控。避免出現(xiàn)問題。

三、有狀態(tài)節(jié)點雙機熱備。如存儲節(jié)點，本身也需要寫2-3份，以保證數(shù)據(jù)安全性。當一臺機器出現(xiàn)問題時，可以快速切換到另一臺機器服務。這點相信很多做架構的同學都能做到。

?四、無狀態(tài)節(jié)點盡量使用容器，以做到快速擴縮容。當然，即使使用物理機，一般也能做到快速啟停。

?五、對DB數(shù)據(jù)進行緩存。很多時候，DB可能會成為穩(wěn)定性或性能的瓶頸。一般情況下，建議將DB數(shù)據(jù)進行緩存，而不是將DB作為關鍵路徑。定期從DB讀管理數(shù)據(jù)，并更新緩存。這樣，DB不是關鍵路徑，也不會成為性能瓶頸。

?六、做好對賬功能。日志上，每個模塊發(fā)送、回復一個命令，需要打印日志（但現(xiàn)網(wǎng)可以關閉，只在調(diào)試時打開）。統(tǒng)計上，要有每個模塊每分鐘（或每5分鐘）接受了多少請求，平均處理延時是多少等。

?七、需要把正常錯誤和異常錯誤分開。比如存儲系統(tǒng)中，Get數(shù)據(jù)，“數(shù)據(jù)不存在”，和“存儲節(jié)點異?！倍紩е翯et失敗。但一定要區(qū)分，一個是業(yè)務問題，一個是系統(tǒng)問題。

還有很多設計上要注意的點，比如優(yōu)雅重啟，比如CoreDump數(shù)據(jù)保存等。本次先總結(jié)到這，博主相信，還有很多未概括到的點。有興趣的同學也歡迎私信交流。

本次是從技術上講架構師之路，后續(xù)將在管理上講講如何成為架構師。歡迎關注博主以獲得后續(xù)的干貨分享。