讓我們從面向服務(wù)架構(SOA)和企業(yè)服務(wù)總線(xiàn)(ESB)的一點(diǎn)歷史開(kāi)始，來(lái)看看為什么微服務(wù)變得如此流行。

? ? 很多年以前，軟件供應商提供了一種用于企業(yè)應用集成(EAI)的中間件，通常叫做EAI Broker或者EAI Backbone，這個(gè)中間件是一個(gè)集中式樞紐。當時(shí)，SOA剛剛興起，所選擇的工具是ESB。很多軟件供應商就將他們的EAI工具直接更名為ESB。一段時(shí)間之后，一些新的ESB出現了，不再使用集中式樞紐，而采用分布式代理。所以，ESB成為一種不同的中間件。很多人不喜歡“ESB”這個(gè)術(shù)語(yǔ)，因為他們只知道集中式的概念，而不知道分布式的概念。

? ? 因此，軟件商經(jīng)常避免談?wù)揈SB。他們無(wú)法再銷(xiāo)售一個(gè)集中式的集成中間件，因為一切都變的分布和靈活了?，F在，你可以購買(mǎi)一個(gè)服務(wù)發(fā)布平臺。未來(lái)，它可能是一個(gè)微服務(wù)平臺或者類(lèi)似的東西。在某些情況下，代碼庫可能仍然與20年前的EAI Broker相同。所有這些產(chǎn)品相同的地方是，你能夠通過(guò)實(shí)現“企業(yè)集成模式”來(lái)解決集成問(wèn)題。

? ? 總結一下集成產(chǎn)品的品牌與營(yíng)銷(xiāo)歷史：不要關(guān)注那些性感、動(dòng)人、好聽(tīng)的名字！優(yōu)先關(guān)注它的架構和特性。問(wèn)問(wèn)你自己，你需要解決什么樣的業(yè)務(wù)問(wèn)題，評估那種架構和產(chǎn)品最適合你。當我們再提“ESB”的時(shí)候，不要只想到“集中式的ESB”了。

企業(yè)服務(wù)總線(xiàn)(ESB)之死?

? ? 本文的關(guān)鍵：ESB是否已死？答案明顯是“否”。然而，ESB不再是整個(gè)企業(yè)中一個(gè)集中式，缺乏靈活行的集成主干?，F在我們聽(tīng)到“ESB”，應該想到一個(gè)靈活的、分布式的、可擴展的基礎架構，你可以使用一種敏捷、搞笑的方式創(chuàng )建、部署、監控各種各樣的(微)服務(wù)。開(kāi)發(fā)和部署既可以在企業(yè)內部，也可以在云端，或者采用混合方式(比如，使用云做短期測試環(huán)境或者處理服務(wù)消費的峰值。)

? ? 你使用ESB做它所擅長(cháng)的一些事情：集成、編排、路由、(或者類(lèi)似)事件處理/協(xié)作/業(yè)務(wù)活動(dòng)監控。你也可以通過(guò)(微)服務(wù)創(chuàng )建應用，實(shí)現你的需求或者解決你的業(yè)務(wù)問(wèn)題。你還可以自動(dòng)化的通過(guò)一個(gè)標準化的接口將這些服務(wù)彼此獨立的部署到一個(gè)可擴展的運行平臺。這些服務(wù)是松耦合的并且能夠跨越不同的硬件線(xiàn)性擴展。

? ? 這是我所理解的當今的ESB。ESB是處理這些需求的最好的工具。你只需要聰明的使用ESB，比如通過(guò)面向服務(wù)的方式，而不是面向ESB(集中)的方式?？梢苑Q(chēng)它為ESB，集成平臺，服務(wù)發(fā)布套件，微服務(wù)平臺，或其他你想叫的。

