RSF遠(yuǎn)程服務(wù)調(diào)用框架介紹

1、 RSF遠(yuǎn)程服務(wù)調(diào)用框架介紹聊聊架構(gòu) 微信號 archtime功能介紹 以架構(gòu)之“道”為基礎(chǔ)，呈現(xiàn)更多務(wù)實落地的架構(gòu)內(nèi)容。蘇寧的系統(tǒng)間交互最初使用中心化 ESB 架構(gòu)，但隨著系統(tǒng)拆分工作的展開及業(yè)務(wù)量的迅速攀升，系統(tǒng)間調(diào)用規(guī)模越來越大，ESB 中心化架構(gòu)帶來的諸如中心資源隔離、中心容量動態(tài)評估、問題排查難度、中心化擴展能力瓶頸等問題迅速顯現(xiàn)。并且，隨著自研系統(tǒng)逐步替換商用系統(tǒng)，需要進行協(xié)議轉(zhuǎn)換等工作逐步弱化，因此蘇寧亟待一個更輕量化的去中心化的跨系統(tǒng)服務(wù)調(diào)用方案。蘇寧遠(yuǎn)程服務(wù)框架（RSF）致力于解決系統(tǒng)間的服務(wù)調(diào)用問題，提供一種透明的、高性能的 RPC 服務(wù)調(diào)用方案。目前應(yīng)用于蘇寧 1000+

2、 系統(tǒng)，每天的服務(wù)調(diào)用次數(shù)在 200 億左右，是蘇寧使用最廣泛的技術(shù)組件。開源世界里成熟的 RPC 比較多，簡單的如 spring remoting，應(yīng)用廣泛，短短幾行代碼及配置就可以實現(xiàn)跨系統(tǒng)方法調(diào)用，但是都只是止步于調(diào)通服務(wù)。對于一個由上千個系統(tǒng)協(xié)同交互構(gòu)成的復(fù)雜電商交易平臺來說，只是達(dá)到跨系統(tǒng)能調(diào)通是遠(yuǎn)遠(yuǎn)不夠的，需要考慮的問題有很多，比如服務(wù)節(jié)點的動態(tài)注冊和發(fā)現(xiàn)，生產(chǎn)問題的快速干預(yù)，服務(wù)治理等等。而在不同的環(huán)境、背景下，也會有各自的需求和挑戰(zhàn)，這也正是我們選擇構(gòu)建自己的 RPC 框架的核心原因。本文將重點介紹 RSF 的重點特性及一些我們面臨的挑戰(zhàn)和相應(yīng)的解決方案。重點特性 1. 同步、

3、異步 Future、異步 Callback 三種調(diào)用模型同步調(diào)用：是最普遍使用的形式，使用同步調(diào)用，當(dāng)前調(diào)用線程會阻塞等待服務(wù)調(diào)用返回結(jié)果或拋出異常。異步 future：調(diào)用立刻返回，當(dāng)前線程不會阻塞，不會等待服務(wù)提供方執(zhí)行完成。服務(wù)提供方的返回結(jié)果可以后續(xù)通過 Future get 來獲得，這種調(diào)用形式在某些場景下會特別有用，能實現(xiàn)并行調(diào)用服務(wù)。Future get 會阻塞當(dāng)前線程，直到服務(wù)方返回結(jié)果或有異常拋出。異步 Callback：調(diào)用立刻返回，當(dāng)前線程不會阻塞，不會等待服務(wù)提供方執(zhí)行完成。當(dāng)服務(wù)方返回結(jié)果或拋出異常時，異步執(zhí)行 callback 中相應(yīng)的方法。使用 Future 及

4、Callback 異步調(diào)用在某些場景下非常有用，它能做到調(diào)用方的線程不會阻塞等待服務(wù)調(diào)用結(jié)果。結(jié)合一些其他的異步技術(shù)可以使得整個調(diào)用鏈條異步化。2. 服務(wù)方異步返回調(diào)用結(jié)果服務(wù)方異步返回調(diào)用結(jié)果的機制類似 Async Servlet，當(dāng)前處理調(diào)用請求的線程不返回最終結(jié)果，而是在其他線程中異步返回結(jié)果給消費方，比如服務(wù)實現(xiàn)方在實現(xiàn)服務(wù) A 時，需要調(diào)用依賴的其他外部服務(wù) B，如果外部服務(wù) B 通過 Http 協(xié)議開放服務(wù)，則可以通過支持異步的 Http Client 來調(diào)用外部服務(wù) B，然后在異步回調(diào)中返回 A 的最終調(diào)用結(jié)果。如果 B 也通過 RSF 開放服務(wù)，可以通過異步 Callback

