共用方式為

微服務評量和整備程度

  • 發行項

微服務架構可為您的應用程式提供許多優點，包括靈活度、延展性和高可用性。 除了這些優點之外，此架構也帶來了挑戰。 當您建置微服務型應用程式或將現有應用程式轉換成微服務架構時，您需要分析及評估目前的情況，以識別需要改進的區域。

本指南將協助您瞭解移至微服務架構時要記住的一些考慮。 您可以使用本指南來評估應用程式的成熟度、基礎結構、DevOps、開發模型等等。

瞭解商務優先順序

若要開始評估微服務架構，您必須先瞭解您企業的核心優先順序。 例如，核心優先順序可能與靈活度、變更採用或快速開發有關。 您需要分析架構是否適合您的核心優先順序。 請記住，業務優先順序可能會隨著時間而變更。 例如，創新是新創公司的首要任務，但在幾年後，核心優先順序可能是可靠性和效率。

以下是一些要考慮的優先順序：

  • 創新
  • 可靠性
  • 效率

記載與應用程式各個部分一致的 SLA，以確保組織承諾可作為評定指南。

記錄架構決策

微服務架構可協助小組自主。 例如，Teams 可以自行決定技術、方法和基礎結構元件。 不過，這些選擇應遵守正式同意的原則，稱為共用治理，這表示小組之間如何解決微服務更廣泛策略的協定。

考量下列因素：

  • 是否已就地共用治理？
  • 您是否在架構日誌中追蹤決策及其取捨？
  • 您的小組是否可以輕鬆地存取您的架構日誌？
  • 您是否有評估工具、技術和架構的程式？

評估小組組合

您需要有適當的小組結構，以避免跨小組進行不必要的溝通。 微服務架構鼓勵形成小型、專注、跨功能小組，而且需要思維變更，其之前必須進行團隊重組。

考量下列因素：

  • 您的小組是否根據子域進行分割，並遵循 網域驅動設計 （DDD） 原則？
  • 您的小組是否可跨功能，且有足夠的容量可獨立建置及操作相關的微服務？
  • 在與項目無關的臨機操作活動和工作中花費了多少時間？
  • 跨小組共同作業花費多少時間？
  • 您是否有識別和最小化技術債務的程式？
  • 如何學習課程，以及跨小組溝通的經驗？

使用十二因素方法

選擇微服務架構的基本目標是更快提供價值，並遵循敏捷式做法來適應變更。 十二因素應用程式方法提供建置可維護且可調整應用程式的指導方針。 這些指導方針可提升屬性，例如不變性、暫時性、宣告式設定和自動化。 藉由納入這些指導方針並避免常見的陷阱，您可以建立鬆散結合的自封微服務。

瞭解分解方法

將整合型應用程式轉換成微服務架構需要時間。 從邊緣服務開始。 Edge 服務與其他服務的相依性較少，而且可以輕鬆地從系統分解為獨立服務。 強烈建議使用 Strangler Fig 和反損毀層等模式，讓整合型應用程式保持運作狀態，直到所有服務分解成個別的微服務為止。 在隔離期間，DDD 的原則可協助小組根據子域從整合型應用程式選擇元件或服務。

例如，在電子商務系統中，您可能會有下列模組：購物車、產品管理、訂單管理、定價、發票產生和通知。 您決定使用通知模組啟動應用程式的轉換，因為它與其他模塊沒有相依性。 不過，其他模組可能相依於此模組來傳送通知。 通知模組可以輕鬆地分解成個別的微服務，但您必須在整合型應用程式中進行一些變更，才能呼叫新的通知服務。 您決定接下來轉換發票產生模組。 產生訂單之後會呼叫此模組。 您可以使用 Strangler 和 Anti-corruption 之類的模式來支援此轉換。

