簡(jiǎn)介這份PDF是IBM大中華區(qū)實(shí)驗(yàn)室服務(wù)總經(jīng)理孫宏關(guān)于架構(gòu)現(xiàn)代化轉(zhuǎn)型的實(shí)踐分享適合企業(yè)技術(shù)管理者、架構(gòu)師及數(shù)字化轉(zhuǎn)型負(fù)責(zé)人閱讀。內(nèi)容圍繞數(shù)據(jù)作為戰(zhàn)略資產(chǎn)、混合多云環(huán)境下的數(shù)據(jù)流轉(zhuǎn)、結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)協(xié)同、多數(shù)據(jù)中心整合等關(guān)鍵議題展開并結(jié)合國(guó)內(nèi)大型保險(xiǎn)公司與百度冷數(shù)據(jù)管理案例剖析上云與擴(kuò)容中的臨界點(diǎn)、數(shù)據(jù)豎井及合規(guī)難題。資源為單個(gè)PDF文件大小3.9MB共1個(gè)文件便于直接閱讀。已有60人學(xué)習(xí)下載。通過(guò)這份分享讀者可以系統(tǒng)了解IBM地平線項(xiàng)目等解決方案的思路掌握從數(shù)據(jù)中心整合、高性能計(jì)算到冷數(shù)據(jù)調(diào)用與成本控制的具體實(shí)踐路徑為企業(yè)架構(gòu)現(xiàn)代化規(guī)劃提供參考。1. 架構(gòu)現(xiàn)代化轉(zhuǎn)型IBM這份實(shí)踐分享到底在解決什么問(wèn)題很多團(tuán)隊(duì)是被業(yè)務(wù)倒逼著才來(lái)做架構(gòu)現(xiàn)代化的單體系統(tǒng)跑了好幾年發(fā)版要排期到一個(gè)低流量窗口業(yè)務(wù)方要上新功能改一行代碼要牽連十幾個(gè)模塊CI/CD基本形同虛設(shè)。市面上講架構(gòu)現(xiàn)代化的文章不少IBM這份實(shí)踐分享的可貴之處在于沒(méi)有把“上云”“微服務(wù)”當(dāng)作終點(diǎn)而是把它拆成一連串有先后順序的工程動(dòng)作評(píng)估現(xiàn)狀、技術(shù)選型、容器化、切入口、拆服務(wù)、遷中間件。這套邏輯對(duì)從業(yè)者的實(shí)際價(jià)值是提供了一條可以按步驟復(fù)現(xiàn)的落地路徑。這篇筆記就順著這條路徑把每一步該做什么、參數(shù)怎么設(shè)、坑在哪里拆開講。適合正在做系統(tǒng)改造、準(zhǔn)備遷移上云但還沒(méi)想清楚先動(dòng)哪一塊的團(tuán)隊(duì)也適合剛接手一個(gè)老系統(tǒng)、想找到切入點(diǎn)的新人。2. 現(xiàn)狀評(píng)估與技術(shù)選型上微服務(wù)之前先把賬算清楚2.1 現(xiàn)狀盤點(diǎn)先給系統(tǒng)做一次體檢而不是直接談微服務(wù)我在實(shí)際項(xiàng)目里最常見的開場(chǎng)錯(cuò)誤就是團(tuán)隊(duì)還沒(méi)摸清自己的系統(tǒng)長(zhǎng)什么樣就開始討論用 Spring Cloud 還是 Service Mesh。做架構(gòu)現(xiàn)代化第一步一定是先做現(xiàn)狀盤點(diǎn)而且盤點(diǎn)要有可操作的具體動(dòng)作不是開個(gè)會(huì)大家憑感覺(jué)打分。常見的做法是下面三件事并行第一代碼層面的依賴分析。用工具把模塊間的調(diào)用關(guān)系拉出來(lái)看依賴是清晰的還是纏成一團(tuán)的。Java 項(xiàng)目可以用 jdepend、ArchUnit 這類工具掃描包依賴或者用 IntelliJ IDEA 的 Dependency Structure Matrix 看依賴走向。如果發(fā)現(xiàn)核心域模塊被十幾個(gè)周邊模塊反向依賴那拆分順序就要往后排了。第二數(shù)據(jù)層面的形態(tài)梳理。查一下生產(chǎn)庫(kù)里有多少?gòu)埍砟男┍肀豢缒K訪問(wèn)。很多老系統(tǒng)的“業(yè)務(wù)耦合”本質(zhì)是“數(shù)據(jù)耦合”——訂單服務(wù)直接讀用戶表用戶服務(wù)直接寫訂單表的冗余字段。這種耦合不拆開后面微服務(wù)拆得再干凈數(shù)據(jù)庫(kù)一發(fā)生鎖等待服務(wù)層面照樣全掛。第三運(yùn)行層面的現(xiàn)狀記錄。看一周的監(jiān)控?cái)?shù)據(jù)發(fā)布頻率、峰值 QPS、平均響應(yīng)時(shí)間、錯(cuò)誤率、慢 SQL 數(shù)量、有沒(méi)有定時(shí)任務(wù)在跑批。重點(diǎn)看一下這個(gè)系統(tǒng)是不是每周都要人工半夜發(fā)版有沒(méi)有人肉運(yùn)維的“黑匣子”操作。盤點(diǎn)完要輸出一張現(xiàn)狀表不要只寫“耦合嚴(yán)重”“性能一般”這種模糊描述。建議按下面這張表收集數(shù)據(jù)評(píng)估維度具體檢查項(xiàng)現(xiàn)狀記錄發(fā)布能力從提交代碼到上生產(chǎn)的耗時(shí)、發(fā)布窗口期每周四凌晨發(fā)版 2 小時(shí)模塊耦合度跨模塊調(diào)用數(shù)、反向依賴數(shù)核心域被 15 個(gè)模塊反向調(diào)用數(shù)據(jù)形態(tài)單庫(kù)表數(shù)量、跨域訪問(wèn)的表數(shù)量單庫(kù) 400 張表20 張被跨域訪問(wèn)技術(shù)棧狀態(tài)JDK / 中間件 / 框架版本是否 EOLJDK 8 老版本MQ 版本已停止維護(hù)可觀測(cè)性日志是否統(tǒng)一、有沒(méi)有鏈路追蹤無(wú) Trace日志散落各節(jié)點(diǎn)成本結(jié)構(gòu)大機(jī) / 物理機(jī) / 云上的資源賬單物理機(jī)集群擴(kuò)容周期 2 周這張表的價(jià)值在于它決定了你后續(xù)選哪條改造路線。如果數(shù)據(jù)耦合已經(jīng)從 20 張表惡化到 60 張表那前面就算選“絞殺者模式”漸進(jìn)拆分也得先處理數(shù)據(jù)歸屬問(wèn)題。我自己基本會(huì)花一整個(gè)星期在調(diào)研上這個(gè)時(shí)間后面一定省得回來(lái)。2.2 技術(shù)路線選型重寫、絞殺者模式還是平臺(tái)化改造現(xiàn)狀盤點(diǎn)完擺在你面前的無(wú)非三條路大多數(shù)團(tuán)隊(duì)在沒(méi)有搞清楚差異的情況下直接選了第一條然后陷入長(zhǎng)達(dá)一年的“重構(gòu)泥潭”。第一條路是推倒重寫。用新技術(shù)棧把老系統(tǒng)從頭實(shí)現(xiàn)一遍。這條路只適合業(yè)務(wù)邏輯相對(duì)簡(jiǎn)單、用戶規(guī)模不大、團(tuán)隊(duì)有充足人力和業(yè)務(wù)方愿意等的情況。重寫的最大風(fēng)險(xiǎn)是“舊系統(tǒng)的隱性邏輯”根本沒(méi)法從代碼里看全——很多規(guī)則散落在存儲(chǔ)過(guò)程、定時(shí)腳本、甚至某個(gè)運(yùn)維的手里。你在重寫過(guò)程中會(huì)不斷發(fā)現(xiàn)“原來(lái)這里還有個(gè)補(bǔ)丁邏輯”拖幾個(gè)月甚至一年根本交付不了。第二條路是絞殺者模式Strangler Pattern這也是我見過(guò)落地成功率最高的一種。從老系統(tǒng)外圍的功能開始用新架構(gòu)的服務(wù)逐步替換替換完一個(gè)就把老系統(tǒng)對(duì)應(yīng)的入口切到新服務(wù)。你的老系統(tǒng)不會(huì)一次性死掉而是像被藤蔓纏繞的老樹一樣慢慢被新系統(tǒng)接管。這條路適合大多數(shù)業(yè)務(wù)邏輯復(fù)雜、不能停服的系統(tǒng)。IBM 實(shí)踐分享里強(qiáng)調(diào)的也是這種漸進(jìn)式思路本質(zhì)上是把風(fēng)險(xiǎn)控制在一個(gè)可回退的范圍內(nèi)。第三條路是平臺(tái)化先行。先把承載應(yīng)用的運(yùn)行環(huán)境標(biāo)準(zhǔn)化統(tǒng)一容器平臺(tái)、統(tǒng)一 CI/CD 管道、統(tǒng)一日志與監(jiān)控體系應(yīng)用層暫時(shí)不動(dòng)。這樣做的收益是不用動(dòng)業(yè)務(wù)代碼就能先拿到發(fā)布效率和可觀測(cè)性的提升也為后續(xù)拆分打底。很多傳統(tǒng)制造業(yè)和金融客戶的項(xiàng)目第一步往往就是這個(gè)。因?yàn)樗麄兊耐袋c(diǎn)不是微服務(wù)化而是發(fā)版太慢、系統(tǒng)不透明。選型不是拍腦袋可以用一張簡(jiǎn)單的對(duì)比表來(lái)輔助決策路線適配場(chǎng)景主要風(fēng)險(xiǎn)周期預(yù)估團(tuán)隊(duì)要求推倒重寫邏輯簡(jiǎn)單、停服可接受隱性邏輯丟失、交付遙遙無(wú)期12 個(gè)月以上需要完整業(yè)務(wù)專家團(tuán)隊(duì)絞殺者模式業(yè)務(wù)復(fù)雜、不能停服雙系統(tǒng)并行期長(zhǎng)、數(shù)據(jù)一致性處理難每個(gè)模塊 3~6 個(gè)月需要能穩(wěn)定推進(jìn)的迭代型團(tuán)隊(duì)平臺(tái)化先行基礎(chǔ)設(shè)施老舊、發(fā)布效率低應(yīng)用層仍然耦合后續(xù)仍需拆基礎(chǔ)設(shè)施 2~4 個(gè)月需要運(yùn)維與架構(gòu)能力強(qiáng)的平臺(tái)團(tuán)隊(duì)如果你的系統(tǒng)已經(jīng)是一個(gè)“大型單體”我的建議是直接選“平臺(tái)化先行 絞殺者模式”的結(jié)合先用容器和 CI/CD 把底座打平隨后挑一個(gè)相對(duì)獨(dú)立的功能模塊做第一個(gè)替換試點(diǎn)用試點(diǎn)的經(jīng)驗(yàn)校準(zhǔn)后續(xù)節(jié)奏。2.3 量化評(píng)估用一張打分表決定是否啟動(dòng)改造前面的盤點(diǎn)輸出的是定性結(jié)論但很多團(tuán)隊(duì)在立項(xiàng)時(shí)需要給領(lǐng)導(dǎo)一個(gè)“該不該干、干到什么程度”的量化說(shuō)法。我習(xí)慣把盤點(diǎn)表里的幾個(gè)核心維度做成一個(gè)打分模型每項(xiàng) 1 到 5 分分?jǐn)?shù)越低越需要改造。評(píng)估維度打分標(biāo)準(zhǔn)得分發(fā)布效率1 分每周一次以上人工深夜發(fā)版5 分隨時(shí)可發(fā)布2擴(kuò)展能力1 分?jǐn)U容要重新申請(qǐng)物理機(jī)5 分資源可按需伸縮1模塊耦合1 分核心域被超 10 個(gè)模塊反向依賴5 分依賴清晰2數(shù)據(jù)歸屬1 分單庫(kù)承載全部業(yè)務(wù)且嚴(yán)重跨域訪問(wèn)5 分?jǐn)?shù)據(jù)域清晰2可觀測(cè)性1 分無(wú)日志聚合無(wú)鏈路追蹤5 分全鏈路可追蹤2技術(shù)棧健康1 分存在 EOL 且有高危漏洞的組件5 分版本受支持2總分的經(jīng)驗(yàn)判斷低于 15 分建議啟動(dòng)系統(tǒng)性改造15 到 20 分之間選擇局部改造20 分以上說(shuō)明當(dāng)前架構(gòu)還能支撐只需要持續(xù)優(yōu)化。這個(gè)模型不嚴(yán)謹(jǐn)?shù)锰幨悄軓?qiáng)制團(tuán)隊(duì)把含糊認(rèn)知變成可比較的數(shù)據(jù)后續(xù)改造做完一個(gè)模塊再用這張表復(fù)打分可以直觀看到“什么時(shí)候可以驗(yàn)收”。這個(gè)打分還有一個(gè)隱藏作用它能擋住不合理的需求。很多時(shí)候領(lǐng)導(dǎo)看了一篇講微服務(wù)的文章就要求拆微服務(wù)但打完分發(fā)現(xiàn)當(dāng)前系統(tǒng)問(wèn)題根本不在服務(wù)粒度而在于發(fā)布與可觀測(cè)性。這時(shí)候拿數(shù)據(jù)說(shuō)話比講一百句技術(shù)道理都管用。3. 分步落地路徑從容器化到老中間件遷移的可復(fù)現(xiàn)順序3.1 第一步先把運(yùn)行形態(tài)統(tǒng)一到容器讓環(huán)境不再飄忽架構(gòu)現(xiàn)代化不要上來(lái)就拆服務(wù)。對(duì)任何一個(gè)仍有業(yè)務(wù)價(jià)值的單體系統(tǒng)來(lái)說(shuō)第一步應(yīng)該是把它的運(yùn)行形態(tài)統(tǒng)一到容器。這一步不改變業(yè)務(wù)代碼但能解決兩個(gè)實(shí)際問(wèn)題環(huán)境一致性開發(fā)、測(cè)試、生產(chǎn)不再因?yàn)榄h(huán)境差異出現(xiàn)“在我本機(jī)是好的”和部署效率鏡像構(gòu)建完直接滾動(dòng)更新不用再登錄服務(wù)器手動(dòng)替換 JAR。對(duì)一個(gè) Java 單體應(yīng)用我一般會(huì)從一份這樣的 Dockerfile 開始FROM eclipse-temurin:17-jre LABEL maintainerteamexample.com RUN useradd --system --no-create-home appuser COPY --chownappuser:appuser target/app.jar /app/app.jar WORKDIR /app EXPOSE 8080 HEALTHCHECK --interval30s --timeout5s --start-period20s --retries3 \ CMD curl -f http://localhost:8080/actuator/health || exit 1 USER appuser ENTRYPOINT [java, -XX:MaxRAMPercentage75.0, -jar, /app/app.jar]這份文件的關(guān)鍵點(diǎn)有四個(gè)。第一使用非 root 用戶運(yùn)行降低容器內(nèi)被入侵后的影響半徑第二通過(guò) HEALTHCHECK 聲明健康檢查指令便于容器編排平臺(tái)感知應(yīng)用狀態(tài)第三JVM 參數(shù)刻意不寫-Xmx而是用-XX:MaxRAMPercentage75.0讓 JVM 根據(jù)容器內(nèi)存限制動(dòng)態(tài)取值避免容器設(shè)置 2G 而 JVM 認(rèn)為物理機(jī)有 64G 內(nèi)存、最終被 OOMKilled 的經(jīng)典事故第四時(shí)區(qū)和字體這類隱性問(wèn)題直接在鏡像層處理比在每個(gè)啟動(dòng)腳本里做要可靠得多。3.2 第二步在負(fù)載均衡后面插入 API 網(wǎng)關(guān)先把入口切開容器化跑穩(wěn)之后第二步是切入口。老單體通常是對(duì)外暴露一堆直接 HTTP 接口或者基于 ESB 的 SOAP 服務(wù)客戶端直接打到應(yīng)用服務(wù)器上。這種形態(tài)下你不敢拆服務(wù)因?yàn)橹灰獡Q一個(gè) IP所有客戶端都要跟著改配置。解決方法是引入 API 網(wǎng)關(guān)作為統(tǒng)一入口。常見選型是 Kong、APISIX 或 Spring Cloud Gateway。我的習(xí)慣是 APISIX 或者 Kong 這類獨(dú)立部署網(wǎng)關(guān)因?yàn)樗鼈儾唤壎硞€(gè)特定編程語(yǔ)言后續(xù)服務(wù)用 Java、Go、Python 都能統(tǒng)一接入。落地時(shí)先把現(xiàn)有負(fù)載均衡的流量原樣轉(zhuǎn)發(fā)到網(wǎng)關(guān)網(wǎng)關(guān)按原來(lái)相同的路徑規(guī)則轉(zhuǎn)發(fā)到后端單體客戶端完全無(wú)感知。這一階段不要急著在網(wǎng)關(guān)上搞復(fù)雜的認(rèn)證和限流先把路由跑通。一個(gè)最小可用的 APISIX 路由配置是這樣的routes: - name: legacy-monolith uri: /* upstream: type: roundrobin nodes: legacy-app-1:8080: 1 legacy-app-2:8080: 1 plugins: proxy-rewrite: regex_uri: [^/api/(.*), /$1]這段配置做的事情很簡(jiǎn)單所有以/api/開頭的請(qǐng)求都轉(zhuǎn)發(fā)到后端的兩個(gè)單體節(jié)點(diǎn)并且把/api/前綴剝掉與老應(yīng)用實(shí)際接口路徑對(duì)齊。roundrobin是負(fù)載均衡策略兩個(gè)節(jié)點(diǎn)權(quán)重都是 1表示均分流量。網(wǎng)關(guān)就位后后續(xù)每拆出一個(gè)新服務(wù)只需要加一條更具體的路由規(guī)則把某個(gè) URL 前綴的流量從單體切到新服務(wù)客戶端與網(wǎng)關(guān)之間的約定完全不用變。做完這一步你的系統(tǒng)入口變成了一個(gè)可編程的開關(guān)這個(gè)開關(guān)是后續(xù)絞殺者模式落地的關(guān)鍵。沒(méi)有這個(gè)開關(guān)每拆一個(gè)服務(wù)都要?jiǎng)涌蛻舳说扔诮o自己上刑。3.3 第三步按依賴關(guān)系由外向內(nèi)拆服務(wù)接口兼容優(yōu)先網(wǎng)關(guān)就位后可以開始真正動(dòng)手拆服務(wù)了。最常見的拆分錯(cuò)誤是從核心域下手——比如電商系統(tǒng)上來(lái)就先拆訂單服務(wù)。因?yàn)橛唵伪凰心K依賴拆它的瞬間會(huì)牽出一大片調(diào)用方改造項(xiàng)目直接卡住。我通常會(huì)倒過(guò)來(lái)拆。拿第 2 章的依賴分析結(jié)果從“被依賴最少、邏輯相對(duì)獨(dú)立”的功能開始。很典型的是通知服務(wù)、短信服務(wù)、導(dǎo)出服務(wù)這類周邊功能。把它們拆出來(lái)通過(guò)網(wǎng)關(guān)把對(duì)應(yīng) URL 轉(zhuǎn)發(fā)到新服務(wù)老代碼里的原入口下線。這樣一個(gè)周期通常一到兩周就能完成一次上線且風(fēng)險(xiǎn)可控——出問(wèn)題把網(wǎng)關(guān)路由切回去就行這就是后悔藥。拆服務(wù)的技術(shù)細(xì)節(jié)里接口兼容性問(wèn)題最大。老系統(tǒng)內(nèi)部大量 Feign 或 HTTP 調(diào)用拆出去的服務(wù)不可能讓所有調(diào)用方一次性改完。我的做法是三個(gè)原則新服務(wù)提供 V1 版本的 REST 接口路徑和參數(shù)盡量與老的內(nèi)部調(diào)用方式對(duì)齊老系統(tǒng)保留原有調(diào)用方式通過(guò)網(wǎng)關(guān)或注冊(cè)中心把請(qǐng)求轉(zhuǎn)到新服務(wù)期間不在老代碼里新增對(duì)拆分服務(wù)的新調(diào)用點(diǎn)避免兩頭擴(kuò)展。這一步不需要分布式事務(wù)框架因?yàn)椴鸬亩际侵苓吂δ懿僮鞯臄?shù)據(jù)相對(duì)獨(dú)立。真正的數(shù)據(jù)耦合問(wèn)題放到下一步處理。3.4 第四步老中間件的遷移與替換IBM MQ 是繞不開的場(chǎng)景在很多制造業(yè)、銀行和政企客戶現(xiàn)場(chǎng)IT 系統(tǒng)里一定有一個(gè)繞不開的老中間件IBM MQ。它是上一代 SOA 架構(gòu)的核心組件承擔(dān)著系統(tǒng)間的異步消息通信。我在不少項(xiàng)目里見過(guò)同一個(gè)問(wèn)題IBM MQ 的版本已經(jīng)非常老舊跑在幾臺(tái)物理機(jī)上運(yùn)維手冊(cè)只有一個(gè)人會(huì)看每次擴(kuò)容都要停機(jī)變更。老中間件遷移通常有三條路。第一條路是版本升級(jí)與容器化部署把老版本 MQ 遷移到新版并跑在容器里。這適用于“消息中間件本身運(yùn)行穩(wěn)定只是硬件老化、運(yùn)維不便”的場(chǎng)景。IBM MQ 有官方容器鏡像支持在 Kubernetes 上部署高可用隊(duì)列管理器但要注意它的 License 模式和傳統(tǒng)部署有差別需要和廠商確認(rèn)指標(biāo)。第二條路是替換為云上的托管消息服務(wù)。如果業(yè)務(wù)允許更換協(xié)議這是最省運(yùn)維成本的路。原來(lái)用 MQ 的 JMS/原生 API 改成新客戶端隊(duì)列模型換成主題/消費(fèi)組模型。這條路的工程量主要在應(yīng)用代碼適配不在消息路由本身。第三條路是保留 IBM MQ 但把它邊緣化在新架構(gòu)中用 Kafka 或 RocketMQ 承載新的業(yè)務(wù)事件流老 MQ 只做新舊系統(tǒng)之間的數(shù)據(jù)交換橋接逐步把它的負(fù)載降到最低。這個(gè)方案特別適合絞殺者模式過(guò)渡期——新舊系統(tǒng)并存時(shí)消息通信還是走 MQ但新系統(tǒng)內(nèi)部的事件已經(jīng)走新的消息管道。我見過(guò)走得最穩(wěn)的遷移路徑是把這三條路按時(shí)間先后串起來(lái)先容器化部署解決硬件與運(yùn)維問(wèn)題中間件穩(wěn)定后新系統(tǒng)間逐步使用新的事件管道替代 MQ最后把只在舊系統(tǒng)間流轉(zhuǎn)的消息保留在 MQ 上設(shè)置好最終下線時(shí)間。這個(gè)節(jié)奏下每一步都有明確驗(yàn)收標(biāo)準(zhǔn)不會(huì)出現(xiàn)“遷移到一半消息兩端對(duì)不上賬”這種黑匣子式返工。4. 關(guān)鍵技術(shù)參數(shù)容器、網(wǎng)關(guān)與 IBM MQ 遷移里的落地配置4.1 容器資源與 JVM 參數(shù)別讓 Java 應(yīng)用在容器里死得不明不白Java 應(yīng)用容器化最容易翻車的就是內(nèi)存參數(shù)。傳統(tǒng)部署時(shí)大家習(xí)慣在啟動(dòng)腳本里寫-Xmx2g但到了容器環(huán)境里這個(gè)固定值會(huì)帶來(lái)兩個(gè)問(wèn)題容器內(nèi)存上限設(shè)了 2GJVM 堆也只認(rèn) 2G堆外內(nèi)存一超就 OOMKilled或者容器明明只有 2GJVM 卻按物理機(jī)內(nèi)存自動(dòng)算出一個(gè)大堆直接把自己壓死。推薦的做法是讓 JVM 感知容器限制動(dòng)態(tài)取值。在 Kubernetes 的 Deployment 配置里資源聲明和 JVM 參數(shù)要配套寫resources: requests: memory: 2Gi cpu: 1 limits: memory: 2Gi cpu: 2配套的 JVM 啟動(dòng)參數(shù)是-XX:MaxRAMPercentage75.0 -XX:InitialRAMPercentage50.0MaxRAMPercentage75.0的意思是 JVM 最多使用容器內(nèi)存上限的 75%剩下的留給堆外內(nèi)存和系統(tǒng)開銷。InitialRAMPercentage50.0是讓 JVM 啟動(dòng)時(shí)先申請(qǐng)一半內(nèi)存避免一次性把堆撐到頂也給運(yùn)維留出觀察空間。這里有兩個(gè)血淚經(jīng)驗(yàn)一是不要試圖把MaxRAMPercentage調(diào)到 90 以上除非你確定應(yīng)用沒(méi)有大量堆外緩沖二是 JVM 參數(shù)不要寫在 Dockerfile 里寫死要允許通過(guò)環(huán)境變量在部署層覆蓋否則不同規(guī)格的 Pod 只能共用同一套內(nèi)存策略。CPU 方面Java 應(yīng)用在容器里的線程池大小默認(rèn)會(huì)參考可用 CPU 核數(shù)。如果limits.cpu設(shè)得太小而requests.cpu設(shè)得過(guò)大會(huì)出現(xiàn) Pod 能調(diào)度但一壓測(cè)就線程饑餓的現(xiàn)象。我的經(jīng)驗(yàn)值是requests和limits之間的差距不要超過(guò) 1 倍且要壓測(cè)確認(rèn)。4.2 網(wǎng)關(guān)限流與超時(shí)參數(shù)數(shù)值差一點(diǎn)表現(xiàn)差很多網(wǎng)關(guān)給系統(tǒng)帶來(lái)了統(tǒng)一的入口但也容易成為新的不穩(wěn)定點(diǎn)。最常見的問(wèn)題不是網(wǎng)關(guān)本身掛了而是上游服務(wù)變慢時(shí)網(wǎng)關(guān)的連接池被占滿導(dǎo)致所有下游服務(wù)跟著不可用。因此網(wǎng)關(guān)上三個(gè)參數(shù)必須提前設(shè)置合理。以 APISIX 為例我一般在每個(gè)服務(wù)路由上配一個(gè)統(tǒng)一的超時(shí)時(shí)間upstream: timeout: connect: 5 send: 10 read: 15數(shù)字單位是秒。connect: 5表示連接到后端服務(wù)最多等 5 秒超過(guò)即失敗send: 10指網(wǎng)關(guān)向服務(wù)發(fā)送請(qǐng)求的整體超時(shí)read: 15是從發(fā)送完請(qǐng)求到收到響應(yīng)體的最大等待時(shí)間這是最需要關(guān)注的參數(shù)。如果后端服務(wù)有長(zhǎng)輪詢或大文件下載接口read需要單獨(dú)調(diào)大不要全局套用否則會(huì)出現(xiàn)“新服務(wù)一切正常但老系統(tǒng)頻繁報(bào) 504”的現(xiàn)象。限流參數(shù)方面做現(xiàn)代化改造的初期我一般不用復(fù)雜的限流算法先在網(wǎng)關(guān)上做最簡(jiǎn)單的固定窗口限流按 URL 前綴限制 QPS。數(shù)值可以這樣配plugins: limit-count: count: 2000 time_window: 60 rejected_code: 429 key: remote_addr這組配置的含義是每個(gè)客戶端 IP 在 60 秒窗口內(nèi)最多 2000 次請(qǐng)求超過(guò)返回 429。key: remote_addr是按來(lái)源 IP 限流。需要注意如果你們的系統(tǒng)前端是統(tǒng)一出口 IP那這個(gè) 2000 會(huì)非常容易被擊穿。此時(shí)應(yīng)改用key: remote_addr 全局限流的組合或者按請(qǐng)求路徑做限流而不是只依賴單一維度。限流參數(shù)調(diào)不好經(jīng)常給人一種玄學(xué)的感覺(jué)其實(shí)背后的判斷邏輯只有一個(gè)——你的后端服務(wù)在峰值負(fù)載下能承受多少 QPS壓測(cè)打出來(lái)的真實(shí)數(shù)字就是限流值的上限。4.3 IBM MQ 遷移時(shí)的關(guān)鍵參數(shù)與雙跑策略IBM MQ 遷移的細(xì)節(jié)大多數(shù)踩坑都集中在參數(shù)與數(shù)據(jù)一致性上。先講最要命的一個(gè)連接參數(shù)。老系統(tǒng)連 MQ 時(shí)很多用的是綁定模式當(dāng)前 MQ 客戶端用 Java Native Interface 直連隊(duì)列管理器遷移到容器化部署或新環(huán)境后必須改為客戶端模式連接。這個(gè)改動(dòng)涉及連接工廠參數(shù)包括隊(duì)列管理器名稱QMGR、連接主機(jī)、端口、通道名稱Channel和傳輸類型Transport Type任何一個(gè)填錯(cuò)客戶端都體現(xiàn)為“MQRC 2059無(wú)法連接隊(duì)列管理器”或“MQRC 2009連接斷開”。這里有一份常見參數(shù)對(duì)照參考參數(shù)項(xiàng)傳統(tǒng)部署方式容器化/客戶端模式隊(duì)列管理器QMGR本地綁定直連填寫遠(yuǎn)端 QMGR 名稱連接通道無(wú)綁定模式不需要必須指定如CHL.TO.QMGR連接端口本機(jī)進(jìn)程隊(duì)列管理器監(jiān)聽端口常見 1414傳輸類型綁定BINDING客戶端CLIENT消息確認(rèn)AUTO_ACKNOWLEDGEAUTO_ACKNOWLEDGE 或 TRANSACTED數(shù)據(jù)一致性是另一個(gè)大坑。遷移期間新舊系統(tǒng)并存消息不能丟也不能重復(fù)。穩(wěn)妥的做法是采用“雙寫 消費(fèi)冪等”生產(chǎn)端同時(shí)將消息寫入 MQ 和新的消息管道消費(fèi)端在新舊系統(tǒng)都上線后先消費(fèi)新管道消息消息表記錄消費(fèi)唯一鍵這條遷移期一過(guò)再把生產(chǎn)端 MQ 寫入關(guān)掉。消費(fèi)冪等表是實(shí)現(xiàn)數(shù)據(jù)不重不漏的關(guān)鍵核心字段就是消息 ID 和業(yè)務(wù)唯一鍵。我在現(xiàn)場(chǎng)見過(guò)很多團(tuán)隊(duì)在遷移 MQ 時(shí)只關(guān)注生產(chǎn)端雙寫忘了消費(fèi)端的冪等結(jié)果消息被兩個(gè)系統(tǒng)各消費(fèi)一次第二天對(duì)賬單數(shù)據(jù)全亂了。這個(gè)教訓(xùn)后面細(xì)講。5. 避坑指南架構(gòu)現(xiàn)代化最常見的六個(gè)翻車點(diǎn)5.1 服務(wù)拆了數(shù)據(jù)庫(kù)沒(méi)拆微服務(wù)白拆現(xiàn)象團(tuán)隊(duì)花了大半年把服務(wù)拆成了十幾個(gè)每個(gè)服務(wù)能獨(dú)立部署了但生產(chǎn)庫(kù)還是原來(lái)那一個(gè)大庫(kù)。上線第一個(gè)雙十一訂單庫(kù)的慢 SQL 把用戶服務(wù)拖死了所有服務(wù)集體超時(shí)。原因拆分順序搞反了。代碼層面的接口調(diào)用可以快速改完但數(shù)據(jù)層面的耦合才是根上的依賴。不拆數(shù)據(jù)服務(wù)之間的“隱藏依賴”就永遠(yuǎn)存在數(shù)據(jù)庫(kù)一張表被幾個(gè)服務(wù)同時(shí)讀寫的時(shí)候你的微服務(wù)在物理上還是單體。解決回到第 2 章的數(shù)據(jù)盤點(diǎn)先把跨域訪問(wèn)的表梳理出來(lái)按歸屬分配給某個(gè)服務(wù)其他服務(wù)不再直連這張表改為通過(guò) API 調(diào)用歸屬服務(wù)訪問(wèn)數(shù)據(jù)。這個(gè)過(guò)程比拆服務(wù)本身要長(zhǎng)但這是唯一正確的路徑。5.2 容器化后應(yīng)用一重啟用戶全部掉線現(xiàn)象單體應(yīng)用容器化上線某次滾動(dòng)更新后大量用戶被踢下線登錄態(tài)消失。原因老單體應(yīng)用把 Session 存在 JVM 本地內(nèi)存里。容器化后Pod 重建意味著內(nèi)存清空。過(guò)去物理機(jī)部署很少重啟問(wèn)題不顯眼容器一滾動(dòng)問(wèn)題立刻暴露。這也是容器化對(duì)“無(wú)狀態(tài)化”要求的典型體現(xiàn)。解決把 Session 外置到 Redis或直接改用無(wú)狀態(tài)登錄憑證。單體階段改造成本最低的做法是把 Session 從 Tomcat 本地存儲(chǔ)遷移到 Redis 存儲(chǔ)Tomcat 有現(xiàn)成的tomcat-redis-session-manager方案或者用 Spring 的 session 共享方案。總之一切不能隨 Pod 重建而消失的狀態(tài)都不能留在 JVM 里。5.3 網(wǎng)關(guān)成了新的單點(diǎn)掛了以后全站癱瘓現(xiàn)象服務(wù)拆分進(jìn)展順利某天凌晨發(fā)版后網(wǎng)關(guān)機(jī)器負(fù)載飆高然后所有接口不可用?？匆幌卤O(jiān)控后端服務(wù)都活著只有網(wǎng)關(guān)掛了。原因網(wǎng)關(guān)在拆分初期承接了所有流量但團(tuán)隊(duì)沒(méi)有給它配置熔斷和合理的超時(shí)。上游一個(gè)服務(wù)變慢連接池被占滿網(wǎng)關(guān)線程全部阻塞最終拖垮整個(gè)網(wǎng)關(guān)進(jìn)程。解決兩個(gè)動(dòng)作。第一網(wǎng)關(guān)必須集群化部署至少兩個(gè)副本前面用負(fù)載均衡掛住第二給所有下游路由配上超時(shí)與熔斷規(guī)則參考 4.2 的參數(shù)。熔斷觸發(fā)后寧可讓這部分功能暫時(shí)不可用也別讓網(wǎng)關(guān)整體死掉。網(wǎng)關(guān)是接入層它的可用性優(yōu)先級(jí)高于任何單個(gè)業(yè)務(wù)服務(wù)。5.4 IBM MQ 遷移時(shí)消息雙寫后出現(xiàn)重復(fù)消費(fèi)現(xiàn)象按“生產(chǎn)端雙寫 MQ 和新管道”的方案遷移消息系統(tǒng)上線后下游應(yīng)用收到大量重復(fù)消息部分訂單狀態(tài)被重復(fù)更新。原因只做了生產(chǎn)端的雙寫沒(méi)有做消費(fèi)端的冪等去重。兩條管道各自投遞消息消費(fèi)端兩個(gè)進(jìn)程并駕齊驅(qū)同一個(gè)業(yè)務(wù)消息被處理了兩次。這個(gè)坑是排隊(duì)系統(tǒng)遷移到流式系統(tǒng)最容易踩的。解決所有消費(fèi)端統(tǒng)一加一張消息去重表以業(yè)務(wù)唯一鍵做唯一約束消費(fèi)前先插入插入成功才處理業(yè)務(wù)邏輯。唯一鍵通常由消息頭加業(yè)務(wù)主鍵拼接生成。只要冪等表在重復(fù)消費(fèi)最多浪費(fèi)一點(diǎn)處理時(shí)間不會(huì)產(chǎn)生臟數(shù)據(jù)。后來(lái)我把“消費(fèi)冪等必須先行”寫進(jìn)了項(xiàng)目的驗(yàn)收定義里這條屬于不需要討論的必要條件。5.5 分布式事務(wù)沒(méi)人想好方案數(shù)據(jù)對(duì)不上賬現(xiàn)象拆完服務(wù)后一個(gè)創(chuàng)建訂單的流程要經(jīng)過(guò)訂單服務(wù)、庫(kù)存服務(wù)、積分服務(wù)三個(gè)系統(tǒng)。某個(gè)節(jié)點(diǎn)失敗后數(shù)據(jù)出現(xiàn)不一致——訂單創(chuàng)建了庫(kù)存扣了積分沒(méi)加。原因單體時(shí)代靠本地?cái)?shù)據(jù)庫(kù)事務(wù)保證一致性的邏輯在服務(wù)拆分后不再成立。而團(tuán)隊(duì)在拆分設(shè)計(jì)階段沒(méi)有約定一致性方案以為同步調(diào)用就能保證不出錯(cuò)。解決不是所有業(yè)務(wù)都需要強(qiáng)一致。先按業(yè)務(wù)場(chǎng)景劃分金錢賬與明細(xì)賬強(qiáng)一致場(chǎng)景用盡量縮小事務(wù)邊界的方案能接受最終一致的業(yè)務(wù)用本地消息表加異步補(bǔ)償。IBM 的實(shí)踐分享里提到的策略也是這個(gè)方向。拆服務(wù)前先把一致性方案定下來(lái)這件事要寫進(jìn)設(shè)計(jì)文檔的必填項(xiàng)里評(píng)審時(shí)逐項(xiàng)確認(rèn)。5.6 改造期間只上技術(shù)、不上治理半年后技術(shù)債照舊現(xiàn)象容器化也做了微服務(wù)也拆了但半年后新環(huán)境里的系統(tǒng)耦合度和老系統(tǒng)差不多只是從“大泥球”變成了“分布式大泥球”。原因現(xiàn)代化改造期間沒(méi)有同步建設(shè)架構(gòu)治理機(jī)制。服務(wù)之間隨意新增調(diào)用新團(tuán)隊(duì)不懂依賴規(guī)則代碼評(píng)審沒(méi)人約束跨服務(wù)調(diào)用邊界。架構(gòu)現(xiàn)代化只解決了運(yùn)行形態(tài)沒(méi)解決組織與協(xié)作方式。解決從拆分第一批服務(wù)起就建立兩個(gè)紀(jì)律新的跨服務(wù)調(diào)用必須經(jīng)過(guò)評(píng)審與登記每周用工具掃描一次服務(wù)依賴圖出現(xiàn)新環(huán)立即處理。架構(gòu)治理不是成立一個(gè)虛擬架構(gòu)組就完事要落到 CI 流水線里掃描不通過(guò)就不允許合入代碼。6. 進(jìn)階技巧用灰度發(fā)布和流量回放給轉(zhuǎn)型上雙保險(xiǎn)架構(gòu)現(xiàn)代化改造進(jìn)行到中后期最大的風(fēng)險(xiǎn)已經(jīng)不是“做不出來(lái)”而是“改完了不知道自己改壞了”。微服務(wù)拆分后接口的語(yǔ)義、超時(shí)行為、異常碼傳遞都可能與老系統(tǒng)存在細(xì)微差異這些差異在單元測(cè)試和預(yù)發(fā)環(huán)境里往往發(fā)現(xiàn)不了。我的習(xí)慣是給每個(gè)關(guān)鍵模塊上線時(shí)配兩套驗(yàn)證手段灰度發(fā)布和流量回放。灰度發(fā)布是第一步。改造后的新服務(wù)先不要直接承接全部流量而是通過(guò)網(wǎng)關(guān)設(shè)置權(quán)重路由把 5% 的線上真實(shí)流量切到新服務(wù)人為讓新老兩套并行運(yùn)行一段時(shí)間。APISIX 的權(quán)重路由配置很簡(jiǎn)單給同一個(gè)路由配兩個(gè) upstream 節(jié)點(diǎn)權(quán)重分別設(shè) 5 和 95 即可。運(yùn)行時(shí)觀察新服務(wù)的錯(cuò)誤率、響應(yīng)延遲和業(yè)務(wù)報(bào)表數(shù)據(jù)是否與老系統(tǒng)對(duì)得上。沒(méi)有問(wèn)題就逐步調(diào)高權(quán)重到 10%、30%、50%、100%有問(wèn)題就一鍵把權(quán)重歸零切回老系統(tǒng)。這套機(jī)制比任何預(yù)發(fā)聯(lián)調(diào)都可靠因?yàn)榫€上真實(shí)流量的復(fù)雜程度永遠(yuǎn)比測(cè)試環(huán)境模擬出來(lái)的高一個(gè)量級(jí)。流量回放是第二步。灰度發(fā)布能發(fā)現(xiàn)大多數(shù)問(wèn)題但有些低頻操作可能一周才發(fā)生一次灰度窗口覆蓋不到。這時(shí)候用流量回放補(bǔ)盲區(qū)用 GoReplay 這類工具把老系統(tǒng)接到的線上請(qǐng)求錄下來(lái)回放到新服務(wù)里對(duì)比新老兩個(gè)系統(tǒng)的響應(yīng)差異。我一般會(huì)在高峰期錄制半小時(shí)到一小時(shí)的流量然后在預(yù)發(fā)環(huán)境回放重點(diǎn)對(duì)比響應(yīng)碼、響應(yīng)耗時(shí)和部分關(guān)鍵字段?；胤挪灰?100% 報(bào)文一致——時(shí)間戳、生成的 ID 這類字段必然不同但響應(yīng)碼分布和業(yè)務(wù)核心字段必須對(duì)得上。自動(dòng)化對(duì)比腳本跑完后人工看一眼差異清單里的高優(yōu)先級(jí)項(xiàng)目這一步能篩出絕大多數(shù)隱藏問(wèn)題。我自己做架構(gòu)改造有一條始終堅(jiān)持的教訓(xùn)任何一次的切流上線都要準(zhǔn)備好當(dāng)天回滾的方案并確保團(tuán)隊(duì)里至少有一個(gè)人完整演練過(guò)回滾操作?；叶劝l(fā)布、流量回放、回滾預(yù)案這三樣疊加起來(lái)架構(gòu)現(xiàn)代化開工到收官都會(huì)踏實(shí)很多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取