從螞蟻金服微服務實踐談起 | SOFAChannel#1 直播整理

時間 2019-11-17

標籤螞蟻微服實踐談起 sofachannel#1 sofachannel 直播整理简体版

原文原文鏈接

<SOFA:Channel/>，有趣實用的分佈式架構頻道。git

<SOFA:Channel/> 做爲 SOFA 全部在線內容的承載，包含直播/音視頻教程，集中體現 SOFAStack 的能力全景圖。github

本文根據 2018/1/17 晚直播內容整理，算法

歡迎加入直播互動釘釘羣：23127468（搜索羣號加入便可）。數據庫

你們晚上好，今天是 SOFAChannel 第一次線上直播，感謝你們的收看。編程

先自我介紹下，我是來自螞蟻金服中間件的章耿，花名餘淮，目前在負責應用框架與 SOFAStack 開源相關的工做。json

螞蟻服務化架構演進簡介

你們如今對螞蟻金服技術的概念，聽得比較多的應該是「餘額寶」、「相互寶」、「螞蟻森林」、「刷臉支付」，「掃碼乘坐公交和地鐵」、「雙十一」等等這些耳熟能詳的產品和場景。數組

這些產品的背後，是螞蟻金融科技的一套核心技術，包括「三地五中心異地多活架構」、「金融級分佈式架構 SOFAStack」、「金融級分佈式數據庫 OceanBase」、「智能風控」、「區塊鏈」等諸多黑科技。安全

固然，螞蟻金服的微服務架構體系像其它傳統的企業同樣，也不是一開始就這麼高大上，也是隨着業務的發展慢慢演進而來的。下面給你們簡單介紹下演進的過程。網絡

這個支付寶最先的架構示意圖，能夠看到當時支付寶只是電商後臺的一個支付系統，是一個單體應用，裏面簡單的分了幾個業務模塊，連的也是一個數據庫。但隨着業務規模的不斷擴展，單系統架構已經沒法知足業務需求。架構

因此支付寶就對大系統進行了拆分，將原來的一個單體應用內部的多個模塊變成了多個獨立的子系統，這算是典型的 SOA 化的架構。

最開始系統之間是使用 F5 的硬件負載設備來作系統間的負載均衡，但因爲 F5 設備存在單點的問題，因此後面就在中間引入一個註冊中心的組件。服務提供者去註冊中心註冊服務，服務消費者去註冊中心訂閱服務列表，服務消費者經過軟負載方式經過 RPC 框架直接調用服務提供者。這在如今看來是一種很是顯而易見的服務化架構，但當時 07 年就採用這樣的架構仍是算比較超前的。

支付寶在作系統拆分的同時，對數據庫也按子系統進行了垂直拆分。數據庫的拆分就會引入分佈式事務的問題，螞蟻金服中間件就提供了基於 TCC 思想的分佈式事務組件 DTX。

業務仍是不斷擴展，系統也愈來愈多，當系統節點到必定數量的時候，單個物理機房已經沒法承受。另外考慮到同城容災的問題，支付寶就在同城再擴建另一個機房，經過專線部署爲一個內部網絡，而後將應用部署上去。

同城多機房會引入一個跨機房遠程訪問的問題，相比同機房調用，這個延遲損耗必定是更高的。遠程訪問主要包括兩種：RPC 調用和數據庫訪問。爲了解決 RPC 跨機房調用的問題，支付寶的工程師選擇的方案是在每一個機房都部署註冊中心，同機房優先調用本機房服務的方式，也就變成圖中的部署模式。可是數據庫跨機房訪問的問題，在這個階段並無解決。

另外還存在的一個問題就是調用鏈路混亂以及數據庫鏈接瓶頸的調用。例如這個圖裏，咱們對數據進行了分片，而後圖中的 user0 的請求進來後，隨機轉到 S2，再隨機轉到B0，再隨機到C1，最終跟進數據分配落到了數據庫 D0。能夠看到這裏的調用鏈路是隨機的，而每個核心層也須要跟全部的分庫都創建長鏈接。

