在生產環境中實施微服務

資訊科技數位 » recursos » 在生產環境中實施微服務

在實際環境中採用微服務架構不僅僅是將單體應用程式分割成更小的部分：它還包括 重新思考基礎設施、設備、流程、資料、安全和運營當系統從理論走向生產集群時，就會出現服務發現、團隊之間的契約、CI/CD、可觀測性、彈性和可擴展性等方面的問題，如果這些問題沒有得到妥善解決，就會將微服務變成分散式混亂。

好消息是，如今我們從 Netflix、亞馬遜、谷歌等大型企業或營運公司累積了大量經驗。 生產環境中已有數百個微服務投入使用。基於這些經驗教訓，加上 Kubernetes 和 OpenShift 企業環境中的最佳實踐，可以製定出一個非常可靠的方法，用於大規模地設計、部署和運行微服務，而不會失去控制。

為什麼要將微服務部署到生產環境（以及何時不值得這樣做）

精心設計的微服務架構使您能夠與…合作 小型、自主、多功能的團隊 每個團隊都負責端到端服務。每個團隊都在明確的環境中運作，可以頻繁部署，並對其服務承擔全部責任，從而縮短開發週期，加快新功能的交付。

另一個主要好處是 每個服務的獨立擴展如果只有商品目錄、結帳頁面或公共 API 出現流量高峰，則無需大幅擴展整個應用程式。您可以根據每個微服務的負載模式進行水平或垂直擴展，精確衡量每個功能的成本，即使特定區域的流量激增，也能保持應用程式的可用性。

這些服務的打包和部署方式有利於… 持續實施，風險低如果每個微服務都是獨立發布的，那麼測試新想法和回滾有問題的版本就簡單得多：金絲雀部署、藍綠部署和自動回滾降低了出錯的成本，並為實驗留出了空間。

從技術角度來看，微服務促進了 可以自由選擇語言、框架和資料庫 每個服務都適用不同的技術棧。並非所有需求都適合相同的技術堆疊：例如，業務服務可能使用 .NET 或 Java，資料處理可能使用 Scala/Spark，專業服務可能使用 Python 或 F#，而 AI 微服務可能使用 R。這種可控的多樣性使您能夠針對每個特定情況使用合適的工具，而無需將整個應用程式拖曳到全域技術變更。

此外，將其分解成小的、明確的部分有助於… 功能重複使用作為建置模組最初是作為某個功能的一部分所建立的微服務，之後可以作為系統其他部分的依賴項重複使用，而無需重寫邏輯。而且，由於這些服務是相互隔離的，因此只要從一開始就設計了彈性機制，其中一個服務的故障通常只會導致部分系統效能下降，而不會導致整個系統癱瘓。

建築及服務設計

為了使微服務在生產環境中運作，您必須從以下方面開始： 精心設計服務範圍和職責從實際角度來看，它通常從識別現有單體架構中的粗粒度服務開始：大型功能區域或業務領域（例如，訂單、目錄、使用者、計費），這些區域或業務領域已經存在一些邏輯上的分離。

從這些大塊材料開始，你必須不斷提煉，直到你獲得 細粒度的微服務，它們基於一致的資料集運作。它們應該擁有自己的模型，並清楚知道需要讀取或寫入哪些其他服務的資料。這個過程通常由領域驅動設計 (DDD) 和限界上下文的概念支持，從而防止微服務變成「小型單體應用」。

公開這些服務的 API 必須具備 定義明確且穩定的合約這包括嚴格的文件編寫（REST 使用 OpenAPI，gRPC 使用 .proto 檔案等）、明確的版本控制、盡可能保持向後相容性，以及自動化合約驗證，以便在變更進入生產環境之前檢測到破壞性變更。

在擁有數十或數百個服務的環境中，從設計階段就融入彈性模式至關重要，這樣系統才能確保系統正常運作。 做好應對部分故障的準備諸如斷路器、具有退避機制的重試、明確的超時時間、隔離區和反壓等機制有助於防止一個服務的故障影響其他服務。混沌工程工具（例如 Chaos Monkey 或 Gremlin）用於在模擬故障情況下實際測試平台的運作情況。

在許多複雜的系統中，相對簡單的 CRUD 服務與更複雜的、專注於改變業務規則的服務並存。 並非所有微服務都需要複雜的內部架構。有些可能是簡單的 HTTP 控制器，具有基本的資料存取功能，而其他一些控制器，例如訂單或計費服務，可能會利用更高級的模式（DDD、CQRS、領域事件等）。

生產基礎設施：雲端、容器和 Kubernetes/OpenShift

