BAT/TMD大廠單元化架構設計衍變之路分享

• 隨著大型互聯(lián)網(wǎng)公司業(yè)務的多元化發(fā)展，就拿滴滴纠亚、美團等大廠來講塘慕，如滴滴打車、單車蒂胞、外賣图呢、酒店、旅行骗随、金融等業(yè)務持續(xù)高速增長岳瞭，單個大型分布式體系的集群，通過加機器+集群內部拆分（kv蚊锹、mq瞳筏、Mysql等），雖然具備了一定的可擴展性牡昆。但是姚炕，隨著業(yè)務量的進一步增長摊欠，這個集群規(guī)模琢漸變的巨大，從而一定會在某個點達到瓶頸柱宦，無法滿足擴展性需要些椒，并且大集群內核服務出現(xiàn)問題，會影響全網(wǎng)所有用戶掸刊。

• 以滴滴打車免糕、美團外賣舉例來說：
  打車業(yè)務體量巨大，尤其在早晚高峰期忧侧。全年訂單量已越10億石窑。
  外賣業(yè)務體量龐大，目前單量突破1700w/天蚓炬，對應如此龐大的單個大型分布式集群松逊，會面臨一下問題：

  1. 容災問題
  2. 資源擴展性問題
  3. 大集群拆分問

• 容災問題
  核心服務（比如訂單服務）掛掉，會影影響全網(wǎng)所有的用戶肯夏，導致整個業(yè)務不可用经宏；
  數(shù)據(jù)庫主庫集中在一個IDC，主機房掛掉驯击，會影響全網(wǎng)所有用戶烁兰，整個業(yè)務無法快速切換和恢復

• 資源擴展問題
  單IDC的資源（機器、網(wǎng)絡帶寬等）已經(jīng)沒法滿足徊都，擴展IDC時沪斟，存在跨機房訪問延時問題（增加異地機房，時延問題嚴重）碟贾；
  數(shù)據(jù)庫主庫單點币喧，連接數(shù)有限，不能支持應用程序的持續(xù)發(fā)展袱耽；

• 大集群拆分問題
  核心問題：分布式集群規(guī)模擴大后杀餐，會響應的帶來資源擴展、大集群拆分以及容災問題
  所有處于對業(yè)務擴展性以及容災需求的考慮朱巨，我們需要一套從底層架構徹底解決問題的方案史翘，業(yè)界主流解決方案：

SET單元化架構方案（阿里、支付寶冀续、餓了么琼讽、微信等）

• 同城 "雙活" 架構介紹
  目前很多大型互聯(lián)網(wǎng)公司的業(yè)務架構可以理解為同城"雙活"架構，注意這里的“雙活"是加引號的洪唐，具體可以這樣理解：

  1. 業(yè)務層面上已經(jīng)做到的真正的雙活（或者多活）钻蹬，分別承擔部分流量；
  2. 存儲層面比如定時任務凭需、緩存问欠、持久層肝匆、數(shù)據(jù)分析等都是主從架構，會有跨機房寫的問題顺献；
  3. 一個數(shù)據(jù)中心故障旗国，可以手動切換流量，部分組件可以自動切換注整；

• 兩地三中心架構介紹

  使用災備的思想能曾，在同城“雙活”的基礎上，在異地部署一套災備數(shù)據(jù)中心肿轨，每個中心都具有完備的數(shù)據(jù)處理能力寿冕，只有當主節(jié)點故障需要容災時才會緊急啟動備用數(shù)據(jù)中心；

  
  

• SET化方案目標:
  業(yè)務：解決業(yè)務遇到的擴展性和容災等需求萝招，支撐業(yè)務的高速方案
  通用性：架構側形成統(tǒng)一通用的解決方案蚂斤，方面各業(yè)務線接入使用

SET化架構設計：

SET化架構策略

流量路由：

• 按照特殊的key（通常為userid）進行路由存捺，判斷某次請求該路由到中心集群還是單元化集群槐沼；

中心集群：

• 為進行單元化改造的服務（通常不在核心交易鏈路，比如供應鏈系統(tǒng)）稱為中心集群捌治，跟當前架構保持一致岗钩。

