摘要：一微服務(wù)概念微服務(wù)體系結(jié)構(gòu)由輕量級松散耦合的服務(wù)集合組成。每個(gè)服務(wù)都有自己的計(jì)劃測試發(fā)布部署擴(kuò)展集成和獨(dú)立維護(hù)。團(tuán)隊(duì)不必因?yàn)檫^去的技術(shù)決定而受到懲罰。用在這里是指將相關(guān)的服務(wù)通過聚合器聚合在一起，這個(gè)聚合器就是門面。

微服務(wù)架構(gòu)現(xiàn)在是談到企業(yè)應(yīng)用架構(gòu)時(shí)必聊的話題，微服務(wù)之所以火熱也是因?yàn)橄鄬χ暗膽?yīng)用開發(fā)方式有很多優(yōu)點(diǎn)，如更靈活、更能適應(yīng)現(xiàn)在需求快速變更的大環(huán)境。

一、微服務(wù)概念

微服務(wù)體系結(jié)構(gòu)由輕量級、松散耦合的服務(wù)集合組成。每個(gè)服務(wù)都實(shí)現(xiàn)了單個(gè)業(yè)務(wù)功能。理想情況下，這些服務(wù)應(yīng)該是具有足夠的內(nèi)聚性，可以獨(dú)立地開發(fā)、測試、發(fā)布、部署、擴(kuò)展、集成和維護(hù)。

正式定義

“微服務(wù)架構(gòu)風(fēng)格是一種將單個(gè)應(yīng)用程序開發(fā)為一組小型服務(wù)的方法，每個(gè)小服務(wù)運(yùn)行在自己的進(jìn)程中，并且以輕量級機(jī)制（通常是HTTP REST API）通信。這些服務(wù)是圍繞業(yè)務(wù)能力建立的，并且可以由完全自動化的部署機(jī)構(gòu)獨(dú)立部署。這些服務(wù)的集中管理只有最低限度，可以用不同的編程語言編寫并使用不同的數(shù)據(jù)存儲技術(shù)?！?/p>

—— James Lewis and Martin Fowler

定義微服務(wù)的特性

每個(gè)服務(wù)都是一個(gè)輕量級、獨(dú)立和松散耦合的業(yè)務(wù)單元。

每個(gè)服務(wù)都有自己的代碼庫，由一個(gè)小團(tuán)隊(duì)管理和開發(fā)（主要是用于敏捷環(huán)境中）。

每個(gè)服務(wù)負(fù)責(zé)一部分功能或者說業(yè)務(wù)能力，并且做得很好。

每個(gè)服務(wù)都可以為其用例選擇最佳的技術(shù)棧（無需將整個(gè)應(yīng)用程序綁定在一個(gè)框架中）。

每個(gè)服務(wù)都有自己的DevOps計(jì)劃（測試、發(fā)布、部署、擴(kuò)展、集成和獨(dú)立維護(hù)）。

每個(gè)服務(wù)都部署在一個(gè)獨(dú)立自給的環(huán)境中。

服務(wù)通過使用定義良好的API（智能端點(diǎn)）和簡單協(xié)議如基于HTTP 的REST協(xié)議（啞管道）相互通信。

每個(gè)服務(wù)負(fù)責(zé)持久化自己的數(shù)據(jù)和保持外部狀態(tài)（只有當(dāng)多個(gè)服務(wù)使用相同的數(shù)據(jù)時(shí)，這種情況才在公共數(shù)據(jù)層中處理）。

白小白：

