做集成平臺(tái)這幾年我最大的感觸是方案文檔里的架構(gòu)圖畫(huà)得再漂亮真正決定平臺(tái)好壞的一定是運(yùn)行時(shí)這一層。啟動(dòng)、初始化、裝配這些一次性動(dòng)作做得好只能說(shuō)明設(shè)計(jì)合理而服務(wù)在線上跑起來(lái)之后流量一進(jìn)來(lái)依賴一復(fù)雜各種問(wèn)題才會(huì)浮出水面。這篇是“集成平臺(tái)實(shí)現(xiàn)解釋”系列的第二篇專(zhuān)門(mén)聊運(yùn)行時(shí)視角下的架構(gòu)、服務(wù)和組件。簡(jiǎn)單說(shuō)就是平臺(tái)啟動(dòng)之后服務(wù)之間怎么通信、組件怎么被加載和管理、異常怎么處理、系統(tǒng)怎么保持可用。如果你正在做集成平臺(tái)、中間件或者任何帶插件化、服務(wù)化設(shè)計(jì)的系統(tǒng)這篇內(nèi)容應(yīng)該能幫你少走不少?gòu)澛贰?. 運(yùn)行時(shí)架構(gòu)的整體設(shè)計(jì)思路1.1 為什么運(yùn)行時(shí)架構(gòu)比啟動(dòng)階段更難設(shè)計(jì)第一篇文章里我講過(guò)整個(gè)平臺(tái)的靜態(tài)骨架模塊劃分、接口定義、初始裝配流程。但說(shuō)實(shí)話把服務(wù)注冊(cè)上去、把組件掃描出來(lái)這只是萬(wàn)里長(zhǎng)征第一步。運(yùn)行時(shí)架構(gòu)的核心難點(diǎn)在于系統(tǒng)不再是你可控的“一條直線”它變成了一個(gè)網(wǎng)。每個(gè)服務(wù)都在獨(dú)立運(yùn)行每個(gè)組件都可能被動(dòng)態(tài)加載或卸載任何一條鏈路的抖動(dòng)都可能被放大成整個(gè)平臺(tái)的故障。我見(jiàn)過(guò)不少團(tuán)隊(duì)啟動(dòng)階段做得挺扎實(shí)但運(yùn)行時(shí)架構(gòu)基本沒(méi)設(shè)計(jì)全憑框架自帶能力硬扛。結(jié)果就是服務(wù)間互相調(diào)用靠硬編碼地址組件事件滿天飛沒(méi)人管順序一個(gè)第三方接口變慢把線程池打滿最后整個(gè)平臺(tái)卡死。這些問(wèn)題在架構(gòu)圖上根本看不出來(lái)只能在運(yùn)行時(shí)慢慢暴露。所以我的建議是運(yùn)行時(shí)架構(gòu)要從第一天就開(kāi)始設(shè)計(jì)至少包含三件事服務(wù)間的通信邊界、組件的生命周期管理、以及一個(gè)全局可控的異常與流量治理機(jī)制。這三件事定了運(yùn)行時(shí)的大框架基本就穩(wěn)了。1.2 運(yùn)行時(shí)分層拓?fù)洹⒎?wù)與組件我在實(shí)際項(xiàng)目里喜歡把運(yùn)行時(shí)架構(gòu)拆成三個(gè)視角來(lái)看分別對(duì)應(yīng)三個(gè)層次第一層是運(yùn)行時(shí)拓?fù)鋵咏鉀Q“進(jìn)程和實(shí)例怎么部署”的問(wèn)題。這個(gè)層面關(guān)心的是哪些服務(wù)部署在哪些節(jié)點(diǎn)上有沒(méi)有多副本數(shù)據(jù)狀態(tài)在哪保存是否需要做多活或容災(zāi)。這一層決定了平臺(tái)能抗住多大的流量以及在單點(diǎn)故障時(shí)的恢復(fù)能力。尤其是集成平臺(tái)這種要對(duì)接大量外部系統(tǒng)的中間層拓?fù)湓O(shè)計(jì)不好上游一個(gè)突發(fā)流量就能把整個(gè)平臺(tái)打趴。第二層是服務(wù)層解決“服務(wù)之間怎么調(diào)用、怎么治理”的問(wèn)題。涉及服務(wù)注冊(cè)發(fā)現(xiàn)、負(fù)載均衡、超時(shí)控制、熔斷降級(jí)、重試策略。這一層更像是整個(gè)平臺(tái)的“血管”既要保證正常流通又要在局部堵塞時(shí)不影響全局。第三層是組件層解決“功能模塊怎么被集成、怎么被管理”的問(wèn)題。組件的版本控制、加載順序、依賴關(guān)系、隔離策略全都在這層處理。它是平臺(tái)擴(kuò)展性的體現(xiàn)也是集成平臺(tái)區(qū)別于普通業(yè)務(wù)系統(tǒng)的地方。這三層不是孤立設(shè)計(jì)的拓?fù)鋵訒?huì)影響服務(wù)層的超時(shí)設(shè)置——例如跨機(jī)房調(diào)用和本機(jī)調(diào)用肯定不能用一個(gè)超時(shí)時(shí)間服務(wù)層又會(huì)影響組件層的隔離策略——一個(gè)組件如果內(nèi)部發(fā)了同步調(diào)用那這個(gè)調(diào)用的超時(shí)和熔斷配置必須獨(dú)立可控不能把整個(gè)組件的線程池拖死。設(shè)計(jì)的時(shí)候建議從下往上定拓?fù)鋸纳贤露ㄅ渲脕?lái)回迭代幾輪才會(huì)合理。1.3 三個(gè)必須堅(jiān)守的運(yùn)行時(shí)設(shè)計(jì)原則做運(yùn)行時(shí)架構(gòu)踩的坑多了以后我給自己總結(jié)了幾條必須死守的原則這些原則不一定寫(xiě)在教科書(shū)里但實(shí)戰(zhàn)價(jià)值很高。第一條可觀測(cè)性優(yōu)先于功能性。很多人在設(shè)計(jì)服務(wù)接口時(shí)先想著怎么把功能做出來(lái)日志和指標(biāo)后面再補(bǔ)。運(yùn)行時(shí)架構(gòu)恰恰相反一個(gè)服務(wù)如果沒(méi)有日志、沒(méi)有指標(biāo)、沒(méi)有鏈路追蹤它在生產(chǎn)環(huán)境里等于不存在——出了問(wèn)題上哪查都不知道。我在團(tuán)隊(duì)里定了個(gè)規(guī)矩新服務(wù)上線前第一關(guān)過(guò)的是日志規(guī)范評(píng)審而不是功能測(cè)試。第二條故障必須隔離不允許級(jí)聯(lián)。運(yùn)行時(shí)最怕的事情就是A服務(wù)掛了導(dǎo)致B服務(wù)掛了B又拖垮C最后全網(wǎng)癱瘓。隔離的手段很多包括線程池隔離、信號(hào)量隔離、進(jìn)程隔離、超時(shí)熔斷但手段是次要的關(guān)鍵是要把“不允許級(jí)聯(lián)”當(dāng)成紅線。任何一個(gè)服務(wù)調(diào)用外部依賴時(shí)都必須假設(shè)這個(gè)依賴會(huì)掛并且準(zhǔn)備好降級(jí)方案。第三條一切運(yùn)行時(shí)行為都要可配置、可動(dòng)態(tài)調(diào)整。集成平臺(tái)的使用場(chǎng)景千變?nèi)f化今天對(duì)接的系統(tǒng)吞吐量是100 TPS明天可能就變成1000 TPS。如果超時(shí)時(shí)間、熔斷閾值、線程池大小這些都寫(xiě)死在代碼里那每次流量變化都得發(fā)版代價(jià)太高。我在實(shí)踐中會(huì)把所有運(yùn)行時(shí)參數(shù)都收口到配置中心并支持動(dòng)態(tài)刷新這樣線上調(diào)整閾值不需要重啟服務(wù)接續(xù)能力會(huì)提升很多。2. 服務(wù)層通信、治理與協(xié)議選擇2.1 服務(wù)拆分的兩個(gè)驅(qū)動(dòng)力業(yè)務(wù)邊界與技術(shù)邊界服務(wù)層的第一件事不是把功能做成接口而是把大系統(tǒng)切成合理粒度的服務(wù)。集成平臺(tái)的服務(wù)怎么切我一般只看兩個(gè)驅(qū)動(dòng)力。第一個(gè)是業(yè)務(wù)邊界。集成平臺(tái)里常見(jiàn)的服務(wù)有連接器服務(wù)、數(shù)據(jù)轉(zhuǎn)換服務(wù)、路由分發(fā)服務(wù)、流程編排服務(wù)、監(jiān)控管理服務(wù)。這些服務(wù)各自承擔(dān)清晰的業(yè)務(wù)職責(zé)邊界清楚改動(dòng)時(shí)才不會(huì)你牽我、我牽你。比如連接器服務(wù)負(fù)責(zé)跟外部系統(tǒng)打交道數(shù)據(jù)轉(zhuǎn)換服務(wù)負(fù)責(zé)格式映射兩邊通過(guò)數(shù)據(jù)對(duì)象解耦互不感知對(duì)方內(nèi)部實(shí)現(xiàn)。第二個(gè)是技術(shù)邊界。有些功能雖然在業(yè)務(wù)上是一塊的但技術(shù)特性差異太大硬放一個(gè)服務(wù)里反而互相拖累。舉個(gè)典型例子文件處理和實(shí)時(shí)API調(diào)用就是兩類(lèi)場(chǎng)景——文件處理的瓶頸通常是IO和批量吞吐實(shí)時(shí)接口調(diào)用則更關(guān)注延遲和并發(fā)。這兩類(lèi)服務(wù)實(shí)例的資源需求完全不同拆開(kāi)部署才能分別優(yōu)化。服務(wù)粒度上我踩過(guò)一個(gè)坑一開(kāi)始把服務(wù)切得很細(xì)每個(gè)小功能一個(gè)服務(wù)結(jié)果服務(wù)之間的調(diào)用鏈變長(zhǎng)一次集成要串五六個(gè)服務(wù)延遲翻倍還要處理更多的故障可能。后來(lái)我在團(tuán)隊(duì)里定了條經(jīng)驗(yàn)值一個(gè)服務(wù)的核心職責(zé)不要超過(guò)兩三個(gè)。過(guò)細(xì)的按功能拆分只適用于團(tuán)隊(duì)規(guī)模很大的情況團(tuán)隊(duì)不夠大時(shí)服務(wù)太多反而治理成本吃掉收益。2.2 同步與異步通信方式怎么選服務(wù)之間的通信方式直接影響整個(gè)平臺(tái)的響應(yīng)模式和故障傳播方式。集成平臺(tái)里同步通信和異步通信都會(huì)用到關(guān)鍵是在合適的地方用合適的模式。同步通信典型的如REST、gRPC適合需要即時(shí)拿到結(jié)果的場(chǎng)景。比如用戶在頁(yè)面上觸發(fā)一次集成任務(wù)他需要知道這次觸發(fā)成沒(méi)成那就走同步接口。同步通信的優(yōu)點(diǎn)是很直觀鏈路清晰出問(wèn)題好排查缺點(diǎn)是調(diào)用方必須等被調(diào)用方返回一旦超時(shí)沒(méi)設(shè)好線程就會(huì)被長(zhǎng)時(shí)間占用。異步通信典型的如消息隊(duì)列適合不要求即時(shí)響應(yīng)的場(chǎng)景。比如對(duì)接的文件到了之后要轉(zhuǎn)數(shù)據(jù)、寫(xiě)庫(kù)、觸發(fā)后續(xù)流程每一步都不需要用戶盯在那里等結(jié)果走消息隊(duì)列最合適。異步可以削峰填谷——外部系統(tǒng)打進(jìn)來(lái)10000條消息平臺(tái)消化能力只有2000 TPS消息隊(duì)列能在中間緩沖流量平緩地過(guò)。同時(shí)異步也天然實(shí)現(xiàn)了服務(wù)解耦生產(chǎn)者不感知消費(fèi)者的存在。不過(guò)異步引入的復(fù)雜度不可小覷。消息的順序如何保證消息重復(fù)投遞如何做冪等消息積壓怎么預(yù)警這些都是異步架構(gòu)的常見(jiàn)難題。我的建議是能用同步解決的就別上異步異步一定要有明確理由——比如流量削峰、多系統(tǒng)解耦、或者長(zhǎng)耗時(shí)任務(wù)的拆分。2.3 治理三板斧注冊(cè)發(fā)現(xiàn)、熔斷降級(jí)與動(dòng)態(tài)配置服務(wù)一旦多起來(lái)就必須上治理手段。我用得最順手的治理工具有三個(gè)。服務(wù)注冊(cè)與發(fā)現(xiàn)是第一板斧。服務(wù)實(shí)例啟動(dòng)時(shí)把自己的地址注冊(cè)到注冊(cè)中心消費(fèi)方通過(guò)名字拿到可用地址列表而不是在代碼里寫(xiě)死IP端口。這樣服務(wù)擴(kuò)容縮容甚至某臺(tái)機(jī)器宕機(jī)消費(fèi)方都能通過(guò)健康檢查機(jī)制及時(shí)感知和摘除故障節(jié)點(diǎn)。市面上這一類(lèi)的開(kāi)源組件很多重要的是理解它背后的機(jī)制臨時(shí)節(jié)點(diǎn)、心跳續(xù)約、服務(wù)下線通知這套機(jī)制決定了服務(wù)發(fā)現(xiàn)的時(shí)效性。熔斷與降級(jí)是第二板斧。我見(jiàn)過(guò)最典型的場(chǎng)景是平臺(tái)對(duì)接的某個(gè)外部ERP系統(tǒng)變慢了每次響應(yīng)要30秒導(dǎo)致調(diào)用它的集成任務(wù)線程被占滿線程池耗盡后連本地操作都處理不了。上了熔斷機(jī)制后當(dāng)外部依賴的錯(cuò)誤率或延遲超過(guò)閾值后續(xù)請(qǐng)求直接快速失敗不再傻等外部系統(tǒng)恢復(fù)。與此同時(shí)降級(jí)方案頂上——比如從實(shí)時(shí)同步調(diào)用改成先落庫(kù)后臺(tái)慢慢重試。熔斷是我在所有集成平臺(tái)服務(wù)里優(yōu)先要求部署的能力沒(méi)有熔斷的集成平臺(tái)上線就是裸奔。動(dòng)態(tài)配置是第三板斧。前面我提過(guò)所有運(yùn)行時(shí)參數(shù)必須可動(dòng)態(tài)調(diào)整。不只是超時(shí)時(shí)間、熔斷閾值、線程池大小還包括路由規(guī)則、功能開(kāi)關(guān)、轉(zhuǎn)換映射表。這些參數(shù)統(tǒng)一放到配置中心管理配置變更推送到服務(wù)服務(wù)本地?zé)峒虞d。一套好用的動(dòng)態(tài)配置機(jī)制能讓你在線上應(yīng)對(duì)突發(fā)流量時(shí)從容很多。我甚至?xí)涯承?yīng)急預(yù)案比如強(qiáng)制切到降級(jí)模式、關(guān)閉非核心組件直接做成配置項(xiàng)一鍵下發(fā)而不是臨時(shí)去服務(wù)器上敲命令。3. 組件模型從加載到銷(xiāo)毀3.1 組件的定義與邊界劃分集成平臺(tái)的第三層是組件層。組件的本質(zhì)是把一個(gè)相對(duì)獨(dú)立的功能膠囊化讓它可以被動(dòng)態(tài)安裝、啟動(dòng)、停止和卸載。我做過(guò)的一個(gè)集成平臺(tái)里典型的組件包括定時(shí)任務(wù)組件、事件監(jiān)聽(tīng)組件、數(shù)據(jù)轉(zhuǎn)換器組件、連接器適配器組件。組件設(shè)計(jì)要遵守的一條鐵律是組件之間必須通過(guò)容器提供的接口通信不允許直接互相調(diào)用內(nèi)部類(lèi)。否則兩個(gè)組件一旦產(chǎn)生編譯期依賴卸載A組件就會(huì)導(dǎo)致B組件引用缺失平臺(tái)的動(dòng)態(tài)性就完全喪失了。我在實(shí)踐里會(huì)把組件接口單獨(dú)放一個(gè)工程只定義契約不寫(xiě)實(shí)現(xiàn)所有組件依賴這個(gè)契約工程。這樣即使某個(gè)組件被卸載其他組件最多是找不到實(shí)現(xiàn)而不是直接報(bào)類(lèi)加載錯(cuò)誤。3.2 生命周期狀態(tài)機(jī)注冊(cè)-加載-啟用-停用-卸載組件生命周期管理是運(yùn)行時(shí)架構(gòu)里技術(shù)含量最高的部分之一。我通常把組件生命周期分成五個(gè)狀態(tài)做成狀態(tài)機(jī)來(lái)控制。注冊(cè)狀態(tài)對(duì)應(yīng)的是組件包上傳到平臺(tái)倉(cāng)庫(kù)但還沒(méi)加載到運(yùn)行環(huán)境。加載狀態(tài)是把組件代碼裝載進(jìn)容器做依賴檢查、生成運(yùn)行時(shí)對(duì)象。啟用狀態(tài)是組件正式對(duì)外提供能力的階段事件監(jiān)聽(tīng)開(kāi)始生效定時(shí)任務(wù)開(kāi)始調(diào)度。停用狀態(tài)是組件從運(yùn)行狀態(tài)退下來(lái)但還保留在容器里。卸載狀態(tài)則是徹底從容器中移除釋放所有資源。這個(gè)狀態(tài)機(jī)設(shè)計(jì)的價(jià)值在于我們可以安全地做“停用→升級(jí)→再啟用”的無(wú)縫操作不需要重啟平臺(tái)也可以在組件出問(wèn)題時(shí)先停用止血再排查根因。我在實(shí)際運(yùn)維中經(jīng)常用停用功能來(lái)做“瞬時(shí)隔離”——某個(gè)組件對(duì)接的外部系統(tǒng)出故障了我先把它停用它就不再接收新任務(wù)整個(gè)平臺(tái)的其他部分不受影響。狀態(tài)機(jī)里最容易被忽視的是狀態(tài)遷移的鉤子函數(shù)。你需要在啟用前準(zhǔn)備資源、在停用時(shí)優(yōu)雅釋放資源、在卸載時(shí)清理游街垃圾。如果鉤子做不好組件反復(fù)啟停幾次內(nèi)存就泄漏到OutOfMemory了這樣的問(wèn)題極其隱蔽通常要到高頻運(yùn)維時(shí)才會(huì)暴露。3.3 組件通信的三條路徑組件雖然獨(dú)立部署和加載但它們是同一個(gè)平臺(tái)內(nèi)的協(xié)作單元通信在所難免。我把組件通信方式歸納成三條路徑再?gòu)?fù)雜的組件協(xié)作也是這三條的變種。第一條路徑是定向接口調(diào)用。組件A需要組件B的某個(gè)能力時(shí)通過(guò)容器拿到B的代理對(duì)象直接調(diào)方法這是最常用的通信方式。這里的關(guān)鍵是容器要提供接口代理的透明獲取機(jī)制讓組件代碼里只用聲明“我需要X接口”容器運(yùn)行時(shí)把正確的實(shí)現(xiàn)注入進(jìn)去——這一設(shè)計(jì)能讓組件開(kāi)發(fā)者和服務(wù)調(diào)用方之間保持極低耦合。第二條路徑是事件總線。平臺(tái)有一個(gè)全局消息事件中心任何組件都可以發(fā)布事件也可以訂閱感興趣的事件。組件A發(fā)布“訂單創(chuàng)建完成”事件組件B和組件C各自訂閱并做自己的處理——特別適合從一個(gè)業(yè)務(wù)動(dòng)作觸發(fā)多個(gè)組件并行協(xié)同的場(chǎng)景。事件總線的實(shí)現(xiàn)要特別注意異常隔離單個(gè)訂閱方處理失敗不能阻塞事件分發(fā)主流程否則就是牽一發(fā)動(dòng)全身。第三條路徑是共享數(shù)據(jù)存儲(chǔ)。組件可以把中間結(jié)果寫(xiě)入平臺(tái)的共享存儲(chǔ)比如分布式緩存或數(shù)據(jù)庫(kù)其他組件可以按需讀取或修改。這個(gè)方式適合無(wú)狀態(tài)、可重放的協(xié)作模式但要注意設(shè)計(jì)數(shù)據(jù)版本和一致性校驗(yàn)否則多個(gè)組件同時(shí)讀寫(xiě)同一個(gè)數(shù)據(jù)對(duì)象時(shí)很容易出現(xiàn)互相覆蓋的競(jìng)態(tài)問(wèn)題。3.4 動(dòng)態(tài)組件加載的落地細(xì)節(jié)動(dòng)態(tài)加載是組件機(jī)制的亮點(diǎn)也是坑最多的地方。在Java平臺(tái)我用得最多的技術(shù)棧里動(dòng)態(tài)加載通常用獨(dú)立的ClassLoader來(lái)實(shí)現(xiàn)。每個(gè)組件一個(gè)ClassLoader加載自己依賴的jar包這樣多個(gè)組件就能共存同一接口的不同版本。但動(dòng)態(tài)加載也給我上了深刻的幾課。第一課是類(lèi)加載器泄漏——組件卸載時(shí)如果它的某個(gè)靜態(tài)變量被外部持有了引用這個(gè)組件的ClassLoader永遠(yuǎn)無(wú)法被回收每次升級(jí)都會(huì)泄漏一份內(nèi)存。排查這種問(wèn)題時(shí)很痛苦通常只有通過(guò)堆轉(zhuǎn)儲(chǔ)分析才能定位到是哪個(gè)長(zhǎng)生命周期對(duì)象擋了道。我的對(duì)策是在平臺(tái)層面加強(qiáng)規(guī)范組件代碼里禁止使用靜態(tài)集合保存運(yùn)行時(shí)數(shù)據(jù)必須由容器生命周期回調(diào)統(tǒng)一清理。第二課是依賴沖突。組件A依賴的JSON庫(kù)是版本2組件B用的是版本3如果它們的類(lèi)加載器是隔離的兩個(gè)版本可以共存但如果某個(gè)地方還在用平臺(tái)的公共類(lèi)加載器加載JSON類(lèi)兩種版本就會(huì)沖突。我的方案是公共類(lèi)加載器只常駐平臺(tái)核心類(lèi)業(yè)務(wù)類(lèi)和第三方庫(kù)一律放進(jìn)組件隔離區(qū)寧可重復(fù)加載也要保證互不干擾。組件加載順序也是細(xì)節(jié)中的細(xì)節(jié)。有依賴關(guān)系的組件必須等依賴方啟用后自己再啟用。我通常會(huì)讓容器根據(jù)組件的聲明式依賴描述生成一張依賴圖按拓?fù)湫蚣虞d若遇到循環(huán)依賴直接啟動(dòng)失敗并輸出清晰的錯(cuò)誤信息。畢竟是集成平臺(tái)每天有大量的組件接入和退出加載過(guò)程不能含糊。4. 部署形態(tài)與高可用實(shí)踐4.1 幾種部署形態(tài)的取舍集成平臺(tái)的部署形態(tài)直接決定了運(yùn)維方式和故障邊界。我用過(guò)幾種常見(jiàn)的形態(tài)各有優(yōu)劣。單機(jī)一體式部署最簡(jiǎn)單就是把所有服務(wù)、組件裝在一個(gè)進(jìn)程里跑。優(yōu)點(diǎn)是開(kāi)發(fā)調(diào)試方便一套環(huán)境就能跑起來(lái)缺點(diǎn)是故障隔離性差任何組件的OOM或者死循環(huán)都可能拖垮整個(gè)平臺(tái)。我的判斷是單體形態(tài)只適合開(kāi)發(fā)環(huán)境、演示環(huán)境或者規(guī)模很小的私有化交付項(xiàng)目——尤其當(dāng)項(xiàng)目組成員不多時(shí)過(guò)度拆分部署反而增加運(yùn)維負(fù)擔(dān)。集群分布式部署是目前集成平臺(tái)的主流形態(tài)。平臺(tái)的核心服務(wù)多副本部署前面對(duì)接負(fù)載均衡入口流量分發(fā)到多個(gè)實(shí)例單個(gè)實(shí)例掛掉不影響整體。這種形態(tài)要求服務(wù)本身無(wú)狀態(tài)或者狀態(tài)能外置到共享存儲(chǔ)。我做集成平臺(tái)時(shí)會(huì)把執(zhí)行引擎設(shè)計(jì)成“無(wú)狀態(tài)調(diào)度持久化任務(wù)狀態(tài)”的模式這樣任意一個(gè)引擎實(shí)例崩潰任務(wù)可以從斷點(diǎn)續(xù)跑不需要人工干預(yù)。混合形態(tài)也比較常見(jiàn)尤其是跟外部系統(tǒng)做本地化對(duì)接時(shí)。比如某些數(shù)據(jù)源只能通過(guò)內(nèi)網(wǎng)地址訪問(wèn)你可能就需要在靠近數(shù)據(jù)源的網(wǎng)絡(luò)區(qū)域部署一個(gè)輕量代理節(jié)點(diǎn)這個(gè)代理節(jié)點(diǎn)和主集群通過(guò)異步消息同步狀態(tài)。這種形態(tài)犧牲了一些一致性但換來(lái)了跨網(wǎng)絡(luò)的可用性實(shí)操中很管用。4.2 多實(shí)例部署的難點(diǎn)狀態(tài)不落地與一致性協(xié)同多實(shí)例部署要把“狀態(tài)”當(dāng)成頭等大事來(lái)對(duì)待。集成平臺(tái)里哪些狀態(tài)最容易出問(wèn)題我列幾個(gè)典型的待執(zhí)行的任務(wù)隊(duì)列、定時(shí)任務(wù)的運(yùn)行狀態(tài)、正在處理的文件游標(biāo)位置、以及組件實(shí)例的注冊(cè)數(shù)據(jù)。我的基本設(shè)計(jì)原則是運(yùn)行時(shí)狀態(tài)盡量外置。任務(wù)隊(duì)列放分布式隊(duì)列共享可變數(shù)據(jù)放分布式緩存或數(shù)據(jù)庫(kù)組件的注冊(cè)數(shù)據(jù)放注冊(cè)中心。每個(gè)計(jì)算節(jié)點(diǎn)只保留純執(zhí)行線程的東西不保留業(yè)務(wù)中間狀態(tài)。這樣即使一個(gè)節(jié)點(diǎn)整機(jī)宕掉其他節(jié)點(diǎn)也能接管它的任務(wù)——前提是任務(wù)元數(shù)據(jù)已經(jīng)持久化。我見(jiàn)過(guò)因?yàn)榘讶蝿?wù)狀態(tài)放在本地內(nèi)存宕機(jī)后整個(gè)待處理清單全丟的情況復(fù)盤(pán)時(shí)數(shù)據(jù)恢復(fù)花了一整天那是刻骨銘心的教訓(xùn)。一致性協(xié)同是多實(shí)例的另一個(gè)難點(diǎn)。兩個(gè)執(zhí)行節(jié)點(diǎn)不能同時(shí)處理同一批數(shù)據(jù)所以要用分布式鎖來(lái)做互斥控制。這個(gè)鎖的實(shí)現(xiàn)要慎重別用那種簡(jiǎn)單粗暴搶鎖、死等超時(shí)的方案。我建議用帶租約的分布式鎖鎖持有者要定期續(xù)約避免持鎖節(jié)點(diǎn)崩潰導(dǎo)致鎖長(zhǎng)期不被釋放。所有涉及到錢(qián)、庫(kù)存、排他性資源的集成任務(wù)我都會(huì)在這個(gè)鎖上花心思它撐住了就是把平臺(tái)撐住了。4.3 容錯(cuò)策略超時(shí)、重試與冪等設(shè)計(jì)運(yùn)行時(shí)高可用的前臺(tái)靠的是負(fù)載均衡后臺(tái)靠的是容錯(cuò)策略。容錯(cuò)策略我通常按四個(gè)維度來(lái)設(shè)計(jì)。超時(shí)控制是第一個(gè)維度也是最基礎(chǔ)的一層。任何對(duì)外調(diào)用、組件間調(diào)用、隊(duì)列消費(fèi)都必須設(shè)置超時(shí)時(shí)間不允許“永遠(yuǎn)等下去”。超時(shí)值的選擇要結(jié)合實(shí)測(cè)數(shù)據(jù)而不是拍腦袋。我一般的做法是用壓測(cè)數(shù)據(jù)取P99響應(yīng)時(shí)間再乘以3到5倍留出緩沖。我見(jiàn)過(guò)項(xiàng)目里把超時(shí)設(shè)成30秒結(jié)果外部接口正常P99只要200毫秒故障時(shí)直接把所有線程拖死。這類(lèi)經(jīng)驗(yàn)教訓(xùn)告訴我超時(shí)不是越大越安全而是跟業(yè)務(wù)響應(yīng)模型匹配才叫安全。重試是第二個(gè)維度但要特別謹(jǐn)慎。重試只適合處理“瞬時(shí)故障”——網(wǎng)絡(luò)閃斷、連接池短暫無(wú)可用連接。如果外部接口是超時(shí)或業(yè)務(wù)錯(cuò)誤重試反而會(huì)加重對(duì)方系統(tǒng)壓力甚至造成重復(fù)數(shù)據(jù)。我在團(tuán)隊(duì)里的重試規(guī)范是只對(duì)冪等操作做自動(dòng)重試最多重試2次并且退避策略用指數(shù)退避加隨機(jī)抖動(dòng)。千萬(wàn)別寫(xiě)那種“失敗就每隔1秒重試直到成功”的邏輯那要么把自己打死要么把下游打死。冪等設(shè)計(jì)是第三個(gè)維度也是集成平臺(tái)到萬(wàn)不得已必定要用的兜底手段。外部系統(tǒng)可能重復(fù)推送消息、平臺(tái)重試消費(fèi)同一批數(shù)據(jù)如果處理邏輯不冪等就會(huì)造成數(shù)據(jù)翻倍或狀態(tài)錯(cuò)亂。我通常要求所有集成處理邏輯提供業(yè)務(wù)唯一鍵訂單號(hào)、流水號(hào)、事件ID處理前先查重處理中把處理狀態(tài)存在共享存儲(chǔ)里。有了冪等重試才能安心執(zhí)行沒(méi)有冪等什么高級(jí)容錯(cuò)策略都像走鋼絲。降級(jí)是第四個(gè)維度也是最體現(xiàn)架構(gòu)功力的一層。降級(jí)不是系統(tǒng)崩潰后的補(bǔ)救而是預(yù)案中的主動(dòng)選擇。比如大促時(shí)非核心的報(bào)表推送組件可以暫停外部系統(tǒng)過(guò)載時(shí)文件處理可以切換成批量延遲模式。我的做法是提前給組件和服務(wù)打上“核心”和“非核心”標(biāo)級(jí)給外部依賴也標(biāo)上等級(jí)。線上一旦觸發(fā)熔斷非核心依賴直接刪保核心鏈路。降級(jí)開(kāi)關(guān)不能只是代碼里有運(yùn)維手冊(cè)里也要寫(xiě)清楚“什么情況按哪個(gè)開(kāi)關(guān)、預(yù)期效果是什么”。4.4 可觀測(cè)性的三根支柱日志、指標(biāo)、鏈路高可用不是靠信心而是靠可觀測(cè)性。運(yùn)行時(shí)發(fā)生問(wèn)題如果連定位的手段都沒(méi)有架構(gòu)再漂亮也只是擺設(shè)。關(guān)于可觀測(cè)性我的核心經(jīng)驗(yàn)是三個(gè)字標(biāo)準(zhǔn)化。日志標(biāo)準(zhǔn)化是最基本的要求。所有服務(wù)無(wú)論什么模塊日志格式必須統(tǒng)一時(shí)間、級(jí)別、服務(wù)名、實(shí)例ID、追蹤ID、業(yè)務(wù)維度信息客戶ID、訂單ID、消息體。我曾經(jīng)在處理線上問(wèn)題時(shí)因?yàn)槟硞€(gè)組件的日志里沒(méi)有打追蹤ID只能靠時(shí)間戳硬猜排查效率低到讓人崩潰。現(xiàn)在我在任何地方都嚴(yán)格沿用追蹤ID透?jìng)鞯囊?guī)范每個(gè)集成交互在入口生成一個(gè)全局唯一ID所有相關(guān)服務(wù)日志都帶上這個(gè)ID鏈路一下就串起來(lái)了。指標(biāo)監(jiān)控是第二根支柱。集成平臺(tái)最重要的指標(biāo)有幾類(lèi)接入服務(wù)的請(qǐng)求量、成功率、P99延遲線程池活躍數(shù)和隊(duì)列深度消息隊(duì)列的積壓數(shù)量熔斷器當(dāng)前的狀態(tài)開(kāi)/半開(kāi)/關(guān)以及JVM的GC和內(nèi)存水位。這些指標(biāo)用一套標(biāo)準(zhǔn)化的格式暴露出來(lái)接入統(tǒng)一監(jiān)控平臺(tái)配好告警規(guī)則就能在故障惡化之前收到警報(bào)。我的告警原則是告警寧可多配幾條觸發(fā)條件也不要漏配一條關(guān)鍵場(chǎng)景。分布式鏈路追蹤是第三根支柱。集成平臺(tái)的每次集成任務(wù)可能跨多個(gè)服務(wù)、多個(gè)組件甚至跨多個(gè)外部系統(tǒng)。鏈路追蹤能把一次調(diào)用在所有服務(wù)里的執(zhí)行軌跡串起來(lái)從發(fā)出請(qǐng)求到每一步耗時(shí)都一目了然。這項(xiàng)能力在優(yōu)化響應(yīng)慢的集成任務(wù)時(shí)特別有用比如發(fā)現(xiàn)一次任務(wù)總耗時(shí)2秒通過(guò)鏈路一看1.8秒花在了某個(gè)外部系統(tǒng)等待上該調(diào)超時(shí)還是該換對(duì)接方案立刻就有依據(jù)了。5. 典型運(yùn)行時(shí)問(wèn)題與排查實(shí)戰(zhàn)5.1 高頻故障一線程池被打滿之后發(fā)生了什么這是集成平臺(tái)運(yùn)行時(shí)最常見(jiàn)、也最危險(xiǎn)的故障我碰到不下十次。癥狀是用戶反饋平臺(tái)響應(yīng)越來(lái)越慢最后所有集成任務(wù)全部超時(shí)點(diǎn)擊頁(yè)面按鈕都轉(zhuǎn)圈。排查路徑其實(shí)很固定。第一步看線程池指標(biāo)如果活躍線程數(shù)接近最大值并且隊(duì)列持續(xù)積壓基本可以斷定是某個(gè)依賴調(diào)用被堵住了。第二步看當(dāng)前線程棧用線程轉(zhuǎn)儲(chǔ)看看那些忙碌的線程卡在哪個(gè)調(diào)用上——這一步能直接鎖定是哪個(gè)外部依賴或哪個(gè)組件拖慢了節(jié)奏。第三步確認(rèn)依賴的響應(yīng)時(shí)間指標(biāo)如果確實(shí)變慢或報(bào)錯(cuò)立刻開(kāi)熔斷降級(jí)開(kāi)關(guān)先止損再排查外部接口的問(wèn)題。這類(lèi)問(wèn)題給我的核心啟示是線程池配置絕不能“一次設(shè)置永久不管”。線程池大小、隊(duì)列容量、拒絕策略都要根據(jù)實(shí)際流量和依賴延遲做動(dòng)態(tài)調(diào)整。所以我在前面強(qiáng)調(diào)的動(dòng)態(tài)配置在這里就是救命稻草——線上發(fā)現(xiàn)線程池太小直接改配置刷下去不需要發(fā)版平臺(tái)立刻恢復(fù)正常吞吐。5.2 高頻故障二組件版本沖突和升級(jí)后異常組件化平臺(tái)的另一個(gè)典型問(wèn)題是版本沖突。具體場(chǎng)景是運(yùn)維升級(jí)了某個(gè)組件其他組件對(duì)該組件的調(diào)用開(kāi)始報(bào)方法找不到、類(lèi)轉(zhuǎn)換錯(cuò)誤或者NoSuchMethodError。這種錯(cuò)誤最迷惑的地方在于——編譯期完全沒(méi)提示只有運(yùn)行到真實(shí)調(diào)用才炸出來(lái)。排查思路是先看報(bào)錯(cuò)堆棧中涉及的類(lèi)是從哪個(gè)ClassLoader加載的確認(rèn)幾個(gè)相關(guān)組件各自加載的是哪個(gè)版本的依賴包。通常沖突根源是兩個(gè)組件的傳遞依賴引入了同一個(gè)第三方庫(kù)的不同版本而公共區(qū)域的類(lèi)加載器優(yōu)先加載了其中一個(gè)。解決辦法是用組件隔離機(jī)制或者統(tǒng)一平臺(tái)級(jí)依賴清單把常用第三方庫(kù)做成受控版本組件側(cè)不允許再自己拉這些庫(kù)的另一個(gè)版本。升級(jí)組件后出現(xiàn)異常還有一個(gè)隱藏問(wèn)題——緩存。有些平臺(tái)會(huì)把組件接口反射信息、路由規(guī)則、序列化器緩存起來(lái)如果升級(jí)后的組件結(jié)構(gòu)變化了而未清掉舊緩存可能一直拿到舊結(jié)構(gòu)導(dǎo)致字段對(duì)不上。我在實(shí)際運(yùn)維中會(huì)把“組件升級(jí)后必須清運(yùn)行時(shí)緩存”寫(xiě)進(jìn)操作手冊(cè)的第一條省了很多冤枉時(shí)間。5.3 高頻故障三鏈路超時(shí)定位與瓶頸優(yōu)化集成平臺(tái)慢問(wèn)題只比故障好一點(diǎn)但同樣惱人。用戶說(shuō)“集成任務(wù)跑得慢”你得知道慢在哪一環(huán)。我的做法是先接鏈路追蹤把一次集成的時(shí)間拆成幾段入口接收耗時(shí)、轉(zhuǎn)換邏輯耗時(shí)、外部系統(tǒng)調(diào)用耗時(shí)、消息落庫(kù)耗時(shí)。有一次線上優(yōu)化發(fā)現(xiàn)一個(gè)集成任務(wù)P99延遲需要4秒客戶明確說(shuō)這不行。鏈路一追蹤發(fā)現(xiàn)外部系統(tǒng)調(diào)用只占600毫秒但數(shù)據(jù)轉(zhuǎn)換邏輯花了2.8秒——問(wèn)題出在轉(zhuǎn)換器里某個(gè)循環(huán)處理大量數(shù)據(jù)且頻繁做類(lèi)型轉(zhuǎn)換和反射調(diào)用。優(yōu)化思路很直白把反射調(diào)用換成預(yù)編譯好的適配代碼循環(huán)內(nèi)的重復(fù)計(jì)算提到循環(huán)外再把大對(duì)象分段處理。優(yōu)化后P99降到1.1秒客戶地方非常滿意。鏈路超時(shí)定位的經(jīng)驗(yàn)是不要上來(lái)就懷疑外部依賴也不要先懷疑代碼性能讓數(shù)據(jù)說(shuō)話。數(shù)據(jù)本身會(huì)告訴你瓶頸在哪一層。同時(shí)要注意鏈路數(shù)據(jù)要有采樣和保存策略——全量保存成本太高我會(huì)在正常流量時(shí)按1%采樣在發(fā)生告警或特定客戶時(shí)開(kāi)啟全量追蹤這樣效率和成本兼顧。5.4 運(yùn)維排查的基礎(chǔ)工具清單排查運(yùn)行時(shí)問(wèn)題手上要有一份趁手的工具清單。我從實(shí)際使用體驗(yàn)出發(fā)整理一個(gè)最低限度的組合日志檢索平臺(tái)用來(lái)快速過(guò)濾追蹤ID是所有排查的基礎(chǔ)監(jiān)控面板負(fù)責(zé)看趨勢(shì)和指標(biāo)比如線程池、錯(cuò)誤率、積壓量在什么時(shí)間點(diǎn)開(kāi)始惡化鏈路追蹤系統(tǒng)用來(lái)完整還原一次請(qǐng)求的執(zhí)行路徑回答“到底慢在哪”。這三件套必須配齊缺一個(gè)都會(huì)讓排查效率減半。針對(duì)Java平臺(tái)我會(huì)額外用線程轉(zhuǎn)儲(chǔ)工具分析線程卡點(diǎn)用堆轉(zhuǎn)儲(chǔ)工具排查內(nèi)存泄漏。線上內(nèi)存緩漲不降通常是某個(gè)組件持有對(duì)象不釋放此時(shí)必須抓一份堆轉(zhuǎn)儲(chǔ)離線分析看大對(duì)象分布和引用鏈。這些工具平時(shí)用不到但關(guān)鍵故障一發(fā)生它們就是唯一能救場(chǎng)的家伙。提示所有排查工具和策略都要提前演練不要等出故障了再臨時(shí)學(xué)。我每季度會(huì)安排一次故障演練人為制造一個(gè)線程池打滿場(chǎng)景讓運(yùn)維同學(xué)按照預(yù)案走一遍。實(shí)戰(zhàn)過(guò)的團(tuán)隊(duì)和沒(méi)實(shí)戰(zhàn)過(guò)的團(tuán)隊(duì)面對(duì)同一故障時(shí)的判斷速度差距非常明顯。6. 從架構(gòu)圖到落地運(yùn)行時(shí)是最誠(chéng)實(shí)的試金石做了這么多年集成平臺(tái)我越來(lái)越覺(jué)得架構(gòu)設(shè)計(jì)其實(shí)分兩層一層是畫(huà)出來(lái)的架構(gòu)一層是運(yùn)行時(shí)跑出來(lái)的架構(gòu)。畫(huà)出來(lái)的架構(gòu)講究對(duì)稱、整潔、分層清晰運(yùn)行時(shí)跑出來(lái)的架構(gòu)則要面對(duì)超時(shí)、重試、隔離、并發(fā)、失敗恢復(fù)這些無(wú)比現(xiàn)實(shí)的問(wèn)題。工程師最容易犯的毛病是只在第一層用力卻忽略第二層的復(fù)雜和風(fēng)險(xiǎn)。我個(gè)人最深的體會(huì)是運(yùn)行時(shí)架構(gòu)的成功不在于用了多新潮的技術(shù)、多復(fù)雜的組件體系而在于把基礎(chǔ)功課做到位——服務(wù)的超時(shí)有依據(jù)熔斷的閾值有數(shù)據(jù)支撐組件的生命周期沒(méi)有資源泄漏日志和鏈路在手狀態(tài)不落地且可恢復(fù)。做到這些平臺(tái)不一定驚艷但一定省心做不到這些哪怕架構(gòu)圖上畫(huà)得再完美流量一來(lái)原型畢露。集成平臺(tái)的核心價(jià)值是把復(fù)雜的集成場(chǎng)景沉淀成可復(fù)用的能力而運(yùn)行時(shí)架構(gòu)恰恰是這個(gè)價(jià)值的守門(mén)員。它不顯眼甚至在穩(wěn)定運(yùn)行時(shí)你幾乎感覺(jué)不到它的存在。但正是這些日?？赡鼙缓雎缘募?xì)節(jié)決定了平臺(tái)能在多大流量、多復(fù)雜的故障場(chǎng)景下依然穩(wěn)得住。希望這篇總結(jié)能幫你少踩一些我正在踩的坑把你的集成平臺(tái)做得更扎實(shí)。