什麼是微服務？

微服務的優點

微服務為建立雲端原生應用程式提供了一個框架，能夠適應不斷變化的業務需求。無數的優點來自應用程式的架構。

敏捷性

微服務架構適合獨立開發和部署。與單一應用程式不同，單一應用程式只要變更一行程式碼，就得更新整個應用程式，而開發人員可以修改或更換服務，而不會影響分散式系統。部署個別服務的能力可讓您輕鬆新增新功能或回溯應用程式的變更。

擴充性

大規模擴充整個應用程式並非最佳化。使用微服務時，只會擴充需要擴充的元件。開發人員可根據需要處理個別服務，最終有助於在重負荷下提供更佳效能、有效運用資源及降低基礎架構成本。

選擇

在微服務架構中，雲端原生應用程式不會共用堆疊和資料庫。開發人員可以選擇他們偏好的工具和技術，以滿足各種服務的不同需求。

整合

開發人員可以使用任何語言撰寫微服務，並將其連接到使用任何語言編程的微服務。更重要的是，微服務可以在任何平台上執行，因此可以與傳統系統整合。

程式碼重複使用

微服務架構可讓開發人員建立模組化的服務，並可在應用程式之間重複使用。透過使用可重複使用的元件，程式設計師可以減少開發時間，並在「一次編寫、經常重複使用」的文化下，提高程式碼的品質。

容錯

微服務架構可提升彈性。由於服務被設計為可自主運作，因此單一服務的失敗很少會導致應用程式癱瘓，而單一的應用程式往往會發生這種情況。

合作

微服務架構可讓團隊同時處理不同的服務，進而加快產品上市時間。在開發人員不需要與其他團隊協調就能做出決策的同時，微服務也促進了跨團隊合作，因為每個團隊都負責開發和維護整體的一部分。這能夠更好地與業務目標保持一致，並提高資源使用效率。

不斷地迭代

使用微服務建立的應用程式是為了進化而建立的。開發人員可以快速部署核心微服務作為最小可行產品，並在團隊完成其他服務時升級應用程式。當新技術出現時，可將其納入設計中。以微服務為基礎的應用程式仍處於流程中，不斷地朝理論上的完美邁進。

何時使用微服務

雖然以容器為基礎的微服務提供了許多好處，但它們不一定是正確的應用程式架構選擇。在進行軟體工程決策時，請考慮您對應用程式的目標，以及您在應用程式生命週期中所預見的開發障礙和需求。微服務最適合複雜的應用程式。考慮使用微服務的情況包括

大型應用

如果您正在建立一個大型且複雜的應用程式，微服務將可讓您將應用程式分割成可管理的片段，使其更容易開發、部署和維護。

時間線的複雜性

微服務架構可以容納不同開發速度的獨立服務。即使服務出現意料之外的延遲，專案也能不斷地進行，而不會對應用程式開發時程造成全球性的影響。

頻繁更新

微服務架構非常適合需要頻繁更新的應用程式，因為獨立的服務可讓開發人員修改模組而非應用程式。

高擴充能力

如果您的應用程式需要處理大量流量，或是需要快速大規模擴充，微服務是不可或缺的。特別是當您需要大規模擴充應用程式的特定部分，而非擴充整個應用程式時。

多個團隊

如果您有多個開發團隊在處理相同的應用程式，微服務將可協助您維持敏捷性與效率。每個團隊都可以使用適合自己的技術堆疊來處理自己的微服務，而無需擔心應用程式的其他部分。

分散式架構

如果您想要以分散式架構建立應用程式，微服務是自主性的，可以部署在不同地點，甚至不同的雲端服務供應商之間。

混合雲端

如果您打算採用混合雲架構，其中某些服務會不斷地在內部部署執行，而其他服務則會在雲端執行，那麼微服務將可協助您管理應用程式的複雜性。

建置和部署微服務型應用程式

微服務架構需要仔細的規劃。某些在生產環境中常見的技術與實作，可讓開發人員有效地開發、維護與操作以微服務為基礎的應用程式。

DevOps

DevOps 實務（包括CI/CD）對於微服務的架構方法是不可或缺的。與單一應用程式不同，微服務本質上是複雜的分散式系統，擁有許多活動零件和獨立的技術堆疊。這種複雜性需要開發團隊和作業團隊之間經常合作，以確保元件能夠無縫整合。

DevOps實務提供必要的協作、溝通和自動化工具，有效地將整個 軟體開發生命週期的團隊凝聚在一起。

不斷地遞送