智能端點(diǎn)和啞管道，其實(shí)我一直認(rèn)為“啞”管道不如“笨”管道或者“呆”管道更易理解。防呆設(shè)計(jì)是一種預(yù)防用戶錯(cuò)誤使用產(chǎn)品造成不良后果的設(shè)計(jì)理念，比如USB設(shè)計(jì)成一半有實(shí)體芯片，就是讓用戶可以不假思索的在插錯(cuò)后直接掉轉(zhuǎn)方向再插。不讓用戶思考就是“呆”的含義?！皢　惫艿赖摹皢　逼鋵?shí)就是體現(xiàn)在微服務(wù)的通信過程盡量簡單，不要讓通信機(jī)制有“思考能力”，不在其中加入過多的處理機(jī)制，反例是SOA時(shí)代的ESB產(chǎn)品，ESB產(chǎn)品通常會包含復(fù)雜的設(shè)施用于消息路由，編排和轉(zhuǎn)換，以及業(yè)務(wù)規(guī)則應(yīng)用。反過來，智能端點(diǎn)的概念就容易理解了，也就是將與某服務(wù)相關(guān)的處理都限定在微服務(wù)的范疇之內(nèi)，通信過程中的微服務(wù)端點(diǎn)是“智能”的，這也從一個(gè)方面體現(xiàn)了微服務(wù)“高內(nèi)聚”的含義，有了高內(nèi)聚，才能具備自治和獨(dú)立性，從而可以支持“松耦合”的機(jī)制。

微服務(wù)的好處

微服務(wù)可以用于擴(kuò)展大型系統(tǒng)，也為持續(xù)集成和交付提供了巨大的能力。

獨(dú)立縮放：《 The Art of Scalability》（ http://t.cn/EAvlQ4o）這本優(yōu)秀的書中所描述的Scale Cube概念，是微服務(wù)架構(gòu)所支持的。在開發(fā)微服務(wù)以實(shí)現(xiàn)功能分解時(shí)，應(yīng)用程序通過Y軸自動縮放。當(dāng)服務(wù)調(diào)用量較高時(shí)，微服務(wù)可以通過克隆更多的CPU和內(nèi)存，通過X軸進(jìn)行擴(kuò)展。為了在多臺機(jī)器上分發(fā)數(shù)據(jù)，可以分離大型數(shù)據(jù)庫（分庫分表）轉(zhuǎn)換成更小、更快、更容易管理的部件，從而實(shí)現(xiàn)Z軸的縮放。

獨(dú)立發(fā)布和部署：使用微服務(wù)，Bug修復(fù)和特性發(fā)布更易于管理，風(fēng)險(xiǎn)更小?？梢栽诓恢匦虏渴鹫麄€(gè)應(yīng)用程序的情況下更新服務(wù)，并在出現(xiàn)問題時(shí)回滾或前滾更新。

獨(dú)立開發(fā)：每個(gè)服務(wù)都有自己的代碼庫，由一個(gè)小的焦點(diǎn)小組開發(fā)、測試和部署。開發(fā)人員可以專注于一種服務(wù)，并且只關(guān)注相對較小的范圍。這將提高生產(chǎn)率、項(xiàng)目速度、持續(xù)創(chuàng)新能力和源碼質(zhì)量。

優(yōu)雅降級：如果服務(wù)崩潰，其影響不會傳播到應(yīng)用程序的其他部分，并導(dǎo)致系統(tǒng)發(fā)生災(zāi)難性故障，從而體現(xiàn)某種程度的健壯性。

分散治理：開發(fā)人員可以自由選擇技術(shù)棧，制定最適合其服務(wù)的設(shè)計(jì)標(biāo)準(zhǔn)和實(shí)現(xiàn)決策。團(tuán)隊(duì)不必因?yàn)檫^去的技術(shù)決定而受到懲罰。

業(yè)務(wù)關(guān)切

獨(dú)立的服務(wù)本身并不能形成一個(gè)系統(tǒng)。要使微服務(wù)體系結(jié)構(gòu)真正成功，需要大量投資來處理跨系統(tǒng)的問題，例如：

服務(wù)復(fù)制：一種讓服務(wù)易于擴(kuò)展的基于元數(shù)據(jù)的機(jī)制

服務(wù)注冊和發(fā)現(xiàn)：啟用服務(wù)查找并查找服務(wù)端點(diǎn)的機(jī)制

服務(wù)監(jiān)測和日志：收集來自不同微服務(wù)的日志的機(jī)制，并提供一致的報(bào)告

彈性：服務(wù)在故障期間自動采取糾正行動的機(jī)制

DevOps：處理持續(xù)集成和部署的機(jī)制（CI和CD）

API網(wǎng)關(guān)：為客戶端提供入口的機(jī)制