5、來調(diào)用 B，在 callback 中返回 A 的最終調(diào)用結(jié)果。處理請求 A 的服務(wù)方線程自身不會阻塞等待 B 的調(diào)用結(jié)果，只是發(fā)起了一次異步 Http 或 RSF 調(diào)用就結(jié)束了。通過這些異步手段，可以做到整個調(diào)用鏈條異步化，不會有線程阻塞（浪費）在等待服務(wù)調(diào)用結(jié)果上，從而能極大提高整體資源利用率。在線程技術(shù)還在主宰著 java 的今天，如何讓線程不阻塞、少阻塞是一件很重要的事。3. 所有服務(wù)調(diào)用相關(guān)配置統(tǒng)一管理，修改后實時生效比如服務(wù)調(diào)用的超時時間、重試次數(shù)、授權(quán)、負(fù)載均衡方式、流控、熔斷、成員權(quán)重、服務(wù)路由策略等等服務(wù)調(diào)用相關(guān)的所有配置，在 RSF 都不是寫死在應(yīng)用側(cè)代碼或配置文件中的，都是

6、在 RSF 服務(wù)管理平臺上統(tǒng)一管理的，并且支持修改立刻生效，這一點針對線上問題干預(yù)非常重要，可以想象一下，當(dāng)一個服務(wù)出現(xiàn)服務(wù)質(zhì)量等問題時，想修改一個調(diào)用相關(guān)的配置，還需要發(fā)布應(yīng)用是完全無法接受的。同時，這個能力還可以和監(jiān)控體系有機結(jié)合起來，實現(xiàn)自動調(diào)控。4. 重試及防重當(dāng)進行一次服務(wù)調(diào)用時，如果調(diào)用過程出現(xiàn)可重試的異常（如網(wǎng)絡(luò)異常，調(diào)用方資源不足），并且配置是允許重試的話，那么將發(fā)起重試。RSF 的重試和大部分的重試設(shè)計相比，稍微復(fù)雜。大部分的重試設(shè)計都是包含重試的幾次請求之間是不交叉的，比如第一次請求已經(jīng)超時引發(fā)了第二次重試請求，在第二次請求過程中，第一次請求結(jié)果回來了。大部分的重試設(shè)計是忽

7、略第一次請求結(jié)果的，因為認(rèn)為第一次請求的生命周期已經(jīng)結(jié)束了。在 RSF 中則是認(rèn)為第一次請求返回的結(jié)果是有效的，這個設(shè)計的目的是盡可能的促使調(diào)用成功，但是也引發(fā)了一些復(fù)雜的并發(fā)相關(guān)的問題需要處理，太過細(xì)節(jié)不再展開。如果服務(wù)調(diào)用是冪等的，那么不管調(diào)用多少次都不會影響系統(tǒng)的狀態(tài)，重試是安全的。但是，如果服務(wù)調(diào)用不是冪等的，那么重試就需要考慮防重的問題，RSF 中包含一些擴展點可以由用戶來定義自己的防重邏輯，并且也自帶了一個基于 redis 的默認(rèn)防重實現(xiàn)。5. 服務(wù)節(jié)點的自動注冊和發(fā)現(xiàn)Service discovery 是服務(wù)框架中最核心的部件，這個部件的目標(biāo)很明確，就是服務(wù)節(jié)點上下線 (包括擴縮

8、容、應(yīng)用發(fā)布、節(jié)點宕機等等場景) 引起服務(wù)方節(jié)點列表變更時，服務(wù)消費方能實時、準(zhǔn)確的知道。怎么達(dá)到則有各種設(shè)計，有基于中心化的如 Netflix/eureka，或者基于 ZooKeeper、etcd 的簡單一點的方案，也有去中心化的方案，這個部件對數(shù)據(jù)一致性要求并不高，并不追求數(shù)據(jù)強一致性，但是如何做到可靠非常關(guān)鍵，試想如果這個部件出問題，導(dǎo)致消費方錯誤的認(rèn)為服務(wù)方節(jié)點全部或者大部分都下線了，會引起什么樣的后果，如果是中心化的設(shè)計，則會引發(fā)全局性的災(zāi)難。RSF 的服務(wù)節(jié)點發(fā)現(xiàn)采用的是中心化的設(shè)計，但是我們認(rèn)為去中心化的思路更優(yōu)，因為不存在中心化架構(gòu)下的中心瓶頸，出問題也不會是全局性的災(zāi)難，我們