持續交付與微服務相輔相成，讓開發人員可以利用基礎架構自動化工具，例如持續整合伺服器、部署管道和自動化測試框架來簡化 CI/CD 管道程序，進而頻繁且可靠地發佈軟體更新。

為了確保每個服務都能獨立於其他微服務更新與釋出，不斷地遞送 尤其重要。

REST

微服務與微服務之間進行溝通 - 而且大多數是在網路應用程式中進行 - 這使得 REST 成為一種補充。REST 或稱為「表現狀態傳輸」（Representational State Transfer），是建立 RESTful API 的架構設計模式，可讓服務透過 HTTP 以 XML、HTML 和 JSON 等標準格式進行通訊。但基於幾個原因，REST API 是基於微服務的應用程式的基礎。

REST API 是輕量級且與平台無關的，這意味著它們提供了標準化的介面，讓微服務能夠溝通，不論它們的底層技術為何。由於請求包含完成請求所需的資訊，因此 REST API 不需要儲存於伺服器上的上下文。它們可以在不影響效能的情況下處理大量的要求，而且以 REST 為基礎的微服務架構中的服務可以獨立演進，以無狀態的方式有效地溝通。

集裝箱

雖然微服務讓團隊可以選擇服務的語言和框架，但在相同的 CD 管線中使用各種語言會帶來挑戰。容器 抽象化了服務之間的差異，因為每個微服務都成為一個自足的單元，並將其程式碼庫、資料庫和相依性打包在一起。現在同質化的 CD 管線可以對每個容器執行一致的測試。

當服務被容器分隔時，就能互動而不會互相干擾，一旦部署完成，容器就能提供輕量、可移植的執行環境，讓服務能在不同平台上一致運作。Docker 和 Kubernetes 等工具被廣泛用來管理容器化的微服務。

Kubernetes Orchestrator

Kubernetes 之類的協調工具可以抽象出底层基礎架構，並在多台伺服器上自動化容器管理、部署和大規模擴充。它的可擴充性還可以讓開發人員和操作人員使用他們偏好的開放原始碼和商業軟體工具，減少容器管理的手動工作。

無伺服器

無伺服器運算是部署微服務的另一種選擇。無伺服器架構 使用功能即服務 (FaaS) 平台來建立更小的部署單位，並依需求進行大規模擴充。雖然無伺服器架構可能會增加對供應商的依賴，但卻能降低作業成本、複雜性和工程前置時間。

微服務最佳實務

設計微服務架構需要仔細的規劃與考量。若要成功建立以微服務為基礎的應用程式，開發人員應該觀測下列最佳實務：

• 領域驅動設計：領域驅動設計 (Domain-driven design, DDD) 是一種專注於業務領域和應用程式行為的設計方法。它可以幫助開發人員將應用程式分割成更小、更容易管理的元件，使其更容易建立、部署和維護。
• 服務範圍：在設計微服務架構時，定義清楚的服務邊界是非常重要的。每個微服務都應該有明確的責任。
• 小型服務：保持服務「微觀」，專注於單一職責。忽略這項基本原則會犧牲可管理性。
• API 設計：微服務透過 API 進行通訊，因此請使用一致、可擴充且安全的 API，限制資料存取給授權的應用程式、使用者和伺服器。
• 分散式資料管理：微服務應用程式需要各種儲存和資料庫選項。每個微服務都應該有自己的資料儲存區。此方法可協助您避免資料不一致，並允許您自主大規模擴充每個微服務。您希望開發團隊為每項服務選擇資料庫，以確保資料庫最適合他們的專案。
• CI/CD 管道：實作 CI/CD 將可協助您快速找到並修復錯誤，這對於在微服務架構中需要管理多個程式碼庫的情況尤其有價值。
• 有意的適應力：保護應用程式免於依賴性故障關機。如果可能的話，請勿在微服務之間使用遠端程序呼叫 (RPC)，並加入斷路器等功能以防止連鎖故障。
• SOP：制定定義編碼慣例、目錄結構和通訊協定的標準作業程序。遵循一套標準會產生一致且可管理的微服務。

採用微服務

eBay、Etsy、Uber - 無數企業已拆除其單體應用程式，並將其重構為以微服務為基礎的架構，以善用大規模優勢、業務敏捷性及財務優勢。

計畫過渡到微服務的組織應該先採用 DevOps，這會讓您準備好管理所遇到的複雜問題。從基本層面來看，在規劃您的專案時，請預期以下概述的階段。

識別業務能力

