螞蟻金服微服務實踐 | 開源中國年終盛典分享實錄

螞蟻金服分散式架構發表於2018-12-20

章耿，花名餘淮，螞蟻金服高階技術專家。

2007 年畢業後一直從事服務化相關的工作，最早在國家電網做電子商務平臺 SOA 化的工作，之後在京東負責京東的服務化框架 JSF，目前在螞蟻金服中介軟體服務與框架組負責應用框架及 SOFAStack 相關的工作。

本文根據餘淮在 2018 開源中國年終盛典的演講內容整理，完整的分享 PPT 獲取方式見文章底部。

本次分享主要分為三部分：

螞蟻金服服務化架構演進
螞蟻金服微服務體系
螞蟻金服 SOFAStack 的開源情況

1、螞蟻金服服務化架構演進

在開始講架構演進之前，我們先來看一組資料。

這是歷年來的雙十一資料圖，柱狀是雙十一的交易額，從最初到20億到去年的1682億，今年是2135億。而這個橙色的折線則是支付寶雙十一 0 點的交易峰值，去年是 26.5w筆每秒，今年更高。從這兩組資料可以看出螞蟻的業務每年都是在高速增長，那技術面臨的壓力更是在不斷的增長。但是最近幾年，峰值雖然越來越大，但是大家有個體感，就是大促的購物體驗更好了，再也不像以前系統會被大促搞掛，系統反而越來越穩了。

而支撐這些數字的背後，是螞蟻金融科技的一些核心技術，我們可以看到有三地五中心多活架構，分散式資料庫OceanBase，金融級分散式架構SOFAStack，還有更多的一些黑科技，例如Zoloz生物識別，螞蟻區塊鏈，第五代智慧風控引擎。

相信大家都聽過一句話 “羅馬不是一天建成的”。螞蟻金服科技的技術也不是最早就設計成這樣，和所有的大公司發展一樣，目前這些技術架構也是隨著業務發展、系統的壯大，一步一步演進而來的。

下面給大家介紹下螞蟻的演進。

這個是支付寶最早的架構示意圖，可以看到當時支付寶只是電商後臺的一個支付系統，是一個單體應用，裡面簡單的分了幾個業務模組，連的也是一個資料庫。但隨著業務規模的不斷擴充套件，單系統架構已經無法滿足業務需求。

所以支付寶就對大系統進行了拆分，將原來的一個單體應用內部的多個模組變成了多個獨立的子系統，這算是典型的 SOA 化的架構。最開始系統之間是使用 F5 的硬體負載裝置來做系統間的負載均衡，但由於 F5 裝置存在單點的問題，所以後面就在中間引入一個註冊中心的元件。服務提供者去註冊中心註冊服務，服務消費者去註冊中心訂閱服務列表，服務消費者通過軟負載方式通過 RPC 框架直接呼叫服務提供者。這在現在看來是一種非常顯而易見的服務化架構，但當時 07 年就採用這樣的架構還是算比較超前的。支付寶在做系統拆分的同時，對資料庫也按子系統進行了垂直拆分。資料庫的拆分就會引入分散式事務的問題，螞蟻金服中介軟體就提供了基於 TCC 思想的分散式事務元件 DTX。

業務還是不斷擴充套件，系統也越來越多，當系統節點到一定數量的時候，單個物理機房已經無法承受。另外考慮到同城容災的問題，支付寶就在同城再擴建另外一個機房，通過專線部署為一個內部網路，然後將應用部署上去。同城多機房會引入一個跨機房遠端訪問的問題，相比同機房呼叫，這個延遲損耗一定是更高的。遠端訪問主要包括兩種：RPC 呼叫和資料庫訪問。為了解決 RPC 跨機房呼叫的問題，支付寶的工程師選擇的方案是在每個機房都部署註冊中心，同機房優先呼叫本機房服務的方式，也就變成圖中的部署模式。但是資料庫跨機房訪問的問題，在這個階段並沒有解決。

為了解決上面的跨機房資料訪問、資料庫連線數瓶頸以及未來資料水平擴充套件的問題，螞蟻的工程師們設計了一套單元化的架構，這是單元化的一個示意圖。在沒有單元化的時候，使用者請求進入內部後，所有請求鏈路都是隨機走的，例如圖裡的 S0 到 B1 到 C2 到 D0。首先螞蟻的請求都是跟使用者相關的，所以我們將資料按使用者的維度進行水平分片，例如這張示意圖我們將所有使用者分為三組。然後我們將我們的應用也部署成三組獨立的邏輯單元，每個邏輯單元的應用和資料都是獨立的，相當於每個邏輯單元都處理1/3總量使用者的資料。

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