9、也曾基于 gossip 完整設(shè)計了一個方案，但是評估后認(rèn)為實現(xiàn)較為復(fù)雜，重點要規(guī)避的風(fēng)險是任何情況下都不會引發(fā) gossip 風(fēng)暴。RSF 的服務(wù)發(fā)現(xiàn)會在本文后半部分稍微深入的展開探討。6. 負(fù)載均衡當(dāng)消費方發(fā)起一次服務(wù)調(diào)用時，RSF 會基于隨機策略優(yōu)先選擇當(dāng)前負(fù)載低（Least Pending Requests）的服務(wù)提供方節(jié)點，選擇過程同時也會加入提供方節(jié)點權(quán)重因子。這種負(fù)載均衡方式能基于服務(wù)方節(jié)點的實時處理能力進行動態(tài)調(diào)整，能較好的規(guī)避短板效應(yīng)。并且，負(fù)載均衡還會優(yōu)先選擇當(dāng)前和提供方的連接已就緒的（關(guān)于 RSF 的連接管理，本文后半部分會稍微深入展開探討），并且沒有被熔斷的服務(wù)方節(jié)點，這

10、些策略目的都是為了為每次請求選擇最優(yōu)的服務(wù)方節(jié)點。7. 熔斷RSF 的熔斷有兩種，一種是服務(wù)方法級的熔斷，當(dāng)調(diào)用某服務(wù)方法出現(xiàn)較高異常比例時，會禁止訪問該服務(wù)方法一段時間，這段時間過去后，允許少量的請求，如果依然出現(xiàn)較高異常比例時，則繼續(xù)禁止訪問一段時間，否則放開訪問限制。合適的設(shè)置消費方服務(wù)方法熔斷，既可以保護服務(wù)提供方，避免其已經(jīng)處于不健康狀態(tài)下時繼續(xù)給壓。也可以避免消費方應(yīng)用大量線程因等待服務(wù)方結(jié)果返回被阻塞（在同步調(diào)用下），有效的保護服務(wù)消費方自身。從而避免事故級聯(lián)蔓延。但同時，一旦觸發(fā)服務(wù)方法熔斷，后果是嚴(yán)重的，會引起服務(wù)方法在一段時間內(nèi)完全被禁止訪問，所以應(yīng)根據(jù)服務(wù)自身情況合理的設(shè)

11、置觸發(fā)條件閥值，不應(yīng)該因為瞬間的服務(wù)質(zhì)量毛刺導(dǎo)致輕易被觸發(fā)。RSF 另外一種熔斷是針對服務(wù)方節(jié)點的，當(dāng)某個服務(wù)方節(jié)點出現(xiàn)超時、資源繁忙等等異常時，會快速被熔斷，負(fù)載均衡在選擇提供方節(jié)點時，會優(yōu)先選擇沒有被熔斷的服務(wù)方節(jié)點，以提高調(diào)用成功率。8. 并發(fā)流控RSF 的并發(fā)流控有兩種，一種是服務(wù)提供方側(cè)的流控，一種是服務(wù)消費方側(cè)的流控。服務(wù)提供方側(cè)的流控，是為了避免服務(wù)請求的并發(fā)量超出其設(shè)計的承受能力，從而引起各種蔓延以至整個服務(wù)方最終被沖垮，應(yīng)該合理的設(shè)置服務(wù)方法的并發(fā)閥值，超過并發(fā)閥值的請求會被快速拒絕，從而有效的保護服務(wù)方。 在服務(wù)提供方，RSF 維護一個線程池，該線程池負(fù)責(zé)服務(wù)調(diào)用的業(yè)務(wù)代碼

12、執(zhí)行。線程池有一個任務(wù)排隊隊列，一旦排隊隊列滿了，請求將被拒絕。線程池的線程數(shù)和排隊隊列長度都可以在服務(wù)配置平臺中設(shè)置。為服務(wù)設(shè)置并發(fā)閥值，是將有限寶貴的線程池線程及排隊數(shù)資源分配給服務(wù)。并發(fā)閥值可以分組來設(shè)置，也可以為某一個服務(wù)方法單獨設(shè)置。如果使用分組的方式進行設(shè)置，那么分組下的所有接口方法將共享一個計數(shù)器和閥值。服務(wù)消費方側(cè)的流控，RSF 可以針對某一個服務(wù)方法設(shè)置某一個服務(wù)消費方應(yīng)用的并發(fā)流控閥值。當(dāng)調(diào)用開始時并發(fā)計數(shù) +1，當(dāng)調(diào)用結(jié)束（調(diào)用返回或拋出異常都認(rèn)為是結(jié)束）時并發(fā)計數(shù) -1。當(dāng)計數(shù)累計超過指定閥值，則拋出超出并發(fā)閥值相關(guān)的異常。合適的設(shè)置消費方流控，既可以保護服務(wù)提供方，也