遷移至微服務架構的第一步是確定您的應用程式需要支援的業務能力或功能。這將有助於您定義應用程式的範圍，並告知您哪些功能應該優先開發，以及這些微服務應該如何設計和彼此整合。

分解單一應用程式

大多數組織使用領域驅動設計或基於功能的分解來分解其單體應用程式。

確定應用程式的業務功能後，為每個微服務定義服務邊界，確保每個微服務都有獨特且明確的責任。您需要對應業務功能、資料儲存區和外部系統之間的依賴關係。根據受限的上下文和依賴關係，定義將取代單一應用程式的微服務。

每個專注於單一業務能力的微服務都應該有明確的介面。檢視資料實體的存取方式，最後考慮如何分割資料以減少服務間的依賴性。

定義服務介面

實作每個微服務的服務介面，確保介面反映微服務的唯一責任。您可以使用不同的技術，例如 RESTful API 或訊息通訊協定，來定義服務介面。

實作與測試服務

根據您的需求和專業知識，選擇程式語言和框架來實作服務。根據需要迭代設計，包括測試新的介面、通訊協定和資料儲存區。

將服務容器化

實作並測試服務之後，您會想要使用容器技術（例如 Docker 或 Kubernetes）將它們容器化。容器化將使您能夠獨立部署和管理服務。

自動化部署和協調

使用 Kubernetes 或 Docker Swarm 等工具自動化服務的協調。除了有效率地簡化服務的部署之外，透過 Kubernetes 或 Docker 進行自動化還能提高應用程式的可靠性和可用性。兩種平台都能偵測到服務實體失效或無反應的情況，並採取行動來補救問題。例如，Kubernetes 可以重新啟動失敗的實體，或將它們重新排程到其他節點，而 Docker 則可以自動將失敗的容器遷移到其他節點

監控和管理服務

分解單一應用程式並非一次性的過程。它需要隨著應用程式及其使用者需求的演進而進行維護和更新。監控新的微服務並追蹤關鍵指標，例如回應時間和資源利用率。

微服務的安全

高度分散、雲端原生的微服務應用程式會引進複雜的安全性問題。它們的潛在漏洞點不是單一的，而是數以百計，甚至數十計，而且每個漏洞點都必須加以保護。在現代應用程式不斷擴大的攻擊面中，API 和程式碼依賴性只是兩個風險來源。

Web 應用程式與 API 安全

現代應用程式會消耗來自各種來源的輸入 - 標準 Web 請求、行動裝置 API 呼叫、雲端事件、物聯網裝置遙測通訊、雲端儲存等。更重要的是，單一客戶端的 Web 請求（即南北流量）可能會在內部微服務之間產生數百個 API 呼叫（即東西流量）。

以 API 為中心的 Web 應用程式非常複雜，需要可擴充、靈活且多層次的策略，以適用於任何類型環境或雲端架構中的任何類型 工作負載 。僅保護雲端原生應用程式的前端網路介面是不夠的。雲端原生應用程式需要應用程式層為雲端原生 API 提供保護。Web 應用程式和 API 安全性 (WAAS) 是必要的。

程式碼相關性及軟體組成分析

開放原始碼軟體元件約佔雲端原生應用程式的 70%。雖然這樣可以加快開發速度，但許多開放原始碼套件及其相依性都含有漏洞。此外，依賴驅動的 OSS 套件的每個版本都可能會變更關鍵功能。如果沒有完全的可視性，漏洞就不會被發現。

獨立的 軟體組成分析 (SCA)工具在開發生命週期中太遲浮現開放原始碼風險，導致漏洞積壓，無法隨時解決。針對 SCA 和 IaC 安全性 的單獨工具會產生嘈雜的警示，而沒有上下文和相互關聯風險的知識。因為在沒有運行時間和工作負載覆蓋的情況下，缺口是不可避免的，所以最好是使用整合的雲端原生 安全性來 保護雲端端原生應用程式。

程式碼到雲端 CNAPP

雲端原生應用程式防護平台 (CNAPP) 能夠識別整個雲端 原生應用程式 的關鍵風險並排定優先順序，整合多種類型的安全性，提供全面的從程式碼到雲端的防護 - 雲端安全勢態管理 (CSPM)、雲端工作負載防護、雲端基礎架構權限管理 (CIEM)、Kubernetes 安全勢態管理 (KSPM)、基礎架構即程式碼安全性、WAAS、SCA 等。

雲端安全性領導者在探索如何以最佳方式保護採用雲端原生技術 (例如容器、微服務和無伺服器功能) 的應用程式的快速開發需求時，應考慮採用 CNAPP。

微服務常見問題