我們把這種邏輯單元稱之為 RegionZone。在實際的部署過程中，物理資料中心 IDC 和邏輯單元的數量沒有完全的對等關係。例如圖中我們物理機房可以是兩地三中心，而 RegionZone 則是分為五個。
兩地三中心是國家對金融機構的一個容災指導方案，要求在同城或相近區域內（ ≤ 200K M ）建立兩個資料中心 : 一個為資料中心，負責日常生產執行 ;
另一個為災難備份中心，負責在災難發生後的應用系統執行。同時在異地（＞ 200KM ) 建立異地容災中心。
有了這套單元化的架構做指導思想，螞蟻進行大規模的改造，包括應用改造、基礎框架改造、資料中心的建設。

機房建設完成後，同時螞蟻金服將自己的使用者分成了若干份，劃了幾個邏輯單元，分別部署進了不同的物理機房，同時完成大規模的資料遷移。

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

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

再後面我們基於單元化的思想做了更多彈性排程等能力，這裡就不展開了。

2015 年 9 月螞蟻金融雲對外正式釋出，在今年 9 月的雲棲大會，螞蟻金融雲正式升級為螞蟻金融科技，並宣佈技術全面對外開放，其中就包括金融級分散式架構 SOFAStack，左上角就是網址，感興趣的朋友可以看下：https://tech.antfin.com/sofa。

雲上的 SOFAStack 繼承了螞蟻金服內部的能力，有三大特點，分別是開放（全棧開放、開源共建）、雲原生（異地多活、無限擴充套件）、金融級（資金安全、無損容災），下面是一些核心能力大家可以看下。這一切就使得螞蟻金服的微服務體系不僅僅在螞蟻內部玩得轉，也需要適應雲上例如雲原生、多租戶等更復雜的場景。

2、螞蟻微服務體系

講到微服務，大家就會看到或者腦子就跳出各種各樣的詞，例如RPC框架、服務安全、路由定址等等。

除了這些以外，其實還有更多的服務歸屬、服務測試、服務編排等更多概念。

那螞蟻內部圍繞微服務體系，也建設了很多的元件和框架對應這些微服務的概念點。

這是一張螞蟻內部微服務體系的一張簡圖，只列了部分主要元件，這些元件都是自研的，部分已經開源。可以看到有配置中心 DRM、註冊中心 SOFARegistry，應用開發框架 SOFABoot，應用裡的 RPC 框架、分散式鏈路跟蹤元件 Tracer、監控度量元件 Lookout 等微服務元件，應用旁邊是我們的 SOFAMosn，也就是 ServiceMesh 裡的資料平面 SideCar，會將 RPC 裡的路由、限流、鑑權等一些能力整合到這個元件裡，下面的 OCS 是我們的可觀測性平臺，可以在上面看 tracer 和 metrics 資訊，兩邊的兩個元件是 Edge Proxy，主要是在跨機房或者跨 BU 的遠端服務訪問的 Proxy。

下面我會逐一介紹各個元件：

SOFABoot 是我們的開發框架，目前已經開源。開源地址是：https://github.com/alipay/sofa-boot

SOFABoot 是基於 Spring Boot 的，我們對其做了功能擴充套件，同時也保持完全相容。SOFABoot 提供了基於 Spring 上下文隔離的模組化開發、基於 SOFAArk 的類隔離/動態模組、中介軟體和業務日誌框架隔離等能力。由於 Spring Cloud 也是基於 Spring Boot 的，所以 SOFABoot 和 Spring Cloud 體系也是完全相容的。我們將 SOFAStack 下的中介軟體都作為 SOFABoot Starter，同時一些會員、安全等基礎業務我們也作為 Starter 供各個應用方便的整合使用。

SOFARPC 是內部的 RPC 框架，目前也已經開源，開源地址是：https://github.com/alipay/sofa-rpc

SOFARPC 和其它的開源的 RPC 框架一樣，做了很多分層很多的模型抽象，例如圖中的 Filter/Router/Cluster/Loadbalance/Serilization/Protocol/Transport 等這些模型。
它的特點如下：

透明化、高效能
豐富的擴充套件機制、事件機制
支援自定義Filter和自定義Router
支援多種負載均衡策略，隨機/權重/輪詢/一致性hash 等
支援多種註冊中心，zookeeper/consul/etcd/nacos 等
支援多協議， Bolt/Rest/HTTP/H2/gRPC/dubbo 等
支援多種呼叫方式，同步、單向、回撥、泛化等
支援叢集容錯、服務預熱、自動故障隔離

SOFARPC 基於Java Proxy 機制實現透明的，預設的基於二進位制協議 Bolt 和 NIO 非同步非阻塞實現高效能通訊。SOFARPC 基於其 ExtensionLoader 擴充套件機制和 EventBus 的事件匯流排機制可以進行非常方便整合各種各樣的擴充套件。例如註冊中心，我們內建支援了 ZooKeeper 和 nacos 的實現，社群幫我們共享了 consul 和 etcd 等實現。