數據同步處理、多寫入整合型和微服務介面、數據擁有權、架構分解、聯結、數據量和數據完整性，可能會使數據分解和移轉變得困難。 您可以使用數種技術，例如在微服務之間保留共用資料庫、根據商務功能或網域將資料庫與服務群組分離，以及隔離資料庫與服務。 建議的解決方案是使用每個服務來分解每個資料庫。 在許多情況下，這並不實用。 在這些情況下，您可以使用資料庫檢視模式和資料庫包裝服務模式等模式。

評估 DevOps 整備程度

當您移至微服務架構時，請務必評估 DevOps 能力。 微服務架構旨在促進應用程式中的敏捷式開發，以提高組織靈活性。 DevOps 是您應該實作以達到此能力的重要做法之一。

當您評估微服務架構的 DevOps 功能時，請記住下列幾點：

  • 貴組織中的人員是否知道DevOps的基本做法和原則？
  • 小組是否瞭解原始檔控制工具及其與 CI/CD 管線的整合？
  • 您是否正確實作 DevOps 做法？
    • 您是否遵循敏捷式做法？
    • 是否實作持續整合？
    • 是否實作持續傳遞？
    • 是否實作持續部署？
    • 是否實作持續監視？
    • 基礎結構即程序代碼 （IaC） 是否就緒？
  • 您是否使用正確的工具來支援 CI/CD？
  • 如何為應用程式管理預備和生產環境的設定？
  • 工具鏈是否有社群支持和支援模型，並提供適當的通道和檔？

識別經常變更的商務領域

微服務架構具有彈性且可調整。 在評量期間，請推動組織中的討論，以判斷同事認為經常變更的區域。 建置微服務可讓小組快速回應客戶要求的變更，並將回歸測試工作降到最低。 在整合型應用程式中，一個模組中的變更需要許多層級的回歸測試，並減少發行新版本的靈活度。

考量下列因素：

  • 服務是否可獨立部署？
  • 服務是否遵循 DDD 原則？
  • 服務是否遵循 SOLID 原則？
  • 資料庫是否為服務私用？
  • 您是否使用支援的微服務底座模式來建置服務？

評估基礎結構整備程度

當您移至微服務架構時，基礎結構整備程度是需要考慮的重要點。 如果未正確設定基礎結構，或未使用正確的服務或元件，應用程式效能、可用性和延展性將會受到影響。 有時候會使用所有建議的方法和程式來建立應用程式，但基礎結構不足。 這會導致效能和維護不佳。

當您評估基礎結構整備程度時，請考慮這些因素：

  • 基礎結構是否確保已部署服務的延展性？
  • 基礎結構是否支援透過可透過 CI/CD 自動化的腳本進行布建？
  • 部署基礎結構是否提供可用性 SLA？
  • 您是否有災害復原 （DR） 計劃和例行演練排程？
  • 數據是否複寫至不同的DR區域？
  • 您是否有資料備份計劃？
  • 部署選項是否記載在內？
  • 部署基礎結構是否受到監視？
  • 部署基礎結構是否支援服務的自我修復？

評估發行週期

微服務可適應變更，並利用敏捷式開發來縮短發行週期，併為客戶提供更多價值。 當您評估發行週期時，請考慮這些因素：

  • 您建置和發行應用程式的頻率為何？
  • 您的版本在部署後失敗的頻率為何？
  • 在中斷后復原或補救問題需要多久時間？
  • 您是否使用應用程式的語意版本控制？
  • 您是否維護不同的環境，並在序列中傳播相同的版本（例如，先暫存再傳播至生產環境）。
  • 您是否使用 API 的版本設定？
  • 您是否遵循 API 的適當版本控制指導方針？
  • 何時變更 API 版本？
  • 您處理 API 版本控制的方法為何？
    • URI 路徑版本控制
    • 查詢參數版本控制
    • 內容類型版本控制
    • 自定義標頭版本控制
  • 您有事件版本設定的練習嗎？

評估服務之間的通訊

