譯者 | 劉汪洋

審校 | 重樓

微服務架構以其可擴展性、敏捷性和彈性深受青睞，但在實踐中，許多組織往往遭遇可能削弱這些優勢的挑戰。本文聚焦于常見的微服務反模式，并結合實際經驗提供構建高效、可擴展微服務的實用建議。

要避免的微服務反模式

1.分布式單體

問題

“分布式單體” 是指盡管系統形式上采用了微服務架構，但服務之間高度耦合，以至于每次更新一個服務時，都需要同時調整或重新部署多個其他服務。這種設計實質上延續了單體架構的特點，只是將其組件分散在了不同的服務中，未能實現真正的微服務范式。

真實場景

例如，在一個包含支付服務、訂單服務和庫存服務的電子商務系統中，若這些服務彼此強依賴以完成用戶事務，則任何一項改動都會導致連鎖反應，要求其他服務同步更新或重新部署。盡管從外部看似為分布式系統，實際上這種耦合模式背離了微服務的核心原則。

實用解決方案

通過采用領域驅動設計 (DDD)，明確各服務的邊界上下文，從而實現職責分離。例如，將“支付服務”設計為獨立的自治域，僅通過定義清晰的 API 與其他服務交互，如“訂單服務”。同樣，訂單服務與庫存服務之間可以采用事件驅動的設計模式（如基于 Kafka 的消息中間件），從而避免直接依賴。

專業建議

在系統遷移過程中，建議使用功能開關逐步引入新功能，同時確保與現有系統的向后兼容性。這種方法不僅降低了遷移風險，還能在實際應用中驗證新架構的穩定性和可行性。

2.跨服務共享數據

問題

跨服務共享數據庫，尤其是允許多個服務對同一數據庫表進行寫操作，會違反微服務架構中關于服務自治的核心原則。這種設計增加了服務間的耦合度，使得對數據庫的任何更改都可能影響多個服務，從而削弱了微服務的獨立性和靈活性。

真實場景

在典型的 ERP 系統中，銷售服務和庫存服務可能需要訪問同一產品表進行數據寫入。例如，對產品信息的任何架構調整或寫操作，都會引發連鎖反應，導致相關服務發生故障。這種共享數據庫的模式不僅增加了系統的復雜性，還需要團隊間密切協調，降低了開發效率。

實用解決方案

• 封裝數據庫邏輯：將數據庫訪問邏輯封裝在特定的服務中，通過定義明確的 API 提供數據訪問功能，避免其他服務直接訪問數據庫。
• 引入只讀副本：使用只讀副本或緩存解決方案（如 Redis）滿足其他服務的讀取需求，同時確保寫操作僅限于擁有數據所有權的服務。
• 分布式數據庫隔離：最終目標是為每個微服務提供獨立的數據庫，但在過渡期間，可以先定義明確的寫入權限，僅允許單一服務對特定表進行寫操作，其他服務通過 API 或查詢接口實現只讀訪問。

實際挑戰

實現每個微服務獨立數據庫可能面臨較大的遷移成本，特別是在復雜系統中。作為折衷方案，可以在共享數據庫中采用“每個服務一個模式”的方法。具體而言，為每個微服務分配專屬的數據庫模式（Schema），其他服務無法直接訪問這些模式中的數據，除非通過指定的 API。

陷阱

對于無模式數據庫（如 MongoDB），嚴格的 Schema 管理并不適用。然而，即便在無模式數據庫中，共享集合的微服務仍可能因為隱式的數據協議產生耦合問題。例如，一個服務以特定格式存儲數據，另一個服務卻期望以不同格式讀取這些數據，這種隱式契約會導致隱藏的兼容性問題。因此，無模式數據庫中的服務間數據訪問也應通過 API 抽象來避免直接依賴。

3.過度同步調用

問題

過度同步調用（如通過 REST 請求）可能導致系統性能下降。這種模式不僅增加了延遲，還提高了故障傳播的風險，尤其是在高流量場景下，會對系統的穩定性和可擴展性構成嚴重挑戰。

真實場景

以客戶服務系統為例，處理每個客戶工單請求時，系統需要同步調用多個外部服務，如客戶服務以獲取客戶信息、賬戶服務以獲取賬戶詳情、通知服務以發送通知。在高并發流量下，這種設計模式可能導致網絡資源耗盡或服務響應緩慢，嚴重影響用戶體驗。

實用解決方案

• 減少同步調用：將多次 API 調用合并到單個聚合調用中，封裝在一個獨立的網關或終端節點后統一處理。這不僅減少了網絡請求，還提升了整體效率。
• 引入異步通信：采用異步通信機制（如 RabbitMQ 或 Kafka），尤其適用于通知服務等無需實時響應的場景。異步模式可以有效解耦服務間的直接依賴。
• 緩存和非規范化：使用數據緩存或非規范化策略，預處理和存儲讀取優化的數據，以減少對實時請求的依賴。例如，將相關的客戶和賬戶信息提前整合，以便直接響應查詢請求，而無需多次調用其他服務。

