譯者 | 劉汪洋

審校 | 重樓

微服務(wù)架構(gòu)以其可擴(kuò)展性、敏捷性和彈性深受青睞，但在實(shí)踐中，許多組織往往遭遇可能削弱這些優(yōu)勢的挑戰(zhàn)。本文聚焦于常見的微服務(wù)反模式，并結(jié)合實(shí)際經(jīng)驗(yàn)提供構(gòu)建高效、可擴(kuò)展微服務(wù)的實(shí)用建議。

要避免的微服務(wù)反模式

1.分布式單體

問題

“分布式單體” 是指盡管系統(tǒng)形式上采用了微服務(wù)架構(gòu)，但服務(wù)之間高度耦合，以至于每次更新一個服務(wù)時，都需要同時調(diào)整或重新部署多個其他服務(wù)。這種設(shè)計實(shí)質(zhì)上延續(xù)了單體架構(gòu)的特點(diǎn)，只是將其組件分散在了不同的服務(wù)中，未能實(shí)現(xiàn)真正的微服務(wù)范式。

真實(shí)場景

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

實(shí)用解決方案

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

專業(yè)建議

在系統(tǒng)遷移過程中，建議使用功能開關(guān)逐步引入新功能，同時確保與現(xiàn)有系統(tǒng)的向后兼容性。這種方法不僅降低了遷移風(fēng)險，還能在實(shí)際應(yīng)用中驗(yàn)證新架構(gòu)的穩(wěn)定性和可行性。

2.跨服務(wù)共享數(shù)據(jù)

問題

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

真實(shí)場景

在典型的 ERP 系統(tǒng)中，銷售服務(wù)和庫存服務(wù)可能需要訪問同一產(chǎn)品表進(jìn)行數(shù)據(jù)寫入。例如，對產(chǎn)品信息的任何架構(gòu)調(diào)整或?qū)懖僮?，都會引發(fā)連鎖反應(yīng)，導(dǎo)致相關(guān)服務(wù)發(fā)生故障。這種共享數(shù)據(jù)庫的模式不僅增加了系統(tǒng)的復(fù)雜性，還需要團(tuán)隊間密切協(xié)調(diào)，降低了開發(fā)效率。

實(shí)用解決方案

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

實(shí)際挑戰(zhàn)

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

陷阱

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

3.過度同步調(diào)用

問題

過度同步調(diào)用（如通過 REST 請求）可能導(dǎo)致系統(tǒng)性能下降。這種模式不僅增加了延遲，還提高了故障傳播的風(fēng)險，尤其是在高流量場景下，會對系統(tǒng)的穩(wěn)定性和可擴(kuò)展性構(gòu)成嚴(yán)重挑戰(zhàn)。

真實(shí)場景

以客戶服務(wù)系統(tǒng)為例，處理每個客戶工單請求時，系統(tǒng)需要同步調(diào)用多個外部服務(wù)，如客戶服務(wù)以獲取客戶信息、賬戶服務(wù)以獲取賬戶詳情、通知服務(wù)以發(fā)送通知。在高并發(fā)流量下，這種設(shè)計模式可能導(dǎo)致網(wǎng)絡(luò)資源耗盡或服務(wù)響應(yīng)緩慢，嚴(yán)重影響用戶體驗(yàn)。

實(shí)用解決方案

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

專業(yè)建議

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

4.服務(wù)邊界定義不明確

問題

服務(wù)的職責(zé)范圍如果定義不清晰或存在重疊，會導(dǎo)致系統(tǒng)復(fù)雜化，使維護(hù)變得困難。同時，模糊的邊界關(guān)系也會引發(fā)所有權(quán)不明確的問題，增加協(xié)調(diào)成本。

真實(shí)場景

在某電子商務(wù)系統(tǒng)中，假設(shè)一個“產(chǎn)品服務(wù)”負(fù)責(zé)處理產(chǎn)品創(chuàng)建、庫存更新以及客戶評論。由于這些職責(zé)相互獨(dú)立且功能復(fù)雜，將它們歸于同一服務(wù)會導(dǎo)致代碼臃腫、不相關(guān)邏輯糾纏，并最終使系統(tǒng)難以擴(kuò)展。

