讓我們從面向服務(wù)架構(gòu)(SOA)和企業(yè)服務(wù)總線(ESB)的一點歷史開始，來看看為什么微服務(wù)變得如此流行。

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

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

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

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

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

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

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

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

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

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

? ? 讓我們定義一下術(shù)語“微服務(wù)”。就想你在上一節(jié)中看到的，應(yīng)用的設(shè)計、架構(gòu)、開發(fā)和運營都必須改變。企業(yè)需要建立一種服務(wù)策略來使它在不同的應(yīng)用當(dāng)中重用?？雌饋砣匀幌袷荢OA？的確，但是還有很多重要的不同：

? ?????? 沒有承諾一個特有的技術(shù)

? ? ?? ? 更加靈活的架構(gòu)

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

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

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

微服務(wù)的挑戰(zhàn)

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

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

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

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

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

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

服務(wù)契約

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

? ? ?? ? 從現(xiàn)有應(yīng)用暴露微服務(wù)

? ? ?? ? 服務(wù)發(fā)現(xiàn)

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

? ? ?? ? 管理復(fù)雜部署和擴展

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

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

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

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

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

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

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

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

需求2：從現(xiàn)有應(yīng)用暴露微服務(wù)

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

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

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

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

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

API開放和API管理

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

? ? 下圖是關(guān)于API管理的解決方案：網(wǎng)關(guān)、門戶和分析。

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

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

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

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

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

? ? ?? ? 狀態(tài)需要進行跨調(diào)用的共享時，更易于開發(fā)

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

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

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

? ? ?? ? 如果流程沒有很好的設(shè)計，會消耗更多的內(nèi)存

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

? ? ?? ? 沒有涉及的流程，狀態(tài)就無法被查詢

內(nèi)存數(shù)據(jù)網(wǎng)格

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

需求5：管理復(fù)雜部署和擴展

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

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

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

統(tǒng)一的管理

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

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

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

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

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

需要總線嗎？

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

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

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

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