實際經驗表明，微服務正在部署於 基於容器和編排的雲端基礎設施 相較於在隔離的虛擬機器上運行，Kubernetes 和 OpenShift 等平台提供了必要的底層機制，可將服務打包成容器，進行擴展、升級、負載平衡和管理高可用性。

通常，每個微服務都是 基於企業基礎影像的容器包裝影像 （例如，Java 服務使用 OpenJDK 21）由基礎架構團隊管理。此基礎鏡像會定期更新安全性補丁，當發布新版本時，開發團隊負責在相應的環境中重建和重新部署其服務。

在 Kubernetes/OpenShift 中，基本部署單元是 pod，它封裝了一個或多個容器通常，微服務對應於一種 Pod，並使用 Deployment（用於無狀態服務）或 StatefulSet（用於有狀態的服務）等資源進行部署。從一開始就為每個環境定義了最小副本數，以確保測試、預生產和生產環境的可用性等級與其重要性相符。

自動縮放功能已實現。 水平 Pod 自動縮放器 (HPA)這會根據 CPU、記憶體或其他自訂指標等指標調整副本數量。平台也必須配置 Pod 反親和性規則，以便將相同服務的副本分佈在不同的節點上，防止節點故障導致所有執行個體都宕機。

關於垂直尺寸，它與 resources.requests 和 resources.limits 定義 Pod 可以使用的 CPU 和記憶體範圍。例如，為 Java 服務預留至少 100MB 的 CPU 和 256MB 的內存，並允許分別使用高達 500MB 和 2GB 的 CPU 和內存，同時調整 JVM（XMS、XMX、XSS）以充分利用容器的資源。

狀態管理：無狀態和有狀態微服務

大多數業務微服務都被設計成這樣： 無國籍服務這表示 Pod 不會儲存需要在重新啟動後仍然存在的資訊；狀態持久化到外部資料庫、訊息佇列或其他儲存媒體。這種方法便於動態水平擴展和無縫部署，因為任何副本都可以處理任何請求。

然而，在某些情況下，除了這樣做別無選擇。 由持久卷支援的有狀態微服務對於某些需要維護本機資料的資料庫、分散式檔案系統或元件而言，情況就是如此。這些 Pod 通常使用 StatefulSet 進行部署，並透過 PersistentVolumeClaims 連結到 PersistentVolume，並且採用垂直擴展而非水平擴展的方式。

當微服務需要持久性儲存時， 持久卷聲明 (PVC)，包含尺寸、存取模式和預期用途運維團隊負責根據平台策略進行配置。此 PVC 會在部署清單中引用，並掛載到 Pod 上，以便服務可以持續地讀寫資料。

雖然在某些特定情況下可能需要有狀態模型，但一般建議是盡量使模型無狀態。 盡可能多的服務保持無國籍狀態。這簡化了部署、擴展、彈性和災難恢復，並降低了具有許多微服務的環境中的操作複雜性。

資料去中心化和服務主權

在傳統架構中，為了最大限度地提高效率，通常會將資料庫和儲存集中化。而微服務架構則採用了不同的方法。 這與團隊自主性和解耦原則相衝突。如果許多服務共享同一個關係模式，任何結構性變更都可能阻礙多個團隊，並無意中破壞相容性。

因此，建議的做法是每個微服務都應該… 他們擁有自己的資料模型和資料庫雖然在開發環境中，該資料庫可能會作為叢集內的容器運行以簡化部署，但在生產環境中，通常會使用雲端管理執行個體或其他高可用性資料庫伺服器，並最終保持清晰的所有權邊界。

這並不意味著數據之間沒有整合：而是意味著… 服務間的一致性透過事件和非同步訊息傳遞來管理。在合理的情況下接受最終一致性。通常使用事件匯流排（例如 RabbitMQ、Azure 服務匯流排、Kafka 等）在微服務之間傳播狀態變更，從而減少對單一資料庫的強烈依賴。

雲端平台讓團隊更容易選擇 每項服務的最佳資料庫類型 （關係型、文件型、鍵值型、時間序列型等），而不限於單一技術。重要的是，設計要考慮到在不破壞與其他服務的契約的情況下遷移模式和結構的可能性，並且資料決策要符合每個微服務的領域邊界。

分散式治理、團隊和組織

如果不改變組織結構就轉向微服務，無異於自找麻煩。 網路、系統、資料庫、開發和運維等方面的功能孤島我們鼓勵採用以產品團隊為基礎的組織架構，將開發、品質保證、DevOps 等人員聚集在一起，並在適用的情況下，納入業務或資料分析師。

每個團隊負責同一功能領域內的一個或多個微服務，並承擔以下兩項職責： 開發是一種營運活動（你建造它，你運行它）這意味著團隊負責管理其 CI/CD 管線，與基礎設施團隊合作以滿足特定需求，並參與事件監控和回應。基礎設施和雲端平台領域則專注於提供通用且標準化的服務。

