萬字長文剖析架構設計全攻略（上）

• 2019 年 12 月 12 日
• 筆記

正文開始前，先花大量筆墨推薦幾個我工作中常用的思考框架、實踐框架，後續文章中會使用這幾種思考框架作為工具來描述、拆解、分析問題。當然你也可以使用到其它工作內容中，掌握幾種利器，比無頭蒼蠅樣做事效率會高很多。

1. 幾個思考、實踐框架

1、目標驅動、可量測的行動框架

OGSM 是 Objective（目的）、Goal（目標）、Strategy（策略）、Measurement（測量）的英文首字母組成。一種實踐策略的手段，以達成理想的目的與目標。

學術界一個研究方向快速進展的關鍵，是清晰地定義了問題的目標函數。當年 Google 和雅虎的幾位大師把廣告清晰地定義為一個優化問題，這個領域的進展才日新月異。按照某前輩的話說，管理一個工程團隊，只需要做好兩件事：一是定義好目標，二是建立一個評測系統。可見目標、可量測不是神秘職務，在各個領域都有案例。

當我們做事情時候，可以按照以下流程來實踐：

• 目的：明白領導意圖。通常這個目的是領導層或上層給予執行層面、部門、團隊的任務。通常比較含糊或者宏大，一方面不容易快速達到，另一方面這個目的，對於執行者來說，很不容易測量。
• 目標：當我們面臨一項任務或目的時候，都會把目的拆分為 易執行、可量測的小目標。可以拆解成小目標、小任務，排優先、定重點、分配給下屬、並制定 KPI 或 OKR 關鍵性指標。
• 策略：執行層面考究團隊執行力，可以針對小目標或可量測指標，做很多 TIP 或工作策略。例如：寫代碼時，對代碼的測試覆蓋、結對編程、Code Review 等。具體到不同時期，有不同方法論，這裡暫不展開。
• 量測：拆解的目標必須是可量測、可量化，有指標可以衡量任務是否完成、完成度等。如果特別特別放到量測指標，其實算過度 KPI， 對我們架構創造性事情，需要更深層次考慮。畢竟，軟件不是富士康計件類型工作。
• 不斷迭代：通過量測指標，不斷調整執行策略，甚至調整拆解目標。小步快進，達成目的，良好的完成上游給予的任務。

業內實踐或很多書籍，從不同角度驗證該工作方法的適用：

• 很多運營方面，尤其是增長黑客、數字營銷方面工作，特彆強調數字指標設定、運營方法、迭代運營。比如：《增長黑客》中海盜模型轉化漏斗，以及衍生出來一些列案例；《運營之光》提到的「優秀的運營要以目標為導向，主動行事。」
• 目標驅動、數字衡量的新型運營手段：大數據時代，數據帶給決策更加豐富、準確的素材或理由。改變了企業運營、運作的傳統方法。個人認為傳統運營偏文科一些，需要更多活動策劃、文案文字相關工作。而有些領域，如計算廣告中，廣告優化師，需要很強的數據能力。市面上運營兩類書，一類一看就是文科寫的，增加很多數據指標之類問題，不深入，但寫的很好看。後一類一看理科生寫的，很多數據模型，但是看得很頭大。
• 測試先行的敏捷實踐：當項目足夠複雜的時候，想要保證儘可能的減少 Bug，有兩種有效的方式分別是代碼審核和測試先行。我們完成正式邏輯前，先編寫測試用例，就是編寫量測方法。
• ABTest 的產品衡量手段：ABTest 在互聯網公司廣泛使用，並在各個領域發揚光大。比如：拆分用戶，針對不同用戶界面功能使用投票等。推薦系統中評估體系的建設。廣告優化師，通過不斷的調整素材、定向等優化投放姿勢。 甚至抖音這類 App，整體產品邏輯，就是「ABTest 」。
• 機器學習算法中，假設空間、優化目標、尋解算法三角中，優化目標的設計是為了設定衡量標準。可以說機器學習、深度學習背後的理論，跟測試用例編寫是很像的。註：例子還可以很多，前面例子可以當成一個職業方向去學習研究，這裡點到為止，也可以留言溝通交流。

