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

摘要： <SOFA:Channel/>，有趣實用的分散式架構頻道。 <SOFA:Channel/> 作為 SOFA 所有線上內容的承載，包含直播/音視訊教程，集中體現 SOFAStack 的能力全景圖。 本文根據 2018/1/17 晚直播內容整理， 歡迎加入直播互...

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

<SOFA:Channel/> 作為 SOFA 所有線上內容的承載，包含直播/音視訊教程，集中體現 SOFAStack 的能力全景圖。

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

歡迎加入直播互動釘釘群：23127468（搜尋群號加入即可）。

大家晚上好，今天是 SOFAChannel 第一次線上直播，感謝大家的收看。

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

螞蟻服務化架構演進簡介

大家現在對螞蟻金服技術的概念，聽得比較多的應該是“餘額寶”、“相互寶”、“螞蟻森林”、“刷臉支付”，“掃碼乘坐公交和地鐵”、“雙十一”等等這些耳熟能詳的產品和場景。

這些產品的背後，是螞蟻金融科技的一套核心技術，包括 “三地五中心異地多活架構”、“金融級分散式架構 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 有更多可能。

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

螞蟻微服務體系之 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

總結

最後做個總結，今天主要給大家簡單介紹了螞蟻微服務架構的演進，從單模組應用到最終的三地五中心彈性架構。

然後介紹了我們開源的情況，歡迎大家去 Star 或者貢獻程式碼。最後介紹了 SOFARPC 的一些設計理念、思想和特性。

其實我們現在看到越來越多的企業都會選擇往微服務方向轉型，但是微服務體系建設是不能一蹴而就的，企業微服務架構往往會隨著業務發展而慢慢演進。目前微服務的發展正在從趨勢走向最佳實踐，而最佳實踐將大大降低微服務引入的複雜度和開銷。

今天的直播分享到這裡結束了，謝謝大家！

相關連結

視訊回放也給你準備好啦：

https://tech.antfin.com/activities/148

提到的地址：

• SOFAStack官網：

  https://sofastack.tech

• SOFA Github地址：

  https://github.com/alipay

• SOFA 碼雲地址：

  https://gitee.com/alipay

• SOFARPC 更多特性請關注：

  https://www.sofastack.tech/sofa-rpc/docs/Home

• SOFARPC Github地址：

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

講師觀點

長按關注，不錯過每一場技術直播

歡迎大家共同打造 SOFAStack https://github.com/alipay