章耿,花名餘淮,螞蟻金服高級技術專家。git
2007 年畢業後一直從事服務化相關的工做,最先在國家電網作電子商務平臺 SOA 化的工做,以後在京東負責京東的服務化框架 JSF,目前在螞蟻金服中間件服務與框架組負責應用框架及 SOFAStack 相關的工做。github
本文根據餘淮在 2018 開源中國年終盛典的演講內容整理,完整的分享 PPT 獲取方式見文章底部。算法
螞蟻金服服務化架構演進數據庫
螞蟻金服微服務體系後端
螞蟻金服 SOFAStack 的開源狀況緩存
在開始講架構演進以前,咱們先來看一組數據。安全
這是歷年來的雙十一數據圖,柱狀是雙十一的交易額,從最初到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 繼承了螞蟻金服內部的能力,有三大特色,分別是開放(全棧開放、開源共建)、雲原生(異地多活、無限擴展)、金融級(資金安全、無損容災),下面是一些核心能力你們能夠看下。這一切就使得螞蟻金服的微服務體系不只僅在螞蟻內部玩得轉,也須要適應雲上例如雲原生、多租戶等更復雜的場景。
講到微服務,你們就會看到或者腦子就跳出各類各樣的詞,例如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、平滑升級。
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/
PPT 地址:
http://www.sofastack.tech/posts/2018-12-17-01
SOFA 文檔: http://www.sofastack.tech/
SOFA 開源總體地址: https://github.com/alipay
長按關注,獲取分佈式架構乾貨
歡迎你們共同打造 SOFAStack https://github.com/alipay