2、互聯網思維-迭代思維

「迭代思維」是互聯網產品開發的典型方法論。「天下武功，唯快不破」，只有快速地對消費者需求做出反映，產品才更容易貼近消費者。這裡暫且不說這個「快字」，按照我們傳統思維方式，我已經足夠了解產品需求了，我直接設計滿足用戶需求的產品不就可以了嘛？答案是否定的！

互聯網產品是迭代而成的，（無數案例證實這點，這裡不展開篇幅）！那麼我們為這些產品設計的後台、前台、數據架構，也必定是迭代而成的！按照達爾文進化論來解釋的話，物種是迭代進化而來的。人這個物種對外界的需求、訴求、主動變革，都在不停地迭代。那麼軟件產品、架構也肯定需要迭代。

產品生命周期理論如圖1所示（PLC 模型）是由美國經濟學家 Raymond Vernon 提出的，即一種新產品從開始進入市場到被市場淘汰的整個過程。用戶、產品、人、事都存在生命周期。

圖 1 PLC模型

從另一方面來看，我們看待用戶、產品、人、事，絕對不能是靜態思維，我們制定計劃、制定目標時候，不可能是不變的。舉個例子：筆者原來在北大方正工作，每年集團都會制定***戰略目標，等落實到各個子公司、子部門時候，整體外部環境都已經改變，這些「戰略目標」很可能不合適了，但是由於集團最大，也沒法反駁。造成整個集團、公司 運轉效率、努力方向、同業競爭都產生很大的問題。

這個問題攤開講，會很複雜，回到軟件架構這一領域，一定要明白架構是從簡單合適，通過業務需求推進，再到複雜的演進過程。近一年挺火的中台概念，阿里需要中台，難道小創業公司也需要中台戰略嗎？不了解中台演進或推進中台的業務需求痛點，根本了解不了中台，更不可能架構好。

3、5W1H-認識、分析一件事物時的思維方法

IT 從業者要不斷面臨新的語言、新的技術、新的框架，如何才能快速學習、認知一門新技術呢？5W1H（WWWWWH）分析法也叫六何分析法，是一種思考方法，也可以說是一種創造技法。在企業管理、日常工作生活和學習中得到廣泛的應用。

5W+1H：是對選定的項目、工序或操作，都要從原因（何因 Why）、對象（何事 What）、地點（何地 Where）、時間（何時 When）、人員（何人 Who）、方法（何法 How）等六個方面提出問題進行思考。

實踐案例：

認識 Redis、認識微服務、認識 Docker、Kubernetes、認識機器學習、認識深度學習，讓我們面臨新的技術或概念時候，都會需要學習。我是怎麼學習的呢？

以 Redis 為例，不一定強調內容全面或完全正確，主要體會思考學習方法：

• What：基於內存實現的 K-V 存儲系統；內存數據庫；NoSQL；支持 sting、list、set、hashmap、zset 五種數據結構。
• Why：在分佈式系統中，本地緩存不能滿足需求。 分佈式緩存系統，類似框架 Memacache、基於 SSD 低磁盤的成本分佈式緩存系統。
• Where：相當於使用場景。如果系統按照 App->Gateway->Service->Dao->持久層來分的話。Dao 與持久層（MySQL）之間使用，減少與持久化數據訪問頻率，提高 QPS；Service 層可以使用，例如：做一些業務緩存；Gateway 層，也可以把鑒權 token 放到 Redis 中。
• When：性能、QPS需要提升時，緩存是第一時間想到的解決手段。當然 Redis 擴展出很多其它用法，例如：分佈式鎖、分佈式優先隊列、布隆過濾器、set 交集等較為高級用法。
• Who：通常架構師、後端工程師使用。
• How：API 查閱文檔，看看例子就能明白。
• 類似比較學習：當我們認識新事物時候，類比法也是特別好的使用方法。假如我么使用過本地緩存 Ehcache、Guava，再去學習 Redis 會簡單很多。