專業建議

進一步提升系統性能的策略包括構建讀取優化管道，通過變更數據捕獲 (CDC) 技術實時更新非規范化數據。可以利用 Kafka 等流處理工具搭建數據流管道，當數據源發生變更時，系統自動生成非規范化的讀取副本。這種方法使用戶請求能夠直接訪問預處理的數據，避免了實時解析復雜關系的開銷，從而顯著減少系統延遲和壓力。

4.服務邊界定義不明確

問題

服務的職責范圍如果定義不清晰或存在重疊，會導致系統復雜化，使維護變得困難。同時，模糊的邊界關系也會引發所有權不明確的問題，增加協調成本。

真實場景

在某電子商務系統中，假設一個“產品服務”負責處理產品創建、庫存更新以及客戶評論。由于這些職責相互獨立且功能復雜，將它們歸于同一服務會導致代碼臃腫、不相關邏輯糾纏，并最終使系統難以擴展。

實用解決方案

采用領域驅動設計 (DDD) 原則，根據業務功能而非技術需求劃分服務。例如，將“庫存管理”“客戶評論”和“產品創建”拆分為獨立的微服務，確保每個服務專注于單一領域。清晰的功能分界能夠提高服務自治性，同時減少服務間的耦合。

專業建議

為每個微服務設立對應的跨職能團隊，確保領域知識與技術所有權一致。這樣不僅能夠快速響應業務需求，還能減少因職責不明帶來的溝通障礙。

5.通信協議不一致

問題

在微服務架構中，如果通信協議沒有統一標準，頻繁混用 REST、gRPC 和 WebSockets 等協議，可能會造成維護困難，并增加集成復雜性。開發人員需要理解并適應不同協議的特點，學習曲線陡峭，排障成本高。

真實場景

傳統微服務系統可能使用 REST 處理外部 API 請求，同時在某些內部服務之間采用 gRPC，而事件通知則依賴消息傳遞系統。這種多樣化的協議選擇缺乏一致性，開發人員必須深入理解每種技術的差異和用法，導致項目復雜度增加。

實用解決方案

根據使用場景對通信協議進行標準化。例如：

• 外部接口：采用 REST 作為主要協議，便于跨平臺兼容。
• 內部調用：對低延遲和高性能要求的場景，優先選擇 gRPC。
• 事件驅動架構：利用消息隊列（如 RabbitMQ 或 Kafka）實現異步事件通知。

為團隊提供清晰的文檔和工具以支持標準協議的實現，同時定期審查實際使用情況以確保遵循設計理念。

專業建議

采用服務網格（如 Istio 或 Linkerd），統一管理服務間的通信協議和流量控制。服務網格可以簡化跨服務調用的配置，同時提高監控和故障排除能力，幫助實現標準化和展示一致。

6.缺乏可觀察性

問題

當服務運行狀況、交互方式和性能缺乏可見性時，診斷問題的難度將大幅增加。這種情況會削弱系統的彈性和恢復能力，特別是在復雜的分布式系統中。

真實場景

例如，在一個支付系統中，如果某服務出現故障，這種問題可能通過服務之間的交互鏈發生級聯效應。然而，由于缺乏全局視角和系統級的監控手段，定位根本原因往往需要開發人員手動檢索和分析各服務的分散日志，導致問題解決效率低下。

實用解決方案

• 分布式跟蹤：采用工具如 OpenTelemetry，通過跨服務傳播交易 ID，幫助開發人員追蹤請求在整個系統中的流轉路徑，快速發現問題根源。
• 集中式日志管理：引入 ELK 堆棧（Elasticsearch、Logstash、Kibana）等集中式日志解決方案，將所有服務的日志集中到一個平臺，便于快速檢索和分析。
• 指標采集與監控：使用 Prometheus 等工具收集系統性能指標，并通過 Grafana 等可視化工具監控服務運行狀況。

專業建議

建議從基礎日志記錄開始，隨著系統復雜性增加，逐步引入分布式跟蹤和高級監控功能。同時，設置預警閾值，結合監控系統自動發送告警通知，從被動診斷轉向主動預防。

7.硬編碼配置

問題

硬編碼的配置（如數據庫 URL、密鑰或服務終端節點）不僅會限制部署的靈活性，還可能造成嚴重的安全風險。配置的泄露可能導致敏感信息暴露甚至系統被攻擊。

真實場景

例如，生產環境的數據庫連接字符串直接硬編碼在源代碼中。如果開發人員將代碼提交到版本控制系統，該敏感信息可能意外暴露。此外，某些外部腳本（如自動化工具）也可能包含硬編碼配置，增加了管理難度。

實用解決方案

• 外部化配置：將所有配置（如連接字符串和密鑰）從源代碼中移除，存儲在環境變量、配置管理系統（如 Consul）或 Kubernetes 的 ConfigMaps 和 Secrets 中。
• 自動化管理：在 CI/CD 流水線中集成安全掃描工具，檢測代碼中的硬編碼配置，并在部署前阻止可能的安全風險。

