1. 從“夾心層”說起中間層到底在解決什么問題但凡做過稍微復(fù)雜一點(diǎn)系統(tǒng)的人遲早都會(huì)撞上“中間層”這個(gè)詞。它有時(shí)候叫中間件有時(shí)候叫適配層有時(shí)候叫服務(wù)層還有的時(shí)候干脆被含糊地稱為“那一層”。名字五花八門但本質(zhì)說的是同一件事在兩個(gè)原本不該直接打交道的東西之間硬生生插進(jìn)去的一層。我最早對(duì)中間層產(chǎn)生實(shí)感是做一個(gè)數(shù)據(jù)同步的小工具。上游是一個(gè)定時(shí)吐數(shù)據(jù)的接口下游是一個(gè)結(jié)構(gòu)完全不同的存儲(chǔ)系統(tǒng)。最直覺的做法是在同步邏輯里直接寫轉(zhuǎn)換代碼字段對(duì)字段類型對(duì)類型幾十行搞定。當(dāng)時(shí)覺得挺美直到上游改了一次字段命名下游又換了一次存儲(chǔ)格式那幾十行代碼瞬間變成了一團(tuán)亂麻改一處崩三處。后來我把轉(zhuǎn)換邏輯單獨(dú)抽出來上游只管把原始數(shù)據(jù)丟進(jìn)來下游只管從這層拿已經(jīng)規(guī)整好的數(shù)據(jù)兩邊互不感知對(duì)方的存在。那一刻我才真正理解中間層的第一價(jià)值不是“多寫一層代碼”而是把變化隔離在一個(gè)可控的范圍內(nèi)。這件事聽起來簡(jiǎn)單但真正理解它的人并不多。很多人一聽到“加一層”就本能地反感覺得是過度設(shè)計(jì)是沒事找事。這種反感在項(xiàng)目早期是合理的因?yàn)樵缙谧兓?、參與者少直接調(diào)用確實(shí)最省事。但系統(tǒng)的復(fù)雜度不是線性增長(zhǎng)的它是隨著參與方數(shù)量、變化頻率、以及各方對(duì)彼此穩(wěn)定性的依賴程度一起往上走的。當(dāng)上游有五個(gè)團(tuán)隊(duì)在改下游有三個(gè)系統(tǒng)在消費(fèi)中間還夾著歷史包袱和不同步的發(fā)布節(jié)奏時(shí)沒有中間層的系統(tǒng)就會(huì)變成一場(chǎng)災(zāi)難。所以中間層要解決的核心問題可以歸結(jié)成三個(gè)詞解耦、適配、收斂。解耦是讓兩邊不互相依賴適配是讓兩邊的差異在這層被消化掉收斂是把散落在各處的重復(fù)邏輯集中到一處管理。這三個(gè)詞聽著像教科書但每一個(gè)背后都是血淚。我見過太多項(xiàng)目前期為了快把適配邏輯散落在調(diào)用方結(jié)果同一個(gè)轉(zhuǎn)換規(guī)則在七八個(gè)地方各寫了一遍改一個(gè)業(yè)務(wù)規(guī)則要翻遍整個(gè)代碼庫(kù)。這就是沒有中間層的代價(jià)。還有一個(gè)容易被忽略的點(diǎn)中間層其實(shí)是契約的載體。兩個(gè)系統(tǒng)直接對(duì)接時(shí)契約是隱式的藏在雙方的代碼里誰也不知道對(duì)方到底依賴了自己哪些字段、哪些行為。而一旦有了中間層契約就變成了顯式的、可以被文檔化、可以被測(cè)試、可以被版本管理的東西。這一點(diǎn)在多人協(xié)作里價(jià)值巨大因?yàn)樗选拔乙詾槟阒馈弊兂闪恕鞍准埡谧謱懬宄薄?. 中間層的幾種典型形態(tài)與它們的適用邊界中間層不是一個(gè)固定的東西它隨著場(chǎng)景變化會(huì)呈現(xiàn)出完全不同的形態(tài)。我大致把它歸成幾類每一類都有自己最適合的土壤也有自己容易翻車的地方。2.1 數(shù)據(jù)轉(zhuǎn)換型中間層字段映射與格式歸一這是最常見的一種。上游給的是A格式下游要的是B格式中間層負(fù)責(zé)把A翻譯成B。聽起來很無聊但魔鬼全在細(xì)節(jié)里。字段命名不一致、時(shí)間格式不統(tǒng)一、空值語(yǔ)義不同、枚舉值對(duì)不上這些都是家常便飯。做這類中間層我的經(jīng)驗(yàn)是一定要有一份顯式的映射表而不是把轉(zhuǎn)換邏輯散在代碼里。映射表可以是配置可以是代碼里的一個(gè)常量結(jié)構(gòu)但必須是集中的、可讀的。我見過有人把映射寫成一大串 if-else結(jié)果新增一個(gè)字段要改五處漏一處就出線上問題。更穩(wěn)妥的做法是把映射關(guān)系數(shù)據(jù)化代碼只負(fù)責(zé)執(zhí)行映射不負(fù)責(zé)定義映射。另一個(gè)坑是默認(rèn)值和缺失值的處理。上游沒給某個(gè)字段下游卻必須有值這時(shí)候中間層要決定是給默認(rèn)值、報(bào)錯(cuò)、還是透?jìng)骺?。這個(gè)決策不能拍腦袋要和上下游都對(duì)齊。我曾經(jīng)因?yàn)橐粋€(gè)默認(rèn)值給錯(cuò)了導(dǎo)致下游統(tǒng)計(jì)口徑整體偏移排查了兩天才定位到是中間層悄悄補(bǔ)了一個(gè)不該補(bǔ)的值。2.2 協(xié)議適配型中間層讓說不同語(yǔ)言的兩邊對(duì)話有些中間層不是為了轉(zhuǎn)數(shù)據(jù)而是為了轉(zhuǎn)協(xié)議。比如一邊是同步調(diào)用一邊是異步消息一邊是HTTP一邊是某種內(nèi)部RPC一邊要求請(qǐng)求響應(yīng)一邊只有單向通知。這種中間層的核心工作是把一種交互模式翻譯成另一種。這類中間層最難的地方在于語(yǔ)義的丟失。同步調(diào)用有明確的成功失敗異步消息往往只有“發(fā)出去了”和“沒發(fā)出去”至于對(duì)方處理沒處理、處理成功沒成功中間層未必知道。如果硬要把異步包裝成同步就要引入超時(shí)、重試、狀態(tài)查詢等一堆機(jī)制復(fù)雜度會(huì)陡增。我的建議是除非萬不得已不要試圖抹平同步和異步的根本差異而是讓中間層誠(chéng)實(shí)地暴露這種差異讓調(diào)用方自己決定怎么處理。2.3 聚合編排型中間層把多個(gè)下游拼成一個(gè)結(jié)果這種中間層面對(duì)的是多個(gè)下游服務(wù)它負(fù)責(zé)并發(fā)調(diào)用、合并結(jié)果、處理部分失敗。典型場(chǎng)景是一個(gè)頁(yè)面要展示來自三四個(gè)服務(wù)的數(shù)據(jù)前端不想調(diào)四次就由中間層統(tǒng)一聚合。聚合型中間層的核心挑戰(zhàn)是失敗處理。三個(gè)下游里有一個(gè)掛了是整體失敗還是降級(jí)返回部分?jǐn)?shù)據(jù)這個(gè)決策直接影響用戶體驗(yàn)和系統(tǒng)穩(wěn)定性。我傾向于能降級(jí)就降級(jí)但要明確告訴調(diào)用方哪些數(shù)據(jù)缺失了而不是悄悄吞掉錯(cuò)誤返回一個(gè)看起來正常的結(jié)果。悄悄吞錯(cuò)誤是聚合層最危險(xiǎn)的陷阱因?yàn)樗鼤?huì)讓問題在最不該出現(xiàn)的地方爆發(fā)。2.4 緩存與限流型中間層在流量和成本之間找平衡還有一類中間層不改變數(shù)據(jù)語(yǔ)義只改變?cè)L問方式。緩存層把熱點(diǎn)數(shù)據(jù)擋在前面限流層把過量請(qǐng)求攔在門外。這類中間層的價(jià)值很直接但配置起來很講究。緩存的坑在于一致性。數(shù)據(jù)更新了緩存什么時(shí)候失效是更新時(shí)主動(dòng)刪還是等過期主動(dòng)刪有可能刪失敗等過期又可能讀到舊數(shù)據(jù)。我的經(jīng)驗(yàn)是緩存層一定要有明確的失效策略并且這個(gè)策略要能被監(jiān)控。如果緩存命中率和失效率都看不見那這層緩存就是在裸奔。限流的坑在于閾值怎么定。定高了沒效果定低了誤傷正常流量。比較穩(wěn)的做法是先只觀測(cè)不攔截跑一段時(shí)間看看真實(shí)流量分布再根據(jù)下游的實(shí)際承載能力定閾值。上來就硬限流很容易把正常用戶擋在外面。3. 設(shè)計(jì)中間層時(shí)最容易踩的幾個(gè)坑中間層這東西設(shè)計(jì)好了是潤(rùn)滑劑設(shè)計(jì)不好就是新的故障點(diǎn)。我踩過的坑不算少挑幾個(gè)最有代表性的說說。3.1 中間層變成“萬能層”什么都往里塞這是最典型的失控。一開始中間層只做轉(zhuǎn)換后來有人覺得反正都要經(jīng)過這層不如把日志也放進(jìn)來再后來鑒權(quán)也放進(jìn)來再后來業(yè)務(wù)規(guī)則也放進(jìn)來。半年后這層變成了一個(gè)巨大的、沒人敢動(dòng)的怪物任何改動(dòng)都可能影響所有上下游。我的原則是中間層只做它名字所聲明的那件事。轉(zhuǎn)換層就只做轉(zhuǎn)換聚合層就只做聚合。日志、鑒權(quán)、監(jiān)控這些橫切關(guān)注點(diǎn)應(yīng)該用統(tǒng)一的基礎(chǔ)設(shè)施去解決而不是塞進(jìn)業(yè)務(wù)中間層。如果實(shí)在要在中間層做也要做成可插拔的、與核心邏輯分離的模塊而不是和轉(zhuǎn)換邏輯攪在一起。3.2 過度抽象為了“未來可能的變化”提前加層和上一條相反這個(gè)坑是加層加得太早。項(xiàng)目才兩個(gè)調(diào)用方就設(shè)計(jì)了一套完整的中間層結(jié)果每個(gè)調(diào)用方都要繞過這層直接調(diào)中間層形同虛設(shè)還增加了維護(hù)成本。判斷要不要加中間層我一般看三個(gè)信號(hào)調(diào)用方是否超過三個(gè)、變化頻率是否高到影響協(xié)作、兩邊是否由不同團(tuán)隊(duì)維護(hù)。三個(gè)里中兩個(gè)才值得認(rèn)真考慮加層。否則先用最簡(jiǎn)單的方式跑著等信號(hào)出現(xiàn)了再重構(gòu)也不遲。重構(gòu)出中間層比一開始就設(shè)計(jì)錯(cuò)要容易得多。3.3 契約不清晰中間層的接口成了“薛定諤的接口”中間層的接口是它存在的意義如果接口定義含糊那這層就白加了。我見過接口文檔寫著“返回一個(gè)對(duì)象”具體有哪些字段、什么類型、是否可空全靠讀代碼猜。這種中間層不但沒解耦反而增加了一層理解成本。好的中間層接口應(yīng)該滿足字段有明確類型和語(yǔ)義、錯(cuò)誤有明確分類、版本有明確標(biāo)識(shí)。尤其是錯(cuò)誤分類不能只有一個(gè)“失敗”要區(qū)分是參數(shù)錯(cuò)、下游錯(cuò)、還是中間層自己的錯(cuò)。這樣調(diào)用方才能做出正確的處理決策。3.4 忽略可觀測(cè)性出了問題兩眼一抹黑中間層夾在兩邊之間一旦出問題排查難度是加倍的。如果中間層沒有足夠的日志、指標(biāo)和追蹤那定位問題就像在黑箱里找東西。我的做法是中間層至少要有三個(gè)維度的可觀測(cè)性請(qǐng)求量、成功率、延遲分布。這三個(gè)指標(biāo)能覆蓋大部分問題。再進(jìn)一步關(guān)鍵路徑上要有請(qǐng)求級(jí)別的追蹤能串起上下游的調(diào)用鏈。這些投入在平時(shí)看起來是負(fù)擔(dān)但出故障時(shí)能救命。4. 一個(gè)可復(fù)現(xiàn)的中間層落地思路說了這么多原理和坑落到實(shí)操上我一般按下面這個(gè)順序來推進(jìn)。這套流程不復(fù)雜但每一步都有它的道理。4.1 先畫清楚兩邊的邊界和差異動(dòng)手寫代碼之前先把上游給什么、下游要什么、兩者差在哪里列清楚。我習(xí)慣用一張表來梳理左邊是上游字段右邊是下游字段中間標(biāo)注轉(zhuǎn)換規(guī)則和差異點(diǎn)。這張表就是中間層的需求文檔也是后續(xù)測(cè)試的依據(jù)。上游字段下游字段轉(zhuǎn)換規(guī)則差異說明user_iduid直接映射命名不同create_timecreated_at時(shí)間戳轉(zhuǎn)ISO格式格式不同statusstate枚舉映射值域不同無source固定填“sync”下游必填這張表看起來樸素但它能避免大量“我以為你知道”的溝通成本。而且當(dāng)上游或下游變化時(shí)改這張表比改代碼直觀得多。4.2 定義中間層的輸入輸出契約邊界理清后定義中間層自己的接口。這個(gè)接口應(yīng)該獨(dú)立于上下游的具體實(shí)現(xiàn)只表達(dá)中間層承諾提供的能力。比如一個(gè)轉(zhuǎn)換中間層它的接口應(yīng)該是“給我原始數(shù)據(jù)我還你規(guī)整數(shù)據(jù)”而不是“給我上游的A格式我還你下游的B格式”。前者是穩(wěn)定的后者會(huì)隨上下游變化。契約定義時(shí)我建議先寫測(cè)試用例再寫實(shí)現(xiàn)。把各種邊界情況——空值、超長(zhǎng)字段、非法枚舉、下游超時(shí)——都寫成測(cè)試實(shí)現(xiàn)的時(shí)候照著測(cè)試過。這樣能保證中間層的行為是可預(yù)期的而不是“跑起來看著沒問題”。4.3 實(shí)現(xiàn)時(shí)把“變化點(diǎn)”和“穩(wěn)定點(diǎn)”分開中間層內(nèi)部有些邏輯是穩(wěn)定的比如字段映射的基本框架有些是易變的比如具體的映射規(guī)則。實(shí)現(xiàn)時(shí)要把這兩者分開穩(wěn)定的部分寫成通用邏輯易變的部分做成配置或獨(dú)立模塊。這樣上游改字段時(shí)只需要改配置不用動(dòng)核心代碼。我通常會(huì)把映射規(guī)則放在一個(gè)獨(dú)立的配置結(jié)構(gòu)里代碼只負(fù)責(zé)讀取配置并執(zhí)行。配置可以用JSON、YAML甚至就是一個(gè)代碼里的字典關(guān)鍵是它和邏輯分離。這樣改規(guī)則的人不需要理解中間層的實(shí)現(xiàn)細(xì)節(jié)降低出錯(cuò)概率。4.4 上線前先做“影子運(yùn)行”中間層上線最怕的是它悄悄改變了數(shù)據(jù)語(yǔ)義而兩邊都沒發(fā)現(xiàn)。我的做法是先讓中間層跑在旁路只記錄不生效把它的輸出和現(xiàn)有邏輯的輸出做對(duì)比。跑一段時(shí)間確認(rèn)兩者一致再切換流量。這一步多花幾天但能避免上線后才發(fā)現(xiàn)轉(zhuǎn)換錯(cuò)了的尷尬。影子運(yùn)行期間要重點(diǎn)看差異率和差異樣本。差異率不為零不一定有問題可能是現(xiàn)有邏輯本身就有bug但每一個(gè)差異都要能解釋清楚。解釋不清的差異就是潛在的事故。4.5 上線后盯住三個(gè)指標(biāo)中間層上線后我盯的第一個(gè)指標(biāo)是錯(cuò)誤率尤其是中間層自己產(chǎn)生的錯(cuò)誤而不是下游透?jìng)鞯摹５诙€(gè)是延遲增量中間層不應(yīng)該成為性能瓶頸如果它讓整體延遲明顯上升就要查是不是做了不必要的同步等待。第三個(gè)是調(diào)用量分布看看是不是所有調(diào)用方都在正常使用有沒有哪個(gè)調(diào)用方繞過了中間層。這三個(gè)指標(biāo)穩(wěn)定運(yùn)行一段時(shí)間后中間層才算真正落地。之后每次上下游變化都要重新審視中間層的契約是否還成立必要時(shí)做版本升級(jí)而不是硬改。5. 關(guān)于中間層的一些零散體會(huì)做中間層這件事技術(shù)含量其實(shí)不在代碼本身而在對(duì)邊界的判斷。什么時(shí)候該加層什么時(shí)候不該加哪些邏輯放中間層哪些不放契約怎么定才能既穩(wěn)定又靈活。這些問題沒有標(biāo)準(zhǔn)答案只能靠對(duì)具體場(chǎng)景的理解。我自己的體會(huì)是中間層應(yīng)該薄而清晰。薄是指它只做必要的轉(zhuǎn)換和適配不承載業(yè)務(wù)邏輯清晰是指它的職責(zé)、接口、錯(cuò)誤處理都一目了然。一個(gè)又厚又模糊的中間層比沒有中間層更糟糕因?yàn)樗黾恿艘粚永斫獬杀緟s沒有帶來對(duì)應(yīng)的解耦收益。另外中間層不是一勞永逸的。上下游在變中間層也要跟著變。但好的中間層變化應(yīng)該集中在配置和映射規(guī)則上而不是核心邏輯。如果每次上下游改動(dòng)都要大動(dòng)中間層的代碼那說明這層的抽象沒做對(duì)。最后一點(diǎn)中間層的價(jià)值往往在出問題時(shí)才體現(xiàn)出來。平時(shí)它安安靜靜地待在那里沒人注意一旦上游抽風(fēng)或下游抖動(dòng)它能把影響擋住讓另一邊不受牽連。這種“平時(shí)無感、出事有用”的特性恰恰是中間層設(shè)計(jì)得當(dāng)?shù)臉?biāo)志。反過來如果中間層一出問題就導(dǎo)致全線崩潰那它就不是中間層而是單點(diǎn)故障。我在實(shí)際項(xiàng)目里越來越傾向于一個(gè)判斷中間層的復(fù)雜度應(yīng)該和它隔離的變化量成正比。兩邊差異越大、變化越頻繁中間層就值得做得越認(rèn)真如果兩邊本來就很像、也很少變那加一層反而是負(fù)擔(dān)。這個(gè)判斷不精確但足夠用來做大多數(shù)決策。