如果你維護(hù)過(guò)超過(guò)幾十臺(tái)節(jié)點(diǎn)的集群一定對(duì)“進(jìn)程之間跨節(jié)點(diǎn)通信到底該走什么協(xié)議”這個(gè)問(wèn)題頭疼過(guò)。TCP/IP 用得好好的為什么還要去了解一個(gè)叫 TIPC 的協(xié)議我最初也是這么想的直到在一個(gè)需要快速故障切換的分布式系統(tǒng)里被連接重建時(shí)間折磨得夠嗆才真正意識(shí)到TIPC 這類(lèi)協(xié)議解決的不是“能不能通”而是“通得是否可靠、是否自動(dòng)化、是否讓?xiě)?yīng)用層無(wú)感知”。TIPC 這個(gè)名字在中文技術(shù)社區(qū)里不算熱門(mén)但在高可用集群、分布式基礎(chǔ)設(shè)施、電信后臺(tái)系統(tǒng)這些領(lǐng)域它是實(shí)打?qū)嵉摹袄辖?。這篇文章作為系列的第一篇先把最核心的概念講透它是什么、要解決什么問(wèn)題、跟 TCP/IP 有什么本質(zhì)區(qū)別、什么時(shí)候該認(rèn)真考慮它。不涉及太深的調(diào)優(yōu)重在幫你建立完整的認(rèn)知框架。1. 項(xiàng)目概述先搞清楚 TIPC 到底是什么1.1 名字與定位TIPC 的全稱(chēng)是 Transparent Inter-Process Communication直譯就是“透明進(jìn)程間通信”。這里最關(guān)鍵的詞是“透明”。什么意思呢就是說(shuō)一個(gè)進(jìn)程去調(diào)用另一個(gè)進(jìn)程的服務(wù)時(shí)不需要知道對(duì)方在集群里的哪個(gè)節(jié)點(diǎn)上、不需要關(guān)心對(duì)方的 IP 地址是什么、不需要處理連接斷開(kāi)后的重連邏輯——這些臟活累活協(xié)議棧在底層幫你干了。它不是一個(gè)應(yīng)用層協(xié)議也不是什么中間件框架而是系統(tǒng)內(nèi)核原生支持的一個(gè)地址族Address Family通過(guò)你熟悉的 socket 編程接口對(duì)外暴露。也就是說(shuō)你在 C 語(yǔ)言里照樣用socket()、bind()、connect()、send()這套 API只是地址族從AF_INET換成了AF_TIPC底層的通信行為就完全不同了。很多剛接觸的人會(huì)問(wèn)這跟 TCP 有什么區(qū)別區(qū)別非常大。TCP 解決的是“兩臺(tái)機(jī)器之間怎么可靠地傳字節(jié)”TIPC 解決的是“一個(gè)集群里成百上千個(gè)進(jìn)程之間怎么像本地調(diào)用一樣通信”而且自帶服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移能力。這兩個(gè)問(wèn)題的層次和出發(fā)點(diǎn)都不一樣。1.2 它從哪來(lái)通信設(shè)備集群里長(zhǎng)出來(lái)的協(xié)議TIPC 最早源自北歐某通信設(shè)備制造商的內(nèi)部項(xiàng)目服務(wù)于電信領(lǐng)域的高可用集群系統(tǒng)。電信設(shè)備對(duì)可用性的要求有多苛刻呢主備切換要在極短時(shí)間內(nèi)完成業(yè)務(wù)幾乎不能中斷節(jié)點(diǎn)故障后其他節(jié)點(diǎn)要立刻接管工作。在這種環(huán)境里TCP 的建連、斷連、重連機(jī)制顯得太重了——每次鏈路切換都要重新握手、重新協(xié)商一旦節(jié)點(diǎn)批量故障大量連接同時(shí)重建很容易雪崩。于是他們自己設(shè)計(jì)了一套面向“可信集群內(nèi)部節(jié)點(diǎn)間通信”的協(xié)議核心思路就是把服務(wù)尋址、拓?fù)涓兄?、故障切換這些事全部納入?yún)f(xié)議棧讓上層業(yè)務(wù)不用管。后來(lái)這個(gè)協(xié)議開(kāi)源并進(jìn)入了主流內(nèi)核成為標(biāo)準(zhǔn)內(nèi)核功能之一。這段歷史決定了它的性格為高可用集群而生為可靠性和低延遲做了大量?jī)?yōu)化而不是為公網(wǎng)大數(shù)據(jù)量傳輸設(shè)計(jì)的。1.3 一個(gè)貫穿全文的類(lèi)比想把 TIPC 和 TCP 的區(qū)別一次講明白我常用一個(gè)類(lèi)比TCP/IP 像是公用電話網(wǎng)你得知道對(duì)方的完整電話號(hào)碼IP 加端口撥號(hào)前還要確認(rèn)對(duì)方是否開(kāi)機(jī)網(wǎng)絡(luò)出問(wèn)題你只能聽(tīng)到忙音然后自己重?fù)?。TIPC 更像是公司內(nèi)部的對(duì)講機(jī)系統(tǒng)——每個(gè)人都有工號(hào)節(jié)點(diǎn) ID部門(mén)有服務(wù)臺(tái)服務(wù)名你只需要說(shuō)“我要聯(lián)系財(cái)務(wù)部門(mén)”系統(tǒng)自動(dòng)找到財(cái)務(wù)部當(dāng)前的辦公位置。某個(gè)財(cái)務(wù)同事臨時(shí)換工位了你不需要知道對(duì)講機(jī)系統(tǒng)會(huì)自動(dòng)更新路由。如果你換工位時(shí)他沒(méi)吭聲還有一套心跳機(jī)制能發(fā)現(xiàn)并通知你“他現(xiàn)在不在服務(wù)區(qū)我?guī)湍憬恿硪粋€(gè)同事”。這個(gè)類(lèi)比能幫你記住 TIPC 最核心的價(jià)值按名字找服務(wù)而不是按地址找機(jī)器。2. 核心設(shè)計(jì)拆解TIPC 與傳統(tǒng)通信協(xié)議的本質(zhì)差異2.1 服務(wù)尋址讓進(jìn)程互相“按名字”找傳統(tǒng) socket 編程里客戶(hù)端必須知道服務(wù)端的 IP 和端口這是一個(gè)“地理位置”導(dǎo)向的模型。在集群環(huán)境里這非常痛苦服務(wù)端只要遷移、擴(kuò)容、故障切換IP 就變了客戶(hù)端代碼也得跟著改就算用上負(fù)載均衡和 DNS也躲不開(kāi)一層額外的配置管理。TIPC 把尋址模型整個(gè)顛倒了過(guò)來(lái)。通信對(duì)象不是一個(gè)“地址”而是一個(gè)“服務(wù)”。服務(wù)由三元組描述服務(wù)類(lèi)型Service Type相當(dāng)于業(yè)務(wù)的種類(lèi)比如“計(jì)費(fèi)服務(wù)”“日志服務(wù)”“配置服務(wù)”。服務(wù)實(shí)例Service Instance同一類(lèi)型下的具體編號(hào)比如計(jì)費(fèi)服務(wù)的第 3 個(gè)副本。域Domain限定這個(gè)服務(wù)在多大的范圍內(nèi)可見(jiàn)可以只在節(jié)點(diǎn)內(nèi)部也可以在整個(gè)集群。業(yè)務(wù)進(jìn)程要提供某個(gè)服務(wù)時(shí)只需要在本地 socket 上綁定這個(gè)服務(wù)名要調(diào)用某個(gè)服務(wù)時(shí)也只需要指定服務(wù)名發(fā)起連接。至于這個(gè)服務(wù)當(dāng)前跑在哪臺(tái)機(jī)器上由 TIPC 內(nèi)核自己去查名字表、做路由選擇。這意味著什么假設(shè)你的后端服務(wù)從節(jié)點(diǎn) A 遷移到節(jié)點(diǎn) B服務(wù)實(shí)例編號(hào)不變調(diào)用方的代碼一個(gè)字符都不用改。客戶(hù)端甚至不需要知道一次故障切換已經(jīng)發(fā)生TIPC 會(huì)自動(dòng)把新消息轉(zhuǎn)到幸存節(jié)點(diǎn)。對(duì)應(yīng)用層來(lái)說(shuō)這就是“透明”兩個(gè)字的真實(shí)含義。2.2 自動(dòng)拓?fù)涓兄c故障轉(zhuǎn)移TIPC 的節(jié)點(diǎn)之間不是“需要通信時(shí)才建連接”這種臨時(shí)關(guān)系而是維護(hù)著常駐鏈路。節(jié)點(diǎn)之間周期性交換心跳信息每個(gè)節(jié)點(diǎn)都能在本地維護(hù)一份集群拓?fù)湟晥D誰(shuí)在線、誰(shuí)離線、誰(shuí)提供了什么服務(wù)、服務(wù)當(dāng)前映射到哪個(gè)節(jié)點(diǎn)。新節(jié)點(diǎn)加入時(shí)通過(guò)承載層自動(dòng)發(fā)現(xiàn)然后建立鏈路整個(gè)過(guò)程不需要人工配置“集群里有哪幾臺(tái)機(jī)器”。節(jié)點(diǎn)掉線時(shí)對(duì)端在秒級(jí)內(nèi)就能感知隨后把該節(jié)點(diǎn)發(fā)布的服務(wù)從本地名字表中剝離開(kāi)。如果這個(gè)服務(wù)有多個(gè)副本后續(xù)消息會(huì)自動(dòng)路由到存活的副本上。這套機(jī)制部署過(guò)的人都懂實(shí)際價(jià)值極大。用 TCP 自己擼這套邏輯你得有一整套注冊(cè)中心、健康檢查、故障轉(zhuǎn)移策略還要處理各種腦裂和狀態(tài)不一致的邊界情況。TIPC 把這些全部下沉到了協(xié)議棧里業(yè)務(wù)代碼可以保持簡(jiǎn)潔。2.3 TIPC 提供的幾種通信模式TIPC 也遵循 socket 的語(yǔ)義給開(kāi)發(fā)者的選擇并不少模式語(yǔ)義類(lèi)比SOCK_STREAM面向連接、可靠、保序的字節(jié)流類(lèi)似 TCPSOCK_SEQPACKET面向連接、可靠、保序但保留消息邊界類(lèi)似“有郵戳的信封”很實(shí)用SOCK_DGRAM無(wú)連接、盡力投遞類(lèi)似 UDPSOCK_RDM可靠傳輸?shù)槐ＷC順序TCP 的可靠性 UDP 的自由順序重點(diǎn)提一下SOCK_SEQPACKET。很多集群業(yè)務(wù)處理的是結(jié)構(gòu)化消息每條消息是獨(dú)立的“信封”。如果走 TCP 流你得自己設(shè)計(jì)消息頭、處理半包和粘包如果走SOCK_SEQPACKET內(nèi)核幫你保留了消息邊界一次send()對(duì)應(yīng)一次recv()省掉相當(dāng)多瑣碎的解析代碼。3. 工作原理與關(guān)鍵機(jī)制3.1 節(jié)點(diǎn)、鏈路與域的層級(jí)結(jié)構(gòu)TIPC 網(wǎng)絡(luò)是一個(gè)層級(jí)模型從底往上分別是節(jié)點(diǎn)Node、集群Cluster、域Zone。每個(gè)節(jié)點(diǎn)有唯一的節(jié)點(diǎn)標(biāo)識(shí)在集群內(nèi)部唯一。多個(gè)節(jié)點(diǎn)組成集群集群是最常用的操作范圍。域是把多個(gè)集群聚合起來(lái)的更大范圍實(shí)際部署中用得相對(duì)少。節(jié)點(diǎn)之間的通信依賴(lài)鏈路Link鏈路建立在下層承載Bearer上。承載層可以是以太網(wǎng)設(shè)備也可以是 UDP 隧道。每條鏈路都是全雙工的而且支持一條物理鏈路上建立多個(gè)邏輯鏈路并行使用。這種層級(jí)設(shè)計(jì)帶來(lái)一個(gè)實(shí)際好處底層組網(wǎng)變化時(shí)上層的服務(wù)尋址不感知。你換了一臺(tái)機(jī)器的網(wǎng)卡、改了它的物理接口它的節(jié)點(diǎn) ID 和服務(wù)不變其他節(jié)點(diǎn)照樣能找到它。3.2 名字表如何讓服務(wù)被“看見(jiàn)”每個(gè)節(jié)點(diǎn)內(nèi)部都維護(hù)著一張名字表Name Table記錄“哪些服務(wù)跑在本機(jī)”。這張表會(huì)通過(guò)鏈路在整個(gè)集群內(nèi)同步。也就是說(shuō)每臺(tái)節(jié)點(diǎn)最終都擁有一份“全集群服務(wù)名到節(jié)點(diǎn) ID 的映射表”。這個(gè)機(jī)制對(duì)應(yīng)生活里的“企業(yè)內(nèi)部通訊錄”每個(gè)部門(mén)動(dòng)態(tài)更新自己的成員名單總機(jī)定期同步全公司的通訊錄。當(dāng)你呼叫某個(gè)服務(wù)時(shí)本機(jī)的名字表會(huì)告訴你應(yīng)該走哪條鏈路、發(fā)給哪個(gè)節(jié)點(diǎn)。服務(wù)發(fā)布和撤銷(xiāo)時(shí)名字表會(huì)動(dòng)態(tài)增刪條目并通過(guò)鏈路傳播出去。一個(gè)容易被忽略的點(diǎn)是這個(gè)設(shè)計(jì)天然支持服務(wù)多副本。同一個(gè)服務(wù)類(lèi)型加實(shí)例可以同時(shí)綁定在多個(gè)節(jié)點(diǎn)上名字表里會(huì)有多條記錄。TIPC 在轉(zhuǎn)發(fā)時(shí)會(huì)做負(fù)載均衡節(jié)點(diǎn)故障時(shí)自動(dòng)剔除失效記錄切換對(duì)調(diào)用方完全透明。3.3 可靠性與復(fù)制策略TIPC 支持不同的可靠性策略。默認(rèn)是單副本模式即每條消息只發(fā)一份依靠協(xié)議棧的確認(rèn)和重傳機(jī)制保證可靠性語(yǔ)義上接近 TCP。在高可用要求更嚴(yán)苛的場(chǎng)景可以啟用雙副本模式消息同時(shí)在兩條不同鏈路上發(fā)送接收方取最先到的那個(gè)另一份直接丟棄。代價(jià)是帶寬翻倍好處是一份消息在網(wǎng)絡(luò)抖動(dòng)時(shí)依然能及時(shí)送達(dá)鏈路單點(diǎn)故障不影響消息交付。協(xié)議棧還內(nèi)置了流控和反壓機(jī)制。當(dāng)某個(gè)節(jié)點(diǎn)處理不過(guò)來(lái)時(shí)發(fā)送端會(huì)被“按一下剎車(chē)”避免積壓消息拖垮整個(gè)集群。因?yàn)樵O(shè)計(jì)場(chǎng)景是可信集群內(nèi)部網(wǎng)絡(luò)TIPC 刻意沒(méi)有做 TCP 那樣復(fù)雜的擁塞控制邏輯這既降低了延遲也減少了 CPU 開(kāi)銷(xiāo)。4. 選型指南什么時(shí)候該用它什么時(shí)候別硬上4.1 適合 TIPC 的場(chǎng)景從我接觸過(guò)的項(xiàng)目來(lái)看滿(mǎn)足下面這些特征的系統(tǒng)非常適合引入 TIPC節(jié)點(diǎn)數(shù)量幾十到幾百的集群且服務(wù)經(jīng)常遷移或擴(kuò)縮容。有自動(dòng)服務(wù)發(fā)現(xiàn)運(yùn)維成本會(huì)明顯下降。對(duì)故障恢復(fù)時(shí)間有強(qiáng)要求。比如主備切換、雙活數(shù)據(jù)中心內(nèi)部TCP 重連的秒級(jí)停頓無(wú)法接受。通信模式以請(qǐng)求/響應(yīng)為主消息大小相對(duì)較小。這類(lèi)負(fù)載正是 TIPC 的舒適區(qū)。電信后臺(tái)、工業(yè)控制、分布式存儲(chǔ)這類(lèi)要求確定性行為的領(lǐng)域。這些場(chǎng)景里 TCP 的握手延遲和重連不確定性非常礙事。4.2 不適合 TIPC 的場(chǎng)景跨公網(wǎng)或跨數(shù)據(jù)中心的長(zhǎng)距離通信。TIPC 假設(shè)的是可信、低時(shí)延、高帶寬的內(nèi)部網(wǎng)絡(luò)公網(wǎng)上的丟包、擁塞和地址轉(zhuǎn)換場(chǎng)景不適合它。大規(guī)模單向傳輸比如大量視頻流、文件同步。這類(lèi)場(chǎng)景 TCP 的流控反而更合適。與外部客戶(hù)端互通的場(chǎng)景。瀏覽器、外部應(yīng)用不會(huì)支持 TIPC它們注定走 TCP/UDP。TIPC 更應(yīng)作為集群內(nèi)部通信的“高速公路”對(duì)外暴露還是靠常規(guī)協(xié)議。需要消息落庫(kù)、審計(jì)日志的場(chǎng)景。協(xié)議本身不提供持久化語(yǔ)義持久化還是得交給業(yè)務(wù)層。4.3 與 TCP、UDP、共享內(nèi)存的橫向?qū)Ρ染S度TCP/IPUDP/IPTIPC共享內(nèi)存跨節(jié)點(diǎn)是是是面向集群否單機(jī)服務(wù)發(fā)現(xiàn)無(wú)需自建無(wú)自動(dòng)服務(wù)尋址不需要故障切換客戶(hù)端自處理無(wú)協(xié)議棧自動(dòng)切換不適用延遲較高重連慢低低且切換快極低消息邊界不保留保留可選保留保留適用邊界通用網(wǎng)絡(luò)流媒體等可信集群內(nèi)單機(jī)多進(jìn)程這張表我建議你保存下來(lái)。每次有人問(wèn)“要不要用 TIPC”直接拿這張表對(duì)照就行它在“集群內(nèi)部、高可用、低延遲”這個(gè)象限幾乎是無(wú)可替代的出了這個(gè)象限TCP 仍是通用答案。5. 快速上手搭建一個(gè)最小的 TIPC 環(huán)境5.1 檢查內(nèi)核支持并加載模塊TIPC 已經(jīng)內(nèi)置在主流發(fā)行版的內(nèi)核模塊里只是沒(méi)有默認(rèn)加載。先確認(rèn)一下ls /proc/net/tipc 2/dev/null echo TIPC 已加載 || echo TIPC 未加載如果沒(méi)有加載直接加載模塊并順手配置成開(kāi)機(jī)自動(dòng)加載modprobe tipc echo tipc /etc/modules-load.d/tipc.conf如果modprobe tipc報(bào)“模塊不存在”大概率是內(nèi)核編譯時(shí)沒(méi)勾選 TIPC 支持需要手動(dòng)編譯內(nèi)核開(kāi)啟CONFIG_TIPC或者換一個(gè)更通用的內(nèi)核版本。這個(gè)屬于環(huán)境問(wèn)題不是協(xié)議本身的問(wèn)題。5.2 初始化 TIPC 域和承載層TIPC 網(wǎng)絡(luò)需要一個(gè)網(wǎng)絡(luò)標(biāo)識(shí)來(lái)區(qū)分不同的 TIPC 集群。設(shè)置網(wǎng)絡(luò)標(biāo)識(shí)tipc-config -netid1234然后設(shè)置節(jié)點(diǎn)地址并指定承載層綁定的網(wǎng)卡tipc-config -addr1.1.2 tipc-config -beeth0注意不同發(fā)行版和管理工具的命名有差異。較新的內(nèi)核環(huán)境推薦用tipc命令tipc node set netid 1234 tipc bearer enable media eth這里給出的是通用配置思路。實(shí)際起服務(wù)時(shí)建議先用tipc-config -n查一下當(dāng)前網(wǎng)絡(luò)狀態(tài)確認(rèn)節(jié)點(diǎn)已經(jīng)加入域、鏈路狀態(tài)正常再繼續(xù)往下走。5.3 用 socket API 跑通第一個(gè)示例配置好 TIPC 域后寫(xiě)代碼跟寫(xiě)普通 socket 沒(méi)太大區(qū)別只是地址族變成AF_TIPC地址結(jié)構(gòu)用sockaddr_tipc。服務(wù)端發(fā)布一個(gè)服務(wù)#include linux/tipc.h #include sys/socket.h #include string.h int main() { int sd socket(AF_TIPC, SOCK_SEQPACKET, 0); struct sockaddr_tipc addr; memset(addr, 0, sizeof(addr)); addr.family AF_TIPC; addr.addrtype TIPC_ADDR_NAME; addr.addr.name.name.type 1000; // 服務(wù)類(lèi)型 addr.addr.name.name.instance 1; // 服務(wù)實(shí)例 addr.addr.name.domain 0; // 集群范圍可見(jiàn) bind(sd, (struct sockaddr *)addr, sizeof(addr)); listen(sd, 16); // 正常 accept / recv / send 邏輯 }客戶(hù)端連接這個(gè)服務(wù)#include linux/tipc.h #include sys/socket.h #include string.h int main() { int sd socket(AF_TIPC, SOCK_SEQPACKET, 0); struct sockaddr_tipc addr; memset(addr, 0, sizeof(addr)); addr.family AF_TIPC; addr.addrtype TIPC_ADDR_NAME; addr.addr.name.name.type 1000; addr.addr.name.name.instance 1; addr.addr.name.domain 0; int rc connect(sd, (struct sockaddr *)addr, sizeof(addr)); // 成功后即可 send / recv }這段代碼突出展示了一個(gè)核心點(diǎn)客戶(hù)端從頭到尾沒(méi)有關(guān)心服務(wù)端在哪個(gè)節(jié)點(diǎn)、IP 是什么。服務(wù)端無(wú)論是運(yùn)行在節(jié)點(diǎn) A 還是節(jié)點(diǎn) B客戶(hù)端代碼完全一樣。你甚至可以手動(dòng)把服務(wù)端 kill 掉再在另一臺(tái)節(jié)點(diǎn)上啟動(dòng)一樣的進(jìn)程綁定同一個(gè)服務(wù)類(lèi)型和實(shí)例客戶(hù)端下一輪調(diào)用就能自動(dòng)切過(guò)去。注意示例代碼為了清晰做了大量簡(jiǎn)化生產(chǎn)環(huán)境務(wù)必補(bǔ)全錯(cuò)誤處理、超時(shí)重試、連接關(guān)閉等邏輯。6. 常見(jiàn)問(wèn)題與踩坑記錄6.1 模塊加載與權(quán)限問(wèn)題最常遇到的坑是模塊沒(méi)加載導(dǎo)致socket(AF_TIPC, ...)直接失敗報(bào)Address family not supported by protocol。這個(gè)問(wèn)題好解決modprobe tipc之后再看lsmod | grep tipc確認(rèn)。另一個(gè)坑是權(quán)限。配置 TIPC 網(wǎng)絡(luò)標(biāo)識(shí)和承載層需要root權(quán)限很多 CI 環(huán)境里用的是普通用戶(hù)一執(zhí)行tipc-config就報(bào)Operation not permitted。不是命令有問(wèn)題是權(quán)限不夠加上sudo就行。生產(chǎn)環(huán)境建議通過(guò) systemd 的方式在服務(wù)啟動(dòng)前統(tǒng)一完成初始化。6.2 服務(wù)實(shí)例編號(hào)的設(shè)計(jì)坑服務(wù)類(lèi)型和實(shí)例編號(hào)完全由開(kāi)發(fā)者自定義。我見(jiàn)過(guò)不少人把實(shí)例編號(hào)當(dāng)成端口號(hào)來(lái)用結(jié)果服務(wù)遷移后出現(xiàn)沖突兩個(gè)進(jìn)程綁定了同一個(gè)服務(wù)類(lèi)型加實(shí)例。TIPC 沒(méi)有像 TCP 的端口沖突檢查那樣直接拒絕啟動(dòng)進(jìn)程而是在名字表里出現(xiàn)兩條記錄導(dǎo)致調(diào)用方摸不清到底該發(fā)給誰(shuí)出現(xiàn)偶發(fā)的“一半請(qǐng)求打到舊節(jié)點(diǎn)”問(wèn)題。我的經(jīng)驗(yàn)是建立一套全局的編號(hào)規(guī)范服務(wù)類(lèi)型按業(yè)務(wù)模塊劃分實(shí)例編號(hào)預(yù)留連續(xù)的可用范圍。運(yùn)維側(cè)新增實(shí)例前必須查詢(xún)現(xiàn)有編號(hào)占用情況避免“拍腦袋指定”造成數(shù)據(jù)面混亂。6.3 實(shí)測(cè)后的性能與穩(wěn)定性心得關(guān)于性能我給不出通用 benchmark但可以說(shuō)幾條實(shí)測(cè)中穩(wěn)定的結(jié)論在請(qǐng)求/響應(yīng)小消息場(chǎng)景下TIPC 的單跳時(shí)延通常比同網(wǎng)絡(luò) TCP 低因?yàn)樗〉袅宋帐趾蛷?fù)雜擁塞控制。雙副本模式會(huì)顯著增加網(wǎng)絡(luò)占用帶寬緊張時(shí)反而拖慢整體吞吐。只在主備切換場(chǎng)景開(kāi)啟日常通信保持單副本更劃算。心跳間隔、鏈路重試參數(shù)是可以在配置里調(diào)的。默認(rèn)配置偏保守如果你的網(wǎng)絡(luò)足夠穩(wěn)適當(dāng)調(diào)快心跳能加快故障感知速度反過(guò)來(lái)網(wǎng)絡(luò)抖動(dòng)頻繁的環(huán)境里過(guò)短的心跳會(huì)導(dǎo)致誤判節(jié)點(diǎn)故障引發(fā)頻繁切換比不切換還糟糕。我個(gè)人在實(shí)際操作中的一個(gè)體會(huì)是TIPC 部署在從一開(kāi)始就把它當(dāng)作一等公民來(lái)設(shè)計(jì)的系統(tǒng)里效果最好。如果系統(tǒng)本身已經(jīng)用 TCP 注冊(cè)中心跑得很好那沒(méi)有必要折騰遷移但如果你的故障切換一直做不到“秒級(jí)”或者服務(wù)擴(kuò)縮容時(shí)到處要改連接配置TIPC 就非常值得花時(shí)間試點(diǎn)一下。先用兩臺(tái)機(jī)器開(kāi)一個(gè)最小集群把服務(wù)發(fā)布、調(diào)用、故障切換跑通再?zèng)Q定要不要推開(kāi)。這個(gè)協(xié)議的學(xué)習(xí)曲線并不陡真正陡的是“如何用分布式的思維去設(shè)計(jì)服務(wù)通信”。后續(xù)系列文章我會(huì)專(zhuān)門(mén)講服務(wù)尋址的細(xì)節(jié)、雙副本模式的配置流程以及一個(gè)完整的分布式系統(tǒng)改造案例。下一篇見(jiàn)。