? ? 此外，對于這個(gè)工具(仍稱(chēng)之為ESB)，你可以使用服務(wù)網(wǎng)關(guān)提供服務(wù)安全，服務(wù)策略執行和暴露(微)服務(wù)作為開(kāi)放API給外部消費者。服務(wù)網(wǎng)關(guān)管理你的集成服務(wù)(通過(guò)你的ESB創(chuàng )建)，你的應用服務(wù)(通過(guò)ESB或者其他技術(shù)創(chuàng )建)和外部云服務(wù)(你不需要關(guān)心他們如何創(chuàng )建，你只需要關(guān)心服務(wù)契約)。

? ? 還有一點(diǎn)：你真的需要“總線(xiàn)”之類(lèi)嗎？如果你需要關(guān)聯(lián)不同的(微)服務(wù)中發(fā)生的事件，總線(xiàn)是有意義的。將這些事件放入內存當中，讓他們對實(shí)時(shí)監控、分析和預測行為可見(jiàn)。后面給將有關(guān)于這個(gè)話(huà)題更詳細的信息。對于我所理解的現代ESB，我已經(jīng)討論論的微服務(wù)。所以，你可以看到，ESB和微服務(wù)不是敵人，是朋友和合作伙伴。

?“微服務(wù)”的定義

? ? 讓我們定義一下術(shù)語(yǔ)“微服務(wù)”。就想你在上一節中看到的，應用的設計、架構、開(kāi)發(fā)和運營(yíng)都必須改變。企業(yè)需要建立一種服務(wù)策略來(lái)使它在不同的應用當中重用?？雌饋?lái)仍然像是SOA？的確，但是還有很多重要的不同：

? ?????? 沒(méi)有承諾一個(gè)特有的技術(shù)

? ? ?? ? 更加靈活的架構

? ? ?? ? 具有自己生命周期的服務(wù)管理產(chǎn)品

? ? ?? ? 工業(yè)化部署

這是微服務(wù)時(shí)代的開(kāi)始：服務(wù)實(shí)現一組有限的功能；服務(wù)的開(kāi)發(fā)、部署和擴展相互獨立。這讓您能夠獲得更短的實(shí)施時(shí)間和提升靈活性。

微服務(wù)的挑戰

? ? 微服務(wù)具有很多優(yōu)勢，但是它仍然面臨了一些挑戰：

? ? ?? ? 所有這些服務(wù)都需要繼承

? ? ?? ? 所有這些服務(wù)和技術(shù)需要自動(dòng)化的部署和配置

? ? ?? ? 所有這些服務(wù)需要日志記錄和監控

? ? ?? ? 所有這些服務(wù)需要混合部署

? ? 所以，現在忘記那些關(guān)于產(chǎn)品的討論吧?？紤]你需要創(chuàng )建的微服務(wù)的架構。之前的章節提到的六個(gè)關(guān)鍵需求能夠克服這些挑戰并且充分發(fā)揮微服務(wù)的價(jià)值：

服務(wù)契約

? ???? ? 服務(wù)契約

? ? ?? ? 從現有應用暴露微服務(wù)

? ? ?? ? 服務(wù)發(fā)現

? ? ?? ? 跨服務(wù)的協(xié)同

? ? ?? ? 管理復雜部署和擴展

? ? ?? ? 跨服務(wù)的可見(jiàn)性

? ? 不論你使用的是ESB、服務(wù)發(fā)布平臺或者“僅僅”自定義的源代碼，在你未來(lái)的項目中，為了創(chuàng )建一個(gè)敏捷、靈活和高效的微服務(wù)架構，必須遵循了下面列出的六個(gè)需求。

需求1：服務(wù)契約

? ? 服務(wù)契約是分布式、獨立服務(wù)世界的頭號需求。服務(wù)提供者使用契約發(fā)布服務(wù)的使用目的和需求。其他開(kāi)發(fā)人員可以很容易的訪(fǎng)問(wèn)這些信息。

? ? 在SOA世界中，契約隨著(zhù)SOAP接口定義。SOAP仍然是一種很好的進(jìn)行內部通訊的標準，它提供了很多的安全標準。此外，工具也為最重要的WS-*標準比如WS-Security或者WS-Policy提供了很好的支持。