專業建議

定期審核配置文件和密鑰的安全性，確保訪問權限僅限必要范圍。可以通過在 CI/CD 管道中集成自動化腳本，在構建源代碼之前掃描潛在的硬編碼敏感信息，避免人為錯誤造成的安全漏洞。

8.忽視網絡可靠性和延遲

問題

微服務架構由于依賴分布式網絡通信，其穩定性容易受到網絡故障和延遲的影響。如果未采取有效措施緩解網絡問題，可能會引發服務掛起、超時甚至全系統失效。

真實場景

例如，當一個服務調用外部支付提供商的 API 時，如果網絡請求超時且沒有超時保護或重試機制，下游服務可能被阻塞，進而導致整個交易流程中斷。

實用解決方案

• 實施彈性模式：采用工具如 Resilience4j 實現斷路器模式，防止服務因頻繁失敗請求而過載；配置指數回退重試策略，以智能化地重新嘗試失敗的請求。
• 設置超時保護：定義合理的超時時間，避免請求長時間掛起。
• 負載均衡：通過負載均衡器分散請求壓力，防止單一服務因過載而失效。

專業建議

引入服務網格（如 Istio）為系統提供內置的彈性功能，如自動流量控制和故障注入測試。通過模擬網絡延遲和故障場景，驗證系統在極端情況下的可靠性。

9.API 版本控制不足

問題

在缺乏有效版本控制的情況下，對 API 進行破壞性變更（如修改請求/響應結構或以非向后兼容的方式更新功能）可能導致依賴該 API 的客戶端應用程序無法正常運行。這種不兼容會引發緊急回滾或代價高昂的修復。

真實場景

假設一個 REST API 更新了請求有效負載的結構，但未通知客戶端開發團隊。結果，多個客戶端應用程序因調用失敗而中斷，進而影響最終用戶體驗。

實用解決方案

• 采用版本控制策略：對 API 進行顯式版本化，例如通過 URL 路徑（如 /v1/resource）或 HTTP 頭信息明確區分不同版本。
• 管理棄用周期：在引入新版本的同時，提供明確的遷移計劃和過渡期，避免強制客戶端立即調整。
• 清晰的變更通知：通過文檔和公告及時傳達 API 的變更內容，確保使用者了解和適應。

專業建議

使用 OpenAPI 等工具自動生成和管理 API 文檔，跟蹤變更歷史并簡化開發人員對新版本的適應過程。此外，考慮在 API 網關中添加版本路由邏輯，以同時支持舊版和新版 API，進一步減少遷移帶來的沖擊。

10.為基礎設施問題重新造輪子

問題

嘗試自行開發服務發現、運行狀況檢查或負載均衡等基礎設施功能，往往既耗費資源，又增加了維護復雜性。這類定制解決方案容易出現兼容性問題，并且占用了本應聚焦于業務功能開發的時間和精力。

真實場景

例如，構建一個自定義的服務發現工具，不僅需要處理多環境部署的復雜性，還可能隨著微服務數量增加而暴露出性能和兼容性問題，最終造成運營負擔。

實用解決方案

• 使用標準化工具：采用經過驗證的開源或商用工具，如 Kubernetes，來處理服務發現、運行狀況檢查和負載均衡等基礎設施需求。
• 借助服務網格：通過服務網格（如 Istio 或 Linkerd），實現跨服務的一致流量管理策略、運行狀況監控和故障注入測試，從而避免重復開發基礎設施功能。

專業建議

將團隊的工程重點放在業務邏輯和客戶價值上，而非重新構造已有的基礎設施組件。這種方法不僅減少了開發和維護成本，還可以利用社區和現成生態系統的支持來快速解決問題。

結論

構建可擴展的微服務架構既充滿機遇，也伴隨著挑戰。通過識別和解決常見的反模式（如分布式單體架構、跨服務共享數據和過度同步調用），可以顯著提升服務的獨立性、彈性和擴展能力。

在實際的項目設計中，約束條件往往需要我們在理論與實踐之間找到平衡。例如，在數據分離中，可能需要臨時采用封裝的 API 訪問共享數據；在選用 MongoDB 等靈活數據庫時，則需格外關注隱式依賴帶來的風險。微服務的成功在于明確的邊界定義、一致的通信標準以及強大的可觀察性能力。

根據實際情況，將技術決策與業務需求相結合，充分發揮微服務的優勢，并有效規避常見陷阱。這種方法不僅有助于提升團隊效率，還能為系統的長期可持續性打下堅實基礎。

作者介紹

劉汪洋，51CTO社區編輯，昵稱：明明如月，一個擁有 5 年開發經驗的某大廠高級 Java 工程師。

原文標題：10 Microservices Anti-Patterns to Avoid for Scalable Applications，作者：Abhishek Goswami