.NET 微服務架構重點摘要
提示
本內容節錄自《容器化 .NET 應用程式的 .NET 微服務架構》(.NET Microservices Architecture for Containerized .NET Applications) 電子書，可以在 .NET Docs 上取得，或免費下載可供離線閱讀的 PDF。
以下的摘要和重點為本指南最重要的結論。
使用容器的優點。 以容器為基礎的解決方案提供重要的成本節省方式，因為它們有助於降低缺少相依性所造成的部署問題。 容器會大幅改善 DevOps 與生產環境作業。
容器會普及。 Docker 式容器會成為產業的既定標準，並受到 Windows 和 Linux 生態系統中重要廠商的支援 (例如 Microsoft、Amazon AWS、Google 和 IBM)。 Docker 可能很快就會在雲端或內部部署的資料中心廣泛運用。
作為部署單位的容器。 Docker 容器會變成任何以伺服器為基礎之應用程式或服務的標準部署單位。
微服務。 微服務架構逐漸成為分散式大型或複雜關鍵任務應用程式慣用的方法，這些應用程式是以自發性服務的許多獨立子系統為基礎。 在微服務架構中，應用程式會建置為可獨立開發、測試、設定版本、部署及調整的服務集合。 每個服務都可包含任何相關的自發資料庫。
網域驅動設計與 SOA。 微服務架構模式衍生自服務導向架構 (SOA) 和網域驅動設計 (DDD)。 當您使用發展中商務需求和規則設計與開發環境微服務時，請務必考慮 DDD 方法和模式。
微服務挑戰。 微服務提供許多強大的功能，例如獨立部署、強式子系統界限和技術多樣化。 不過，它們也會引發許多與分散式應用程式開發相關的新挑戰，例如分散式和獨立的資料模型、微服務彼此間的彈性通訊、最終一致性，以及因彙總記錄及監視多項微服務的資訊而產生的操作複雜性。 這些層面比傳統的整合型應用程式更為複雜。 如此一來，只有特定的案例才適合微服務型應用程式。 這些特定案例包括有多個發展中子系統的大型複雜應用程式。 在這些案例中，值得投入更複雜的軟體架構，因為它會提供更好的長期靈活度和應用程式維護。
適用於任何應用程式的容器。 容器對於微服務很方便，但也適用於以 .NET Framework 為基礎的傳統整合型應用程式 (使用 Windows 容器時)。 Docker 的使用優點，例如解決部署到生產環境的許多問題以及提供先進的開發和測試環境，都適用於多種不同類型的應用程式。
CLI 與 IDE。 使用 Microsoft 工具，您可以使用慣用的方法來開發容器化的 .NET 應用程式。 您可以使用 Docker CLI 和 Visual Studio 程式碼來開發 CLI 和以編輯器為基礎的環境。 或者，您也可以使用具備 Visual Studio 及其獨特 Docker 功能的聚焦 IDE 方法，例如針對多容器進行偵錯。
具復原功能的雲端應用程式。 在一般的雲端式系統和分散式系統中，一定有部分失敗的風險。 由於用戶端和服務是不同的流程 (容器)，因此服務可能無法及時回應用戶端的要求。 例如，服務可能因為部分失敗或進行維護而中斷；服務可能會多載且回應要求的速度很慢；或是因為網路問題而暫時無法存取。 因此，雲端式應用程式必須不怕失敗，而且備有回應這些失敗的策略。 這些策略可以包含重試原則 (重新傳送訊息或重試要求) 和實作斷路器模式，以避免指數載入的重複要求。 基本上，雲端式應用程式必須有復原機制 (以雲端基礎結構為基礎或是自訂)，如協調器或服務匯流排提供的高階機制。
安全性。 現代化的容器和微服務世界會暴露新的弱點。 有多種方式可以實作以驗證和授權為基礎的基本應用程式安全性。 不過，容器安全性必須考量能讓應用程式更安全的其他重要元件。 建置更安全應用程式的關鍵元素，是擁有與其他應用程式和系統通訊的安全方式，這通常需要認證、權杖、密碼等等，通常稱為應用程式祕密。 任何安全的解決方案都必須遵循安全性最佳做法 (例如在傳輸和待用時加密祕密)，並預防最終應用程式使用祕密時洩漏祕密。 那些祕密必須儲存並安全地保護，就和使用 Azure Key Vault 時一樣。
協調器。 容器式協調器 (例如 Azure Kubernetes Service 和 Azure Service Fabric) 是任何微服務和容器式應用程式的重要組件。 這些應用程式帶有高複雜性、延展性需求，並經歷不斷的演變。 本指南已在微服務及容器解決方案中推出協調器及其角色。 如果您的應用程式需求將您推向複雜的容器化應用程式，您會發現它對找出其他資源以深入了解協調器十分有幫助。