13、可以避免消費方大量線程因等待服務(wù)方結(jié)果返回被阻塞（在同步調(diào)用下），有效的保護服務(wù)消費方自身。9. 服務(wù)路由RSF 服務(wù)路由是根據(jù)調(diào)用請求參數(shù)列表，調(diào)用方機房信息，服務(wù)方節(jié)點機房部署拓?fù)涞刃畔?，將請求路由到正確的目標(biāo)服務(wù)方節(jié)點的過程，比如會員系統(tǒng)可能在多個機房部署相同的服務(wù)，并基于會員編號特定的規(guī)則將會員數(shù)據(jù)分布到不同的機房，那么在調(diào)用獲取會員信息服務(wù)時，RSF 需要根據(jù)調(diào)用參數(shù)中的會員編號以及會員服務(wù)的機房部署拓?fù)湫畔?，將請求路由到正確的機房中的服務(wù)方節(jié)點。RSF 的服務(wù)路由在蘇寧多機房多活項目中發(fā)揮至關(guān)重要的作用，當(dāng)前支持優(yōu)先同機房、會員編號分片、主機房、自定義腳本等多種路由策略。10. 服

14、務(wù)治理及監(jiān)控RSF 提供全量服務(wù)調(diào)用統(tǒng)計信息，以幫助服務(wù)提供方進行服務(wù)質(zhì)量的持續(xù)優(yōu)化，服務(wù)調(diào)用的統(tǒng)計信息包括調(diào)用次數(shù)、失敗率、響應(yīng)時間（平均 /TP90/TP99/TP999）等核心指標(biāo)，服務(wù)相關(guān)方可以針對這些核心指標(biāo)設(shè)置安全閥值進行告警。RSF 還提供了端到端的完整 trace 能力，可以清晰的看到某一次調(diào)用的各個時間點明細(xì)，如調(diào)用方什么時候發(fā)起的請求，請求什么時候?qū)懙?socket，請求什么時間點到達(dá)服務(wù)方節(jié)點，在服務(wù)方線程池中排隊等待了多長時間，什么時候開始執(zhí)行業(yè)務(wù)代碼，業(yè)務(wù)代碼執(zhí)行了多長時間等等。 這些能力對迅速感知及定位線上問題至關(guān)重要。11. 與非 JAVA 系統(tǒng)的交互蘇寧大部分的

15、系統(tǒng)基于 JAVA，但也存在一些老的系統(tǒng)如 SAP 或一些異構(gòu)系統(tǒng)如使用 PHP/NODEJS 等，這些系統(tǒng)目前和 RSF 的交互使用 RSF 提供的 SAP Adapter 和 HTTP Adapter 來達(dá)到。一些挑戰(zhàn) 下面稍微深入的展開探討下我們經(jīng)歷過的一些挑戰(zhàn)和解決方案。1. 服務(wù)節(jié)點注冊和發(fā)現(xiàn)中心的擴展能力及穩(wěn)定性RSF 早期版本的服務(wù)節(jié)點注冊和發(fā)現(xiàn)模塊基于 ZooKeeper，思路也很簡單，就是服務(wù)方節(jié)點上線的時候向 ZK 寫入一個臨時節(jié)點，當(dāng)服務(wù)方節(jié)點主動下線時刪除這個臨時節(jié)點，當(dāng)服務(wù)方節(jié)點宕機或其他異常狀況時，依賴 ZK 的 session timeout 機制由 ZK ser

