做互聯網應用很重要的一點是要保證服務可用性，特別是某些業務更是需要7*24小時不間斷的對外提供服務，任何停機、宕機都會引起大面積的用戶不滿。持續可用性是把業務服務化時一個需要考慮的重要指標，很多時候我們都會犧牲一些功能來換取可用性。如何保證服務的持續可用性，是每個互聯網架構師一直堅持不懈追求的目標。在不同行業、不同場景下都有不同的解決方案。今天就與大家聊聊特來電在物聯網模式下的多活數據中心架構上的認識和實踐。

特來電是全球首家提出了將車聯網、充電網、互聯網三網融合的充電樁生態公司，擁有近18萬個充電樁，覆蓋了全國240多個城市，服務客戶不僅有ToC端、ToB端，還有很多的社會運營車輛。在如此復雜的客戶群面前，充電網每時每刻都有大量的充電用戶，無論在靜寂無聲的夜晚，還是在節假日，充電永不停歇。用戶入眠的時候，是我們充電網絡最繁忙的時刻，可以說特來電的充電網必須要有99.9%甚至更高的可用性，才能滿足業務的需要。特來電的充電網與其他廠商的充電樁還不一樣，其完全構建在物聯網之上的。每個充電終端都是智能的，都在時時刻刻與雲平臺保持著通訊，下面是業務全景圖。

像其他互聯網公司一樣，我們做多活也是迫不得已的事情：

1. 所有業務放到一個籃子裏面，當出現嚴重故障時，整個充電雲服務將完全宕機，無法滿足SLA99.9%甚至更高的要求。
2. 雲平臺架構完全是分布式的，部署結構復雜，各產品功能不支持灰度發布，產品新功能上限頻繁，產品中隱藏很深的bug，很容易引起大面積的雲服務故障。
3. 因為架構和一些技術實現，一個數據中心服務負載總會有上限，在特定的一些條件下，增加虛擬數量也無法提升系統的服務水平（比如：TCP連接數是有上限的）

基於以上考慮，以及填過無數坑的教訓，我們決定必須要建立多活數據中心。既然要建多數據中心，那就要看看業界的一些主流做法和技術趨勢。在眾多的解決方案中我們找到了兩篇非常富有代表性的文章：微信高並發資金交易系統設計方案——百億紅包背後的技術支撐、首席架構師揭秘螞蟻金服互聯網IT運維體系實踐。

微信紅包的主要思路是：

1. 系統垂直SET化，分而治之。各個SET之間相互獨立，互相解耦。並且同一個紅包ID的所有請求，包括發紅包、搶紅包、拆紅包、查詳情詳情等，垂直stick到同一個SET內處理，高度內聚。通過這樣的方式，系統將所有紅包請求這個巨大的洪流分散為多股小流，互不影響，分而治之。
2. 邏輯Server層將請求排隊，解決DB並發問題。使拆紅包的事務操作串行地進入DB，只需要將請求在Server層以FIFO（先進先出）的方式排隊，就可以達到這個效果。從而問題就集中到Server的FIFO隊列設計上。
3. 雙維度庫表設計，保障系統性能穩定。當單表數據量達到一定程度時，DB性能會有大幅度下降，影響系統性能穩定性。采用冷熱分離，將歷史冷數據與當前熱數據分開存儲。系統在以紅包ID維度分庫表的基礎上，增加了以循環天分表的維度，形成了雙維度分庫表的特色

螞蟻金服的主要思路是：

螞蟻金服提出了“LDC”架構，其核心思想是：把數據水平拆分的思路，向上提升到接入層、終端層，從接入層開始，把原來部署在一個IDC中的系統集群，進一步分成多個更細粒度的部署單元。

1. 每個單元對外是封閉的，在一個單元內的系統調用鏈路和各類存儲訪問是局部化在本單元內的；
2. 每個單元的實時數據是獨立不共享的；會員或配置類信息等對延時性要求不高的數據全局共享；
3. 單元間的通信統一管控，盡量以異步化消息進行通信；同步調用則通過單元間代理方案實現。

通過兩家互聯網巨頭公司的方案可以看出一個共同的特點，就是期望通過分流的模式，把大流量切成小流量，從接入層開始，把原來部署在一個IDC中的系統集群，進一步分成多個更細粒度的部署單元 ，應對流量壓力。這種架構下，不僅僅解決了流量天花板問題，而且在系統整體可用性上有了一個質的變化。即使系統不可用，也是少部分服務單元出問題，不會影響全國業務。這不正是我們夢寐以求的東西嗎？

基於此我們規劃設計了特來電雲平臺的多活系統架構。總體思路是分為三步走：

第一步：中間件、技術平臺要進行適應性改造，以支持多數據中心、多Set化的架構。不管後續部署結構如何變化，技術平臺和組件都要可適應。下面是技術平臺和中間件的架構圖，圖中的五個平臺都需要改造。

第二步：架設兩個數據中心，每個數據中心部署一個服務單元，兩個數據中心進行引流，驗證總體架構和設想，實現雙活架構。核心思路：

1. 上海、北京異地兩數據中心雙活，部分充電樁分流到上海數據中心。
2. 用戶充電時，根據集控所在數據中心，下達充電指令。非充電業務，默認訪問主數據中心
3. 當北京數據中心或上海數據中心宕機時，通過流量管理器自動切換到另一個數據中心。提升系統可用性。

第三步：架設多個數據中心、多個服務單元，按照地區對流量進行切割，真正實施多活架構。核心思路：

1. 建立多活數據中心，每個數據中心多個服務單元。
2. 充電樁在接入雲服務時，根據所在地區自動引流到對應的服務單元。
3. 用戶充電時，根據登錄地區，由流量管理器映射到對應的服務單元

通過近半年的努力，我們不僅完成了第一步的工作，而且還完成了第二步規劃。在2017-6-27日，上海數據中心正式激活並引流成功。至此，我們終於在多活架構上邁出了最堅實的一步。這標誌著，我們不僅僅具備了完善了技術架構，而且這個架構是可以復制的、多活的，終於有可能把整個系統可用性做到100%。

架構的變遷會隨著業務的變化而變化，不同階段有不同的需求。規劃了這些、做了這些，也是只萬裏長征的第一步。2020年後才會真正迎來新能源汽車爆發式發展，屆時會有50%以上的電動汽車在我們的平臺下充電，每天都有可能數千萬度電甚至數億電在特來電的充電網上發生。架構的升級將會繼續，會越來越快，也會越來越復雜，但是我們樂在其中，期望誌同道合的戰友一起戰鬥！！！

物聯網模式下的多活數據中心架構認識與實踐