二、中間件與設(shè)計(jì)模式

API網(wǎng)關(guān)（所有客戶端的單一入口點(diǎn)）

API網(wǎng)關(guān)風(fēng)格的微服務(wù)體系結(jié)構(gòu)（圖片來自：Microsoft Azure Docs），是用于微服務(wù)的最常見的設(shè)計(jì)模式。API網(wǎng)關(guān)是一個(gè)中間層，具有最小化的路由功能，只是充當(dāng)一個(gè)“啞管道”，里面沒有業(yè)務(wù)邏輯。一般來說，API網(wǎng)關(guān)允許客戶端基于REST/HTTP調(diào)用托管的API。其他類型的微服務(wù)集成模式有：點(diǎn)對點(diǎn)風(fēng)格（直接從客戶端應(yīng)用程序調(diào)用服務(wù)）和消息代理風(fēng)格（實(shí)現(xiàn)異步消息傳遞）。

API網(wǎng)關(guān)充當(dāng)所有客戶端的單一入口點(diǎn)，API網(wǎng)關(guān)也作為一種邊緣服務(wù)來將微服務(wù)作為托管API公開給外部世界。這聽起來像是一個(gè)反向代理，但也有一些額外的責(zé)任，例如簡單的負(fù)載平衡，認(rèn)證和授權(quán)，故障處理，審核，協(xié)議轉(zhuǎn)換，和路由機(jī)制。開發(fā)團(tuán)隊(duì)可以選擇以下方法之一來實(shí)現(xiàn)API網(wǎng)關(guān)。

自己編程實(shí)現(xiàn)：具有更好的客戶化和管控能力。

部署現(xiàn)有的API網(wǎng)關(guān)產(chǎn)品：節(jié)省初始開發(fā)時(shí)間，并使用高級內(nèi)置功能（缺點(diǎn)在于：此類產(chǎn)品依賴于供應(yīng)商，并不完全免費(fèi)。配置和維護(hù)通常是冗長而耗時(shí)的）

解釋API網(wǎng)關(guān)行為的一些設(shè)計(jì)模式如下（請參閱微服務(wù)設(shè)計(jì)模式 http://t.cn/RKx8bhG）.

網(wǎng)關(guān)聚合（http://t.cn/EAvT2jl）：將針對多個(gè)內(nèi)部微服務(wù)的多個(gè)客戶端請求（通常是HTTP請求）聚合到單個(gè)客戶端請求中，減少了使用者和服務(wù)之間的交互和網(wǎng)絡(luò)延遲。

網(wǎng)關(guān)分流（http://t.cn/EAvTGmA）：使單個(gè)微服務(wù)能夠?qū)⒁恍┕蚕淼姆?wù)功能分流到API網(wǎng)關(guān)級別。這些跨服務(wù)功能包括認(rèn)證、授權(quán)、服務(wù)發(fā)現(xiàn)、容錯(cuò)機(jī)制、QoS、負(fù)載平衡、日志記錄、分析等。

網(wǎng)關(guān)路由（第7層路由，通常是HTTP請求 http://t.cn/EAvTMm4）：使用單一入口端點(diǎn)將請求路由到內(nèi)部微服務(wù)的端點(diǎn)，這樣服務(wù)調(diào)用者就不需要自行管理多個(gè)獨(dú)立的端點(diǎn)

請注意，API網(wǎng)關(guān)應(yīng)該始終是一個(gè)高可用性和高性能的組件，因?yàn)樗钦麄€(gè)系統(tǒng)的入口點(diǎn)。

事件總線（用于異步事件驅(qū)動通信的、發(fā)布/訂閱、中介通道）

微服務(wù)之間基于事件驅(qū)動的異步通信實(shí)現(xiàn)最終一致性

（圖片來源：microsoft.com）

