本篇文章轉自微軟官網技術文檔。設計原則，優缺點等都總結的很好，非常值得閱讀收藏，歡迎關注我。

微服務體系結構由一系列小型的自治服務組成。每個服務都是自包含服務，并且應實現單個業務功能。

在某些方面，微服務是面向服務的體系結構 (SOA) 的自然演變，但微服務與 SOA 之間也存在一些差異。下面是微服務的一些典型特征：

在微服務體系結構中，服務具有規模小、獨立和松散耦合的特點。
每個服務都是一個單獨的基本代碼，可由小型開發團隊管理。
服務可獨立部署。團隊可以更新現有服務，而無需重新生成和重新部署整個應用程序。
服務負責暫留自己的數據或外部狀態。這一點與傳統模型不同，后者由單獨的數據層處理數據暫留。
服務通過定義完善的 API 相互通信。每個服務的內部實現細節均對其他服務隱藏。
服務無需共享相同的技術堆棧、庫或框架。

除了服務本身，典型微服務體系結構中還會出現其他組件：

管理。管理組件負責將服務放置在節點上、標識故障、跨節點重新平衡服務等等。

服務發現。維護一個包含服務及其所在節點的列表。支持使用服務查找功能查找服務的終結點。

API 網關。 API 網關是客戶端的入口點。客戶端不直接調用服務，而是調用 API 網關，網關再將調用轉發到后端上的相應服務。 API 網關可以聚合來自多個服務的響應，并返回聚合的響應。

使用 API 網關的優點如下：

它分離了客戶端與服務。無需更新所有客戶端，便可對服務進行版本控制或重構。
服務可以使用對 Web 不友好的消息傳遞協議，比如 AMQP。
API 網關可執行身份驗證、日志記錄、SSL 終止和負載均衡等其他跨領域功能。

何時使用此架構

請對以下情況考慮使用此體系結構樣式：

需要較高發布速度的大型應用程序。
需要高度可縮放的復雜應用程序。
具有大量域或多個子域的應用程序。
由小型開發團隊組成的組織。

優點

獨立部署。無需重新部署整個應用程序便可更新服務，出現問題時可回滾或前滾更新。 Bug 修復和功能發布更易管理，風險更低。
獨立開發。單個開發團隊便可生成、測試和部署服務，從而推動持續創新，加快發布節奏。
小型專屬團隊。團隊可專注于一個服務。縮小每個服務的范圍后，基本代碼變得更好理解，新的團隊成員也能更快上手。
錯誤隔離。某個服務中斷不會影響整個應用程序。但是，這并不意味著用戶可以無償復原。用戶仍需遵循復原最佳做法和設計模式。請參閱設計可靠的 Azure 應用程序。
混合技術堆棧。團隊可選取最適合其服務的技術。
精細縮放。服務可獨立縮放。與此同時，每個 VM 的較高服務密度也意味著 VM 資源得到充分利用。使用放置約束，可將服務與 VM 配置文件（高 CPU、高內存等等）匹配。

挑戰

復雜性。與同等的單一式應用程序相比，微服務應用程序具有更多移動部件。每個服務更簡單，但整個系統作為整體來說更復雜。
開發和測試。針對服務依賴關系的開發需要采用不同的方法。現有工具不一定能處理這些服務依賴關系。跨服務邊界進行重構可能很困難。測試服務依賴關系也有一定難度，尤其是在應用程序快速發展之時。
缺乏監管。用于生成微服務的分散式方法具有一定優勢，但也可能導致許多問題。用戶在生成過程中可能采用了許多不同的語言和框架，從而使應用程序變得難以維護。這種情況下可以實施一些項目范圍內的標準，不過分限制團隊的靈活性。這尤其適用于日志記錄等跨領域功能。
網絡擁塞和延遲。使用大量小型的精細服務可能會增加服務間的通信量。此外，如果服務依賴關系鏈變得太長（服務 A 調用 B，B 調用 C...），額外延遲可能會成為一個問題。用戶需要精心設計 API。應避免過于繁瑣的 API，考慮使用序列化格式，并找到可以使用異步通信模式的地方。
數據完整性。每個微服務負責其自己的數據持久性。因此，數據一致性可能是個挑戰。如果可能，請采用最終一致性。
管理。成功使用微服務需要有成熟的 DevOps 區域性。跨服務的關聯日志記錄可能很難。通常情況下，日志記錄必須為單個用戶操作關聯多個服務調用。
版本控制。對某個服務的更新不應中斷依賴于它的其他服務。多個服務可在任意給定時間更新，因此，若不精心設計，可能會遇到向后或向前兼容性問題。
技能組合。微服務是一種高度分布式系統。請仔細評估團隊是否具有成功使用微服務所需的技能和經驗。

最佳做法

圍繞業務域對服務建模。
分散所有資源。單個團隊負責設計和生成服務。避免共享代碼或數據架構。
擁有數據的服務應當有專用的數據存儲。為每個服務和數據類型使用最合適的存儲。
服務通過設計完善的 API 進行通信。避免泄露實現細節。 API 應對域建模，而不是對服務的內部實現建模。
避免服務之間耦合。耦合的原因包括共享的數據庫架構和嚴格的通信協議。
將身份驗證和 SSL 終止等跨領域操作分流到網關。
讓網關不必了解域。網關應處理和路由客戶端請求，而無需了解業務規則或域邏輯。否則，網關會變成一個從屬物，從而導致服務之間耦合。
服務應具有松散耦合和高功能內聚的特點。應當將可能會一起更改的函數打包并部署在一起。如果它們駐留在不同的服務中，這些服務最終會緊密耦合，因為一個服務中的更改將需要更新其他服務。兩個服務之間的通信過于頻繁可能是緊密耦合和低內聚的征兆。
隔離故障。