微服務的優點和缺點

基于微服務的解決方案的好處

• 開發人員很容易了解并以良好的生産力快速入門。
• 容器啟動很快，這使開發人員的工作效率更高。
• 像Visual Studio這樣的IDE可以快速加載較小的項目，使開發人員高效。
• 每個微服務都可以獨立于其他微服務進行設計，開發和部署，進而提供靈活性，因為它更容易經常部署新版本的微服務。

可以擴充應用程式的各個區域。例如，可能需要擴充目錄服務或購物籃服務，而不是訂購流程。對于擴充時使用的資源而言，微服務基礎結構将比單片體系結構更有效。

您可以在多個團隊之間劃分開發工作。每個服務都可以由一個開發團隊擁有。每個團隊都可以獨立于其他團隊管理，開發，部署和擴充他們的服務。

問題更加孤立。如果一個服務中存在問題，則最初隻影響該服務（除非使用了錯誤的設計，微服務之間存在直接依賴關系），其他服務可以繼續處理請求。相比之下，單片部署體系結構中的一個故障元件可能會導緻整個系統崩潰，尤其是當涉及資源（如記憶體洩漏）時。此外，當解決微服務中的問題時，您可以僅部署受影響的微服務，而不會影響應用程式的其餘部分。

您可以使用最新技術。因為您可以獨立開始開發服務并并行運作（感謝容器和.NET Core），您可以友善地開始使用最新的技術和架構，而不是被困在整個應用程式的舊堆棧或架構上。

基于微服務的解決方案的缺點

像這樣的基于微服務的解決方案也有一些缺點：

分布式應用。分發應用程式會增加開發人員在設計和建構服務時的複雜性。例如，開發人員必須使用HTTP或AMPQ等協定實作服務間通信，這增加了測試和異常處理的複雜性。它還增加了系統的延遲。

部署複雜性。具有數十種微服務類型并且需要高可伸縮性的應用程式（它需要能夠為每個服務建立多個執行個體并在多個主機上平衡這些服務）意味着IT操作和管理的高度部署複雜性。如果您不使用面向微服務的基礎架構（如協調器和排程程式），那麼額外的複雜性可能需要比業務應用程式本身更多的開發工作。

原子交易。多個微服務之間的原子事務通常是不可能的。業務需求必須包含多個微服務之間的最終一緻性。

增加全局資源需求（所有伺服器或主機的總記憶體，驅動器和網絡資源）。在許多情況下，當您使用微服務方法替換單一應用程式時，新的基于微服務的應用程式所需的初始全局資源量将大于原始單片應用程式的基礎架構需求。這是因為更高的粒度和分布式服務需要更多的全局資源。但是，考慮到整體資源成本低，并且與單個應用程式發展過程中的長期成本相比，能夠擴充應用程式的某些區域的好處，增加資源的使用通常是一個很好的權衡期限申請。