互聯網大廠單元化架構設計衍變之路
隨着業務的多元化發展，拿滴滴，美團等大廠來說，如滴滴打車，外賣，酒店，旅行等持續高速增長，單個大型分佈式的集羣，通過機器+集羣內部拆分，雖然具備了一定的可擴展性。但隨着業務量的進一步增長，整個集羣規模主鍵變得巨大，從而會在某個點達到瓶頸，無法滿足擴展性需要，並且大集羣內核心服務出現了問題，會影響全網用戶
以滴滴打車、美團外賣舉例：
打車業務量巨大，尤其是早晚高峯。全年訂單已越10億
外賣業務量龐大，目前單量突破1700w/天
面臨問題
容災問題
核心服務（比如訂單服務）掛掉，會影響全網所有用戶，導致整個業務不可用
數據庫主庫集中在一個IDC，主機房掛掉，會影響全網所有用戶，整個業務無法快速切換和恢復
資源擴展問題
單IDC的資源（機器、網絡帶寬等）已經無法滿足，擴展ICD時，存在跨機房訪問時延問題（增加異地機房時，時延問題更加嚴重）
數據庫主庫單點，連接數有限，不能支持應用程序的持續擴展
大集羣拆分問題
分佈式集羣規模開大後，會相應的帶來資源擴展、大集羣拆分及容災問題
所以對業務擴展及容災需求考慮，我們需要一套從底層架構徹底解決問題的方案，業界主流解決方案：單元化架構方案（阿里、支付寶、餓了麼、微信 等）
SET化方案目標
業務：解決業務遇到的擴展性和容災問題，支撐業務的高速發展
通用性：架構側形成統一通用的解決方案，方便個業務線接入使用
SET化架構設計
解決容災問題：
UnitA一套業務的核心組件，比如網購，從加入購物車到下單，經過A、B、C、D等步驟，全部部署到UnitA的一個機房中，UnitB和UnitC是UnitA的備份，如果UnitA的服務或MQ發生故障，就會路由到UnitB或UnitC中
非核心的業務組件部署到center中
解決擴展問題：
UnitA可以是旅遊，UnitB可以是外賣，將來還可以擴展
相關概念
流量路由：按照特殊的key（通常爲userid）進行路由，判斷某次請求該路由到中心集羣還是單元化集羣
中心集羣：爲進行單元化改造的服務（通常不在覈心交易鏈路）成爲中心集羣，跟當前架構保存一致
單元化集羣：
每個單元化集羣只負責本單元內的流量處理，以及實現流量拆分及故障隔離
每個單元化集羣前期只存儲本單元產生的交易數據，後續會做雙向數據同步，實現容災切換需求
中間件（RPC、KV、MQ等）
RPC：對於SET服務，調用封閉在SET內；對於非SET服務，沿用現有路由邏輯
KV：支持分SET的數據產生和查詢
MQ：支持分SET的消息生產和消費
數據同步
全局數據（數據量小且變化不大，比如商家的菜品數據）部署在中心集羣，其他單元化集羣同步全局數據到本單元化內
未來演變爲異地多活架構時，各單元化集羣數據需要進行雙向同步來實現容災需要
SET化路由策略及其能力
異地容災：
通過SET化架構的流量調度能力，將SET分別部署到不停地區的數據中心，實現跨地區容災支持
高效本地化服務
利用前端位置信息採集和域名解析策略，將流量路由由最近的SET，提供最高效的本地化服務
比如O2O場景天然具有本地生產，本地消費的特點，更加需要SET化支持
集裝箱式擴展
SET的封裝性支持更靈活的部署擴展性，比如SET一鍵創建/下線，SET一鍵發佈等（比如docker）
C不是很重要，所以放到中心集羣，需要的時候去中心集羣調用
中心集羣A可以通過路由服務同單元的Set服務
Set3中B如果調用不到本單元的C（本單元優先級最高），可以通過路由服務調用Set2中的C
SET架構原則
對業務的透明原則：
SET架構的實現業務代碼透明，業務代碼層面不需要關心SET化規則，SET部署的問題
SET切分規則：
理論上，切分規則由業務層面按需定製
實現上，建議優先選最大的業務維度進行切分
比如海量用戶的O2O業務，按用戶位置信息進行切分。此外接入層、邏輯層和數據層可以有獨立的SET切分規則，有利於實現部署和運維成本的最優化
部署規範原則：
一個SET並不一定只限制在一個機房，也可以跨機房或者跨地區部署；爲保證靈活性，單個SET內機器數不宜過多（如不超過1000臺物理機）