SOFA:Channel/ 有趣實用的分布式架構頻道。
SOFA:Channel/ 作為 SOFA 所有線上内容的承載，包含直播/音視訊教程，集中展現 SOFAStack 的能力全景圖。歡迎加入直播互動釘釘群：23127468（搜尋群号加入即可）。
大家晚上好，今天是 SOFAChannel 第一次線上直播，感謝大家的收看。
先自我介紹下，我是來自螞蟻金服中間件的章耿，花名餘淮，目前在負責應用架構與 SOFAStack 開源相關的工作。
今天給大家的分享主要分為三部分，第一部分是螞蟻金服服務化演進的簡介，第二部分是SOFAStack開源的情況。這兩部分之前的分享也提到過，我們講快一點，第三部分會詳細介紹下 SOFARPC 的一些設計和實作細節。
分享過程中如果大家對技術點比較感興趣，或者其他元件感興趣，也歡迎留言，後面的直播會安排更多的相關分享。
螞蟻服務化架構演進簡介
大家現在對螞蟻金服技術的概念，聽得比較多的應該是“餘額寶”、“互相寶”、“螞蟻森林”、“刷臉支付”，
“掃描工具地鐵”、“雙十一”等等這些耳耳熟能詳的産品和場景。
這些産品的背後，是螞蟻金融科技的一套核心技術，包括 “三地五中心異地多活架構”，“金融級分布式架構”、“國産金融級分布式資料庫 OceanBase”，“智能風控”，“區塊鍊” 等諸多黑科技。
當然，螞蟻金服的微服務架構體系像其它傳統的企業一樣，也不是一開始就這麼高大上，也是随着業務的發展慢慢演進而來的。下面給大家簡單介紹下演進的過程。
這個支付寶最早的架構示意圖，可以看到當時支付寶隻是電商背景的一個支付系統，是一個單體應用，裡面簡單的分了幾個業務子產品，連的也是一個資料庫。但随着業務規模的不斷擴充，單系統架構已經無法滿足業務需求。
是以支付寶就對大系統進行了拆分，将原來的一個單體應用内部的多個子產品變成了多個獨立的子系統，這算是典型的 SOA 化的架構。
最開始系統之間是使用 F5 的硬體負載裝置來做系統間的負載均衡，但由于 F5 裝置存在單點的問題，是以後面就在中間引入一個注冊中心的元件。服務提供者去注冊中心注冊服務，服務消費者去注冊中心訂閱服務清單，服務消費者通過軟負載方式通過 RPC 架構直接調用服務提供者。這在現在看來是一種非常顯而易見的服務化架構，但當時 07 年就采用這樣的架構還是算比較超前的。
支付寶在做系統拆分的同時，對資料庫也按子系統進行了垂直拆分。資料庫的拆分就會引入分布式事務的問題，螞蟻金服中間件就提供了基于 TCC 思想的分布式事務元件 DTX。
業務還是不斷擴充，系統也越來越多，當系統節點到一定數量的時候，單個實體機房已經無法承受。另外考慮到同城容災的問題，支付寶就在同城再擴建另外一個機房，通過專線部署為一個内部網絡，然後将應用部署上去。
同城多機房會引入一個跨機房遠端通路的問題，相比同機房調用，這個延遲損耗一定是更高的。遠端通路主要包括兩種：RPC 調用和資料庫通路。為了解決 RPC 跨機房調用的問題，支付寶的工程師選擇的方案是在每個機房都部署注冊中心，同機房優先調用本機房服務的方式，也就變成圖中的部署模式。但是資料庫跨機房通路的問題，在這個階段并沒有解決。
另外還存在的一個問題就是調用鍊路混亂以及資料庫連接配接瓶頸的調用。例如這個圖裡，我們對資料進行了分片，然後圖中的 user0 的請求進來後，随機轉到 S2，再随機轉到B0，在随機到C1，最終跟進資料配置設定落到了資料庫 D0。可以看到這裡的調用鍊路是随機的，而每一個核心層也需要跟所有的分庫都建立長連接配接。
為了解決上面的跨機房資料通路、資料庫連接配接數瓶頸以及未來資料水準擴充的問題，螞蟻的工程師們設計了一套單元化的架構，這是單元化的一個示意圖。
在沒有單元化的時候，使用者請求進入内部後，所有請求鍊路都是随機走的，例如圖裡的 S0 到 B1 到 C2 到 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架構、服務發現、動态配置、熔斷限流，還有分布式事務，分庫分表等一整套中間件。
目前 SOFAStack 也在螞蟻金融科技上進行了技術輸出。我們對中間件産品進行了産品化，并在螞蟻金融雲上變成了雲上的産品，并提供了諸多例如同城雙活之類的解決方案。這個是商業的産品，大家有空可以看下。
在去年的 4.19 号，SOFAStack 正式宣布開源，我們第一批主要開了SOFABoot 和 SOFARPC 架構，以及 SOFABolt、SOFAArk、SOFAHessian 等周邊元件；在 5 月 31 日我們第二批開源了 SOFATracer 和 SOFALookout 的用戶端，完善了微服務元件；在 6 月 28 日我們的開源官網正式上線，域名就是
http://sofastack.tech；在 7 月 16 日我們第三批開源了 ServiceMesh 領域的兩個項目 SOFAMesh 和SOFAMosn。截止到今年的雙十一，這些項目的總 Star 數已經破萬。
這張是我們的 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 感興趣，可以通過使用回報、文檔、文章、PR 等方式參與到我們的 SOFAStack 社群活動，或者參加我們的線下 Meetup。
螞蟻微服務體系之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 機制的方式來擴充我們的能力。擴充方式比較簡單，可以看到隻需要先實作接口并加上注解、加上配置項、最後在使用的時候根據擴充别名來擷取擴充執行個體即可。目前注冊中心、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數組。
旁邊還有一個回調線程池，主要執行一些回調處理、事件處理。
而用戶端這邊的調用鍊路就如這張圖所示。用戶端的調用主要會經過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 更多特性請關注：
- SOFARPC Github位址：
講師觀點