爲了解決上面的跨機房數據訪問、數據庫鏈接數瓶頸以及將來數據水平擴展的問題，螞蟻的工程師們設計了一套單元化的架構，這是單元化的一個示意圖。

首先螞蟻的請求都是跟用戶相關的，因此咱們將數據按用戶的維度進行水平分片，例如這張示意圖咱們將全部用戶分爲三組。而後咱們將咱們的應用也部署成三組獨立的邏輯單元，每一個邏輯單元的應用和數據都是獨立的，至關於每一個邏輯單元都處理1/3總量用戶的數據。

這個時候咱們的三個不一樣終端的用戶，不論是在PC端或者手機端或者掃二維碼，當請求進入統一接入層的時候，接入層會按上面邏輯單元的分組規則，將用戶請求轉發到對應的邏輯單元，例如 user0 的請求轉到 S0，後面的應用之間的調用、數據都只在邏輯單元 0 內。統一的 user1 只在邏輯單元 1，user2 也只到邏輯單元 2。

咱們把這種邏輯單元稱之爲 RegionZone。在實際的部署過程當中，物理數據中心 IDC 和邏輯單元的數量沒有徹底的對等關係。例如圖中咱們物理機房能夠是兩地三中心，而 RegionZone 則是分爲五個。

兩地三中心是國家對金融機構的一個容災指導方案，要求在同城或相近區域內（ ≤ 200K M ）創建兩個數據中心 : 一個爲數據中心，負責平常生產運行 ; 另外一個爲災難備份中心，負責在災難發生後的應用系統運行。同時在異地（＞ 200KM ) 創建異地容災中心。

有了這套單元化的架構作指導思想，螞蟻進行大規模的改造，包括應用改造、基礎框架改造、數據中心的建設。

機房建設完成後，同時螞蟻金服將本身的用戶分紅了若干份，劃了幾個邏輯單元，分別部署進了不一樣的物理機房，同時完成大規模的數據遷移。

從兩地三中心到容災能力更強大的三地五中心，咱們只須要先進行第三個城市的機房建設，而後將部分 RegionZone 部署到第三個城市，最後再完成數據遷移和引流便可。

每個 RegionZone 在異地都有備份，當發生城市級的故障時，咱們經過統一的管控中心將新的邏輯規則推送到統一接入層以及異地的備 RegionZone 時，就能夠作到城市級的總體容災切換。

再後面基於單元化思想，螞蟻工程師還建設了彈性 LDC 的能力，例如大型活動開始的時候，咱們將動態的將大促相關應用調度到其它的臨時機房（例如是雲上的機房）去，而後將流量引入。例如圖中實例將 10% 的流量引入了 ZoneX 中。等到活動結束，咱們再將流量引回。

SOFAStack 開源狀況

從前面的服務化演進能夠看到，螞蟻的微服務架構面臨的場景已經慢慢從簡單的遠程調用發展到要面臨複雜的三地五中心異地多活場景，爲了支持這些場景，螞蟻中間件自研了一套中間件 SOFAStack。

SOFAStack 中的 SOFA 實際上是 Scalable Open Financial Architecture 的首字母縮寫，它是用於快速構建金融級分佈式架構的一套中間件，也是在金融場景裏錘鍊出來的最佳實踐。

這是咱們內部的技術棧，能夠看到微服務領域各個功能點咱們都有對應的內部系統或者組件。包括有RPC框架、服務發現、動態配置、熔斷限流，還有分佈式事務，分庫分表等一整套中間件。

這張是咱們的 OpenSource Landscape，目前只開源了部分組件，部分組件還在開源準備中，雖然很多內部組件沒有開源，可是在每一個微服務領域咱們都會打通當前已經開源的比較成熟的組件。

