顧名思義，微服務架構是將伺服器應用程式建置為一組小型服務的方法。 這表示微服務架構主要面向後端，雖然方法也用於前端。 每個服務都會在自己的進程中執行，並使用 HTTP/HTTPS、WebSockets 或 AMQP 等通訊協定與其他進程通訊。 每個微服務都會在特定內容界限內實作特定的端對端網域或商務功能，而且每個微服務都必須獨立開發並獨立部署。 最後，每個微服務都應該擁有其相關的領域數據模型和領域邏輯（主權和分散式數據管理），而且可以根據不同的數據儲存技術（SQL、NoSQL）和不同的程式設計語言。
微服務應該是什麼大小？ 開發微服務時，大小不應該是重點。 相反地，重點應該是建立鬆散結合的服務，讓每個服務都有開發、部署和調整的自主權。 當然，在識別和設計微服務時，只要您與其他微服務沒有太多直接相依性，就應該盡量將其縮小。 比微服務大小更重要的是其必須具備的內部凝聚力，以及其與其他服務的獨立性。
為什麼是微服務架構？ 簡言之，它提供長期靈活度。 微服務可讓您根據許多獨立部署的服務來建立應用程式，讓每個服務都有細微且自發的生命週期，在複雜、大型且高度可調整的系統中提供更好的可維護性。
作為額外的優勢，微服務可以獨立擴展。 與其將整體應用程式作為一個單位進行擴展，您可以選擇擴展特定的微服務。 如此一來，您可以只調整需要更多處理能力或網路頻寬的功能區域，以支援需求，而不是調整不需要擴充的應用程式其他部分。 這代表您能節省成本，因為需要的硬體減少了。
圖 4-6。 整合型部署與微服務方法
如圖 4-6 所示，在傳統的整合型方法中，應用程式會藉由在數部伺服器/VM 中複製整個應用程式來進行調整。 在微服務方法中，功能會以較小的服務區隔，因此每個服務都可以獨立調整。 微服務方法可讓每個微服務進行敏捷式變更和快速反覆運算，因為您可以變更特定、小型複雜、大型且可調整的應用程式區域。
建造精細的微服務型應用程式可啟用持續整合與持續傳遞作法。 也能加速將新功能傳遞至應用程式。 更細緻的應用程序組合也可讓您隔離地執行和測試微服務，並在它們之間維持明確的合約的同時，自主發展微服務。 只要不變更介面或合約，您可以變更任何微服務的內部實作，或在不中斷其他微服務的情況下新增新功能。
以下是在使用微服務型系統時，實現生產環境的成功運行的重要方面：
服務和基礎設施的監控與健康檢查。
服務可調整的基礎結構（也就是雲端和協調器）。
多個層級的安全性設計和實作：驗證、授權、秘密管理、安全通訊等。
快速應用程式的交付，通常由不同團隊專注於不同的微服務。
DevOps 和 CI/CD 做法和基礎結構。
其中，本指南只涵蓋或介紹前三個。 最後兩個與應用程式生命週期相關的點會在額外的 Microsoft 平臺和工具的容器化 Docker 應用程式生命週期電子書中進行涵蓋。
其他資源
馬克·魯西諾維奇 微服務：由雲端提供的應用程式革命
https://azure.microsoft.com/blog/microservices-an-application-revolution-powered-by-the-cloud/馬丁·福勒 微服務
https://www.martinfowler.com/articles/microservices.html馬丁·福勒 微服務必要條件
https://martinfowler.com/bliki/MicroservicePrerequisites.html吉米·尼爾森 分塊雲端運算
https://www.infoq.com/articles/CCC-Jimmy-Nilsson塞薩爾·德拉托雷 使用 Microsoft 平臺和工具的容器化 Docker 應用程式生命週期 （可下載電子書）
https://aka.ms/dockerlifecycleebook
