業(yè)界的多機房和單元化架構(gòu)一般是怎么做的

中心機房

除了雙活業(yè)務(wù)外，長尾業(yè)務(wù)以及沒法做多活的業(yè)務(wù)，都在中心機房。

單元機房

為服務(wù)雙機房而新增的機房，用于承接主鏈路雙活流量的機房。

路由

sharding_id作為路由code，雙活系統(tǒng)根據(jù)路由規(guī)則，將請求參數(shù)轉(zhuǎn)換為相應(yīng)的路由code，每個路由code會對應(yīng)中心機房或者單元機房。

網(wǎng)關(guān)層、中間件（如redis、db等分布式存儲）都會根據(jù)路由code將流量路由到目標機房。

路由有三種方式：

- 隨機路由：將流量按照一定比例路由到各自IDC，只需要按照比例路由即可，無需復雜規(guī)則。故障情況下，可以將故障機房的流量切到其他IDC。

- 用戶ID路由：根據(jù)用戶id將流量按照一定的比例路由到各自IDC，每個用戶的操作都會被路由到同一個IDC。故障時，可以將故障機房的流量按照用戶id規(guī)則變化，切換到其他機房即可。

- 地域路由：按照用戶所在地區(qū)的流量按照一定比例路由到同一個機房，每個地區(qū)的用戶操作的流量都會閉環(huán)在指定的IDC下。故障發(fā)生時，可以將故障機房流量按照用戶切換到其他機房即可。

同城雙活

就是在一個城市中雙活部署，部署兩個IDC。

異地雙活

在兩個城市進行雙活部署，每個城市部署一個IDC。

長尾業(yè)務(wù)或?qū)ρ舆t不敏感的業(yè)務(wù)可以發(fā)起遠程調(diào)用，數(shù)據(jù)層做異步復制，采用最終一致性。

異地多活

在多個城市做多活部署，每個城市有一個或多個IDC。

正常來說，同機房優(yōu)先，同地區(qū)優(yōu)先，最后才是異地機房訪問。

同城雙活：

- 優(yōu)點：物理距離短，底層數(shù)據(jù)同步延遲低，rpc接口跨機房調(diào)用延遲低。

- 缺點：雙活災備能力不夠，同城斷電或自然災害，無法雙活。

異地雙活：

- 優(yōu)點：災備相比于同城雙活效果更好，可以做到城市級別容災。

- 缺點：相對于同城物理距離長，底層數(shù)據(jù)同步存在一定的延遲，rpc的跨機房調(diào)用延遲相對較高。

異地多活：

- 優(yōu)點：災備較雙活有一定提升。

- 缺點：多活之間涉及到多個IDC的數(shù)據(jù)同步，數(shù)據(jù)同步的延遲、一致性需要在架構(gòu)層面做冗余考量，導致架構(gòu)設(shè)計及服務(wù)部署相對復雜一些，服務(wù)調(diào)用鏈路變長，存在更高的rpc調(diào)用延遲。

單元化

一個業(yè)務(wù)請求tps達到幾十萬或者幾百萬的業(yè)務(wù)，在架構(gòu)上，機房部署會出現(xiàn)瓶頸。

比如公司內(nèi)某個業(yè)務(wù)發(fā)展很快，達到了幾億的tps，導致架構(gòu)上無法快速擴縮容，而且機房內(nèi)的電力、物理面積、機架都已經(jīng)達到極限無法擴容，那么架構(gòu)就很難支撐這種并發(fā)，而單元化理論上可以無限水平擴容架構(gòu)能力。

單元化可以理解為異地多活的終極形態(tài)。

單元化在流量入口將流量按照規(guī)則分到不同的IDC，每個IDC分別承接自己的流量，且IDC之間流量不會相互調(diào)用。

單元化和區(qū)域無關(guān)，理論上做到單元化之后，新增的流量可以匹配新增的IDC解決，而新增的IDC不再受到區(qū)域限制，因為IDC不會有之前的流量進行調(diào)用。

判斷架構(gòu)是否已經(jīng)做到單元化的標準是，流量是否可以自閉環(huán)。

比如A機房部署在上海，B機房部署在海外，如果A機房服務(wù)調(diào)用B機房服務(wù)，由于地理位置遠，如果無法做到自閉環(huán)，那么RT勢必會變長，影響業(yè)務(wù)。如果做到了單元化，則業(yè)務(wù)毫無影響，也就代表單元化成功了。

單元化機房之間做多活，只需要在底層的數(shù)據(jù)層做好數(shù)據(jù)同步即可。

隨著O2O及移動化的發(fā)展，很多具有LBS屬性的業(yè)務(wù)，采用的都是按照地區(qū)路由的方式實現(xiàn)了異地多活或者單元化架構(gòu)。

