微服務體系結構描述了一種使用松散耦合服務集合開發應用程序的方法。以前，應用程序是基于集中式多層體系結構的。在大型機和臺式機的時代，這種方法很有效。但在云計算和移動設備中，后端必須隨時可用于各種設備。Bug修復和特性必須在不停機或不部署整個應用程序的情況下快速交付。

微服務是獨立部署的，通過webapi或消息隊列進行通信以響應傳入事件。它們協同工作以提供各種功能，如用戶界面前端、推薦、物流、計費等。

微服務通常在容器中運行。容器簡化了微服務的部署，但即使沒有容器，微服務也可以運行。

微服務是封裝業務場景的自主獨立服務。它包含 代碼 和 狀態 。通常，微服務甚至包含自己的數據存儲。這使得它具有獨立的可版本性、可擴展性和可部署性。微服務是松散耦合的，通過使用http等協議的定義良好的接口與其他微服務交互。它們在出現故障時 保持一致和可用 。微服務是可獨立發布的。每個微服務都可以自己擴展，而不必擴展整個應用程序。

微服務有哪些類型？

大體上，有兩種類型的微服務：

無狀態：沒有狀態或者可以從外部存儲（緩存/數據庫）檢索。它可以擴展而不影響狀態?？梢杂蠳個實例。示例：web前端、協議網關等。無狀態服務不是緩存或數據庫。它經常訪問元數據，沒有實例關聯，節點丟失不明顯。

有狀態：保持一個強硬、權威的狀態。對于大型超規模應用程序，狀態保持在接近計算的狀態。N通過復制和本地持久性實現一致的拷貝。示例：數據庫、文檔、工作流、用戶配置文件、購物車等。有狀態服務由數據庫和緩存組成，節點丟失是一個值得注意的事件。它有時是一個保存大量數據的自定義應用程序。

作為一種變體，一位作者確定了三種類型：無狀態（計算）、持久性（存儲）、聚合（編排）。聚合微服務依賴于其他微服務，因此具有網絡和磁盤I/O依賴性。

當我們將微服務視為分層體系結構時，我們可以確定以下類型：

• 核心/原子服務 ：細粒度的自包含服務。沒有外部服務依賴項。主要是業務邏輯。通常沒有網絡電話。
• 復合/集成服務 ：由多個核心服務組成的業務功能。包括業務邏輯和網絡調用。實現路由、轉換、編排、彈性和穩定性模式。通常與遺留或專有系統接口。
• API/Edge服務 ：一組選定的集成服務和核心服務，作為用戶的托管API提供。實現路由、API版本控制、API安全和限制。

微服務與API有何不同？

API不是微服務，微服務也不是API的實現。API是一個接口。微服務是一個組件。術語“ micro ”指的是組件，而不是公開接口的粒度。微服務可用于公開一個或多個api。然而，并不是所有的微服務組件都公開api。

微服務架構和面向服務架構（SOA）之間的關系是什么？

SOA和微服務架構涉及不同的范圍。SOA與企業服務公開相關，而微服務體系結構與應用程序體系結構相關。兩者都試圖實現許多相同的事情（將業務功能創建為獨立組件），但規模不同。它們在可維護性、粒度、敏捷性等方面有所不同。SOA是一個非常寬泛的術語，微服務是該用法的一個子集。Netflix指出，微服務是“細粒度SOA”。微服務被認為是“SOA做得對”。

一些微服務原則與SOA有很大的不同：

1. 重用不是目標 ：由于通用組件所創建的依賴關系，不鼓勵重用通用組件。最好通過復制重復使用。

2. 同步是不好的 ：進行諸如API或web服務之類的同步調用會創建實時依賴關系。微服務之間盡可能使用消息傳遞。

3. 運行時服務發現 ：假定組件是易失性的。因此，客戶機通常有責任在實例之間找到甚至負載平衡。

4. 采用了數據復制技術 ：事件源等技術可以產生多個獨立的數據“視圖”，確保微服務真正解耦。

在設計微服務架構時，需要牢記哪些重要原則？

一般來說，在設計微服務體系結構時，以下原則是很好的：圍繞業務領域建模、自動化文化、隱藏實現細節、高度可觀察、分散所有內容、隔離故障、消費者優先、獨立部署。

使用微服務架構有什么好處？

優勢跨越開發和運營。簡單地說，我們注意到以下優勢：大規模構建和運營服務，提高資源利用率以降低成本，故障隔離，持續創新，小型專注團隊，使用任何語言或框架。

可伸縮性來自于微服務支持的模塊化。由于容器的存在，微服務在各種環境中的部署變得更加容易。由于服務的隔離，還有一個安全優勢：對一個服務的攻擊不會影響其他服務。

微服務是關于代碼和開發的。容器是關于部署的。容器支持微服務。容器提供了隔離的環境，因此是部署微服務的理想選擇。但是，可以在沒有容器的情況下部署微服務。例如，可以在amazonec2上獨立部署微服務。每個微服務都可以在自己的自動縮放組中獨立縮放。

為什么我不應該為我的應用程序采用微服務呢？

由于應用程序是跨微服務分布的，這樣的分布式系統更難管理和監視。操作復雜性隨著微服務及其實例數量的增加而增加，特別是當它們被動態創建和銷毀時。網絡呼叫可能很慢，有時甚至會失敗。 由于是分布式的，很難保持強一致性，應用程序必須確保最終的一致性。

微服務需要更多的時間來規劃和劃分應用程序。它們的設計應該考慮到失敗。當您正在構建一個最小可行產品（MVP）或嘗試評估什么是有效的或可以為業務增加價值的，那么單一的方法會更快更容易。只有當你的想法和商業價值被證明后需要擴展時，才采用微服務。

如果您管理的是一個遺留應用程序，那么遷移到微服務的工作可能需要相當大的成本。技術堆?？赡鼙葐我粦贸绦虼蟮枚唷贸绦驅W絡及其性能有很大的依賴性。微服務可以獨立測試，但要測試整個應用程序更為困難。