近幾年我很少看源碼，不是源碼不重要，而是你了解了初衷後，對框架本身興趣點會降低，而會思考生態，思考思維路徑。摘錄一段如下，期望有啟發：

建議大家觀看一個視頻，偉大領袖如何激勵行動 TED 演講：偉大的領袖如何激勵行動_騰訊視頻 ；裏面提到一個非常有意思的認知「三環」,絕大多數人是由外而內（What=>How=>why），但偉大的公司或領導者，思考的路徑通常是由內而外（why=>How=>what），團隊或者客戶認可的常常是你的理念/信念即「為什麼」，從而願意接受你的產品或服務。

4、多元視角看問題

著名的大文豪蘇軾的《題西林壁》

橫看成嶺側成峰，遠近高低各不同。

不識廬山真面目，只緣身在此山中。

獵豹 CEO 傅盛曾說：

一個創業者想要成功，首先要用多種視角看事情。

在看待問題時候，既將自己深入其中，能敏銳感受內里變化；抽身其外，又能讓自己變成一個旁觀者，觀察很多事情的發生和結果。

如果看問題的視角只有一種，即從自己出發的視角，我們看到的世界就會過於局限。筆者傳統 i 行業轉型互聯網創業過程中，對這點深有體會。以前都是站在技術角度看問題或個人視角看問題，根本不會站在用戶角度思考。

「微信之父」張小龍就曾說，喬布斯最厲害的地方是什麼？「喬布斯最厲害的地方是他 1 秒鐘就能變成傻瓜，而馬化騰大概需要 5 秒鐘，而我差不多需要 10 秒鐘。」

所以，更重要的是思維觀念上的通達，越聰明的人越可以「大道至簡」

周鴻禕喜歡用「一分鐘變小白」來作為評價產品經理能力的一個要素。而張小龍，據傳私下裡說過「我可以在五分鐘內變成小白，而馬化騰立即就可以」這樣的話。無論真假，可以看出「變小白」這種能力在這幾位產品大拿眼裡是極其重要的，以至於變小白的時間的長短決定了產品能力的段位。

這三位所說的「變小白」，其實是「變用戶」，也就是從「產品設計人員」或「產品經理」的角色切換為「用戶」角色。只不過由於這三位所掌控的產品面向的用戶以「小白」為主，所以有了「變小白」一說。

一個人有足夠的視角或多維視角觀察能力，總是能認清楚要解決的問題，找准目標、確定方向，執行上如何錯誤，至少是在進步。如果不能全面的掌握問題，使勁的方向都不對，可能會事半功倍。

前幾天跟群里幾個同學聊起中台，有的同學拿起微服務說事，有的拿起標準說事，有的說是什麼新的框架技術，有的轉發了微信的幾篇中台文章，我感覺都不是全面或準備。為什麼，因為視角不對，中台戰略最終受益者是誰呢？我覺得站在最終受益者（用戶）視角考慮整個問題可能會全面些！

據說連馬雲都帶人去北歐 Supercell 學習所謂的「大中台架構」，據此調整阿里巴巴的組織結構，以避免了大公司常見的部門與部門爭奪資源，不同的小組做同樣的事情。

如果以上為真的話，按照 OGSM 框架分析一下。馬教主為了避免「大公司常見的部門與部門爭奪資源，不同的小組做同樣的事情」 ，提出大中台架構的目的。各個執行部門針對教主提出的目的，制定自己職權內的目的、目標。技術部門或事業群接收到任務不同，拆分出業務中台、數據中台的概念。我們換個視角思考， 公司的組織結構需要調整嗎？考核標準需要調整？獎金激勵手段需要調整嗎？權利責任各個組織結構節點變了嗎？ 個人在創業公司，這輩子有可能不會做中台相關工作，理解不深，展開也說不清楚（憨笑）。如果我們理解一個新的概念時候，可以換多個視角或提升視角，站在更高的角度看這個問題，可能會更加全面，那麼處理手頭面臨的問題時，會很容易。