? ? 在微服務(wù)世界，REST成為實(shí)際的標準，原因不是因為更好的性能，而是簡(jiǎn)單、關(guān)注分離、無(wú)狀態(tài)和統一接口的良好架構。尤其是針對移動(dòng)設備和物聯(lián)網(wǎng)，是兩種主要的微服務(wù)驅動(dòng)者。

? ? 你也可以用REST使用不同的數據格式，比如，你可以選擇JSON和XML。輕量級的JSON格式更適合于移動(dòng)設備，XML是更好的企業(yè)應用選擇。你可以定義模式，使用低效但是成熟的工具進(jìn)行轉換和驗證。性能在過(guò)去一直都是對XML的爭議。使用現在更強大的商業(yè)服務(wù)器和內存計算，這個(gè)在很多場(chǎng)合都不再是大的問(wèn)題。

? ? 通訊通常都會(huì )使用HTTP。盡管HTTP在很多情況下不符合“現代應用場(chǎng)景”的規模。消息發(fā)送標準，比如JMS，是事件驅動(dòng)企業(yè)的一個(gè)很好的選擇。WebSocket、MQTT和其他的標準也在與數百萬(wàn)的設備通訊中脫穎而出，成為物聯(lián)網(wǎng)的重要需求。因此，你的微服務(wù)架構能否在不進(jìn)行服務(wù)重建的情況下，支持不同的數據格式和傳輸協(xié)議，成為非常重要的標準。

需求2：從現有應用暴露微服務(wù)

? ? 大多數企業(yè)業(yè)務(wù)仍然存在于已有應用當中。他們需要將這些應用的功能與外部服務(wù)或者他們自己的微服務(wù)進(jìn)行融合。因此，集成成為微服務(wù)的基礎。你既可以創(chuàng )建全新的服務(wù)，也可以將已有應用的功能暴露成微服務(wù)。這些功能可以是API，一個(gè)內部服務(wù)或者一些遺留源代碼。

? ? 隨著(zhù)時(shí)間的推移，微服務(wù)可以在不同的上下文中被重用，并且滿(mǎn)足不同的通訊需求。將傳輸邏輯從服務(wù)邏輯中分離是一項在微服務(wù)中至關(guān)重要的最佳實(shí)踐。當創(chuàng )建微服務(wù)的邏輯時(shí)，你不需要考慮服務(wù)如何實(shí)現與端點(diǎn)的通訊——是一個(gè)企業(yè)級服務(wù)(XML/SOAP)、云服務(wù)(XML/HTTP)、移動(dòng)設備(JSON/HTTP)、或者一個(gè)物聯(lián)網(wǎng)設備(底層TCP、MQTT，或者專(zhuān)有協(xié)議)

需求3：服務(wù)發(fā)現

? ? 服務(wù)契約很重要。然而，你也必須能夠發(fā)現和使用別人的服務(wù)。服務(wù)必須通過(guò)一個(gè)服務(wù)網(wǎng)關(guān)發(fā)布。服務(wù)網(wǎng)關(guān)執行消費契約，確保微服務(wù)的垂直擴展和可靠性，并且允許微服務(wù)在不經(jīng)過(guò)變更的情況下，在多個(gè)上下文中重用。

? ? 服務(wù)網(wǎng)關(guān)使微服務(wù)有效。它使用開(kāi)放的標準，比如SAML,Kerberos,OAuth，WS-*或者XACML——取決與你的需求。此外，開(kāi)發(fā)人員需要一種簡(jiǎn)單的方式去發(fā)現微服務(wù)和他們的契約。通常，會(huì )使用一個(gè)自服務(wù)的門(mén)戶(hù)，來(lái)提供服務(wù)目錄和契約信息。

API開(kāi)放和API管理

? ? 談?wù)撐⒎?wù)至今，你應該已經(jīng)知道大多數供應商沒(méi)有討論過(guò)他們在上下文中的服務(wù)發(fā)現，但是會(huì )包括API，API開(kāi)放和API管理。像ESB僅僅是一個(gè)術(shù)語(yǔ)一樣，不管你叫它“微服務(wù)注冊”，“API管理”或者其他什么東西。真正相關(guān)的是業(yè)務(wù)問(wèn)題如何解決，它的需求和良好的架構。

