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