應(yīng)用程序的不同部分在進(jìn)行相互通信時(shí)，無論消息的順序（為處理異步的消息）或使用的語言（為了體現(xiàn)語言無關(guān)性），都可以使用事件總線來實(shí)現(xiàn)。大多數(shù)事件總線支持發(fā)布/訂閱、分布式、點(diǎn)對點(diǎn)和請求響應(yīng)消息傳遞。一些事件總線（如Vert.x）允許客戶端使用相同的事件總線與相應(yīng)的服務(wù)器節(jié)點(diǎn)進(jìn)行通信，這是全堆棧團(tuán)隊(duì)所喜愛的一個(gè)很酷的特性。

服務(wù)網(wǎng)格（用于服務(wù)間通信的外掛（Sidecar）機(jī)制）

服務(wù)網(wǎng)格風(fēng)格的服務(wù)間通信

（圖片來源：微服務(wù)實(shí)踐http://t.cn/EAAJWRi）

如何在應(yīng)用程序中使用服務(wù)網(wǎng)格

（圖片來源：http://t.cn/EAAizgn）

服務(wù)網(wǎng)格通過提供服務(wù)間通信的輔助架構(gòu)來實(shí)現(xiàn)外掛模式，包括彈性（容錯(cuò)、負(fù)載平衡）、服務(wù)發(fā)現(xiàn)、路由、可觀察性、安全性、訪問控制、通信協(xié)議支持等功能。

服務(wù)網(wǎng)格在網(wǎng)絡(luò)堆棧中的位置

（圖片來源：http://t.cn/EAAizgn）

實(shí)際上，外掛實(shí)例部署在每個(gè)服務(wù)的旁邊（理想情況下是在同一個(gè)容器中）。他們可以通過服務(wù)本身的網(wǎng)絡(luò)功能來進(jìn)行通信。服務(wù)網(wǎng)格的控制平面被多帶帶部署，以提供中心功能，如服務(wù)發(fā)現(xiàn)、訪問控制和可觀察性（監(jiān)視、分布式日志記錄）。最重要的是，服務(wù)網(wǎng)格風(fēng)格的設(shè)計(jì)模式允許開發(fā)人員從微服務(wù)代碼中分離網(wǎng)絡(luò)通信功能并使服務(wù)只關(guān)注于業(yè)務(wù)功能。（來自：Netflix Prana, 微服務(wù)網(wǎng)格）

盡管上面的圖片顯示了服務(wù)之間的直接連接，但是處理服務(wù)間通信的好方法是使用一個(gè)簡單的事件總線作為中介，以保持最低級別的耦合。

聚合器（BFF模式）

在API網(wǎng)關(guān)級別上實(shí)現(xiàn)BFF模式和聚合器模式

（圖：microsoft.com）

如果應(yīng)用程序需要裁剪每個(gè)API以適應(yīng)客戶端應(yīng)用程序類型（Web端、移動端以及其他不同平臺），則可以通過聚合器（Aggregator）執(zhí)行不同的業(yè)務(wù)規(guī)則，也可以執(zhí)行不同的配置以根據(jù)客戶端功能適配不同的構(gòu)建。這可以在API網(wǎng)關(guān)級別實(shí)現(xiàn)，也可以在服務(wù)級別并行實(shí)現(xiàn)。這種模式對于提供特定的用戶體驗(yàn)非常有用。但是，開發(fā)團(tuán)隊(duì)?wèi)?yīng)該足夠小心，將BFF保持在可管理的范圍內(nèi)。

白小白：

