ESB和SOA到底是什麼？

• 真相
• 怎麼去清理這一團糟的東西？
• 使用SOA架構，用ESB提供服務
• 但是要注意
• ESB是隻為銀行或者類似的應用服務的嗎？那麼？
• 但是我聽說SOA全部都是關于XML，SOAP和Web服務的
• 更多的内容

ESB和其相關縮寫SOA，是困惑之源。ESB是企業服務總線的縮寫，而SOA的意思是面向服務架構。 但這樣解析并沒有太多的内在含義。是以這裡盡可能的提供一些更多的資訊，而不是僅僅從企業的角度的來介紹ESB和SOA。

真相

假設一下你通過銀行前端的應用登入銀行，會發生什麼呢？

1. 會顯示你的名字
2. 會顯示你的賬号餘額
3. 會展示你的信用卡和借記卡

4. 會列出你的共同基金

   會列出一些你可能感興趣的，預先被計算好的，有吸引力收益的借貸産品

現在，很可能所有這些子產品都來自于不同的系統和應用，通過各種接口把資料展示出來（是HTTP?JSON? AMQP?XML? SOAP? FTP?CSV?都不重要）

1. 是來自在linux和Oracle的CRM系統
2. 是來自z/OS大型機的COBOL系統
3. 據說是來自大型機，但是他們的嘴巴很緊，不肯告訴你任何事情，隻提供CSV檔案。
4. 來自跑在Windows的混合着PHP和Ruby

5. 來自Postgresql，Python和Java，跑在Linux和Solaris的

   現在的問題是，你怎麼讓前端的應用跟1到5互動呢？ 直接通信嗎？ 不，你不會這樣做的，你不會讓他們直接對話的。

   為了讓在這樣的複雜的環境中還能保證通過增加一些系統進行擴充，不能直接通信。這是基本原則。

   在下圖，每條不同寬度或者樣式的線表示了app之間的調用

   

大家要注意到，我們還沒展示高優先級的程序呢。（比如應用1調用應用2 ，然後根據應用6的傳回成功與否來決定調用應用3或者應用5；如果應用1允許的話，應用4晚點還可以抓取從應用2生産的資料。 -_-||| ）。大家還需要注意到，我們說的是服務，不是伺服器。每個系統都可能跑在10台的實體機器上，那麼至少有60個實體部件需要互相通信。

還有一些顯而易見的問題：

怎麼分離接口？你的計劃怎麼展示？如果每個應用由不同的組去管理，怎麼去協調更新或者計劃中的停機時間？如果生産商或者部門一半的開發者都已經離開不在現場了咋辦？

如果你覺得，你解決6個應用沒有問題，那麼30個呢？

你可以處理400個嗎？2000個怎麼樣？每個應用都有自己獨特的生态系統，都需要用10個實體伺服器或者裝置跑在上面。是以，就好比有2萬個移動的群體散落在大陸上，并且有着各自的技術的或者文化的邊界。 所有這些群體彼此之間需要不斷的，持續的交換資訊，聊天，一刻也停不下來。

對這種情況，有個很好的名字，叫一團糟。

怎麼去清理這一團糟的東西？

首先，你得誠實的承認，事情已經發展到不可收拾的地步了。這樣子在找補救措施的時候，你會感覺到沒有那麼内疚。好吧，事情已經發生了，你不知道怎麼辦。但是，有個機會，這團糟東西可以被清理幹淨。

這意味着對IT系統要做一些結構上的變更。另外，我們還要回憶一下以前的經驗，系統和應用很少用來被建立成到處推送資料，他們是為了支援業務，無論你的業務是什麼東西：它可以是銀行業務，聲音記錄，無線電裝置或者其他任何東西。

一旦你有了這兩個清晰的了解， 你可以開始考慮建設或者重新設計你的系統服務。

服務是有趣的，能重用的，并且原子性的，它能提供為其他有需要的應用提供用途，但是它不會用點對點的方式直接暴露出來。我們盡可能給它最短的有意義的定義。

如果一個給定的功能系統要做成服務，需要滿足以下這三個條件：

1. 有趣 I nteresting
2. 可重用 R eusable

3. 原子性 A tomic

   是以，如果滿足這三個條件，他可以也應該以服務展示給其他系統，而不是直接相連。

   我們通過一些例子來讨論IRA方法

   

   

   

   

如果你在過去的50年或更長的時間裡面，做過程式開發，你會很明顯的了解，提供了一個服務，就類似于在代碼中提供一個API接口。

不同的是，你不是在處理單系統的子子產品，而是在處理整個分布式系統的某個層級。

使用SOA架構，用ESB提供服務

當你了解系統并不直接交換資訊，了解什麼是服務，那麼現在你可以開始使用ESB了。

ESB的工作就是提供和調用內建系統的服務。使用了ESB，在大多情況下，每個系統和ESB之間，隻需要定義一個通路方法，一個接口。如果這樣，像上面的表一樣，你有8個系統，就會有16個接口（1個方向1個）需要被建立、維護、管理和關注。

如果沒有ESB，你就需要56個接口需要去思考和處理。（假設每個系統都需要跟其他系統對話）少了40個接口意味着少花時間和金錢。這就是你周末不用那麼神經緊張的原因之一。

基于這個事實，你應該迫切地考慮需要引進ESB。

如果一個系統需要重寫，改變所有者，生産商或者部門分拆，這個是ESB的工作去處理這個變更。其他的系統都甚至不需要周知，因為他們與ESB的接口不變。

