四個架構設計案例分析及其背後的架構師思維
接收程序員的技術早餐
作者｜楊波
編輯｜Linda
寫在前面
架構的本質是管理複雜性，抽象、分層、分治和演化思維是我們工程師 / 架構師應對和管理複雜性的四種最基本武器。
小型系統案例：分散式消息系統
這個是一個真實生產化的消息系統案例，由 1 個架構師 +2 個高級工程師設計開發，第一期研發測試到上生產約 3 個月，目前該系統日處理消息量過億。
假定公司因為業務需要，要構建一套分散式消息系統 MQ，類似 Kafka 這樣的，這個問題看起來很大很複雜，但是如果你抽絲剝繭，透過現象看本質，Kafka 這樣的消息系統本質上是下圖這樣的抽象概念：
隊列其實就是類似數組一樣的結構（用數組建模有個好處，有索引可以重複消費），裡頭存放消息 (Msg)，數組一頭進消息，一頭出消息；
左邊是若干生產者 (Producer)，往隊列裡頭發消息；
右邊是若干消費者 (Consumer)，從隊列裡頭消費消息；
對於生產者和消費者來說，他們不關心隊列實現細節，所以給隊列一個更抽象的名字，叫主題 (Topic)；
考慮到系統的擴容和分散式能力，一般一個主題由若干個隊列組成，這些隊列也叫分區 (Partition)，而且這些隊列可能還是分布在不同機器上的，例如下圖中 Topic A 的兩個隊列分布在 DataNode1 節點上，另外兩個隊列分布在 DataNode2 節點上，這樣以後 Topic 可以按需擴容，DataNode 也可以按需增加。當然這些細節由 MQ 系統屏蔽，用戶只關心主題，不關心底層實現。
單個數組隊列的建模是整個 MQ 系統的關鍵，我們知道 Kafka 使用 append only file 建模隊列，存取速度快。假設我們要存業務數據需要更高可靠性，也可以用資料庫表來建模數組隊列，如下圖所示：
一個隊列 (或者一個分區) 對應一張資料庫表，表中的一個記錄就是一條消息，表採用自增 id，相當於數組索引。這張表是 insert only 的，且 MySQL 會自動對自增 id 建優化索引，沒有其它索引，所以插入和按 id 查找速度都非常快。
下面是總體元數據模型：
一個主題 Topic 對應若干個隊列 Queue
一個數據節點 DataNode 上可以住若干個隊列 Queue
消費者 Consumer 和隊列 Queue 之間是多對多關係，通過消費者偏移 Consumer Offset 進行關聯
一個消費者組 Consumer Group 裡頭有若干個消費者 Consumer，它們共同消費同一個主題 Topic
至此，我們對 MQ 的抽象建模工作完成，下面的工作是將這個模型映射到具體實現，經過分解，整個系統由若干個子模塊組成，每個子模塊實現後拼裝起來的 MQ 總體架構如下圖所示：
Admin 模塊管理資料庫節點，生產者，消費者 (組)，主題，隊列，消費偏移等元數據信息。
Broker 模塊定期從 Admin 資料庫同步元數據，接受生產者消息，按路由規則將消息存入對應的資料庫表 (隊列) 中；同時接受消費者請求，根據元數據從對應資料庫表讀取消息並發回消費者端。Broker 模塊也接受消費者定期提交消費偏移。
Producer 接受應用發送消息請求，將消息發送到 Broker；
Consumer 從 Broker 拉取消息，供上層應用進一步消費；
客戶端和 Broker 之間走 Thrift over HTTP 協議，中間通過域名走 Nginx 代理轉發；
這個設計 Broker 是無狀態，易於擴展。
架構思維總結：
整個架構設計的思路體現了先總體抽象，再分解按模塊抽象並實現，最後組合成完整的 MQ 系統，也就是抽象 + 分治。這個 MQ 的實現工作量並不大，屬於小型系統範疇，初期設計和開發由 1 個架構師 +2 個中高級工程師可以搞定。
在初期研發和上生產之後，根據用戶的不斷反饋，系統設計經過多次優化和調整，符合三分架構、七分演化的演化式架構理念。目前該系統已經進入 V2 版本的架構和研發，其架構仍在持續演化當中，用戶需求的多樣性和對系統靈活性的更高要求，是系統架構演化的主要推動力。
中型系統案例：容器雲平台架構設計
這個也是一個實際研發中的案例。
目前不少技術組織在往 DevOps（研發運維一體化）研發模式轉型，目標是支持業務持續創新和規模化發展。支持 DevOps 的關鍵是需要一套 DevOps 基礎平台，這個平台可以基於容器雲構建，我們把它稱為容器雲平台。這個問題很大很複雜，我基於近年在一線互聯網的實戰經驗積累 + 廣泛調研，設計了如下容器雲平台的總體抽象架構：
核心模塊：
集群資源調度平台：屏蔽容器細節，將整個集群抽象成容器資源池，支持按需申請和釋放容器資源，物理機發生故障時能夠實現自動故障轉移 (fail over)。目前基於 Mesos 實現，將來可考慮替換為 K8S。
鏡像治理中心：基於 Docker Registry，封裝一些輕量的治理功能，例如許可權控制，審計，鏡像升級流程（從測試到 UAT 到生產）治理和監控等。
租戶資源治理中心：類似 CMDB 概念，在容器雲環境中，企業仍然需要對應用 app，組織 org，容器配額 quota 等相關信息進行輕量級的治理。
發布控制台：面向用戶的發布管理平台，支持發布流程編排。它和其它子系統對接交互，實現基本的應用發布能力，也實現如藍綠，金絲雀和灰度等高級發布機制。
服務註冊中心：類似 Netflix Eureka，支持服務的註冊和發現，流量的拉入拉出操作。
網關：類似 Netflix Zuul 網關，接入外部流量並路由轉發到內部的微服務，同時實現安全，限流熔斷，監控等跨橫切面功能。
核心流程：
用戶或者 CI 系統對應用進行集成後生成鏡像，將鏡像推到鏡像治理中心；
用戶在資產治理中心申請發布，填報應用、發布和配額等相關信息，然後等待審批通過；
發布審批通過，開發人員通過發布控制台發布應用；
發布控制台通過查詢資產治理中心獲取發布規格信息；
發布控制台向容器資源調度平台發出啟動容器實例指令；
容器資源調度平台從鏡像治理中心拉取鏡像並啟動容器；
容器內服務啟動後自註冊到服務註冊中心，並保持定期心跳；
用戶通過發布控制台調用服務註冊中心介面進行流量調撥，實現藍綠，金絲雀或灰度發布等機制；
網關和內部微服務客戶端定期同步服務註冊中心上的路由表，將流量按負載均衡策略分發到服務實例上。
架構思維總結：
經過抽象梳理，我們已經得到最終容器雲平台的 6 大關鍵抽象模塊和模塊間交互流程，下一步就是圍繞這 6 大核心模塊組織 6 個小的研發團隊，每個團隊負責一個模塊的設計和實現，待每個團隊完成各自的模塊，再將所有模塊組合拼裝起來，就能最終產出我們需要的容器雲平台產品。整體架構設計思路還是抽象 + 分治，只不過每個模塊的抽象粒度更大，整個平台的規模也更大，需要投入的研發團隊資源也更多，對架構師的抽象能力要求也更高。每個模塊的技術負責人在研發各自的模塊時，同樣遵循抽象 + 分治的思維方式，先做抽象架構，劃分子模塊，安排組員實現子模塊，最後拼裝組合成完整模塊。
由於這個平台規模較大較複雜，目前已經投入了近兩個季度的時間，做第一期架構設計和研發，目前還沒有完全生產化。在第一期過程中，隨著對問題域的理解不斷深入，架構設計經過多次調整，目前架構趨於穩定，已經進入預上線期。在後續生產落地過程中，仍然需要根據用戶的反饋，藉助進化的力量不斷地調整和優化架構。這個符合演化式架構的思路。
大型系統案例：微服務基礎架構
微服務架構是近年很多企業技術架構轉型的趨勢，實際上，微服務架構可以抽象分解為一個兩層架構：上層是微服務業務架構，下層是微服務基礎架構。上層業務架構由於每個企業的業務場景各不相同，所以一般很難通用化，大多企業都是定製自研。而下層基礎架構由於近年業界實踐的不斷沉澱，已經比較通用化和模塊化，其中的核心模塊一般不需要自己重造輪子，重用那些在一線互聯網公司已經落地並開源出來的產品就可以了。
Netflix 是一家偉大的科技公司，它內部的基礎架構團隊很牛，或者說抽象能力非常強，把一些核心微服務基礎組件都以模塊化方式開源出來了，使得其它公司只需組合拼裝這些組件就可以快速搭建微服務架構，可以說 Netflix 將整個行業的技術水平提升了一個層次。
我近期和極客時間合作，開設了一門叫《微服務架構實戰 160 講》的視頻課程，這門課程基於我近年在一線互聯網公司（攜程和拍拍貸）落地微服務基礎架構的實戰經驗和總結。該課程為大家深度剖析微服務 8 大核心模塊的架構和實踐，以及如何使用這些模塊，採用抽象 + 分治的架構思維，像搭積木一樣輕鬆構建微服務基礎架構，歡迎大家訂閱學習。
《微服務架構實戰 160 講》中涉及的 8 大模塊包括
服務認證授權中心 Spring Security OAuth2
服務配置中心 Apollo
服務調用鏈監控 CAT
服務網關 Zuul
服務限流熔斷 Hystrix/Turbine
服務註冊發現和軟路由 Eureka/Ribbon
服務時間序列監控 KairosDB
服務監控告警 ZMon
整體拼裝起來的微服務基礎架構如下圖所示，這個架構是經過實踐落地的，可以作為一線企業搭建微服務基礎架構的參考：
技術體系架構案例
在企業的整個技術體系架構層面，最基本的思考方式還是抽象 + 分治，只不過問題域更大更複雜，還涉及到組織和業務架構，所以一般還要增加分層的維度來解決，下圖是 2016 年的 eBay 技術體系架構（圖片來自文末參考鏈接）：
我最早看到這個架構圖是在 2008 年左右的一次 all hands meeting 上（當時我還在 eBay 中國研發中心做工程師），也就是說大致在 2008 年左右，eBay 就已經有比較清晰的，以分層方式組織的技術體系架構。eBay 當時把它的系統稱為電子商務操作系統，因為據說整個系統的代碼量超過 Windows 7 操作系統的代碼量。
eBay 架構分為清晰的四個抽象層次：
Infrastructure：底層基礎設施，包括雲計算，數據中心，計算 / 網路 / 存儲，各種工具和監控等，國內公司一般把這一層稱為運維層。
Platform Services：平台服務層，主要是一些框架中間件服務，包括應用和服務框架，數據訪問層，表示層，消息系統，任務調度和開發者工具等等，國內公司一般把這一層稱為基礎框架或基礎架構層。
Commerce Services：電商服務層，eBay 作為電子商務平台多年沉澱下來的核心領域服務，相當於微服務業務層，包括登錄認證，分類搜索，購物車，送貨和客服等等。
Applications：應用層，也稱用戶體驗 + 渠道層，包括 eBay 主站，移動端 app，第三方接入渠道等。
我本人在吸收了 eBay 技術體系架構的基礎上，也吸收了一些阿里巴巴中台戰略的思想，同時融合近年的一些業界趨勢（比如大數據 /AI），抽象出一個更通用的分層技術體系架構，可以作為互聯網公司技術體系架構的一般性參考，如下圖所示：
順便提一下，近年阿里提出的所謂大中台，小前台戰略，其實就要強化技術中台 + 業務中台，中台做大做強了，業務前台才可以更輕更靈活的響應業務需求的變化。
寫在最後
架構的本質是管理複雜性，抽象、分層、分治和演化思維是架構師征服複雜性的四種根本性武器。
掌握了抽象、分層、分治和演化這四種基本的武器，你可以設計小到一個類，一個模塊，一個子系統，或者一個中型的系統，也可以大到一個公司的基礎平台架構，微服務架構，技術體系架構，甚至是組織架構，業務架構等等。
架構設計不是靜態的，而是動態演化的。只有能夠不斷應對環境變化的系統，才是有生命力的系統。所以即使你掌握了抽象、分層和分治這三種基本思維，仍然需要演化式思維，在完成系統的初步架構設計之後，後續藉助反饋和進化的力量推動架構的持續演進。
架構師在關注技術，開發應用的同時，需要定期梳理自己的架構設計思維，積累時間長了，你看待世界事物的方式會發生根本性變化，你會發現我們生活其中的世界，其實也是在抽象、分層、分治和演化的基礎上構建起來的。另外架構設計思維的形成，會對你的系統架構設計能力產生重大影響。可以說對抽象、分層、分治和演化掌握的深度和靈活應用的水平，直接決定架構師所能解決問題域的複雜性和規模大小，是區分普通應用型架構師和平台型 / 系統型架構師的一個分水嶺。
參考資料
MicroServices at eBay
https://www.slideshare.net/kasun04/microservices-at-ebay
課程推薦
無論你是程序員還是架構師，如果想提升自己在微服務架構方面的綜合能力，以便在未來邁入架構師行列或者成為更優秀的架構師，歡迎來學習我和極客時間合作的推出的《微服務架構實戰 160 講課程》。
今天是最後一天優惠期，明天就將恢復原價，現在訂閱即享雙重福利：
福利一：限時優惠價￥199，原價 ￥299（明天恢復原價），新用戶還可享受 30 元立減優惠。
福利二：每邀請一位好友購買，你可獲得 36 元現金返現，同時好友可獲得 15 元現金返現。多邀多得，上不封頂，立即提現（提現流程：極客時間公眾號 - 我的 - 現金獎勵提現）
如何訂閱：
TAG:InfoQ |