SOFARPC 還支援多協議，Bolt 是螞蟻內部使用多年的內部協議，也已開源，地址是：https://github.com/alipay/sofa-bolt。

SOFARegistry 是自研的註冊中心。

SOFARegistry 和 Zookeeper、etcd 註冊中心不同的是，它是屬於 AP 架構，保證高可用和資料的最終一致。註冊中心客戶端和註冊中心之間是長連線，當訂閱資料發生變化的時候，註冊中心是推送資料給註冊中心客戶端的。為了保持大量的長連線，我們將註冊中心分為了兩種角色，Session 節點和 Data 節點，Session 節點保持與客戶端的長連線，Data 節點儲存資料。SOFARegistry 還原生支援多資料中心以及單元化場景。在螞蟻金融雲上，SOFARegistry 新增加了 Meta 節點角色用於支援多租戶以及資料分片，這就使其擁有了支援海量服務註冊資訊儲存的能力。

DRM 是我們內部的分散式配置中心。

配置中心客戶端和配置中心服務端資料互動是採用長連線推模式，而不是 HTTP 短輪詢或者長輪詢。配置中心客戶端在本地磁碟儲存配置以資料防止配置中心服務端不可用，同時客戶端也會定時檢查資料一致性；在服務端Nginx、服務端記憶體中設計快取增加效能，沒有的資料才會請求到資料庫。配置中心的管控臺支援單點、灰度、分組、全域性等多種推送模式，並會讀對推送結果做一致性檢查。

Guardian 是我們內部的熔斷限流元件。

它支援監控模式（只記錄不攔截）和攔截模式。支援多種場景的限流例如RPC請求、Web請求等。支援令牌桶、漏桶等多種限流演算法。支援限時熔斷、降級等多種熔斷規則。支援空處理、固定返回值、丟擲異常等降級策略。有時候如果這些規則過於複雜，使用者可以在管理端配置自定義 groovy 指令碼，規則將通過配置中心下發到各個攔截點。Guardian 同時還支援故障注入操作，用於日常的一些應急演練，檢測系統的健壯性等等。

SOFALookout 是我們內部的監控度量元件，目前客戶端已經開源，地址是https://github.com/alipay/sofa-lookout

SOFALookout 的客戶端基於 Mectrics 2.0 標準，內建多種度量規則例如 JVM/cpu/mem/load 等，使用者也可以自定義度量。Lookout-gateway 是一個度量資料收集端，可對接多種資料採集端（例如來自 Lookout 客戶端上報的、agent上報的或者來自 Queue 裡的事件），同時內建一定的計算能力，將處理後的資料丟到訊息佇列中，最後分發到 OB/HBase/ES 等不同的資料儲存中。不同後端資料展示平臺可以直接從資料儲存中撈出資料進行展示。OCS 就是我們的可觀測平臺，可以查 Tracer 和 Metrics 資訊。

SOFATracer 是我們內部的分散式鏈路跟蹤元件，目前客戶端已經開源，地址是https://github.com/alipay/sofa-tracer

SOFATracer 基於 OpenTracing 規範，提供了豐富的元件支援，例如 Servlet/SpringMVC/HTTPClient/RPC/JDBC 等元件，同時也支援 OpenTracing 官方已經整合的實現。SOFATracer 提供了底層多種儲存實現，可以落地到磁碟或者直接彙報到遠端服務端。同時 SOFATracer 還提供了鏈路資料透傳的能力，廣泛用於全鏈路壓測等場景。

DTX 是分散式事務元件，是螞蟻重度依賴的一個元件，保障在大規模分散式環境下業務活動的資料一致性。

DTX 支援 TCC/FMT/XA 三種模式，用的最多的還是 TCC 這種柔性事務的模式。TCC 模式簡單介紹下，它其實是一個兩階段提交的思想，將事務分成兩個階段，try階段和 cofirm/cancel 兩個階段，使用者在業務程式碼中實現各階段要做的事情。事務開始的時候，事務發起者通知所有事務參與者執行 try 的操作，try 的時候做預留業務資源或者資料校驗操作，如果都 try 成功，則執行 confirm 確認執行業務操作，否則執行 cancel 取消執行業務操作。另外也提供了 FMT 模式，它是另外一種易於使用者快速接入、無業務侵入的較自動化的分散式事務模式。
DTX 還支援冪等控制、防懸掛等特性，事務日誌相容多種日誌儲存實現，事務也支援從本地非同步恢復或者遠端服務端恢復。

ACTS 是我們的一個測試框架。

