許多工程團隊在面對巨石應用（Monolith，指將所有功能全部打包在單一程式碼庫與部署單位的系統）時，最常遇到的困境是：想做微服務化遷移，但公司不願意撥出專門的預算或給予數年的開發時間，因為這類工作在短期內不直接產生營收。
本文將分享 Paycor 團隊如何透過「拉動式遷移」（Pull-based Migration）策略，在沒有獨立預算的情況下，將三個巨大的 HCM（人力資本管理）系統拆分為 120 個領域微服務的實務經驗。
拉動式遷移的核心邏輯：硬止損規則
傳統的遷移方式是制定一個龐大的計畫，試圖一次性地將功能搬遷。而「拉動式遷移」則採取一種截然不同的策略：將遷移變成日常開發的副作用。
團隊制定了一條硬止損規則：禁止對巨石應用進行任何新的功能開發、Bug 修復或增強。任何需要觸動巨石應用的需求，都必須直接將該功能「切出」成一個新的領域微服務（Domain Service）。
這意味著遷移的成本被分攤到了每一個產品故事（User Story）中。例如，原本在巨石應用中只需 4 小時的修改，現在可能需要 6 小時來建立新服務。這 50% 的額外成本被視為一種「遷移稅」，由原本的功能開發預算承擔，而非申請專項遷移經費。
讓遷移可行化的三大平台基建
如果建立一個新服務需要申請兩週的權限或配置環境，工程師絕對不會願意支付這 50% 的時間成本。因此，必須先投資以下三項基礎設施，將新服務的啟動時間從「週」縮短到「分鐘」。
第一，基於領域的訂閱模型（Subscription-per-Domain） 在 Azure 中為每個產品領域（如：薪資、考勤、報表）建立獨立的訂閱帳戶。這樣做有三個好處： 成本透明化：能精確知道每個領域消耗了多少雲端資源。 故障隔離（Blast Radius Isolation）：單一領域的配置錯誤或腳本跑飛，不會導致整個平台崩潰。 責任制：團隊能直接看到自己的資源使用量，在 Code Review 時會更在意效能。 為了實現這一點，團隊開發了自助式部署模板，讓 AKS 命名空間、資料庫、訊息佇列等基礎設施能一鍵完成。
第二，使用 API Gateway 作為路由接縫（Routing Seam） 在所有端點前部署 API Management (APIM)。當新服務開發完成後，APIM 可以控制流量分配。客戶端（如 App 或第三方 API）完全不需要修改路徑，後端可以將 1% 的流量導向新服務，驗證沒問題後再逐步調高比例。
第三，快取層支持的特性開關（Feature Flags） 為了支持漸進式發布與秒級回滾，團隊使用了 Azure App Configuration 並在其上封裝了一層 Redis 快取。 這樣做解決了兩個問題：一是避免高併發時頻繁請求設定中心導致的效能瓶頸與高成本；二是當新服務出錯時，能透過開關在數秒內將流量切回巨石應用，將影響降至最低。
針對高可靠性場景的數據處理路徑
在人力資源系統中，考勤打卡（Punch）絕對不能遺失，否則會導致員工領不到薪水。針對這種高要求場景，團隊設計了以下路徑：
持久化優先：所有打卡來源（手機、打卡機、API 等）進入系統後，第一步是進入 Service Bus 佇列，隨即寫入 Table Storage 作為持久化記錄。只有在寫入成功後，才會向客戶端回傳成功。 事件分發（Fan-out）：利用 Event Hub 將持久化後的數據分發給四個獨立消費者（薪資計算、主資料庫、報表、即時清單）。各消費者獨立擴展且互不阻塞。 確定性回填（Deterministic Backfill）：如果下游消費者故障，可以根據持久化記錄，按順序重新執行（Replay）遺漏的事件。由於消費者端實作了冪等性（Idempotency，指相同操作執行多次結果相同），因此能保證數據最終一致且不遺失。
應對流量尖峰的成本優化
考勤系統在早上 8 到 9 點會有極高的流量尖峰。如果為了這 5 分鐘的峰值而維持全天的高規格配置，成本將極其驚人。團隊採取了組合拳策略：
定時預熱（Scheduled Pre-warming）：在預期尖峰前 15 分鐘提前擴展節點。因為反應式自動擴展（Reactive Autoscaling）速度太慢，無法應對瞬間爆發。 反應式擴展：處理預熱之外的變數（如假期或不同公司的上班時間）。 Serverless 分發：將 Event Hub 的消費者部署為 Azure Functions（消費模式），在沒有事件時成本為零，有流量時秒級擴展。
這套組合將尖峰時段的支出降低了約 70%。
可重複的切換模式與反思
遷移 100 多個服務後，團隊總結出一套標準路徑：建立服務 $\rightarrow$ 特性開關雙跑 $\rightarrow$ 內部流量驗證 $\rightarrow$ APIM 權重漸進切換 $\rightarrow$ 移除巨石路徑。
然而，拉動式遷移也有其局限性：那些「沒人觸碰」的舊功能（Cold Corners）永遠不會被遷移。這類功能佔系統的 20%，最終必須決定是要額外撥款遷移，還是就讓它們留在巨石應用中直到系統退役。
給工程領導者的 90 天建議
如果你正處於沒有遷移預算的困境，可以嘗試以下步驟： 前 30 天：選擇一個小領域，建立自動化部署模板、APIM 路由與特性開關基建。 31-60 天：切出第一個微服務，執行端點切換，並量化「遷移稅」（開發時間增加了多少）。 61-90 天：切出第二個服務，將經驗標準化並定義領域邊界圖（Seam Map）。
最關鍵的不是技術，而是組織紀律：能否在 Code Review 中堅持「不增加巨石應用功能」的原則，以及是否能忍受短期內開發速度的輕微下降。
來源：infoq.com (The Hard-Stop Rule: From 3 HCM Monoliths to 120 Domain Microservices)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。