原文鏈接：https://www.voxxed.com/blog/2015/01/good-microservices-architectures-death-enterprise-service-bus-part-one/
品牌和營銷：EAI vs. SOA vs. ESB vs. 微服務
讓我們從面向服務架構(SOA)和企業服務總線(ESB)的一點歷史開始，來看看爲什麼微服務變得如此流行。
很多年以前，軟件供應商提供了一種用於企業應用集成(EAI)的中間件，通常叫做EAI Broker或者EAI Backbone，這個中間件是一個集中式樞紐。當時，SOA剛剛興起，所選擇的工具是ESB。很多軟件供應商就將他們的EAI工具直接更名爲ESB。一段時間之後，一些新的ESB出現了，不再使用集中式樞紐，而採用分佈式代理。所以，ESB成爲一種不同的中間件。很多人不喜歡“ESB”這個術語，因爲他們只知道集中式的概念，而不知道分佈式的概念。
因此，軟件商經常避免談論ESB。他們無法再銷售一個集中式的集成中間件，因爲一切都變的分佈和靈活了。現在，你可以購買一個服務發佈平臺。未來，它可能是一個微服務平臺或者類似的東西。在某些情況下，代碼庫可能仍然與20年前的EAI Broker相同。所有這些產品相同的地方是，你能夠通過實現“企業集成模式”來解決集成問題。
總結一下集成產品的品牌與營銷歷史：不要關注那些性感、動人、好聽的名字！優先關注它的架構和特性。問問你自己，你需要解決什麼樣的業務問題，評估那種架構和產品最適合你。當我們再提“ESB”的時候，不要只想到“集中式的ESB”了。
企業服務總線(ESB)之死?
本文的關鍵：ESB是否已死？答案明顯是“否”。然而，ESB不再是整個企業中一個集中式，缺乏靈活行的集成主幹。現在我們聽到“ESB”，應該想到一個靈活的、分佈式的、可擴展的基礎架構，你可以使用一種敏捷、搞笑的方式創建、部署、監控各種各樣的(微)服務。開發和部署既可以在企業內部，也可以在雲端，或者採用混合方式(比如，使用雲做短期測試環境或者處理服務消費的峯值。)
你使用ESB做它所擅長的一些事情：集成、編排、路由、(或者類似)事件處理/協作/業務活動監控。你也可以通過(微)服務創建應用，實現你的需求或者解決你的業務問題。你還可以自動化的通過一個標準化的接口將這些服務彼此獨立的部署到一個可擴展的運行平臺。這些服務是鬆耦合的並且能夠跨越不同的硬件線性擴展。
這是我所理解的當今的ESB。ESB是處理這些需求的最好的工具。你只需要聰明的使用ESB，比如通過面向服務的方式，而不是面向ESB(集中)的方式。可以稱它爲ESB，集成平臺，服務發佈套件，微服務平臺，或其他你想叫的。
此外，對於這個工具(仍稱之爲ESB)，你可以使用服務網關提供服務安全，服務策略執行和暴露(微)服務作爲開放API給外部消費者。服務網關管理你的集成服務(通過你的ESB創建)，你的應用服務(通過ESB或者其他技術創建)和外部雲服務(你不需要關心他們如何創建，你只需要關心服務契約)。
還有一點：你真的需要“總線”之類嗎？如果你需要關聯不同的(微)服務中發生的事件，總線是有意義的。將這些事件放入內存當中，讓他們對實時監控、分析和預測行爲可見。後面給將有關於這個話題更詳細的信息。對於我所理解的現代ESB，我已經討論論的微服務。所以，你可以看到，ESB和微服務不是敵人，是朋友和合作伙伴。
“微服務”的定義
讓我們定義一下術語“微服務”。就想你在上一節中看到的，應用的設計、架構、開發和運營都必須改變。企業需要建立一種服務策略來使它在不同的應用當中重用。看起來仍然像是SOA？的確，但是還有很多重要的不同：
- 沒有承諾一個特有的技術
- 更加靈活的架構
- 具有自己生命週期的服務管理產品
- 工業化部署
這是微服務時代的開始：服務實現一組有限的功能；服務的開發、部署和擴展相互獨立。這讓您能夠獲得更短的實施時間和提升靈活性。
微服務的挑戰
微服務具有很多優勢，但是它仍然面臨了一些挑戰：
- 所有這些服務都需要繼承
- 所有這些服務和技術需要自動化的部署和配置
- 所有這些服務需要日誌記錄和監控
- 所有這些服務需要混合部署
所以，現在忘記那些關於產品的討論吧。考慮你需要創建的微服務的架構。之前的章節提到的六個關鍵需求能夠克服這些挑戰並且充分發揮微服務的價值：
服務契約
- 服務契約
- 從現有應用暴露微服務
- 服務發現
- 跨服務的協同
- 管理複雜部署和擴展
- 跨服務的可見性
不論你使用的是ESB、服務發佈平臺或者“僅僅”自定義的源代碼，在你未來的項目中，爲了創建一個敏捷、靈活和高效的微服務架構，必須遵循了下面列出的六個需求。
需求1：服務契約
服務契約是分佈式、獨立服務世界的頭號需求。服務提供者使用契約發佈服務的使用目的和需求。其他開發人員可以很容易的訪問這些信息。
在SOA世界中，契約隨着SOAP接口定義。SOAP仍然是一種很好的進行內部通訊的標準，它提供了很多的安全標準。此外，工具也爲最重要的WS-*標準比如WS-Security或者WS-Policy提供了很好的支持。
在微服務世界，REST成爲實際的標準，原因不是因爲更好的性能，而是簡單、關注分離、無狀態和統一接口的良好架構。尤其是針對移動設備和物聯網，是兩種主要的微服務驅動者。
你也可以用REST使用不同的數據格式，比如，你可以選擇JSON和XML。輕量級的JSON格式更適合於移動設備，XML是更好的企業應用選擇。你可以定義模式，使用低效但是成熟的工具進行轉換和驗證。性能在過去一直都是對XML的爭議。使用現在更強大的商業服務器和內存計算，這個在很多場合都不再是大的問題。
通訊通常都會使用HTTP。儘管HTTP在很多情況下不符合“現代應用場景”的規模。消息發送標準，比如JMS，是事件驅動企業的一個很好的選擇。WebSocket、MQTT和其他的標準也在與數百萬的設備通訊中脫穎而出，成爲物聯網的重要需求。因此，你的微服務架構能否在不進行服務重建的情況下，支持不同的數據格式和傳輸協議，成爲非常重要的標準。
需求2：從現有應用暴露微服務
大多數企業業務仍然存在於已有應用當中。他們需要將這些應用的功能與外部服務或者他們自己的微服務進行融合。因此，集成成爲微服務的基礎。你既可以創建全新的服務，也可以將已有應用的功能暴露成微服務。這些功能可以是API，一個內部服務或者一些遺留源代碼。
隨着時間的推移，微服務可以在不同的上下文中被重用，並且滿足不同的通訊需求。將傳輸邏輯從服務邏輯中分離是一項在微服務中至關重要的最佳實踐。當創建微服務的邏輯時，你不需要考慮服務如何實現與端點的通訊——是一個企業級服務(XML/SOAP)、雲服務(XML/HTTP)、移動設備(JSON/HTTP)、或者一個物聯網設備(底層TCP、MQTT，或者專有協議)
需求3：服務發現
服務契約很重要。然而，你也必須能夠發現和使用別人的服務。服務必須通過一個服務網關發佈。服務網關執行消費契約，確保微服務的垂直擴展和可靠性，並且允許微服務在不經過變更的情況下，在多個上下文中重用。
服務網關使微服務有效。它使用開放的標準，比如SAML,Kerberos,OAuth，WS-*或者XACML——取決與你的需求。此外，開發人員需要一種簡單的方式去發現微服務和他們的契約。通常，會使用一個自服務的門戶，來提供服務目錄和契約信息。
API開放和API管理
談論微服務至今，你應該已經知道大多數供應商沒有討論過他們在上下文中的服務發現，但是會包括API，API開放和API管理。像ESB僅僅是一個術語一樣，不管你叫它“微服務註冊”，“API管理”或者其他什麼東西。真正相關的是業務問題如何解決，它的需求和良好的架構。
下圖是關於API管理的解決方案：網關、門戶和分析。
需求4：跨服務的協同
微服務和他們的粒度對於服務的開發和維護非常理想。但是它也確實增加了應用本身的複雜度。那些應用無法管理他們在平臺中經常使用的受限制資源(電池、網絡、CPU)的複雜性。結合服務爲滿足應用目的和業務流程的高層邏輯，能夠證明開發的快捷和維護的簡易。
圖形化工具能夠用於創建微服務，但是也能夠便捷高效的創建組合服務：
微服務的協作能夠採用不同的方式實現：有狀態或者無狀態；服務或事件驅動。在大多數情況下，無狀態是單個服務的最佳實踐，一些特殊的協作/組合服務有可能更適合有狀態流程。
有狀態流程的優勢：
- 狀態需要進行跨調用的共享時，更易於開發
- 不需要外部持久化存儲
- 通常會對低延遲優化
有狀態流程的劣勢：
- 如果流程沒有很好的設計，會消耗更多的內存
- 沒有強制開發人員設計流程狀態
- 沒有涉及的流程，狀態就無法被查詢
內存數據網格
在很多應用場景中，上下文/狀態的改變需要作爲事件在內存數據網格進行共享，以大幅提升性能和降低發佈的延遲。非常重要的一點是要理解內存網格不僅僅能夠在內存中緩存和存儲數據。未來內存計算的特性是事件處理、發佈/訂閱、ACID(原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）)交易，條件查詢和容錯。
需求5：管理複雜部署和擴展
服務對於上下文的使用將會大不相同。服務需要快速的擴展。自動化是微服務開發敏捷、靈活、高效的關鍵。沒有持續集成/持續發佈(DevOps)，你無法認識到微服務所帶來高效性。
在這種方式下，你對企業內部或雲端的應用、中間件進行持續部署、配置和管理。工具會提供端到端的腳本、自動化和可視化圖表，並且監控所部署的應用的質量、端口管理和彈性負載均衡。
持續發佈/DevOps能夠通過Chef，Puppet和Docker之類的自動化工具進行實施。你能夠在包括私有數據中心、虛機和雲環境中部署你的微服務。每一個微服務的創建和部署都是獨立的。相比自編碼/腳本的DevOps腳本，你可以使用產品化的工具來進行持續發佈。成熟的產品提供很多開箱即用的功能，大大提升工作效率。在大多數情況下，這些產品可以來自於與你使用的微服務架構相同的供應商，可利用大量的開箱即用特性。然而，在你選擇產品是需要確認：他是一個能夠從其他供應商擴展的技術；支持與其他的自動化工具和雲架構服務的集成。
統一的管理
統一管理是一個良好的微服務架構的另一個關鍵因素。即使你使用不同的技術進行微服務的開發，確保你能夠在一個統一的界面中管理和監控所有的微服務。全面的可視化非常重要，否則將會發生“微服務混亂”。
要實現這一點，你不能夠將每一個微服務部署到不同的運行環境中。即便是使用微服務，你的項目也應該選擇一個可擴展的、容錯的、高性能的運行環境。即便是微服務的基本思想，我也不喜歡每一個開發人員可以使用不同的開發語言、框架和運行環境的想法。從長期看，這樣的項目或者產品很難維護和保證SLA。如果你選擇一個雲服務，必須有供應商能夠確保SLA。你不必考慮服務契約之後的技術和運行環境。然而，在你的項目中，你必須考慮SLA和可維護性。
需求6：跨服務的可見性
最後，在生產環境中進行微服務的部署和運行之後，你可以結合來自於不同服務事件、上下文和洞察力，實現實時的感知與響應。相互關聯的事件是真正的力量，來自Google、Amazon和Facebook的證明毫無疑問。
事件關聯是一項從大量事件和信息中精確定位幾個真正重要的事件的技術。儘管有一點離題，但這是各種來自於微服務、大數據、物聯網的數據的未來。因此，這個題目在這裏非常重要。使用事件關聯的場景隨處可見，比如網絡監控、情報和監視、風險管理、電商、欺詐監測、智能訂單路由、價格分析或者算法交易。
需要總線嗎？
事件管理是一個你確實需要總線的需求。然而，這個總線不是一個ESB，是一個(內存)事件服務器：
你從不同的源頭獲得事件(比如微服務、標準應用、遺留代碼)，並且在總線中進行對他們進行實時的關聯，並且主動響應。
微服務是獨立的、可擴展的服務！
微服務是獨立的、可擴展的服務。一個使用可擴展平臺的現代架構，允許對不同的技術、服務、應用獨立的進行自動化部署。使用你選擇的工具進行服務契約的定義，實施(微)服務和服務發現，獨立和可擴展的自動部署。進行不同(微)服務的協作，通過在內存中進行事件關聯，實時進行事件的主動響應。這就是你怎樣去創建一個良好的微服務架構。