分享幾個視角：

宇宙視角：宇宙視角能將我們禁錮已久的國與國、區域與區域、地區與地區、公司與公司、個人與個人的界限徹底打破，從而帶給我們更為廣博的胸懷以及更加寬闊的視野。說白了，自己能跳出利益，看清楚利益相關方的嘴臉，靈魂附體後再爭取利益時，會更有優勢（汗一下自己）。

利益相關方視角：做商業產品或撮合交易系統，尤其需要有這方面能力。當然要站在不同利益相關方看問題，需要有同理心、換位思考等等更方面的訓練。可以看一些產品方面的書籍。

用戶視角：產品經理需要經常用用戶視角來思考。當我們做系統、架構時，必須了解是誰使用它。可以確定的是，肯定不是自己使用，所以切勿以自我為中心的思考、設計等。

時間線視角：

• 你可以讓自己退後一步，離開正在進行的一切，站在時間線的後面，注視它，感受它。眼前這根時間線代表的正是你的一生，它像是一條不斷奔湧向前的河，不論你是否正在其中，還是已經退後一步，它的奔涌都從不止息。
• 你也可以試着站在未來某一時點上看問題，它能讓我們從此時此刻的糾結中抽離出去，站到更遠一點的地方回望。
• 當我們不知道自己真正想要什麼、真正在乎什麼的時候，可以嘗試時間線臨終視角。它能幫我們濾盡鉛華，看清內心真實渴望，甚至是我們的核心價值觀。

2. 這些模型如何在架構設計中使用？

第一、 使用目標驅動的行動框架。明確我們要去哪裡？知道架構設計的目的、階段性目標， 才能有針對性的少走彎路。

第二、我們怎麼才能知道我們現在在哪？明白評價架構、系統的常見評價體系，才能針對目標，一步一個台階的走下去。評價指標通常是與數據相關的，但是容易評估的目的，往往是簡單容易實現或案例很多的。

第三、無論我們面對的需求或目標多麼高大，路要一步一步走，飯要一口一口吃。零零散散各個目標指標，只能有側重、有優先不斷迭代、夯實、拔高的達到目標。

第四、如何理解大廠、書籍、國外傳播的最佳實踐呢？ 我們需要明白，任何最佳都是迭代出來的，而不是一蹴而就的。

第五、針對架構設計目的，常用的有哪些手段呢？我們如何建立自己的武器庫，常見的解決問題的手段呢，通過 5W1H 來了解梳理。

第六、架構師崗位是與其他崗位高度協同的崗位，了解業務、了解其它崗位、協同人職責視角很重要。多元視角不光可以讓自己更深刻理解架構本身，還可以了解業務、了解場景，更有效的協同工作。

註：文章只是拋磚引玉，筆者也是在其它崗位的一些經驗，反哺總結到架構崗位上。不一定正確，適合自己的才是最好的。

3. 架構定義

軟件架構（Software Architecture）是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。其實我們把架構當成一個技能、工種、職位、崗位，核心還是為了應對軟件設計、構建中的複雜度，降低成本、提升效率。

對我們常見系統做一下分類。如果按照行業分，篇幅不夠、積累也少，無法全面分類。這裡嘗試按照時間線分類，後面閱讀會更加順暢一些。

事中業務

常見的業務系統。如：電商、交易系統等等大多屬於這類。實際業務中，對業務反饋需要越實時，實現難度相對越高，比如：共享單車APP、股票交易等，需要實時的提示、預警、交互。除了傳統型業務型架構外，對大數據流計算架構要求逐步提高。

事後業務 事後肯定有數據沉澱，有數據肯定可以對未來決策做指導。自然而然查詢統計、報表決策、數據挖掘、事後總結等數據應用類系統。