為防止這種分散式治理導致無政府狀態，關鍵在於明確定義。 輕量級標準和共享目錄已核准的基礎映像、部署模式、命名空間和服務的命名約定、API 指南、Dockerfile 和 Kustomize 範本等。這些指南就像「護欄」一樣，引導團隊，同時又不妨礙他們做決策。

許多商業環境使用 以項目或網域分隔的命名空間每個環境（開發、預生產、生產）至少需要一個命名空間。大型專案可以將微服務分佈在多個命名空間中，前提是內部通訊配置正確且安全規則得到遵守。

CI/CD、自動化和 GitOps 模型

當一個架構包含數十個或數百個微服務時，唯一能保持它們正常運作的方法就是對它們進行大量投資。 端對端自動化這包括一致的 CI/CD 管線、聲明式部署定義、自動化測試和自動回溯機制。

典型的持續整合和持續交付管道處理 編譯程式碼，運行測試，並使用 SonarQube 等工具分析質量根據企業 Dockerfile 建立容器映像並更新部署清單。之後，像 ArgoCD 或類似系統會依照 GitOps 方法將這些變更套用到叢集。

每個微服務儲存庫通常包含 標準化的 Dockerfile，即管道的配置檔案（例如 ci.json）。用於品質分析的屬性以及包含 Kubernetes 定義（Kustomize 或 Helm）的部署目錄，這些定義按環境分類。當發生標籤推送或合併請求等事件時，倉庫 Webhook 會觸發管線。

GitOps模式指出， 基礎架構和部署的權威來源是 Git 倉庫。部署、服務、ConfigMap、PVC、SealedSecret 和其他資源的清單檔案都在此處進行版本控制，並且有專門的工具負責將叢集狀態與 Git 中定義的狀態同步。這提供了可追溯性、拉取請求修訂和便捷的回滾功能。

設定、秘密和安全

在成熟的微服務平台中，組態管理依賴 使用 ConfigMap 儲存非敏感參數，使用 Secret 儲存機密資訊每個微服務通常都有自己的 ConfigMap，用於儲存依賴服務的 URL、功能標誌或調優參數等屬性。

密鑰（憑證、密鑰、令牌、證書）由以下方式處理： 嚴格的安全政策在較不關鍵的環境中，可以接受以明文形式由開發團隊管理，但在預生產和生產環境中，建議使用 Sealed Secrets 等工具或特定的外部雲端管理器對其進行加密。

當需要在多個服務之間共用金鑰時（例如， OTEL Collector 憑證或通用金鑰庫這可以集中儲存在每個命名空間的配置儲存庫中。共享該空間的項目會在必要時協調更新，從而控制誰可以讀取或修改這些資源。

在通訊安全領域，主導模式是 零信任即使流量是「內部」的，也不能想當然。所有服務之間的調用，無論是內部調用還是外部調用，都必須經過身份驗證和授權，理想情況下應使用 mTLS、JWT 令牌或其他等效機制。微服務不會盲目地將安全性委託給 API 管理器或網路；它們也會執行自身的安全性檢查。

微服務、API 和訊息傳遞之間的通信

在成熟的微服務架構中，通訊層被劃分為幾個部分。對於從客戶端（瀏覽器、行動應用程式、第三方）到後端的流量，請使用以下幾種方式： 透過 API 管理器發布和管理 API這些 API 通常是 REST（通常使用 OpenAPI），或者在某些情況下，是透過網關公開的 gRPC。

位於同一命名空間甚至同一專案多個命名空間中的微服務之間的呼叫通常由以下方式處理： 具有內部 DNS 的內部 Kubernetes 服務它們不通過公共 API 管理器，但仍遵循安全性、驗證和授權策略。對於這種情況，可以使用強制執行通用策略的服務網格或內部網關。

當微服務屬於 不同的職能領域或不同的項目在組織層面，通訊被視為「公開」的。在這種情況下，通常會透過 API 管理器或互通性匯流排進行通信，這些管理器或匯流排負責控制合約、配額、安全性、版本控制和審計，從而避免獨立群集或命名空間之間的直接耦合。

對於與傳統系統或外部系統的集成，由於這些系統並非總是提供現代 API，通常會依賴… 互通性匯流排上的特定連接器這樣，微服務就可以使用通用語言（例如，事件或內部 REST API），而連接器則負責與傳統系統進行雙向轉換，並始終加強安全性。

除了同步通訊之外， 非同步訊息傳遞發揮關鍵作用它用於解耦進程、吸收峰值流量、在服務間傳播業務事件並提高系統彈性。每個事件通常都有一個定義明確且版本化的方案，並配有追蹤機制，以防止生產者和消費者在演進過程中出現故障。