實(shí)用解決方案

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

專業(yè)建議

為每個微服務(wù)設(shè)立對應(yīng)的跨職能團(tuán)隊，確保領(lǐng)域知識與技術(shù)所有權(quán)一致。這樣不僅能夠快速響應(yīng)業(yè)務(wù)需求，還能減少因職責(zé)不明帶來的溝通障礙。

5.通信協(xié)議不一致

問題

在微服務(wù)架構(gòu)中，如果通信協(xié)議沒有統(tǒng)一標(biāo)準(zhǔn)，頻繁混用 REST、gRPC 和 WebSockets 等協(xié)議，可能會造成維護(hù)困難，并增加集成復(fù)雜性。開發(fā)人員需要理解并適應(yīng)不同協(xié)議的特點(diǎn)，學(xué)習(xí)曲線陡峭，排障成本高。

真實(shí)場景

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

實(shí)用解決方案

根據(jù)使用場景對通信協(xié)議進(jìn)行標(biāo)準(zhǔn)化。例如：

• 外部接口：采用 REST 作為主要協(xié)議，便于跨平臺兼容。
• 內(nèi)部調(diào)用：對低延遲和高性能要求的場景，優(yōu)先選擇 gRPC。
• 事件驅(qū)動架構(gòu)：利用消息隊列（如 RabbitMQ 或 Kafka）實(shí)現(xiàn)異步事件通知。

為團(tuán)隊提供清晰的文檔和工具以支持標(biāo)準(zhǔn)協(xié)議的實(shí)現(xiàn)，同時定期審查實(shí)際使用情況以確保遵循設(shè)計理念。

專業(yè)建議

采用服務(wù)網(wǎng)格（如 Istio 或 Linkerd），統(tǒng)一管理服務(wù)間的通信協(xié)議和流量控制。服務(wù)網(wǎng)格可以簡化跨服務(wù)調(diào)用的配置，同時提高監(jiān)控和故障排除能力，幫助實(shí)現(xiàn)標(biāo)準(zhǔn)化和展示一致。

6.缺乏可觀察性

問題

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

真實(shí)場景

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

實(shí)用解決方案

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

專業(yè)建議

建議從基礎(chǔ)日志記錄開始，隨著系統(tǒng)復(fù)雜性增加，逐步引入分布式跟蹤和高級監(jiān)控功能。同時，設(shè)置預(yù)警閾值，結(jié)合監(jiān)控系統(tǒng)自動發(fā)送告警通知，從被動診斷轉(zhuǎn)向主動預(yù)防。

7.硬編碼配置

問題

硬編碼的配置（如數(shù)據(jù)庫 URL、密鑰或服務(wù)終端節(jié)點(diǎn)）不僅會限制部署的靈活性，還可能造成嚴(yán)重的安全風(fēng)險。配置的泄露可能導(dǎo)致敏感信息暴露甚至系統(tǒng)被攻擊。

真實(shí)場景

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

實(shí)用解決方案

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

專業(yè)建議

定期審核配置文件和密鑰的安全性，確保訪問權(quán)限僅限必要范圍?？梢酝ㄟ^在 CI/CD 管道中集成自動化腳本，在構(gòu)建源代碼之前掃描潛在的硬編碼敏感信息，避免人為錯誤造成的安全漏洞。

8.忽視網(wǎng)絡(luò)可靠性和延遲

問題

微服務(wù)架構(gòu)由于依賴分布式網(wǎng)絡(luò)通信，其穩(wěn)定性容易受到網(wǎng)絡(luò)故障和延遲的影響。如果未采取有效措施緩解網(wǎng)絡(luò)問題，可能會引發(fā)服務(wù)掛起、超時甚至全系統(tǒng)失效。

真實(shí)場景