事前業務 事前基本為業務預測、分類、推薦、決策輔助燈業務。隨着機器學習、深度學習的火熱，這部分應用越來越廣泛。例如：量化投資、廣告點擊率預測、短視頻推薦、電商推薦等。

趨勢 人類慾望膨脹，業務需求無止境，從而推進技術、架構發展。人工智能、流計算、大數據發展，離線/在線、事後/事前/事中、人工決策/機器預測 等界限已經很模糊。也是我個人認為的技術方向， 大數據、流計算、推薦系統、廣告系統。（機器學習、深度學習等業務系統）。

4. 架構目的有哪些？

架構的目的其實每個架構師、程序員都很清楚，或日常工作中自然而然都會面對。但是我們很容易迷失自我。如果你是個架構師，現在閉上眼睛，回想三十秒，想想當天工作內容的解決了什麼問題？達成什麼目的？晚上加餐學習內容的目的是什麼？是在熬時間等工資？是在踢皮球推卸責任？還是為了少干點活？還是學習新的知識為了提升個人價值，升職跳槽？

面試時，面試官通常會從項目經驗中考察以下幾點：業務複雜引起的複雜度、數據量引起的複雜度、用戶數引起的複雜度。比如，做過什麼項目，是否了解電商交易系統？你們用戶數有多少，峰值 QPS 多少？你們一天產生多少數據？如何存儲處理等？

面臨架構設計 Case 時候，無論是架構升級、還是構建架構地基，主要目的肯定只有一到兩個。比如：用戶規模擴大，原有架構在並發、性能上無法容忍；又如：業務快速發展，7*24 小時運轉下，升級迭代新功能太麻煩， 是否可以考慮微服務架構等。

如果從客觀來說，架構需求肯定包含在以下需求之列：高並發、高性能、高可用、安全性、規模擴展性、規模成本。書籍、網上都是這樣說的，因為這樣說都沒錯。

小節：基本很多書上、文章都有講解，下面來點很少地方能看到的知識點！就算我們設計的架構，都能滿足需求，達到目的，算合格的架構嗎？答案是不算！為啥，回到前面 OGSM， 能夠明確量測方式、可量化任務的目的、目標，其實都不是難事。我們做很多事情時，尤其是探索性架構師，可量測性其實是很模糊的。 舉個例子：當初 MapReduce 框架剛出來時，誰有說它慢呢？是否直到 Spark 在更短時間完成相同任務，才發現 MapReduce 框架如此之慢！

所以是否有個結論，可量測方法、量化指標都是在實踐後的結果。當然，不是說目標的評測不重要，對於初學者肯定是重要的， 但是用這些評價架構或評判事物，可能陷入自欺欺人的境地。

5. 如何評測這些目標？

SLA 服務等級協議(Service-Level Agreement)，指的是系統服務提供者（Provider）對客戶（Customer）的一個服務承諾。這是衡量一個大型分佈式系統是否「健康」的常見方法。SLA 設定一些指標，來考核、衡量系統。

1. 系統可用性：也就是常說的 4 個 9、5 個 9 指標。

2. 準確性或錯誤率：可以簡單理解為 錯誤請求數/全部請求數=錯誤率。

3. 系統容量/吞吐量/預期負載：也就是常說的 QPS/TPS 等， 每秒可處理的查詢數或事務數。

4. 延遲或 RT 等：系統響應時間。

註：關於這部分概念，上網查詢即可，不展開描述。

當系統架構在不停迭代的時候，有了一個明確的 SLA，我們可以知道下一個版本架構的改進目標以及優化好的系統架構是否比上一代的系統 SLA 更加優秀。當然評測系統還有很多其它指標，比如：可擴展性，隨着雲計算的發展，硬件層面擴展性基本不用考慮，我們通常考慮業務需求的擴展性即可， 但這個需求、業務擴展往往無法衡量，而架構師又容易過渡設計，是個考驗架構師火候的指標之一。 還比如分佈式系統數據一致性、持久性、數據可靠性能，這裡不展開闡述。