微服務是獨立的服務，可跨進程界限彼此通訊，以解決商務案例。 若要取得可靠且可靠的通訊，您必須選取適當的通訊協定。

將這些因素納入考慮：

  • 您是否遵循 API 優先方法，其中 API 會被視為一流的公民？
  • 您是否有長鏈作業，其中多個服務會透過同步通訊協定依序通訊？
  • 您是否已考慮在系統中任何地方進行異步通訊？
  • 您是否已評估訊息代理程序技術和其功能？
  • 您是否瞭解服務接收和處理的訊息輸送量？
  • 您是否使用直接客戶端對服務通訊？
  • 您需要在訊息代理程式層級保存訊息嗎？
  • 您是否使用 具體化檢視模式 來解決微服務的閒聊行為？
  • 您是否已實作 Retry、斷路器、指數輪詢和抖動，以進行可靠的通訊？ 處理此作業的常見方式是使用 大使模式。
  • 您是否已定義網域事件來促進微服務之間的通訊？

評估服務如何向客戶端公開

API 閘道是微服務架構中其中一個核心元件。 直接將服務公開給用戶端，會在管理性、控制和可靠通訊方面產生問題。 API 閘道可作為 Proxy 伺服器、攔截流量，並將其路由傳送至後端服務。 如果您需要依IP位址、授權、模擬回應等來篩選流量，您可以在API閘道層級執行此動作，而不需對服務進行任何變更。

將這些因素納入考慮：

  • 用戶端是否直接取用服務？
  • 是否有 API 閘道可作為所有服務的外觀？
  • API 閘道可以設定配額限制、模擬回應和篩選IP位址等原則嗎？
  • 您是否使用多個 API 閘道來解決不同類型的用戶端需求，例如行動應用程式、Web 應用程式和合作夥伴？
  • 您的 API 閘道是否提供用戶端可在其中探索和訂閱服務的入口網站，例如 Azure API 管理 中的開發人員入口網站？
  • 您的解決方案是否提供 L7 負載平衡或 Web 應用程式防火牆 （WAF） 功能以及 API 閘道？

評估交易處理

分散式交易可協助以單一工作單位的形式執行多個作業。 在微服務架構中，系統會分解成許多服務。 單一商務使用案例是由多個微服務作為單一分散式交易的一部分來處理。 在分散式交易中，命令是在事件發生時啟動的作業。 事件會觸發系統中的作業。 如果作業成功，它可能會觸發另一個命令，然後觸發另一個事件，依此直到所有交易完成或回復為止，視交易是否成功而定。

將下列考慮納入考慮：

  • 系統中有多少個分散式交易？
  • 您處理分散式交易的方法為何？ 評估 Saga 模式搭配協調流程或編舞的使用方式。
  • 有多少交易跨越多個服務？
  • 您是否遵循 ACID 或 BASE 交易模型來達成數據一致性和完整性？
  • 您是否針對跨越多個服務的交易使用長時間鏈結作業？

評估您的服務開發模型

微服務架構的最大優點之一是技術多樣性。 微服務型系統可讓小組使用他們所選擇的技術來開發服務。 在傳統應用程式開發中，您可能會在建置新元件時重複使用現有的程式代碼，或建立內部開發架構以減少開發工作。 使用多種技術可防止重複使用程序代碼。

考量下列因素：

  • 您是否使用服務範本來啟動新的服務開發？
  • 您是否遵循 Twelve-Factor 應用程式方法，並使用微服務的單一程式代碼基底、隔離相依性和外部化設定？
  • 您是否將敏感性設定保留在金鑰保存庫中？
  • 您是否將服務容器化？
  • 您知道您的資料一致性需求嗎？

評估您的部署方法

您的部署方法是在各種部署環境中發行應用程式版本的方法。 微服務型系統提供比傳統應用程式更快發行版本的靈活度。