單元化集群：

• 每個單元化集群只負責本單元內的流量處理，以實現(xiàn)流量拆分以及故障隔離肖油；
• 每個單元化集群前期只存儲本單元產生的交易數(shù)據(jù)兼吓，后續(xù)會做雙向數(shù)據(jù)同步，實現(xiàn)容災切換需求森枪；

中間件（RPC视搏、KV、MQ等）：

• RPC：對于SET服務县袱，調用封閉在SET內浑娜；對于非SET服務，沿用現(xiàn)有的路由邏輯式散；
• KV：支持SET的數(shù)據(jù)生產和查詢筋遭；
• MQ：支持分SET的消息生產和消費；

數(shù)據(jù)同步：

• 全局數(shù)據(jù)（數(shù)據(jù)量小且變化不大暴拄，比如商家的菜品數(shù)據(jù)）部署在中心集群漓滔，其他單元化集群同步全局數(shù)據(jù)到本單元化內；
• 未來演變?yōu)楫惖囟嗷罴軜嫊r乖篷，各單元化集群數(shù)據(jù)需要進行雙向同步來實現(xiàn)容災需要

異地容災：

• 通過SET化架構的流量調度能力响驴，將SET分別部署在不同地區(qū)的數(shù)據(jù)中心，實現(xiàn)跨地區(qū)容災支持

高效的本地化服務：

• 利用前端位置信息采集和域名解析策略撕蔼，將流量路由到最近的SET豁鲤，提供最高效的本地化服務石蔗；
• 比如O2O場景天然具有本地生產，本地消費的特點畅形，更加需要SET化支持

集裝箱擴展：

• SET的封裝性支持更靈活的部署擴展性养距，比如SET一鍵創(chuàng)建/下線，SET一鍵發(fā)布等日熬。

SET化架構

SET化架構落地原則

• 對業(yè)務透明原則：
  SET化架構的實現(xiàn)對業(yè)務代碼透明棍厌，業(yè)務代碼層面不需要關系SET化規(guī)則，SET的部署等問題

• SET化切分的規(guī)則：
  理論上竖席，切分規(guī)則有業(yè)務層面按需定制耘纱；
  實際上，建議優(yōu)先選最大的業(yè)務維度進行切分毕荐；
  比如海量用戶的O2O業(yè)務束析，按用戶位置信息進行切分。此外接入層憎亚、邏輯層和數(shù)據(jù)層可以由獨立的SET切分規(guī)則员寇，有利于實現(xiàn)部署和運維成本的最優(yōu)化

• 部署規(guī)范原則：
  一個SET并不一定只限制在一個機房，也可以跨機房或者跨地區(qū)部署第美；為保證靈活性蝶锋，單個SET內機器數(shù)不宜過多（如不超過1000臺物理機）。

RabbitMQ-SET化架構實現(xiàn)

• SET化消息中間件架構實現(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關系的Exchange载佳，也就是有實際的物理Queue來接收消息，才會從Upstream拉取消息到Downstream臀栈。使用AMQP協(xié)議實施代理間通信蔫慧，Downstream會將綁定關系組合在一起，綁定/解綁命令將發(fā)送到Upstream交換機权薯。

  • 第二姑躲，經(jīng)過配置后睡扬，Upstream節(jié)點已經(jīng)可以把消息直接通過Federation Exchanges路由給我們的Downstream節(jié)點，然后進行消費黍析。

    也就是說可以實現(xiàn)消息的轉發(fā)卖怜，接下來也可以在Upstream添加具體的隊列去進行消費Federation Exchanges里的消息，我們一條消息分別發(fā)送到2個RabbitMQ集群并且消費阐枣，這樣我們可以實現(xiàn)SET化的關鍵要素马靠，就是集群間的消息同步了。

  • 第三蔼两，可以根據(jù)自己的業(yè)務規(guī)則去規(guī)劃不同的集群去監(jiān)聽不同的消息隊列甩鳄，從而達到SET化的手段，保障了性能额划、可靠性妙啃、數(shù)據(jù)一致性。