例如，當(dāng)一個服務(wù)調(diào)用外部支付提供商的 API 時，如果網(wǎng)絡(luò)請求超時且沒有超時保護(hù)或重試機(jī)制，下游服務(wù)可能被阻塞，進(jìn)而導(dǎo)致整個交易流程中斷。

實(shí)用解決方案

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

專業(yè)建議

引入服務(wù)網(wǎng)格（如 Istio）為系統(tǒng)提供內(nèi)置的彈性功能，如自動流量控制和故障注入測試。通過模擬網(wǎng)絡(luò)延遲和故障場景，驗(yàn)證系統(tǒng)在極端情況下的可靠性。

9.API 版本控制不足

問題

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

真實(shí)場景

假設(shè)一個 REST API 更新了請求有效負(fù)載的結(jié)構(gòu)，但未通知客戶端開發(fā)團(tuán)隊。結(jié)果，多個客戶端應(yīng)用程序因調(diào)用失敗而中斷，進(jìn)而影響最終用戶體驗(yàn)。

實(shí)用解決方案

• 采用版本控制策略：對 API 進(jìn)行顯式版本化，例如通過 URL 路徑（如 /v1/resource）或 HTTP 頭信息明確區(qū)分不同版本。
• 管理?xiàng)売弥芷?/strong>：在引入新版本的同時，提供明確的遷移計劃和過渡期，避免強(qiáng)制客戶端立即調(diào)整。
• 清晰的變更通知：通過文檔和公告及時傳達(dá) API 的變更內(nèi)容，確保使用者了解和適應(yīng)。

專業(yè)建議

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

10.為基礎(chǔ)設(shè)施問題重新造輪子

問題

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

真實(shí)場景

例如，構(gòu)建一個自定義的服務(wù)發(fā)現(xiàn)工具，不僅需要處理多環(huán)境部署的復(fù)雜性，還可能隨著微服務(wù)數(shù)量增加而暴露出性能和兼容性問題，最終造成運(yùn)營負(fù)擔(dān)。

實(shí)用解決方案

• 使用標(biāo)準(zhǔn)化工具：采用經(jīng)過驗(yàn)證的開源或商用工具，如 Kubernetes，來處理服務(wù)發(fā)現(xiàn)、運(yùn)行狀況檢查和負(fù)載均衡等基礎(chǔ)設(shè)施需求。
• 借助服務(wù)網(wǎng)格：通過服務(wù)網(wǎng)格（如 Istio 或 Linkerd），實(shí)現(xiàn)跨服務(wù)的一致流量管理策略、運(yùn)行狀況監(jiān)控和故障注入測試，從而避免重復(fù)開發(fā)基礎(chǔ)設(shè)施功能。

專業(yè)建議

將團(tuán)隊的工程重點(diǎn)放在業(yè)務(wù)邏輯和客戶價值上，而非重新構(gòu)造已有的基礎(chǔ)設(shè)施組件。這種方法不僅減少了開發(fā)和維護(hù)成本，還可以利用社區(qū)和現(xiàn)成生態(tài)系統(tǒng)的支持來快速解決問題。

結(jié)論

構(gòu)建可擴(kuò)展的微服務(wù)架構(gòu)既充滿機(jī)遇，也伴隨著挑戰(zhàn)。通過識別和解決常見的反模式（如分布式單體架構(gòu)、跨服務(wù)共享數(shù)據(jù)和過度同步調(diào)用），可以顯著提升服務(wù)的獨(dú)立性、彈性和擴(kuò)展能力。

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

根據(jù)實(shí)際情況，將技術(shù)決策與業(yè)務(wù)需求相結(jié)合，充分發(fā)揮微服務(wù)的優(yōu)勢，并有效規(guī)避常見陷阱。這種方法不僅有助于提升團(tuán)隊效率，還能為系統(tǒng)的長期可持續(xù)性打下堅實(shí)基礎(chǔ)。

作者介紹

劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個擁有 5 年開發(fā)經(jīng)驗(yàn)的某大廠高級 Java 工程師。

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