“通過聚合器”，原文是“via a facade”，直譯是“通過一個(gè)外觀/門面”。門面模式（外觀模式），是一種Java的設(shè)計(jì)模式，為子系統(tǒng)中的一組接口提供了一個(gè)統(tǒng)一的訪問接口，引申自一個(gè)前店后廠的生意模式，前面是門面，后面會有進(jìn)料、生產(chǎn)、包裝多個(gè)服務(wù)。用在這里是指將相關(guān)的服務(wù)通過聚合器聚合在一起，這個(gè)聚合器就是門面。服務(wù)調(diào)用者與門面交互而不是與一組服務(wù)交互降低了耦合性，但同時(shí)違反了面向?qū)ο笤O(shè)計(jì)原則開閉原則，開閉原則要求模塊在擴(kuò)展時(shí)可以不改動內(nèi)部的代碼，但顯然當(dāng)聚合器后端的某個(gè)服務(wù)發(fā)生變更時(shí)，需要在聚合器層面也發(fā)生變更，這也是文中說“開發(fā)團(tuán)隊(duì)?wèi)?yīng)該足夠小心”的原因，因?yàn)檫`反了開閉原則，就會降低可復(fù)用性。

三、最佳實(shí)踐

? 領(lǐng)域驅(qū)動設(shè)計(jì)：圍繞業(yè)務(wù)領(lǐng)域進(jìn)行服務(wù)建模。

為了處理大型模型和團(tuán)隊(duì)，可以應(yīng)用領(lǐng)域驅(qū)動設(shè)計(jì)（DDD）。DDD通過將大型模型劃分為不同的有界上下文來明確他們之間的相互關(guān)系和子領(lǐng)域。這些有界上下文可以在應(yīng)用設(shè)計(jì)級別轉(zhuǎn)換為多帶帶的微服務(wù)。（參見：領(lǐng)域驅(qū)動設(shè)計(jì)中的有界上下文 http://t.cn/EAAK4Xk）

? 分散數(shù)據(jù)管理（避免共享數(shù)據(jù)庫）：當(dāng)多個(gè)服務(wù)使用一個(gè)共享數(shù)據(jù)架構(gòu)時(shí)，會在數(shù)據(jù)層形成緊耦合。為了避免這種情況，每個(gè)服務(wù)都應(yīng)該有自己的數(shù)據(jù)存取邏輯和獨(dú)立數(shù)據(jù)存儲。開發(fā)團(tuán)隊(duì)可以根據(jù)服務(wù)和數(shù)據(jù)性質(zhì)的不同自由選擇最適合的數(shù)據(jù)持久性方法。

避免共享數(shù)據(jù)存儲和訪問機(jī)制

（圖片來源：http://t.cn/RcLB5Kv）

? 智能端點(diǎn)和啞管道：每個(gè)服務(wù)都擁有一個(gè)定義良好的外部通信API，并盡量避免泄露實(shí)現(xiàn)細(xì)節(jié)。通信則始終使用簡單協(xié)議，如基于HTTP的REST協(xié)議。

? 異步通信：當(dāng)跨服務(wù)使用異步通信時(shí)，其他服務(wù)不會阻塞數(shù)據(jù)流。

同步消息和異步消息傳遞

（來源： http://t.cn/EAA9xRU）

? 避免服務(wù)耦合：服務(wù)應(yīng)保持松耦合和高內(nèi)聚。產(chǎn)生耦合的主要原因包括共享數(shù)據(jù)庫模型和嚴(yán)格的通信協(xié)議。

? 分散開發(fā)：避免在多個(gè)服務(wù)/項(xiàng)目之間共享代碼庫、數(shù)據(jù)架構(gòu)或開發(fā)團(tuán)隊(duì)成員。讓開發(fā)者從源頭上關(guān)注創(chuàng)新和質(zhì)量。

? 將領(lǐng)域知識排除在網(wǎng)關(guān)之外：讓網(wǎng)關(guān)處理路由和跨服務(wù)問題（如身份驗(yàn)證、SSL終端等）。

? 基于令牌的認(rèn)證：不要在每個(gè)微服務(wù)級別實(shí)現(xiàn)安全組件，因?yàn)檫@將需要組件與集中式/共享用戶存儲庫對話并檢索身份驗(yàn)證信息；而是考慮實(shí)現(xiàn)API網(wǎng)關(guān)級別的身份驗(yàn)證，使用廣泛使用的API安全標(biāo)準(zhǔn)，如OAuth2和OpenID Connect。一旦從認(rèn)證提供者獲得令牌之后，就可以用于與其他微服務(wù)進(jìn)行通信。

使用OAuth2和OpenID Connect的微服務(wù)安全性

（來源：Kasun’s Blog http://t.cn/EAACGvY）

? 事件驅(qū)動性質(zhì)：既然人可以成為對事件作出反應(yīng)的自主主體，系統(tǒng)也可以。（參見：為什么微服務(wù)應(yīng)該是事件驅(qū)動的：自主性與權(quán)威性 http://t.cn/EAACWOx）

? 最終一致性：由于微服務(wù)的高內(nèi)聚特性，很難在整個(gè)系統(tǒng)內(nèi)實(shí)現(xiàn)很強(qiáng)的一致性。因此開發(fā)團(tuán)隊(duì)必須處理最終一致性。

? 容錯(cuò)：由于系統(tǒng)由多個(gè)服務(wù)和中間件組成，因此在某些地方可能很容易發(fā)生故障。對于這些薄弱環(huán)節(jié)，有一些實(shí)現(xiàn)模式，如斷路器，防水艙，重試，超時(shí)，快速失敗，故障轉(zhuǎn)移緩存，速率限制，負(fù)載釋放，可以將重大故障的風(fēng)險(xiǎn)降到最低。（參見：設(shè)計(jì)一種面向故障的微服務(wù)體系結(jié)構(gòu)http://t.cn/RChKlg9）

? 產(chǎn)品工程化：把微服務(wù)工程化為一種產(chǎn)品，而不是作為一個(gè)項(xiàng)目，可以讓微服務(wù)更好的發(fā)揮作用。這意味著，不能僅僅考慮能用而且及時(shí)交付，而是要長期致力于卓越的工程化。

四、微服務(wù)實(shí)踐

何時(shí)使用微服務(wù)

微服務(wù)架構(gòu)最適合的應(yīng)用場景：

具有高可伸縮性需求的應(yīng)用

對交付速度要求較高的項(xiàng)目

具有豐富域或多個(gè)子域的業(yè)務(wù)用例

小型、跨功能的開發(fā)團(tuán)隊(duì)協(xié)作開發(fā)大型產(chǎn)品的敏捷環(huán)境（請參閱：微服務(wù)架構(gòu)的真正成功故事 http://t.cn/EAANng7）

一些實(shí)現(xiàn)微服務(wù)的入門框架

Vert.x：輕量級，易于理解/實(shí)現(xiàn)/維護(hù)，多語言支持（支持多種語言），事件驅(qū)動，非阻塞，可以說，具備了以最少的硬件處理高并發(fā)需求時(shí)的最佳性能和可伸縮性，并且具備足夠的開放性（與傳統(tǒng)的限制性框架不同，Vert.x只提供有用的組件，開發(fā)人員可以自由地創(chuàng)新并仔細(xì)構(gòu)建他們的應(yīng)用程序）

Akka：令人滿意的性能，實(shí)現(xiàn)了Actor模型（一種并發(fā)模型），有利于響應(yīng)式微服務(wù)和事件驅(qū)型微服務(wù)

Spring Boot/Spring Cloud：容易上手（采用熟悉范式），基于良好的舊Spring框架，有點(diǎn)重的框架，許多集成可用，大規(guī)模的社區(qū)支持

Drop Wizard：有利于RESTful Web服務(wù)的快速開發(fā)，它搭載了一些不錯(cuò)的Java工具和庫，如Google Guava、Jetty Server、Logback、Hibernate Validator、Joda Time、Jersey和Jackson。

部署選項(xiàng)

容器：有利于執(zhí)行DevOps目標(biāo)（快速開發(fā)，縮短上市時(shí)間，無縫縮放）

云計(jì)算架構(gòu)：有利于構(gòu)建可靠和可伸縮的基礎(chǔ)設(shè)施，為地理位置分散的用戶服務(wù)。

無服務(wù)器架構(gòu)：適合處理高度不穩(wěn)定的流量。

維護(hù)自己的IT基礎(chǔ)設(shè)施：對那些擁有足夠能力和資源建設(shè)整個(gè)基礎(chǔ)設(shè)施的組織來說是件好事。

微服務(wù)的開發(fā)理念

自給系統(tǒng)：由獨(dú)立系統(tǒng)組裝軟件（按業(yè)務(wù)垂直切分系統(tǒng)）

微前端：將單體應(yīng)用的Web UI劃分為獨(dú)立的特性，這些特性可以作為獨(dú)立的UI組件開發(fā)，并直接與微服務(wù)進(jìn)行通信。

需要搜索和學(xué)習(xí)的關(guān)鍵詞

領(lǐng)域驅(qū)動設(shè)計(jì)（DDD）| 有界上下文（BC）| 聚合持久性（PP）| 命令和查詢責(zé)任隔離（CQRS）| 命令查詢分離（CQS）| 事件溯源（ES）| CAP定理 |最終一致性 |十二要素應(yīng)用 |SOLID原則 |

五、參考架構(gòu)

用于在線購物應(yīng)用程序的微服務(wù)體系結(jié)構(gòu)

（圖片：microsoft.com）

此體系結(jié)構(gòu)是由使用Microsoft技術(shù)的Microsoft開發(fā)人員提出的。在這里，API Gateway是針對不同的Web和移動用戶而定制的。對于數(shù)據(jù)層，數(shù)據(jù)存儲技術(shù)是根據(jù)業(yè)務(wù)功能仔細(xì)選擇的（關(guān)系數(shù)據(jù)庫用于結(jié)構(gòu)化數(shù)據(jù)，Redis用于臨時(shí)數(shù)據(jù)緩存，MongoDB和Cosmos DB用于非結(jié)構(gòu)化數(shù)據(jù)）。事件總線處理服務(wù)間通信。撇開技術(shù)不說，這是基于微服務(wù)的應(yīng)用最常見的集成模式。

一種非阻塞應(yīng)用程序的微服務(wù)體系結(jié)構(gòu)，該應(yīng)用程序使用來自各種事件源（例如交通數(shù)據(jù)、天氣指數(shù)、股票市場線索、社交媒體帖子、傳感器輸出）的大量輸入數(shù)據(jù)流來向最終用戶顯示實(shí)時(shí)更新。這些輸入數(shù)據(jù)流最初由使用Kafka實(shí)現(xiàn)的事件日志收集。它將數(shù)據(jù)保存在磁盤上，因此可以用于批處理調(diào)用（分析、報(bào)告、數(shù)據(jù)科學(xué)、備份、審計(jì)）或用于實(shí)時(shí)調(diào)用（運(yùn)營分析、CEP、管理儀表板、警報(bào)應(yīng)用程序）。上圖中，使用Spark按指定的時(shí)間間隔，將持續(xù)的輸入數(shù)據(jù)流劃分為微批次，并輸入到WSO2 Siddhi CEP引擎中。后者標(biāo)識事件并使用MongoDB存儲以非結(jié)構(gòu)化形式存儲數(shù)據(jù)。微服務(wù)調(diào)取這些數(shù)據(jù)并顯示給最終用戶。仔細(xì)觀察這一設(shè)計(jì)， Vert.x事件總線能夠創(chuàng)建與前端UI組件的連接，該特性僅用于有效地更新UI中的相關(guān)部分。撇開技術(shù)不說，這是基于事件驅(qū)動的非阻塞微服務(wù)應(yīng)用程序的一個(gè)很好的架構(gòu)。

用于訂單管理應(yīng)用程序的云原生泛渠道微服務(wù)體系結(jié)構(gòu)（圖片：ibm.com）這個(gè)設(shè)計(jì)的一個(gè)主要特點(diǎn)是，IBM架構(gòu)師沒有使用API網(wǎng)關(guān)，而是為每個(gè)客戶端通道（移動應(yīng)用程序、Web應(yīng)用程序、IOT設(shè)備、API使用者）提出了一個(gè)具有獨(dú)立后端的邊緣層。另一個(gè)特點(diǎn)是將微服務(wù)層劃分為業(yè)務(wù)邏輯層和基礎(chǔ)層兩個(gè)子層?；A(chǔ)層（即核心服務(wù)層）使用各種云原生服務(wù)（云數(shù)據(jù)存儲、集成和索引Watson會話的Elastic搜索引擎）處理持久化和集成任務(wù)。業(yè)務(wù)邏輯層集成了基礎(chǔ)層的數(shù)據(jù)，并提供了有意義的業(yè)務(wù)功能。這將是一個(gè)很好的架構(gòu)，可以為地理上分散的大量用戶群提供服務(wù)，并通過各種平臺訪問應(yīng)用程序。