微服務設計原則

隔離

服務必須設計為單獨相互隔離工作。 當你將一個整體單片系統分解成一組服務時，這些服務必須彼此解耦，這樣才能更加連貫和自給自足。每個服務應該能夠處理其自己的故障，而不會影響或破壞整個應用程式或系統。 隔離和解耦特性使服務能夠非常快速地從故障狀態中恢復。服務的隔離特性具有以下優點：容易採用連續交付，更好的擴充套件，有效的監控和可測試性。

自治性

隔離為自治性鋪平了道路。 服務必須設計為自主自治的。 它必須具有凝聚力，能夠獨立地實現其職能。 每個服務可以使用良好定義的API（URI）獨立呼叫。 API以某種方式標識服務功能。 自主服務還必須處理自己的資料。 更流行的術語是多語言永續性，其中每個服務都有自己的持久儲存。 自主還確保彈性。 自主服務具有以下優點：有效的服務編排和協調，更好的擴充套件，透過良好定義的API進行通訊，更快速和可控的部署。

單一責任

服務必須設計為高度凝聚。 單一的職責（責任）原則是服務只執行一個重要的功能。 單一責任與“微觀”一詞很好地結合。 ‘微’意味著小，細粒度，只與其責任範圍內相關。 單一責任功能具有以下優點：服務組合無縫，更好的擴充套件，可重用性，可擴充套件性和可維護性。

有界上下文

您的服務應該有多大或小？ 答案就在於所謂有界上下文設計原則。這是一個關鍵模式，同時是領域驅動設計（DDD）建模方法。 有界的上下文是關於微服務將提供其服務功能的上下文。它根據有關領域模型和識別離散邊界，並相應地設計您的微服務，使其更具凝聚力和自主性。 這也意味著跨邊界的通訊變得更有效率，在一個有界上下文中的服務不需要依賴於另外一個有限上下文中的太多的事情了。

非同步通訊

在設計離散邊界和使用其自己的有界上下文設計服務時，跨邊界的服務通訊必須是非同步的。非同步通訊模式自然導致服務之間的松耦合，並允許更好的縮放。使用同步通訊，會阻止呼叫並等待響應。 處於阻塞狀態的服務不能執行另一個任務，直到接收到響應並釋放底層執行緒為止。它導致網路擁塞，並影響延遲和吞吐量。非同步通訊還可以帶來實現良好定義的整合或通訊模式的概念，以實現涉及不同服務的邏輯工作流。

位置獨立

根據設計，微服務是在虛擬化環境或docker容器中部署。隨著雲端計算的出現，我們可以擁有大量可以利用動態縮放環境的服務例項。 服務可以在跨小型或大型叢集的多個節點上執行。服務本身可以根據底層計算資源的可用性或效率來重新定位。 必須能夠以位置獨立的方式來定址或定位服務。通常，可以使用不同的查詢發現模式來消費使用您的服務。服務的客戶端或消費者不必煩惱部署或配置特定服務的位置。 它只是使用某種邏輯或虛擬地址來定位服務。

微服務不是一種技術，框架或解決方案。它是一種架構風格，為您提供一種方法來處理單一應用程式的複雜性質。 這種方法是從上述設計原則開始，您可以使用它來構建基於微服務的應用程式。

Microservices Series: Microservices Design Princip