當架構搭建基礎較好的時候，這些指標其實比較容易提升。從另外一方面說，真正架構難度，不是業務架構，而是支撐核心業務穩定運行的點點滴滴，以微服務為例來看：

• 冗餘部署是提高系統可用性唯一法寶。服務的冗餘部署，是為了提升系統可用性。另外使用微服務架構，有個很重要目標，就是要無感知升級系統模塊。 汽車的備用輪胎也可以提升汽車可用性，但汽車爆胎後，需要換輪胎的時間，這個可用級別上不去。 而微服務，把功能拆分成小服務，可以通過技術手段，無感知的升級。
• 服務治理都會包含服務監測、預警功能。當服務錯誤率達到一定閾值， 很可以報警或開啟限流、服務降級、熔斷等策略，把影響降低到最小。
• 微服務架構中，通常會在在 Gateway 層，甚至 Service、Dao 層 設置限流措施。當流量大於預期時，開啟防禦手段。 也有一些彈性擴容的設定，當流量大於閾值時，自動擴展服務，應對突發流量，這個過程甚至不用人工參與。
• 系統延遲或相應時間，也會在服務監測平台設置相應指標，超過閾值時，啟動相關服務降級、限流、熔斷等策略。

註：個人理解，其實微服務、Kubernetes 等，很大一部分功能都是為了應對 SLA 的智能化擴展。

6. 架構設計常用手段

相信大多數人都認同，與其說架構是設計出來的，不如是說抄襲或拼裝而成的。所以我們需要熟悉常用的手段或成熟的框架來解決日常工作中的問題。每個架構師工作經歷不同、應對過的業務系統不同、興趣點不同，手頭的彈藥庫也不同。我列舉一些自己認為重要的知識點或框架。（前端太久沒接觸，只列舉後端，大多以微服務為例，後續文章有機會展開探討）

業務處理相關技術點和框架

單機：高性能、高並發手段相關 1. 單機高性能手段：可以上網查詢 C10K 問題，獲取相關文章。把進程、線程、池、IO 多路復用相關知識點弄清楚。 2. 分清楚 IO 密集型和 CPU 密集型場景：一般互聯網應用多為 IO 密集型。但是類似：滴滴出行、股市量化投資、在線遊戲之類，屬於 IO 密集型和 CPU 密集型並存的場景，甚至對響應時間要求也很高。 幸好大多數 CPU 密集型應用也是多租戶、區域獨立性架構，容易擴展拆分。 3. 程序訪問存儲介質或鏈路快慢： 程序肯定要與存儲進行消息交換。一定明白，CPU 高速存儲器、內存、SSD 硬盤、機械硬盤、同交換機網絡、同機房網絡、同城網絡、同運營商網絡等。細節展開很多內容，包含緩存、CDN、多機房等，從細節編程到部署架構的知識點。

集群：高性能、高並發相關

1. 負載均衡反向代理：其實把 Nginx 了解就可以了。如果是初創小公司，基本使用雲上 SLB 負載均衡(Server LoadBalancer)就可以， 如果需要自建機房，有專門運維負責這些工作，到時候補補 LVS、F5 相關技術即可。

2. 服務無狀態：以微服務為例來說，服務無狀態會帶來太多的好處，擴展冗餘部署服務會很方便。不談微服務，就說前後端分離，鑒權這塊 token 的實現，其實根本目的也是把用戶狀態剝離出來，實現服務的無狀態化。 （提個小插曲，估計老人才了解 J2EE EJB 規範，當初居然專門設計了一個 sessionBean 有狀態的服務規範）。

3. 任務（服務）拆分：可以理解為服務拆解、功能拆解。其實拆分準則很多，可以按照實際需求來權衡。比如：按照人頭分、按照功能劃分、按照數據庫表劃分、按照功能重要性劃分、按照功能訪問頻度劃分。 不過，水平按照 Gateway、邏輯層、數據層、存儲層算基本規範了。