例如微服務裏的服務發現，咱們沒有開源內部的 SOFARegistry，可是咱們對接了 ZooKeeper/etcd/nacos 等業界成熟的註冊中心產品，又例如分佈式跟蹤，咱們雖然開源了本身的 SOFATracer，可是在 SOFARPC 咱們也提供 skywalking 做爲咱們的分佈式跟蹤的實現。經過保持和業界衆多優秀開源產品的兼容性，使得 SOFAStack 有更多可能。

以上部分的詳細內容也能夠直接閱讀螞蟻金服微服務實踐 | 開源中國年終盛典分享實錄

螞蟻微服務體系之 SOFARPC

在微服務體系裏，服務框架基本是必不可少的組件，在 SOFAStack 裏這個組件叫 SOFARPC。和螞蟻的整個微服務體系同樣，SOFARPC 在內部也經歷了幾代的發展。

能夠看到從最先的支持 WebService 到如今的開源版本，SOFARPC 已經走過了十多年的發展，從時間軸能夠清楚的看到隨着前面總體架構的演進，RPC 框架也進行了幾代的升級，SOFARPC 目前已經開源在 Github 上。

在 2017 年 SOFARPC 進行第五代重構的時候，就列了三大設計原則。

第一個就是核心開發，就是將接口層、 API 層、以及核心實現邏輯統統開放，內部實現保留的是一些兼容內部系統，兼容老的 API，或者是一些歷史包袱比較重的代碼。

第二個就是統一模型，要將歷史遺留的 API 模型，領域模型統一塊兒來，並預留擴展機制。

第三個就是平等擴展，咱們模型要保持良好的擴展性，不論是內部實現仍是外部實現都面向接口編程，平等對待第三方擴展。

基於這些原則，咱們先對 SOFARPC 系統進行了模型分層，在原來的基礎上更加細化，左邊是服務端的一些模塊分層，右邊是客戶端的模塊分層，例如圖中的Filter/Router/Cluster/Loadbalance/Serilization/Protocol/Transport。

爲了保證擴展性，咱們也設計了兩種擴展機制方便你們進行擴展。

一種就是左側示例代碼展現的 ExtensionLoader。咱們能夠方便的以一種相似 JDK SPI 機制的方式來擴展咱們的能力。擴展方式比較簡單，能夠看到只須要先實現接口並加上註解、加上配置項、最後在使用的時候根據擴展別名來獲取擴展實例便可。目前 Registry、Filter、Router、Loadbalance、Transport 等等都是經過這個擴展方式實現的。

另外一種就是右側示例代碼展現的 Eventbus（事件總線）機制，在整個 RPC 調用過程當中，不一樣的階段都會產生不一樣的事件，這些事件都會發送到事件總線。若是某個擴展能力在事件總線上監聽某個事件，那麼就能夠同步或者異步的處理這些事件，再進行一些能力擴展。目前 Metrics/Tracer/Fault tolerance 等等是經過這個擴展方式實現的。

註冊中心也是擴展能力之一，目前咱們能對接的有 Zookeeper，Consul，Nacos等等，社區也在幫咱們共建其它例如 etcd eureka 等的註冊中心實現。若是咱們的註冊中心 SOFARegistry 開源了，SOFARPC 也會第一時間進行支持。

基於良好的擴展，目前 SOFARPC 支持的通訊協議和序列化組合如圖所示。默認的組合是 Bolt+Hessian。Bolt 也是螞蟻開源的基於 Netty 的高性能通信框架。Bolt 協議是自研的 TCP 協議。Hessian 則是在開源的Hessian上加了一下功能優化以及反序列化安全特性的一個版本。

除了這類 TCP 長鏈接 + 二進制序列化的方式，也有傳統的 Restful+ json 方式。其它 dubbo/gRPC 業務能夠集成到 SOFARPC 中。

這是在 bolt 協議下服務端線程模型，咱們分爲主要有三個線程池：

boss 線程是監聽端口上的鏈接/read/write 事件的；