大家知道對於開發來說，寫測試用例其實是一個比較複雜的事情，特別在開發人員水平參差不齊、業務系統又比較複雜的時候。ACTS 是資料物件模型驅動測試引擎的新一代測試框架，致力於提高開發測試人員編寫測試用例的效率，給開發人員一個更好的測試體驗。ACTS 支援了 IDEA 和 Eclipse 兩種 IDE 外掛，開發人員可以在 IDE 裡直接生成標準化的測試用例，然後再通過視覺化的測試資料編輯，對結果可以精細化校驗，測試資料也會自動清理。另外支援 API 重寫提高測試程式碼的可擴充可複用性，提供特有註解提高測試程式碼編排的靈活性。

SOFAMosn 是我們使用 Golang 語言開發的 sidecar，目前已經開源，地址是：https://github.com/alipay/sofa-mosn

這張圖其實是 istio 官方的一種圖，只是我們把 Envoy 換成了 SOFAMosn。SOFAMosn 可以與 istio 無縫整合，完全相容它的 API。SOFAMosn 也支援多種協議，除了 Envoy 支援的之外，還額外支援 SOFARPC 和 Dubbo 協議，當然您也可以非常方便的去擴充套件支援自定義協議。 SOFAMosn 內建了可觀測元件，使用者可以監控其網路、請求壓力等資訊。SOFAMosn 還能支援平滑 reload、平滑升級。

3、SOFAStack 開源

SOFAStack 中的 SOFA 其實是 Scalable Open Financial Architecture 的首字母縮寫，它是用於快速構建金融級分散式架構的一套中介軟體，也是在金融場景裡錘鍊出來的最佳實踐。

目前 SOFAStack 採用的開源策略我們稱之為是「Open Core」，就是將 API 層、介面層以及核心實現邏輯通通開源，內部實現保留的是一些相容內部系統，相容老的 API，或者是一些歷史包袱比較重的程式碼。

這是今年 SOFAStack 開源的時間軸，在今年的 4 月 19 日，SOFAStack 正式宣佈開源，我們第一批主要開了SOFABoot 和 SOFARPC 框架，以及 SOFABolt、SOFAArk、SOFAHessian 等周邊元件；

在 5 月 31 日我們第二批開源了 SOFATracer 和 SOFALookout 的客戶端，完善了微服務元件；在 6 月 28 日我們的開源官網正式上線，域名就是 http://sofastack.tech；在 7 月 16 日我們第三批開源了 ServiceMesh 領域的兩個專案 SOFAMesh 和SOFAMosn。截止到今年的雙十一，這些專案的總 Star 數已經破萬，單個工程最高的是 2700 多。

這是我們內部的 Landscape，可以看到微服務領域各個功能點我們都有對應的內部系統或者元件。部分前面已經介紹過了，不做過多介紹。

另外這張是我們的 OpenSource Landscape，目前只開源了部分元件，部分元件還在開源準備中，雖然不少內部元件沒有開源，但是在每個微服務領域我們都會打通當前已經開源的比較成熟的元件。例如微服務裡的服務發現，我們沒有開源內部的 SOFARegistry，但是我們對接了 ZooKeeper/etcd/nacos 等業界成熟的註冊中心產品，又例如分散式跟蹤，我們雖然開源了自己的 SOFATracer，但是在 SOFARPC 我們也提供 skywalking 作為我們的分散式跟蹤的實現。通過保持和業界眾多優秀開源產品的相容性，使得 SOFAStack 有更多可能。

目前 SOFAStack 的原始碼託管在 Github 和 Gitee 上面，歡迎感興趣的朋友上去看看，也歡迎給我們 Star。

SOFAStack 下的專案大概有 30 來個，每天的 PV 在 10000 以上，總 Star 數一萬多，到 12 月初已經有 80 多位小夥伴給我們貢獻過程式碼或者文章。另外我們也和其它一些國內社群保持了良好的交流與合作，包括 ServiceMesher、Skywalking、AntDesign、Eggjs、K8S 中國社群等。

那如果大家對 SOFAStack 感興趣，可以通過這些方式參與到我們的 SOFAStack 社群活動，我們也為貢獻者們準備了定製的豐富禮物：

您可以使用我們的元件給我們反饋，或者檢視改進我們的文件，或者為 SOFAStack 寫技術分享或者實踐類文章，我們會同步到我們微信公眾號（金融級分散式架構）裡；
當然最好可以貢獻 PR，不管是改錯別字、修復 Bug 還是提 Feature；
也歡迎來見我們，目前我們已經在北京上海深圳杭州舉辦過四次 ServiceMesh Meetup，下一次 1月 6 日在廣州，歡迎感興趣的同學可以參加，歷屆活動可參考：http://www.servicemesher.com/