當您評估部署計劃時，請考慮下列因素：

  • 您是否有部署服務的策略？
  • 您是否使用新式工具和技術來部署服務？
  • 當您部署服務時，小組需要何種共同作業？
  • 您是否使用基礎結構即程式代碼來布建基礎結構？
  • 您是否使用DevOps功能將部署自動化？
  • 您是否將相同的組建傳播至多個環境，如十二因素應用程式方法所建議？

評估裝載平臺

延展性是微服務架構的主要優點之一。 這是因為微服務會對應至商務網域，因此每個服務都可以獨立調整。 整合型應用程式會部署為裝載平臺上的單一單位，而且必須全面調整。 這會導致停機時間、部署風險和維護。 您的整合型應用程式可能設計良好，且元件可尋址個別商務網域。 但由於進程界限不足，違反單一責任原則的可能性變得更加困難。 這最終會產生義大利面代碼。 由於應用程式會組成並部署為單一裝載程式，因此延展性很困難。

微服務可讓小組選擇正確的裝載平臺，以支援其延展性需求。 提供自動調整、彈性布建、高可用性、更快速部署和輕鬆監視等功能，即可使用各種裝載平臺來解決這些挑戰。

考量下列因素：

  • 您用來部署服務（虛擬機、容器、無伺服器）的裝載平台為何？
  • 裝載平臺是否可調整？ 它是否支援自動調整？
  • 調整裝載平臺需要多久時間？
  • 您了解各種裝載平臺所提供的 SLA 嗎？
  • 您的裝載平臺是否支援災害復原？

評估服務監視

監視是微服務型應用程式的重要元素。 由於應用程式分成數個獨立執行的服務，因此疑難解答錯誤可能會令人望而生畏。 如果您使用適當的語意來監視您的服務，您的小組可以輕鬆地監視、調查及回應錯誤。

考量下列因素：

  • 您是否要監視已部署的服務？
  • 您是否有記錄機制？ 您使用哪些工具？
  • 您是否已有分散式追蹤基礎結構？
  • 您記錄例外狀況嗎？
  • 您是否維護商務錯誤碼以快速識別問題？
  • 您是否使用服務的健康情況探查？
  • 您是否使用語意記錄？ 您是否已實作關鍵計量、臨界值和指標？
  • 您是否在記錄期間遮罩敏感數據？

評估相互關聯令牌指派

在微服務架構中，應用程式是由獨立裝載的各種微服務所組成，彼此互動以提供各種商務使用案例。 當應用程式與後端服務互動以執行作業時，您可以將稱為相互關聯令牌的唯一數位指派給要求。 建議您考慮使用相互關聯令牌，因為它們可協助您針對錯誤進行疑難解答。 它們可協助您判斷問題的根本原因、評估影響，以及判斷補救問題的方法。

您可以使用相互關聯令牌來擷取要求線索，方法是識別哪些服務包含相互關聯令牌，以及哪些服務不包含。 沒有該要求相互關聯令牌的服務失敗。 如果發生失敗，您可以稍後再重試交易。 若要強制執行等冪性，只有沒有相互關聯令牌的服務才會提供要求。

例如，如果您有牽涉到許多服務的長鏈作業，將相互關聯令牌傳遞至服務，可協助您輕鬆地調查交易期間是否有任何服務失敗的問題。 每個服務通常都有自己的資料庫。 相互關聯令牌會保留在資料庫記錄中。 如果交易重新執行，其資料庫中具有該特定相互關聯令牌的服務會忽略要求。 只有沒有令牌的服務才會提供要求。

考量下列因素：

  • 您會在哪個階段指派相互關聯令牌？
  • 哪個元件會指派相互關聯令牌？
  • 您是否將相互關聯令牌儲存在服務的資料庫中？
  • 相互關聯令牌的格式為何？
  • 您是否記錄相互關聯令牌和其他要求資訊？

評估微服務底座架構的需求