可觀測性、OTEL 收集器和操作

在由眾多微服務組成的系統中，如果沒有良好的可觀測性，幾乎不可能診斷出問題。這就是為什麼微服務需要在設計階段就進行整合的原因。 指標、集中式日誌記錄和分散式追蹤使我們能夠了解服務和平台層面正在發生的事情。

該方案的核心部分是 OpenTelemetry Collector（OTEL Collector）此元件可以部署在命名空間或集中部署，用於收集所有元件的指標、日誌和追蹤資訊。微服務只需知道它們必須將遙測資料傳送到收集器；收集器隨後會將資料轉發給可觀測性系統（例如 Prometheus、Grafana、Jaeger、Elastic 等），而服務本身無需了解具體細節。

基礎設施規劃中將使用以下工具。 節點級收集器和導出器 這些系統從 Pod 收集 CPU、記憶體、磁碟、網路和日誌指標，並分別傳送到 Prometheus 和 Elasticsearch。 Grafana 和 Kibana 等工具用於視覺化這些資訊、建立儀表板，以及定義具有智慧閾值和相關運作手冊的警報。

當一個專案需要對其指標或追蹤進行非常具體的處理時，它可以在自己的命名空間中部署自己的 OTEL Collector 實例，前提是它獲得了營運批准並且生產維護模型很明確。

測試策略、合約和本地開發經驗

測試分散式微服務架構需要 更精細的測試策略 與單體架構相比，分集架構的優勢更加明顯。單元測試仍然至關重要，但契約測試（針對 API 和事件）、服務間的整合測試以及遍歷完整流程的端到端測試的重要性也日益凸顯。

為了避免因更改而破壞相容性，可以採用以下技術： 面向消費者的合約測試客戶定義 API 預期，服務提供者負責滿足這些預期。每次合約變更都會經過持續整合 (CI) 管線中執行的自動化測試，從而防止部署破壞任何已知使用者。

當服務數量超過一百個時，在本地複製整個系統就變得不切實際。因此，開發經驗依賴… 模擬依賴服務或隧道連接到遠端環境開發人員通常只部署一部分微服務，其餘部分則用類比、偽造或模擬器來代替，或將某些呼叫重新導向到共享的整合環境。

端對端測試越來越依賴 從特性分支建立的臨時環境或“預覽”這些工具創建了一個隔離環境，其中包含與該功能相關的服務。這最大限度地減少了團隊之間的摩擦，降低了「在我機器上運行正常」的影響，並在整合問題蔓延到成本更高的環境（例如預生產環境）之前將其檢測出來。

生產環境中的微服務部署模式

除了 Kubernetes 之外，生產環境中還有幾種值得了解的微服務部署模式，因為它們解決了… 隔離、成本和成熟度的不同情景最古老的模式之一是每個主機運行多個服務實例，即同一實體或虛擬主機運行多個不同服務的實例，通常是在共享的應用伺服器上運行。

按照這種模式 每個虛擬機器的服務實例每個服務都打包成一個虛擬機器鏡像（例如 EC2 AMI），並在其自身的執行個體中執行。這提供了強大的隔離性，但代價是更高的資源消耗和更慢的啟動速度。 Packer 等工具或雲端供應商提供的特定解決方案可以輕鬆產生可用於生產環境的虛擬機器鏡像。

當今最普遍的模式是： 每個容器的服務實例每個微服務都以容器鏡像的形式構建，並部署在編排器（Kubernetes、OpenShift 等）上。容器比虛擬機器更輕量級，啟動速度極快，並且允許您將服務所需的一切打包在一起，從而簡化部署和自動擴展。

最後，這些方法逐漸流行起來。 無伺服器架構，例如 AWS Lambda這種模式將回應 HTTP 請求或來自其他服務（例如 S3、DynamoDB、佇列等）事件的函數打包在一起，使用者只需為實際使用的資源付費。它特別適用於非常小的微服務或生命週期短的事件驅動型任務，但也引入了關於可觀測性、冷啟動和執行限制等方面的額外考慮因素。

實際上，許多組織最終會建立一個混合生態系統：系統的核心部分運行在容器和編排器上，而某些輔助組件則以無伺服器函數或專用虛擬機的形式實現，始終與… 清晰的介面和完善的協議 將它們整合到整體中。

當這一切最終投入生產時，真正起決定性作用的不僅是所選的技術，還有建構一個架構。 它具有容錯性，可根據需要擴展，可自動部署，並且可觀察。憑藉產品導向的團隊、管理完善的合約、去中心化的數據和強大的雲端平台，微服務正從一種承諾轉變為一種有效且可持續的方式，使複雜的應用程式能夠持續發展多年。