4. 常用的語言及框架：了解語言特性，如 Node 語言的快速開發、前後端語言一致帶來的便利、多路復用回調的原生支持等；go 語言「goroutines」特性帶來的編程便利；Java 優秀的生態及開源框架；C++性能優勢等。當然技術選型，跟團隊及業務成熟度很大關係。

5. 緩存：分佈式緩存是提升系統性能利器。基本掌握 Redis 即可，需要知曉 Codis 和 Redis 官方集群部署方式。

6. 消息隊列：消息隊列也是常用提升系統性能利器，如業務邏輯異步化、削峰、解耦等。熟悉 Kafka、RocketMQ即可。

高可用手段（集群）：

高可用手段核心解決思路是冗餘部署，同樣的服務冗餘多份，會帶來服務出錯通知、服務自動切換、容錯等一系列問題。高可用的實現更有技術含量，現在微服務框架服務治理組件，很多在高可用上做創新突破。（高性能冗餘部署為了擴展節點，帶來更高的處理性能）

1. 服務無狀態：當某個服務故障時，自動切換到新的服務，不用產生狀態丟失等問題。

2. 調用方支持超時、重試配置：由於網絡抖動等原因，某個服務可能某次調用不可用，調用方需要重試重新調用。當然超時是調用方通用遇到的故障之一，也會有在其它故障發生，然後發起重試的配置。

3. 被調用方需要冪等支持：顯而易見，無論是重試、還是調用方自動切換到的新的服務， 被調用方服務冪等支持的必備的。

4. 服務狀態監測：所有服務都可用，那是理想情況。當某個服務發生故障時，整個體系必須知道這個服務有問題了，重試調用多少次也不會成功了。按照微服務框架來說，需要兩方知道這個信息：1、服務註冊組件。2、服務上游調用方。當然報警讓運維技術恢復是常規。

5. 服務狀態通知：按照微服務架構，服務的狀態 在註冊中心都會體現。但是註冊中心跟服務之間一般是通過心跳來檢測的，有時間延時。 另外，服務調用方會緩存註冊中心數據，其中就包含服務狀態。 所以說，從註冊中心獲取服務狀態，是有延時，可能會造成很多無效的請求。 高效的服務狀態機制，很難組件化框架化， 所以這塊需要高性能、較實時的自研通信機制或高性能集中存儲機制保證。具體可以留言討論或後續文章探討。

6. 調用方智能路由：除了負載均衡以外，當調用方 A1 知曉下游服務 C1 故障後，可以自動切換到 C2 等服務上。 另外，通過服務狀態通知機制，最好可以告訴 A2、A3，C1 服務故障了，你們別去嘗試了。

7. 服務故障恢復有，狀態通知機制：這部分就比較簡單了。註冊中心狀態變化後，調用方會慢慢更新註冊中心元數據，來獲取最新狀態。 當時，如果有更實時的消息機制，時效性會更高。

系統可靠性（犧牲少部分可容忍體驗，降低問題到最低）

8. 服務（功能）分類：不管是微服務框架也好，單體框架也好，架構師必須對功能、服務進行分類。分類維度很多，比如：重要程度、QPS 量級、是否可以降級停止等等。

9. 應用限流：對於一般規模的應用，在 Gateway 層做即可，從源頭保護整個應用。對於超大應用（個人沒經驗），我覺得架構會更加複雜，可能 Gateway 會分為很多層或多個，甚至有業務中台，層次會更複雜。

10. 服務降級：服務是在服務分類的基礎上的。比如：百度貼吧的發帖功能，信息流廣告功能，緊急情況下是可以降級處理的。可以人工或自動執行。其實 限流也是一種特殊的服務降級。（服務可以是個功能、也可以是接口，就看團隊內如何達成一致）

11. 接口熔斷：熔斷一般在接口方法級別，因為調用鏈路很長，容易引起調用雪崩。讓某個接口方法出現問題，我們可以按照預定配置處理業務，快速返回預設結果，防止整個鏈路的奔潰。

