微服務=ESB的死亡?

Do Good Microservices Architectures Spell the Deat一文進行了分析，內容比較抽象羅嗦，以我個人理解的大意表達如下：

首先，看看EAI vs. SOA vs. ESB vs. Microservices幾個比較，許多年前，軟體廠商提供一種企業應用整合EAI中介軟體，稱為EAI broker或EAI backbone，這個中介軟體類似後端集中式Hub，隨著SOA開始興起，工具選擇變為ESB，許多廠商重新打包它們的EAI工具變為ESB，沒有什麼改變，後來，一些新的ESB產品出來，它們沒有集中Hub，而是分散式代理，這樣ESB能夠為不同的中介軟體服務，許多人不喜歡ESB這個詞語因為他們僅僅知道集中式HUB模型，對分散式模型不瞭解，今天，一些人開始談論NoESB，類似NoSQL，未來可能NoESB像NoSQL流行。

這樣，廠商們就儘量避免談論ESB詞語，它們不能再賣集中式整合中介軟體了，因為現在分散式如此靈活，今天你可以購買一個服務遞交平臺，未來可能是微服務平臺或類似平臺，在某些情況下，程式碼可能還類似於20年前的EAI broker，所有這些產品都有一個共性，就是解決企業整合問題，透過企業整合模式。

回顧整合市場過去，沒有看到任何性感新潮的名詞，與其將注意力放在架構特點上，不如問問你自己你需要解決的業務問題是什麼，然後再評估合適的架構和產品。

ESB會死嗎？
如今ESB不是時髦名詞，今天我們想到的是分散式 靈活可擴充套件的架構，你可以在雲中以更加敏捷有效方式構建 部署和監控應用。使用ESB是為了整合 指揮orchestration和路由事件處理 聚合和業務活動監控，你也能透過微服務構建應用，單獨彼此獨立部署這些服務，基於擴充套件性平臺對外一致的標準介面。

而ESB正好適合這樣的情況，ESB應該是適合面向(微)服務方式，而不是面向集中式ESB方式，可以稱為ESB 或者整合平臺，或者服務遞交套件 或微服務平臺，都可以。

ESB這些套件中介軟體扮演一個服務閘道器角色，負責安全 策略和暴露微服務作為開發API給消費者，服務閘道器管理你的整合服務，你的應用服務 外部雲服務。

關鍵問題是，我們真的需要這樣一個匯流排概念嗎？如果你想聚合來自不同的微服務，匯流排是有用的，將這些事件放入記憶體中，使得它們能夠實時可監控 分析和預測。

也就是說ESB和微服務不是敵人，而是工作在一起的朋友。

好的微服務特徵
需要從下面六個關鍵要求評估微服務：

1.服務合約Services Contract
2.從應用中暴露微服務
3.服務的發現
4.跨服務協調
5.管理複雜部署和它們的可擴充套件性。
6.跨服務的透明度

該文然後balabala逐條就這六個關鍵特徵來說明微服務和ESB的集合特點。