worker 線程池處理具體的數據的解包和封包動做，另外在 worker 線程裏會作反序列化請求的頭部，若是請求對應的接口設置了業務自定義線程池，則分發到這個線程池。不然的話分發到默認的業務線程池。

業務線程池裏會將請求的body解析出來，執行業務邏輯，而後把響應序列化爲byte數組。

旁邊還有一個回調線程池，主要執行一些回調處理、事件處理。

而客戶端這邊的調用鏈路就如這張圖所示。客戶端的調用主要會通過Proxy、Router、loadbalance、Filter 幾部分。這幾個都是擴展點，因此能夠實現各類各樣的能力。固然咱們也內置了一些擴展實現，好比負載均衡咱們內置了隨機、輪詢、權重、一致性hash 等算法。

SOFARPC 的分佈式跟蹤默認實現接的是 SOFATracer，SOFATracer也是螞蟻開源的一個分佈式跟蹤組件。

這個 SOFATracer 就是根據以前提到的 EventBus 擴展實現的。能夠看到請求的各個階段都會有事件產生，例如開始調用，開始發送數據，收到請求，收到響應等等，這些階段都會產生事件到事件總線。而 SOFATracer 模塊裏就有一個訂閱器，訂閱了這些事件，並進行相關記錄。

SOFARPC 除了基本的調用、服務發現等以外，其它獨特特性我這邊簡單介紹兩個。

其中一個是 SOFARPC 內置一個單機故障摘除的能力。該能力主要針對的是那種在 Consumer 和 Provider 的長鏈接還在，註冊中心未下發摘除，可是服務端因爲某些緣由（例如長時間 FullGC、硬件故障、IO 繁忙）等場景下，處於亞健康狀態的節點。這類節點每每的表現就是調用超時等異常率高等動做。

爲此咱們設計一套模型和策略，你們能夠看下上圖。咱們基於事件機制（和Tracer相似，不過是異步的）監聽統計行爲，設置一個統一的入口將調用結果都收集起來；而後按計算策略進行計算，好比每 1 分鐘計算一次；計算後對計算結果進行度量，例如某個節點錯誤率超過平均值 5 倍，咱們認爲須要降級；對降級的節點咱們執行降級策略，例如將權重下降爲5%，那麼發往這個節點的請求就會變成原來的 1/20（留 5 %是爲了留少許請求進行恢復操做）。這個節點在下一次計算和度量的時候，若是錯誤率都恢復正常了，那麼執行恢復策略，例如恢復5倍，也就是慢慢從 5% 恢復到 25% 再到 100%。這樣的話，在某些節點故障的狀況下，總體客戶端可用率將會提升。

另一個特性就是鏈路透傳。其實 SOFATracer 裏內置了一個鏈路數據，並且能夠透傳到各個組件。不過 SOFATracer 的數據透傳是單向的。SOFARPC 基於隱式傳參的能力作了一個雙向鏈路透傳的能力，能夠用於一些鑑權，A/B Test 等場景。業務使用的時候能夠方便的使用 API 進行數據的存取，在整個鏈路上也能夠作到業務無感，也能夠提早阻斷。

其它更多特性，你們能夠去咱們的開源官網上查看。最近的版本咱們也和 hystrix、skywalking 等作了集成。

文檔地址是：https://www.sofastack.tech/sofa-rpc/docs/Home

這是下一步的 Roadmap，咱們會作一下數據校驗類的能力來杜絕一些黑天鵝事件的發生，也會作一下加解密的能力，也會咱們 SOFA 體系下的註冊中心集成。其它在 6.0.0 版本咱們會升級到 JDK8，也會與 gRPC 作集成，支持 etcd 作註冊中心，服務註冊和配置模型分離等特性，屆時歡迎你們關注。

若是你們有想要的能力，也歡迎給咱們提 Issue 或者 PR。

https://github.com/alipay/sofa-rpc