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

1、 RSF遠(yuǎn)程服務(wù)調(diào)用框架介紹聊聊架構(gòu) 微信號(hào) archtime功能介紹 以架構(gòu)之“道”為基礎(chǔ)，呈現(xiàn)更多務(wù)實(shí)落地的架構(gòu)內(nèi)容。蘇寧的系統(tǒng)間交互最初使用中心化 ESB 架構(gòu)，但隨著系統(tǒng)拆分工作的展開及業(yè)務(wù)量的迅速攀升，系統(tǒng)間調(diào)用規(guī)模越來越大，ESB 中心化架構(gòu)帶來的諸如中心資源隔離、中心容量動(dòng)態(tài)評(píng)估、問題排查難度、中心化擴(kuò)展能力瓶頸等問題迅速顯現(xiàn)。并且，隨著自研系統(tǒng)逐步替換商用系統(tǒng)，需要進(jìn)行協(xié)議轉(zhuǎn)換等工作逐步弱化，因此蘇寧亟待一個(gè)更輕量化的去中心化的跨系統(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 比較多，簡(jiǎn)單的如 spring remoting，應(yīng)用廣泛，短短幾行代碼及配置就可以實(shí)現(xiàn)跨系統(tǒng)方法調(diào)用，但是都只是止步于調(diào)通服務(wù)。對(duì)于一個(gè)由上千個(gè)系統(tǒng)協(xié)同交互構(gòu)成的復(fù)雜電商交易平臺(tái)來說，只是達(dá)到跨系統(tǒng)能調(diào)通是遠(yuǎn)遠(yuǎn)不夠的，需要考慮的問題有很多，比如服務(wù)節(jié)點(diǎn)的動(dòng)態(tài)注冊(cè)和發(fā)現(xiàn)，生產(chǎn)問題的快速干預(yù)，服務(wù)治理等等。而在不同的環(huán)境、背景下，也會(huì)有各自的需求和挑戰(zhàn)，這也正是我們選擇構(gòu)建自己的 RPC 框架的核心原因。本文將重點(diǎn)介紹 RSF 的重點(diǎn)特性及一些我們面臨的挑戰(zhàn)和相應(yīng)的解決方案。重點(diǎn)特性 1. 同步、

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

4、Callback 異步調(diào)用在某些場(chǎng)景下非常有用，它能做到調(diào)用方的線程不會(huì)阻塞等待服務(wù)調(diào)用結(jié)果。結(jié)合一些其他的異步技術(shù)可以使得整個(gè)調(diào)用鏈條異步化。2. 服務(wù)方異步返回調(diào)用結(jié)果服務(wù)方異步返回調(diào)用結(jié)果的機(jī)制類似 Async Servlet，當(dāng)前處理調(diào)用請(qǐng)求的線程不返回最終結(jié)果，而是在其他線程中異步返回結(jié)果給消費(fèi)方，比如服務(wù)實(shí)現(xiàn)方在實(shí)現(xiàn)服務(wù) A 時(shí)，需要調(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é)果。處理請(qǐng)求 A 的服務(wù)方線程自身不會(huì)阻塞等待 B 的調(diào)用結(jié)果，只是發(fā)起了一次異步 Http 或 RSF 調(diào)用就結(jié)束了。通過這些異步手段，可以做到整個(gè)調(diào)用鏈條異步化，不會(huì)有線程阻塞（浪費(fèi)）在等待服務(wù)調(diào)用結(jié)果上，從而能極大提高整體資源利用率。在線程技術(shù)還在主宰著 java 的今天，如何讓線程不阻塞、少阻塞是一件很重要的事。3. 所有服務(wù)調(diào)用相關(guān)配置統(tǒng)一管理，修改后實(shí)時(shí)生效比如服務(wù)調(diào)用的超時(shí)時(shí)間、重試次數(shù)、授權(quán)、負(fù)載均衡方式、流控、熔斷、成員權(quán)重、服務(wù)路由策略等等服務(wù)調(diào)用相關(guān)的所有配置，在 RSF 都不是寫死在應(yīng)用側(cè)代碼或配置文件中的，都是

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

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

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

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

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

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

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

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

14、務(wù)治理及監(jiān)控RSF 提供全量服務(wù)調(diào)用統(tǒng)計(jì)信息，以幫助服務(wù)提供方進(jìn)行服務(wù)質(zhì)量的持續(xù)優(yōu)化，服務(wù)調(diào)用的統(tǒng)計(jì)信息包括調(diào)用次數(shù)、失敗率、響應(yīng)時(shí)間（平均 /TP90/TP99/TP999）等核心指標(biāo)，服務(wù)相關(guān)方可以針對(duì)這些核心指標(biāo)設(shè)置安全閥值進(jìn)行告警。RSF 還提供了端到端的完整 trace 能力，可以清晰的看到某一次調(diào)用的各個(gè)時(shí)間點(diǎn)明細(xì)，如調(diào)用方什么時(shí)候發(fā)起的請(qǐng)求，請(qǐng)求什么時(shí)候?qū)懙?socket，請(qǐng)求什么時(shí)間點(diǎn)到達(dá)服務(wù)方節(jié)點(diǎn)，在服務(wù)方線程池中排隊(duì)等待了多長(zhǎng)時(shí)間，什么時(shí)候開始執(zhí)行業(yè)務(wù)代碼，業(yè)務(wù)代碼執(zhí)行了多長(zhǎng)時(shí)間等等。 這些能力對(duì)迅速感知及定位線上問題至關(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é)點(diǎn)注冊(cè)和發(fā)現(xiàn)中心的擴(kuò)展能力及穩(wěn)定性RSF 早期版本的服務(wù)節(jié)點(diǎn)注冊(cè)和發(fā)現(xiàn)模塊基于 ZooKeeper，思路也很簡(jiǎn)單，就是服務(wù)方節(jié)點(diǎn)上線的時(shí)候向 ZK 寫入一個(gè)臨時(shí)節(jié)點(diǎn)，當(dāng)服務(wù)方節(jié)點(diǎn)主動(dòng)下線時(shí)刪除這個(gè)臨時(shí)節(jié)點(diǎn)，當(dāng)服務(wù)方節(jié)點(diǎn)宕機(jī)或其他異常狀況時(shí)，依賴 ZK 的 session timeout 機(jī)制由 ZK ser

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

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

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

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