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

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

　　像其他互聯(lián)網(wǎng)公司一樣，我們做多活也是迫不得已的事情：

　　所有業(yè)務放到一個籃子里面，當出現(xiàn)嚴重故障時，整個充電云服務將完全宕機，無法滿足SLA99.9%甚至更高的要求。

　　云平臺架構完全是分布式的，部署結構復雜，各產(chǎn)品功能不支持灰度發(fā)布，產(chǎn)品新功能上限頻繁，產(chǎn)品中隱藏很深的bug，很容易引起大面積的云服務故障。

　　因為架構和一些技術實現(xiàn)，一個數(shù)據(jù)中心服務負載總會有上限，在特定的一些條件下，增加虛擬數(shù)量也無法提升系統(tǒng)的服務水平(比如：TCP連接數(shù)是有上限的)

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

　　微信紅包的主要思路是：

　　系統(tǒng)垂直SET化，分而治之。各個SET之間相互獨立，互相解耦。并且同一個紅包ID的所有請求，包括發(fā)紅包、搶紅包、拆紅包、查詳情詳情等，垂直stick到同一個SET內處理，高度內聚。通過這樣的方式，系統(tǒng)將所有紅包請求這個巨大的洪流分散為多股小流，互不影響，分而治之。

　　邏輯Server層將請求排隊，解決DB并發(fā)問題。使拆紅包的事務操作串行地進入DB，只需要將請求在Server層以FIFO(先進先出)的方式排隊，就可以達到這個效果。從而問題就集中到Server的FIFO隊列設計上。

　　雙維度庫表設計，保障系統(tǒng)性能穩(wěn)定。當單表數(shù)據(jù)量達到一定程度時，DB性能會有大幅度下降，影響系統(tǒng)性能穩(wěn)定性。采用冷熱分離，將歷史冷數(shù)據(jù)與當前熱數(shù)據(jù)分開存儲。系統(tǒng)在以紅包ID維度分庫表的基礎上，增加了以循環(huán)天分表的維度，形成了雙維度分庫表的特色

　　螞蟻金服的主要思路是：

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

　　每個單元對外是封閉的，在一個單元內的系統(tǒng)調用鏈路和各類存儲訪問是局部化在本單元內的;

　　每個單元的實時數(shù)據(jù)是獨立不共享的;會員或配置類信息等對延時性要求不高的數(shù)據(jù)全局共享;

　　單元間的通信統(tǒng)一管控，盡量以異步化消息進行通信;同步調用則通過單元間代理方案實現(xiàn)。

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

　　基于此我們規(guī)劃設計了特來電云平臺的多活系統(tǒng)架構?？傮w思路是分為三步走：

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

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

　　上海、北京異地兩數(shù)據(jù)中心雙活，部分充電樁分流到上海數(shù)據(jù)中心。

　　用戶充電時，根據(jù)集控所在數(shù)據(jù)中心，下達充電指令。非充電業(yè)務，默認訪問主數(shù)據(jù)中心

　　當北京數(shù)據(jù)中心或上海數(shù)據(jù)中心宕機時，通過流量管理器自動切換到另一個數(shù)據(jù)中心。提升系統(tǒng)可用性。

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

　　建立多活數(shù)據(jù)中心，每個數(shù)據(jù)中心多個服務單元。

　　充電樁在接入云服務時，根據(jù)所在地區(qū)自動引流到對應的服務單元。

　　用戶充電時，根據(jù)登錄地區(qū)，由流量管理器映射到對應的服務單元

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

　　架構的變遷會隨著業(yè)務的變化而變化，不同階段有不同的需求。規(guī)劃了這些、做了這些，也是只萬里長征的第一步。2020年后才會真正迎來新能源汽車爆發(fā)式發(fā)展，屆時會有50%以上的電動汽車在我們的平臺下充電，每天都有可能數(shù)千萬度電甚至數(shù)億電在特來電的充電網(wǎng)上發(fā)生。架構的升級將會繼續(xù)，會越來越快，也會越來越復雜，但是我們樂在其中，期望志同道合的戰(zhàn)友一起戰(zhàn)斗!!!