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

     作互聯網應用很重要的一點是要保證服務可用性，特別是某些業務更是須要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%以上的電動汽車在咱們的平臺下充電，天天都有可能數千萬度電甚至數億電在特來電的充電網上發生。架構的升級將會繼續，會愈來愈快，也會愈來愈複雜，可是咱們樂在其中，指望志同道合的戰友一塊兒戰鬥！！！