微服務底座架構是基底架構，可提供跨領域考慮的功能，例如記錄、例外狀況處理、分散式追蹤、安全性和通訊。 當您使用底座架構時，會更專注於實作服務界限，而不是與基礎結構功能互動。

例如，假設您正在建置購物車管理服務。 您想要藉由叫用該服務的端點來驗證傳入令牌、將記錄寫入記錄至記錄資料庫，並與另一個服務通訊。 如果您使用微服務底座架構，則可以減少開發工作。 Dapr 是一個系統，提供各種建置組塊來實作跨領域考慮。

考量下列因素：

  • 您是否使用微服務底座架構？
  • 您是否使用 Dapr 與跨領域考慮互動？
  • 您的底座架構語言是否無關？
  • 您的底座架構是否為一般，因此它支援各種應用程式？ 底座架構不應該包含應用程式特定的邏輯。
  • 您的底座架構是否提供機制，以視需要使用選取的元件或服務？

評估應用程式測試的方法

傳統上，測試會在開發完成之後完成，且應用程式已準備好推出至使用者驗收測試 （UAT） 和生產環境。 這種方法目前有一個轉變，在應用程式開發生命週期中提前（左）移動測試。 Shift-left 測試會增加應用程式的品質，因為測試會在應用程式開發生命週期的每個階段完成，包括設計、開發和開發後階段。

例如，當您建置應用程式時，首先會設計架構。 當您使用shift-left方法時，您可以使用 Microsoft Threat Modeling 之類的工具來測試弱點的設計。 當您開始開發時，您可以執行靜態應用程式安全性測試 （SAST） 等工具來掃描原始程式碼，並使用其他分析器來找出問題。 部署應用程式之後，您可以使用動態應用程式安全性測試 （DAST） 之類的工具，在裝載應用程式時進行測試。 功能測試、混亂測試、滲透測試和其他種類的測試稍後會發生。

考量下列因素：

  • 您是否撰寫涵蓋整個開發生命週期的測試計劃？
  • 您是否在需求會議和整個應用程式開發生命週期中包含測試人員？
  • 您是否使用測試驅動設計或行為驅動設計？
  • 您要測試使用者劇本嗎？ 您是否在使用者劇本中包含接受準則？
  • 您是否使用 Microsoft 威脅模型化之類的工具來測試您的設計？
  • 您是否撰寫單元測試？
  • 您是否使用靜態程式代碼分析器或其他工具來測量程式代碼品質？
  • 您是否使用自動化工具來測試應用程式？
  • 您是否實作 Secure DevOps 實務？
  • 您是否要進行整合測試、端對端應用程式測試、負載/效能測試、滲透測試和混亂測試？

評估微服務安全性

服務保護、安全存取和安全通訊是微服務架構最重要的考慮之一。 例如，跨多個服務的微服務型系統，並針對每個服務使用令牌驗證並不是可行的解決方案。 此系統會影響整體系統的靈活度，以及跨服務導入實作漂移的可能性。

安全性考慮通常是由 API 閘道和應用程式防火牆處理。 網關和防火牆會採用連入要求、驗證令牌，以及套用各種篩選和原則，例如實作 OWASP 前 10 個原則來攔截流量。 最後，他們會將要求傳送至後端微服務。 此設定可協助開發人員專注於商務需求，而不是跨領域的安全性考慮。

考量下列因素：

  • 服務是否需要驗證和授權？
  • 您是否使用 API 閘道來驗證令牌和傳入要求？
  • 您是否使用 SSL 或 mTLS 來為服務通訊提供安全性？
  • 您是否有網路安全策略可允許服務之間的必要通訊？
  • 您是否使用防火牆 （L4， L7）， 適用於為內部和外部通訊提供安全性？
  • 您是否在 API 閘道中使用安全策略來控制流量？

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

若要查看非公用LinkedIn配置檔，請登入LinkedIn。

下一步