? ? 下圖是關(guān)于A(yíng)PI管理的解決方案：網(wǎng)關(guān)、門(mén)戶(hù)和分析。

需求4：跨服務(wù)的協(xié)同

? ? 微服務(wù)和他們的粒度對于服務(wù)的開(kāi)發(fā)和維護非常理想。但是它也確實(shí)增加了應用本身的復雜度。那些應用無(wú)法管理他們在平臺中經(jīng)常使用的受限制資源(電池、網(wǎng)絡(luò )、CPU)的復雜性。結合服務(wù)為滿(mǎn)足應用目的和業(yè)務(wù)流程的高層邏輯，能夠證明開(kāi)發(fā)的快捷和維護的簡(jiǎn)易。

? ? 圖形化工具能夠用于創(chuàng )建微服務(wù)，但是也能夠便捷高效的創(chuàng )建組合服務(wù)：

? ? 微服務(wù)的協(xié)作能夠采用不同的方式實(shí)現：有狀態(tài)或者無(wú)狀態(tài)；服務(wù)或事件驅動(dòng)。在大多數情況下，無(wú)狀態(tài)是單個(gè)服務(wù)的最佳實(shí)踐，一些特殊的協(xié)作/組合服務(wù)有可能更適合有狀態(tài)流程。

有狀態(tài)流程的優(yōu)勢：

? ? ?? ? 狀態(tài)需要進(jìn)行跨調用的共享時(shí)，更易于開(kāi)發(fā)

? ? ?? ? 不需要外部持久化存儲

? ? ?? ? 通常會(huì )對低延遲優(yōu)化

有狀態(tài)流程的劣勢：

? ? ?? ? 如果流程沒(méi)有很好的設計，會(huì )消耗更多的內存

? ? ?? ? 沒(méi)有強制開(kāi)發(fā)人員設計流程狀態(tài)

? ? ?? ? 沒(méi)有涉及的流程，狀態(tài)就無(wú)法被查詢(xún)

內存數據網(wǎng)格

? ? 在很多應用場(chǎng)景中，上下文/狀態(tài)的改變需要作為事件在內存數據網(wǎng)格進(jìn)行共享，以大幅提升性能和降低發(fā)布的延遲。非常重要的一點(diǎn)是要理解內存網(wǎng)格不僅僅能夠在內存中緩存和存儲數據。未來(lái)內存計算的特性是事件處理、發(fā)布/訂閱、ACID(原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）)交易，條件查詢(xún)和容錯。

需求5：管理復雜部署和擴展

? ? 服務(wù)對于上下文的使用將會(huì )大不相同。服務(wù)需要快速的擴展。自動(dòng)化是微服務(wù)開(kāi)發(fā)敏捷、靈活、高效的關(guān)鍵。沒(méi)有持續集成/持續發(fā)布(DevOps)，你無(wú)法認識到微服務(wù)所帶來(lái)高效性。

? ? 在這種方式下，你對企業(yè)內部或云端的應用、中間件進(jìn)行持續部署、配置和管理。工具會(huì )提供端到端的腳本、自動(dòng)化和可視化圖表，并且監控所部署的應用的質(zhì)量、端口管理和彈性負載均衡。

? ? 持續發(fā)布/DevOps能夠通過(guò)Chef，Puppet和Docker之類(lèi)的自動(dòng)化工具進(jìn)行實(shí)施。你能夠在包括私有數據中心、虛機和云環(huán)境中部署你的微服務(wù)。每一個(gè)微服務(wù)的創(chuàng )建和部署都是獨立的。相比自編碼/腳本的DevOps腳本，你可以使用產(chǎn)品化的工具來(lái)進(jìn)行持續發(fā)布。成熟的產(chǎn)品提供很多開(kāi)箱即用的功能，大大提升工作效率。在大多數情況下，這些產(chǎn)品可以來(lái)自于與你使用的微服務(wù)架構相同的供應商，可利用大量的開(kāi)箱即用特性。然而，在你選擇產(chǎn)品是需要確認：他是一個(gè)能夠從其他供應商擴展的技術(shù)；支持與其他的自動(dòng)化工具和云架構服務(wù)的集成。