12. 彈性擴容：彈性擴容是理想的智能運維，但是具體操作也做大廠才會做相關工作。例如新年紅包業務，雙十一電商業務，秒殺業務，明星結婚對新浪微博的影響等，這些可以預知或未知的突發流量，如果系統可以自動擴容，那將很是完美。其實很多當前 Docker + kubernetes 的使用案例，還只是方便運維工作量，對彈性擴容這塊實踐感覺不是很好。

存儲相關：

1. 關係型數據庫：傳統的 MySQL 數據需要掌握。如果做互聯網業務，對分庫分表肯定有需求，關注 NewSQL，如 TiDB，可以避免分庫分表的麻煩。

2. NoSQL 存儲：Elasticsearch、MongoDB至少掌握一個。筆者對 Elasticsearch 還是比較看好，綜合性 文檔數據、列式存儲、反向索引 都支持，社區生態也很不錯。

3. 大數據數據庫：強烈建議熟悉 HDFS + HBase + openTSDB。如果熟悉時序數據庫 openTSDB 設計以後，對了解各個監控系統如 OpenFalcon 有很大的幫助。基本自研監控系統也難度不是特別大了。

4. 內存數據庫：有些特殊應用使用內存數據會事半功倍。Redis 提供豐富的數據結構及良好特性，並且有很多插件，巧妙使用可以降低業務代碼複雜度。

5. 消息隊列：消息隊列也有存儲機制，使用得當，也可以當成存儲介質使用。例如：kappa 架構、RocketMQ 事務消息支持等。

註：存儲相關其實只是中間件的學習，自研或改造幾率機會還是比較少。

最佳實踐：

筆者強烈建議架構師研究商業化廣告系統的架構，有心得也可以與我交流。廣告系統涵蓋知識點很多，如：高並發、高性能的廣告引擎；倒排索引的廣告定向召回；流計算計費系統；批處理反作弊大數據處理系統；大數據DMP用戶設備畫像系統；點擊率預測機器學習、深度學習方向；adx + ssp + dsp 之間跨公司、跨系統間通信調用；頻次控制等需要的緩存系統設計；交易相關資金方面的處理等等。

7. 提升認知

每個架構師都夢想架構世界，設計未來。可惜當你真正有能力或有義務為社會做點貢獻時候，往往忘了初心或體力有限。所以年輕時候，精力充沛時候，往往經驗能力有限，年輕時候過度設計都會經歷，為了可擴展性、可重用、預防需求變更做這樣那樣的設計。前文互聯網思維-迭代思維中也講到，世事萬物都是在變化的。無論我們如何封裝變化、兼容變化，都有個刻度。變化始終要面對，一勞永逸是不可能的， 好的設計模式本身就是封裝變化、應對變化的最佳實踐。

筆者在多元視角看問題章節也提到過，學會用時間線眼光看待問題。這裡很是適用，刻意練習自己多元視角思維，可能會找到事物發展的趨勢或固有軌跡。如果你能夠把我企業內部、業內流行架構趨勢，或推動架構演進的企業內部業務發展趨勢， 做架構方面取捨時，可能會有更加全面的考慮，從而設計出擴展性更好的架構。

註：當然，做任何事情也是如此，順勢而為。

8. THIS IS NOT THE END

《道生一，一生二，二生三，三生萬物》出自老子的《道德經》第四十二章，是老子的宇宙生成論。這裡老子說到「一」、「二」、「三」，乃是指「道」創生萬物的過程。主要講述了一、二、三這幾個數字，並不把一、二、三看作具體的事物和具體數量。它們只是表示「道」生萬物從少到多，從簡單到複雜的一個過程。

我們對任何事物的認知，尤其用文字表達出來，都是「一」、「二」、「三」這幾個數字，而它們不代表具體事物和數量，就和這篇文章一樣，只是思考的開始或過程，無法代表特定結論。

作者介紹：張凱江，低調的骨灰級架構師。