16、ver 自動剔除這個臨時節(jié)點，當(dāng)發(fā)生 session expire 時恢復(fù)這個臨時節(jié)點。當(dāng)服務(wù)方節(jié)點列表發(fā)生變更時，通過 ZK 的 watch 機制，將最新的服務(wù)節(jié)點列表下發(fā)給訂閱的服務(wù)消費方節(jié)點。這種方案實現(xiàn)簡單，但是當(dāng) ZK 集群出現(xiàn)故障時，大量服務(wù)方節(jié)點發(fā)生 session timeout，引起大量服務(wù)方臨時節(jié)點下線。如果消費方完全信任 ZK 下發(fā)的服務(wù)方節(jié)點列表就會引發(fā)服務(wù)不可用的災(zāi)難。另外，ZK 集群因為數(shù)據(jù)一致性設(shè)計的考量，所有的寫操作都要經(jīng)過 leader，包括 session create，session expire，臨時節(jié)點寫入等等都要經(jīng)過 leader，因此 ZK 集群的

17、寫能力是存在單機瓶頸的，就是不管 ZK 集群怎么擴容，寫能力就那么多，并且隨著加入的 follower 節(jié)點越多，寫能力越差（其實加入 observer 越多，對寫能力也會有影響，畢竟 leader 也要把數(shù)據(jù)同步給 observer）。在服務(wù)節(jié)點注冊和發(fā)現(xiàn)這個場景下，服務(wù)數(shù)量 * 每個服務(wù)的節(jié)點數(shù)，這是一個非常巨大的數(shù)字，試想當(dāng) ZK 集群在最壞情況下要集中處理這么多臨時節(jié)點數(shù)據(jù)的寫入，還有大量的 session 恢復(fù)涉及的數(shù)據(jù)寫入，會造成 leader 處理嚴(yán)重延遲，由此導(dǎo)致的更壞的情況是一個 session 剛恢復(fù)了，又因為后續(xù)寫操作或心跳處理超時導(dǎo)致又 expire，然后又去恢復(fù)這種局

18、面，恢復(fù)的時間難以估計。圖 1RSF 目前采用的方案如圖 1，服務(wù)方節(jié)點注冊和續(xù)約是通過 Redis 來達(dá)到的，當(dāng)服務(wù)方節(jié)點啟動時向 Redis 寫入該節(jié)點提供的服務(wù)列表信息，然后定時發(fā) expire 指令來續(xù)約這份信息，當(dāng)服務(wù)方節(jié)點主動下線時，從 Redis 刪除該數(shù)據(jù)。當(dāng)服務(wù)方節(jié)點宕機或其他異常狀況時，依賴 Redis 的 expire 機制來自動刪除這份數(shù)據(jù)。pump 訂閱所有 redis 的 key space，當(dāng) redis 的 key space 發(fā)生變化時都會通知到 pump，pump 聚合所有的 Redis 數(shù)據(jù)，將提供方節(jié)點 - 服務(wù)列表信息的數(shù)據(jù)轉(zhuǎn)化為服務(wù) - 提供方節(jié)點列

19、表的數(shù)據(jù)結(jié)構(gòu)，寫進 ZK。消費方獲取及更新服務(wù)的服務(wù)方節(jié)點列表還是通過 ZK 來達(dá)到。在這種設(shè)計下，以 Redis 的處理能力，少量的幾臺 Redis 就可以處理幾十萬的服務(wù)節(jié)點注冊和續(xù)約。ZK 方面，只有 pump 節(jié)點向 ZK 寫入數(shù)據(jù)，寫入的頻率是 pump 側(cè)控制的（不需要每次 redis 數(shù)據(jù)變動都會寫一次 ZK，可以做秒級延遲合并處理），并且數(shù)據(jù)經(jīng)過壓縮，因此，這部分?jǐn)?shù)據(jù)的寫入對 ZK 基本沒有寫壓力。實際測試下來，這種設(shè)計經(jīng)過橫向擴展后，可以輕松的處理幾萬的服務(wù) * 幾十萬的服務(wù)節(jié)點的規(guī)模，能滿足我們未來一段時間的需求。另外，還有一個值得一提的問題就是如何解決大量消費方的 session 相關(guān)操作對 ZK 的壓力（雖然沒有了臨時節(jié)點，但是 session create，expire 等還是會都經(jīng)過 leader），在 ZK 3.5.X 版本中有新的 local session 的概念，session 的生命周期都在 follower 或 subscriber 各自節(jié)點本地處理，不會再跟 leader 進行交互。具體細(xì)節(jié)這里不再展開。另外，因為存在中心化的設(shè)計，所以還是要考慮災(zāi)難應(yīng)對的問題，在 RSF 組件側(cè)我們也提供了災(zāi)難應(yīng)對的能力，即使注冊中心出現(xiàn)問題，也能快速在組件側(cè)進行自動修正。2. 連接數(shù)控制的問題大部分基于 TCP 的 RPC 框架，