統一的管理

? ? 統一管理是一個(gè)良好的微服務(wù)架構的另一個(gè)關(guān)鍵因素。即使你使用不同的技術(shù)進(jìn)行微服務(wù)的開(kāi)發(fā)，確保你能夠在一個(gè)統一的界面中管理和監控所有的微服務(wù)。全面的可視化非常重要，否則將會(huì )發(fā)生“微服務(wù)混亂”。

? ? 要實(shí)現這一點(diǎn)，你不能夠將每一個(gè)微服務(wù)部署到不同的運行環(huán)境中。即便是使用微服務(wù)，你的項目也應該選擇一個(gè)可擴展的、容錯的、高性能的運行環(huán)境。即便是微服務(wù)的基本思想，我也不喜歡每一個(gè)開(kāi)發(fā)人員可以使用不同的開(kāi)發(fā)語(yǔ)言、框架和運行環(huán)境的想法。從長(cháng)期看，這樣的項目或者產(chǎn)品很難維護和保證SLA。如果你選擇一個(gè)云服務(wù)，必須有供應商能夠確保SLA。你不必考慮服務(wù)契約之后的技術(shù)和運行環(huán)境。然而，在你的項目中，你必須考慮SLA和可維護性。

需求6：跨服務(wù)的可見(jiàn)性

? ? 最后，在生產(chǎn)環(huán)境中進(jìn)行微服務(wù)的部署和運行之后，你可以結合來(lái)自于不同服務(wù)事件、上下文和洞察力，實(shí)現實(shí)時(shí)的感知與響應。相互關(guān)聯(lián)的事件是真正的力量，來(lái)自Google、Amazon和Facebook的證明毫無(wú)疑問(wèn)。

? ? 事件關(guān)聯(lián)是一項從大量事件和信息中精確定位幾個(gè)真正重要的事件的技術(shù)。盡管有一點(diǎn)離題，但這是各種來(lái)自于微服務(wù)、大數據、物聯(lián)網(wǎng)的數據的未來(lái)。因此，這個(gè)題目在這里非常重要。使用事件關(guān)聯(lián)的場(chǎng)景隨處可見(jiàn)，比如網(wǎng)絡(luò )監控、情報和監視、風(fēng)險管理、電商、欺詐監測、智能訂單路由、價(jià)格分析或者算法交易。

需要總線(xiàn)嗎？

? ? 事件管理是一個(gè)你確實(shí)需要總線(xiàn)的需求。然而，這個(gè)總線(xiàn)不是一個(gè)ESB，是一個(gè)(內存)事件服務(wù)器：

? ? 你從不同的源頭獲得事件(比如微服務(wù)、標準應用、遺留代碼)，并且在總線(xiàn)中進(jìn)行對他們進(jìn)行實(shí)時(shí)的關(guān)聯(lián)，并且主動(dòng)響應。

微服務(wù)是獨立的、可擴展的服務(wù)！

? ? 微服務(wù)是獨立的、可擴展的服務(wù)。一個(gè)使用可擴展平臺的現代架構，允許對不同的技術(shù)、服務(wù)、應用獨立的進(jìn)行自動(dòng)化部署。使用你選擇的工具進(jìn)行服務(wù)契約的定義，實(shí)施(微)服務(wù)和服務(wù)發(fā)現，獨立和可擴展的自動(dòng)部署。進(jìn)行不同(微)服務(wù)的協(xié)作，通過(guò)在內存中進(jìn)行事件關(guān)聯(lián)，實(shí)時(shí)進(jìn)行事件的主動(dòng)響應。這就是你怎樣去創(chuàng )建一個(gè)良好的微服務(wù)架構。