ESB和SOA到底是什麼？
一個關於系統的系統思維方式的優秀表述,
Nick Coghlan核心Python開發者如是說。
Translated from English by kenxinlee.
Also available in Català, Deutsch, Français, italiano, Português, Türkçe and ру́сский.
ESB和其相關縮寫SOA，是困惑之源。ESB是企業服務總線的縮寫，而SOA的意思是面向服務架構。 但這樣解析並沒有太多的內在含義。所以這裏儘可能的提供一些更多的信息，而不是僅僅從企業的角度的來介紹ESB和SOA。
真相
假設一下你通過銀行前端的應用登入銀行，會發生什麼呢？
- 會顯示你的名字
- 會顯示你的賬號餘額
- 會展示你的信用卡和借記卡
- 會列出你的共同基金
- 會列出一些你可能感興趣的，預先被計算好的，有吸引力收益的借貸產品
現在，很可能所有這些模塊都來自於不同的系統和應用，通過各種接口把數據展示出來（是HTTP?JSON? AMQP?XML? SOAP? FTP?CSV?都不重要）
- 是來自在linux和Oracle的CRM系統
- 是來自z/OS大型機的COBOL系統
- 據說是來自大型機，但是他們的嘴巴很緊，不肯告訴你任何事情，只提供CSV文件。
- 來自跑在Windows的混合着PHP和Ruby
- 來自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系統要做一些結構上的變更。另外，我們還要回憶一下以前的經驗，系統和應用很少用來被創建成到處推送數據，他們是爲了支持業務，無論你的業務是什麼東西：它可以是銀行業務，聲音記錄，無線電設備或者其他任何東西。
一旦你有了這兩個清晰的理解， 你可以開始考慮建設或者重新設計你的系統服務。
服務是有趣的，能重用的，並且原子性的，它能提供爲其他有需要的應用提供用途，但是它不會用點對點的方式直接暴露出來。我們儘可能給它最短的有意義的定義。
如果一個給定的功能系統要做成服務，需要滿足以下這三個條件：
- 有趣 I nteresting
- 可重用 R eusable
- 原子性 A tomic
因此，如果滿足這三個條件，他可以也應該以服務展示給其他系統，而不是直接相連。
我們通過一些例子來討論IRA方法
| Variable | Notes |
|---|---|
| 變量 | 備註 |
| 環境 | 電力公司CRM系統 |
| 功能 | 在自己的門戶中返回在2012年Q3所有客戶信息 |
| 有趣嗎？ | 是的，能夠生成各種有用的報表和統計數據 |
| 能重用嗎？ | 不，雖然它可以統計整年的數據，但是很顯然，2018年是用不上這玩意的 |
| 原子嗎？ | 非常像，如果每個季度都有類似的模塊，那麼就可以有一整年的視圖。 |
| 怎麼讓它IRA？ |
|
| Variable | Notes |
|---|---|
| 變量 | 備註 |
| 環境 | 電子商務網站 |
| 功能 | 返回某個給定客戶收集過的每個商品信息 |
| 有趣嗎？ | 是的。當你進入網站，你總是能夠找到你想要的東西 |
| 能重用嗎？ | 足夠有趣，但不是精確的能重用。因爲基本上沒有其他應用關注裏面的數據 |
| 原子嗎？ | 一點也不，這個龐然大物的功能在邏輯上是有幾十個小部分組成的 |
| 怎麼讓它IRA？ |
|
| Variable | Notes |
|---|---|
| 變量 | 備註 |
| 環境 | 任何地方的任意CRM |
| 功能 | 在創建賬戶以後，更新表C_NAZ_AJ 的CUST_AR_ZN 字段 |
| 有趣嗎？ | 當然不是，這是CRM的內部函數，沒有人想要用這麼低層次的功能。 |
| 能重用嗎？ | 可能。通過多渠道創建賬戶的時候，有些東西是可以重用的 |
| 原子嗎？ | 看起來是，只是一個簡單的更新表的行爲 |
| 怎麼讓它IRA？ | 不要嘗試去把他變成一個服務，他並不有趣。沒人願意去考慮特定的列和表，這是CRM錯綜複雜的細節。所以即使它是一個可重用的，原子性的，你也不應該用它來做服務。這是你（CRM）的責任去考慮，不要讓別人去背這個責任。 |
| Variable | Notes |
|---|---|
| 變量 | 備註 |
| 環境 | 移動電話運營商 |
| 功能 | 給預付費卡充值 |
| 有趣嗎？ | 當然，每個系統都想用它。通過文本信息，語音信息，即時信息，門戶，禮物卡等 |
| 能重用嗎？ | 是的，他可以提供給任何其他高級的服務。 |
| 原子嗎？ | 是的，從調用方看，他提供充值成功或者充值失敗的結果。賬務系統會把調用結果作爲一些步驟其中的一步。從商業透視的角度看， 他是不可見的服務，提供接口給賬務系統調用。 |
| 怎麼讓它IRA？ | 已經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類似的解決方案能提供高效的生產力和無與倫比的易用性的原因。
