微服務體系結(jié)構(gòu)由一系列小型的自治服務組成。 每個服務都是自包含服務，并且應實現(xiàn)單個業(yè)務功能。

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

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

除了服務本身，典型微服務體系結(jié)構(gòu)中還會出現(xiàn)其他組件：

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

服務發(fā)現(xiàn)。 維護一個包含服務及其所在節(jié)點的列表。 支持使用服務查找功能查找服務的終結(jié)點。

API 網(wǎng)關。 API 網(wǎng)關是客戶端的入口點。 客戶端不直接調(diào)用服務， 而是調(diào)用 API 網(wǎng)關，網(wǎng)關再將調(diào)用轉(zhuǎn)發(fā)到后端上的相應服務。 API 網(wǎng)關可以聚合來自多個服務的響應，并返回聚合的響應。

使用 API 網(wǎng)關的優(yōu)點如下：

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

何時使用此架構(gòu)

請對以下情況考慮使用此體系結(jié)構(gòu)樣式：

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

優(yōu)點

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

挑戰(zhàn)

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

最佳做法

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

轉(zhuǎn)自：https://docs.microsoft.com/zh-cn/azure/architecture/guide/architecture-styles/microservices