BAT/TMD大廠單元化架構(gòu)設(shè)計衍變之路分享
隨著大型互聯(lián)網(wǎng)公司業(yè)務(wù)的多元化發(fā)展，就拿滴滴、美團等大廠來講，如滴滴打車、單車、外賣、酒店、旅行、金融等業(yè)務(wù)持續(xù)高速增長，單個大型分布式體系的集群，通過加機器+集群內(nèi)部拆分（kv、mq、Mysql等），雖然具備了一定的可擴展性。但是，隨著業(yè)務(wù)量的進一步增長，這個集群規(guī)模琢漸變的巨大，從而一定會在某個點達到瓶頸，無法滿足擴展性需要，并且大集群內(nèi)核服務(wù)出現(xiàn)問題，會影響全網(wǎng)所有用戶。
-
以滴滴打車、美團外賣舉例來說：
打車業(yè)務(wù)體量巨大，尤其在早晚高峰期。全年訂單量已越10億。
外賣業(yè)務(wù)體量龐大，目前單量突破1700w/天，對應(yīng)如此龐大的單個大型分布式集群，會面臨一下問題：- 容災(zāi)問題
- 資源擴展性問題
- 大集群拆分問
容災(zāi)問題
核心服務(wù)（比如訂單服務(wù)）掛掉，會影影響全網(wǎng)所有的用戶，導(dǎo)致整個業(yè)務(wù)不可用；
數(shù)據(jù)庫主庫集中在一個IDC，主機房掛掉，會影響全網(wǎng)所有用戶，整個業(yè)務(wù)無法快速切換和恢復(fù)資源擴展問題
單IDC的資源（機器、網(wǎng)絡(luò)帶寬等）已經(jīng)沒法滿足，擴展IDC時，存在跨機房訪問延時問題（增加異地機房，時延問題嚴重）；
數(shù)據(jù)庫主庫單點，連接數(shù)有限，不能支持應(yīng)用程序的持續(xù)發(fā)展；大集群拆分問題
核心問題：分布式集群規(guī)模擴大后，會響應(yīng)的帶來資源擴展、大集群拆分以及容災(zāi)問題
所有處于對業(yè)務(wù)擴展性以及容災(zāi)需求的考慮，我們需要一套從底層架構(gòu)徹底解決問題的方案，業(yè)界主流解決方案：
SET單元化架構(gòu)方案（阿里、支付寶、餓了么、微信等）
-
同城 "雙活" 架構(gòu)介紹
目前很多大型互聯(lián)網(wǎng)公司的業(yè)務(wù)架構(gòu)可以理解為同城"雙活"架構(gòu)，注意這里的“雙活"是加引號的，具體可以這樣理解：- 業(yè)務(wù)層面上已經(jīng)做到的真正的雙活（或者多活），分別承擔部分流量；
- 存儲層面比如定時任務(wù)、緩存、持久層、數(shù)據(jù)分析等都是主從架構(gòu)，會有跨機房寫的問題；
- 一個數(shù)據(jù)中心故障，可以手動切換流量，部分組件可以自動切換；
-
兩地三中心架構(gòu)介紹
使用災(zāi)備的思想，在同城“雙活”的基礎(chǔ)上，在異地部署一套災(zāi)備數(shù)據(jù)中心，每個中心都具有完備的數(shù)據(jù)處理能力，只有當主節(jié)點故障需要容災(zāi)時才會緊急啟動備用數(shù)據(jù)中心；
SET化方案目標:
業(yè)務(wù)：解決業(yè)務(wù)遇到的擴展性和容災(zāi)等需求，支撐業(yè)務(wù)的高速方案
通用性：架構(gòu)側(cè)形成統(tǒng)一通用的解決方案，方面各業(yè)務(wù)線接入使用
SET化架構(gòu)設(shè)計：
SET化架構(gòu)策略
流量路由：
- 按照特殊的key（通常為userid）進行路由，判斷某次請求該路由到中心集群還是單元化集群；
中心集群：
- 為進行單元化改造的服務(wù)（通常不在核心交易鏈路，比如供應(yīng)鏈系統(tǒng)）稱為中心集群，跟當前架構(gòu)保持一致。
單元化集群：
- 每個單元化集群只負責(zé)本單元內(nèi)的流量處理，以實現(xiàn)流量拆分以及故障隔離；
- 每個單元化集群前期只存儲本單元產(chǎn)生的交易數(shù)據(jù)，后續(xù)會做雙向數(shù)據(jù)同步，實現(xiàn)容災(zāi)切換需求；
中間件（RPC、KV、MQ等）：
- RPC：對于SET服務(wù)，調(diào)用封閉在SET內(nèi)；對于非SET服務(wù)，沿用現(xiàn)有的路由邏輯；
- KV：支持SET的數(shù)據(jù)生產(chǎn)和查詢；
- MQ：支持分SET的消息生產(chǎn)和消費；
數(shù)據(jù)同步：
- 全局數(shù)據(jù)（數(shù)據(jù)量小且變化不大，比如商家的菜品數(shù)據(jù)）部署在中心集群，其他單元化集群同步全局數(shù)據(jù)到本單元化內(nèi)；
- 未來演變?yōu)楫惖囟嗷罴軜?gòu)時，各單元化集群數(shù)據(jù)需要進行雙向同步來實現(xiàn)容災(zāi)需要
異地容災(zāi)：
- 通過SET化架構(gòu)的流量調(diào)度能力，將SET分別部署在不同地區(qū)的數(shù)據(jù)中心，實現(xiàn)跨地區(qū)容災(zāi)支持
高效的本地化服務(wù)：
- 利用前端位置信息采集和域名解析策略，將流量路由到最近的SET，提供最高效的本地化服務(wù)；
- 比如O2O場景天然具有本地生產(chǎn)，本地消費的特點，更加需要SET化支持
集裝箱擴展：
- SET的封裝性支持更靈活的部署擴展性，比如SET一鍵創(chuàng)建/下線，SET一鍵發(fā)布等。
SET化架構(gòu)落地原則
對業(yè)務(wù)透明原則：
SET化架構(gòu)的實現(xiàn)對業(yè)務(wù)代碼透明，業(yè)務(wù)代碼層面不需要關(guān)系SET化規(guī)則，SET的部署等問題SET化切分的規(guī)則：
理論上，切分規(guī)則有業(yè)務(wù)層面按需定制；
實際上，建議優(yōu)先選最大的業(yè)務(wù)維度進行切分；
比如海量用戶的O2O業(yè)務(wù)，按用戶位置信息進行切分。此外接入層、邏輯層和數(shù)據(jù)層可以由獨立的SET切分規(guī)則，有利于實現(xiàn)部署和運維成本的最優(yōu)化部署規(guī)范原則：
一個SET并不一定只限制在一個機房，也可以跨機房或者跨地區(qū)部署；為保證靈活性，單個SET內(nèi)機器數(shù)不宜過多（如不超過1000臺物理機）。
RabbitMQ-SET化架構(gòu)實現(xiàn)
-
SET化消息中間件架構(gòu)實現(xiàn)（RabbitMQ雙活）：
使用RabbitMQ異步消息通信插件 Federation（節(jié)點和節(jié)點、集群和集群之間通信） 安裝與配置：
安裝插件
rabbitmq-plugins enable rabbitmq_federation
rabbitmq-plugins enable rabbitmq_federation_management
備注：當你再一個cluster鐘使用了federation插件，所有在集群中的 nodes都需要安裝federation插件
使用RabbitMQ通信插件Rederation：
Federation插件是一個在不需要cluster進行數(shù)據(jù)同步的（選擇一個cluster中的節(jié)點和另一個cluster節(jié)點同步），而brokers之間傳輸消息的高新性能插件。Federation插件可以在brokers或者cluster之間傳輸消息，鏈接的雙方可以使用不同的users和virtual hosts、或者雙方的rabbitmq和erlang版本不一致，federation插件使用AMQP協(xié)議通信，可以接受不連續(xù)的傳輸。
-
SET化配置規(guī)則：
第一，F(xiàn)ederation Exchanges，可以看成Downstream(82節(jié)點）從Upstream（81節(jié)點）主動拉取消息，并不是拉取所有消息，必須是在Downstream上已經(jīng)明確定義Bindings關(guān)系的Exchange，也就是有實際的物理Queue來接收消息，才會從Upstream拉取消息到Downstream。使用AMQP協(xié)議實施代理間通信，Downstream會將綁定關(guān)系組合在一起，綁定/解綁命令將發(fā)送到Upstream交換機。
-
第二，經(jīng)過配置后，Upstream節(jié)點已經(jīng)可以把消息直接通過Federation Exchanges路由給我們的Downstream節(jié)點，然后進行消費。
也就是說可以實現(xiàn)消息的轉(zhuǎn)發(fā)，接下來也可以在Upstream添加具體的隊列去進行消費Federation Exchanges里的消息，我們一條消息分別發(fā)送到2個RabbitMQ集群并且消費，這樣我們可以實現(xiàn)SET化的關(guān)鍵要素，就是集群間的消息同步了。
第三，可以根據(jù)自己的業(yè)務(wù)規(guī)則去規(guī)劃不同的集群去監(jiān)聽不同的消息隊列，從而達到SET化的手段，保障了性能、可靠性、數(shù)據(jù)一致性。