當你開始每天使用IRA服務，你可以考慮組合他們。

還記得上面的“把客戶所有資訊給我”的服務嗎？你最好不要去建立這樣的服務。雖然有時候你不得不處理用戶端應用需要內建和彙總這樣的資訊。

這将是ESB的責任，去選擇原子的服務組合成混合服務，提供給某些用戶端系統需要的特定的資料組合。

随着時間的推移，大家開始明白，不再有資料庫表、檔案、批處理、功能、程式或記錄。系統是架設在有趣的、可重用的、原子性的，由ESB提供的服務應用的架構之上。人們不會再考慮應用和系統之間直接傳遞東西。他們隻會考慮ESB作為統一的接入網關，提供可以使用的有趣服務。他們甚至不在了理會誰能夠提供什麼，他們的系統隻會關注ESB，處理與ESB相關的事情。

這需要時間，耐心和合作，但是這個是可行的。

但是要注意

毀掉SOA概念的最好的方法就是，推出ESB，就期待所有的事情自己順順利利。雖然ESB是一個了不起的想法，但很不幸，隻是簡單的安裝ESB不會解決你太多問題。最好的方法，你還是要打掃一下你的毛毯（整理一下你的架構）。

像下圖一樣，如果不打掃，即使用了ESB也得不到任何好處。

（如果如上圖建構你的系統），那麼你的it維護人員就會厭惡這個系統（ESB），管理層雖然一開始會容忍ESB，認為他作為一個新系統，總會出點小問題，但是後來它就會成為一個笑柄（系統難以維護）。“什麼？這就是你的新殺手锏？哈哈！”。如果ESB不是作為你IT大計劃中的重要組成部分來推動事情發展的，那麼這種結果不可避免。

ESB是隻為銀行或者類似的應用服務的嗎？那麼？

完全不是。隻要是需要多資料源和多通路方法合作去獲得一個有趣結果的情況，都是一個好的選擇。

例如，從熱傳感器讀取資訊，并且釋出到幾個通道去，比如email警告、iPhone應用。 這聽起來就是一個很好的內建應用平台場景。周期性的查詢和監控是否某個應用的所有執行個體都起來了沒有，跑一個預配置的腳本去發送文字資訊給管理者的應用場景聽起來也不錯。所有需要內建在一個幹淨的，定義好的環境，可能都是一個ESB服務的應用場景。但通常，判斷某個東西是否真的比對成一個服務則需要相關人員的經驗。當然了， Zato support 後面的團隊可以幫助到你。

但是我聽說SOA全部都是關于XML，SOAP和Web服務的

是的，這是某些人希望你這樣相信的。

如果你與某些使用BASE64編碼的CSV檔案，并且用SAML2保護的SOAP資訊來發送的人或者生産商一起工作，其實挺能了解為什麼你會有這樣的想法。

XML，SOAP和web服務有他們各自的用途，但是就像其他東西一樣，他們也可能被濫用。

SOA是一個關于幹淨的，可管理的架構。具體的某個服務用或者不用SOAP，其實是與SOA無關的。作為一個架構方法，即使你完全沒有SOAP服務在上面，SOA依然是有效的。比如一個建築師在設計一棟漂亮的建築，他們真的跟油漆勞工采用什麼顔色的油漆來處理内飾沒太大關系。

是以不是這樣的。 SOA不是關于XML，SOAP和web服務的，這些都能在SOA裡面使用，但不是SOA的主體。

我們鼓勵你友好地去指引你被誤導了的同僚去閱讀本文，使他們了解SOA的真正含義

更多的内容

這篇文章主要覆寫非常基礎的知識，但是能夠讓你明白ESB和SOA應該是怎麼樣的，以及如果要獲得成功需要做什麼。

這篇文章還不包含（不限于）以下的内容：

怎麼為ESB獲得管理層的支援

怎麼組織SOA架構師和分析團隊

在組織中引入規範資料模型

關鍵業績名額-你現在系統中有統一和通用的方法來提供服務，你應該監控和評估你的系統你收到了什麼

業務流程管理–什麼時候以及怎麼樣引入業務流程管理平台去協調各個服務（别太快，先熟悉怎麼搭建優秀的，優雅的服務）

如果沒有API的系統，應該怎麼做？比如ESB應該直接通路他們的資料庫嗎？（看情況，沒有黃金法則）

是以，Zato确切來說是什麼東西？

Zato 是ESB，并且服務都是用Python寫的。Zato它可以用來建構中間件和後端系統。它是開源軟體，有商業公司和社群支援。并且 Zato使用了Python，這個因為他的易用性和生産效率高而聞名的程式設計語言。使用Python和Zato意味着你有更高的生産效率，少花一些時間在麻煩事上。

Zato 是實用主義者寫給實用主義者的軟體。 他并不是那些在炒作ESB/SOA的生産商快速胡拼亂湊出來的系統。事實上，Zato來自于對上述一團糟的系統的救火經驗。Zato的作者花了太多的時間去處理這些災難性的的環境，才使他們不至于陷入困境。

是以，Zato就是這樣被設計出來的，它是應時而生的解決方案。這也是為什麼跟Zato類似的解決方案能提供高效的生産力和無與倫比的易用性的原因。

參考連結：https://zato.io/docs/intro/esb-soa-cn.html

說了這麼多其實是為了推銷自家的ESB産品Zato😂。