主要理由是，隨機路由在各種多活架構(gòu)下，都不是一個好的方案，原因是隨機路由無法確保規(guī)律性，多活架構(gòu)本身就是復雜的技術(shù)架構(gòu)，確定性越強越好。

選擇地域路由的原因是，LBS類的業(yè)務(wù)區(qū)別于電商這種純線上業(yè)務(wù)有自己的業(yè)務(wù)特點。

比如電商或者SNS基本上是圍繞于C端用戶，用戶只關(guān)注于自己的訂單即可，因此按照用戶id路由其實是可以實現(xiàn)數(shù)據(jù)隔離的，單元化和多活都很好做。

但這種方案在LBS類的業(yè)務(wù)場景下，會犧牲B端商家的體驗，商家的很多訂單訪問操作勢必會跨機房，從而影響商家操作體驗。

比如外賣業(yè)務(wù)C端用戶和B端商家，比如網(wǎng)約車業(yè)務(wù)C端用戶和B端司機，這種都屬于雙訂單模型，就是需要從C、B兩端共同考慮訂單問題。

如果用戶id路由，則b端用戶在查詢用戶訂單時，勢必會跨機房路由。

而采用地域來分的話，由于訂單很少跨城或者跨省的（哪怕有，概率也比較低），所以跨機房訪問概率就很低，可以提升B、C兩端用戶體驗。

針對于跨城市或地區(qū)訪問的情況，其實通過大數(shù)據(jù)是可以很好的識別的，這樣可以做一些中間方案解決這部分用戶的體驗問題。

為提供雙活或單元化能力，需要對中間件進行一定的改造。

在存儲層面，需要實現(xiàn)底層數(shù)據(jù)的雙向同步。

redis的跨機房讀寫和跨機房加鎖均是因為雙訂單模型無法做到單元化，提供的雙活能力。 

redis雙寫則為無雙向同步能力時的臨時能力。 

db糾偏則是db層面指定路由，也是為了兜底，當soa路由出異常，在db層做最后的兜底（可訪問跨機房數(shù)據(jù)）。 

db禁寫保護則是當業(yè)務(wù)開啟禁寫保護，非本機房的訂單無法在本訂單操作，也是db兜底保護的一種。

在MQ層面，可以將消息的發(fā)送和消費分開來看。

對于發(fā)送來說，單元到中心的復制和中心到單元的復制，則都是一個機房消息復制到另外機房，也是無法單元化的一種解決方案。當然該方案也可以兼容雙活應(yīng)用發(fā)送消息和非雙活應(yīng)用消費者的問題。 

消費本機房：只能消費本機房產(chǎn)生的消息，異地機房的復制消息無法消費。 

都不消費：代表本機房和異地機房都不消費。 

消費本機房和異地機房消息，則代表消息消費本機房和異地機房消息（消費雙份消息）。

在微服務(wù)架構(gòu)層面，需要根據(jù)特定的條件，將rpc流量路由到正確的機房。

服務(wù)提供方路由則表示該路由規(guī)則由服務(wù)提供方指定。

服務(wù)消費方路由則表示該路由規(guī)則由服務(wù)消費方指定。

在發(fā)號器層面，比如在雙活部署下，zk集群是雙機房的，需要通過雪花算法打上機房標識，保證全局唯一。

對應(yīng)的，在業(yè)務(wù)架構(gòu)上也需要做一系列的改造。

首先要對業(yè)務(wù)做單元化改造，涉及到一系列的存儲，主從復制，rpc調(diào)用，邏輯梳理等工作。

在訂單可靠性層面，需要考慮db和緩存的一致性問題，可以采用binlog消息雙機房同步消費，保證數(shù)據(jù)一致性。

需要基于機房信息，做服務(wù)調(diào)用層面的請求過濾，過濾掉非本機房處理的數(shù)據(jù)邏輯。

訂單單號生成，采用發(fā)號器，對訂單的查詢和修改時，根據(jù)訂單的單號進行路由，將流量打到目標機房。

異地多活和多機房容災，在過去是比較神秘高深的技術(shù)架構(gòu)。這幾年頭部大廠的業(yè)務(wù)基本上都已經(jīng)做了多機房或者異地容災，實現(xiàn)了單元化，所以這部分技術(shù)已經(jīng)不怎么神秘了。

也與頭部的幾家公司的架構(gòu)師交流過，結(jié)論上差不多，就是方法論都很類似，差別的是技術(shù)債不同。

在跨機房延遲和數(shù)據(jù)一致性上，大家喜歡舉的例子也是庫存業(yè)務(wù)，看起來庫存業(yè)務(wù)的一致性與穩(wěn)定性確實是一個非常通用的技術(shù)難題。