ESB和SOA是什麼？

ESB和SOA是什麼？

ESB Enterprise Service Bus(企業服務總線)
SOA Service Oriented Architecture(面向服務架構)

真相

想像在你登陸到你的銀行帳戶頁面時能夠看到什麼：

1. 顯示你的名字
2. 帳號餘額
3. 你的信用卡和借記卡列表
4. 基金列表
5. 你可能感興趣的優惠貸款

這些信息來自不一樣的系統和應用，每一條信息可能經過不一樣的接口取得，這些接口或數據多是 (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV, 但這並不重要)：

1. 來自一個運行在Linux和Oracle上的CRM系統
2. 來自一個在z/OS上的COBOL系統
3. 有可能只是給你個CSV文件，數據從哪來的你徹底不知
4. 來自一個部署在windows上的由PHP和Ruby混合實現的應用
5. 來自一個部署在 Linux和Solaris上的由PostgreSQL, Python和Java 實現的應用

如今的問題是：你怎麼來作個前端程序支持這5種途徑的數據？
參見下圖，各應用間的數據交互及調用關係能夠有多種形式（不一樣的連線）

更可怕的是上圖尚未描述各調用間的依賴關係，如(App1調用App2，App3，App5前須要使用調用App6時成功後返回的數據，以後App4採集App2的數據須要獲得App1的許可，等等，有點暈吧？)

每一個應用運行在10臺服務器上，那麼至少有60個組件之間要交互.
怎樣拆分接口？你怎樣按計劃上線？每一個應用由不一樣的廠商，部門或團隊管理時怎樣協調更新或維護，並且是在最初的開發人員已經走了一半的狀況下

即便你能處理好6個應用，那麼30個應用呢？以下圖：

增長到400個，2000個呢？每一個應用可能須要運行在10臺服務器或其它設備組成的系統環境中，這樣就有20K臺服務器，加上應用能夠是跨行業的，可能使用了各類不一樣的技術實現，全部部件不停的交換消息，並且永遠沒有中止的時候。
這種場景有個好的名字，稱爲混亂(mess)

你怎樣清理這種混亂局面

先得認可這種狀況已經失去了控制，沒必要感到內疚，已經這樣了，這裏有個方法可能能夠清理這種局面。

由IT部門着手處理這種局面，明確一點，不管是銀行，錄音，定位設備或其它業務，系統和應用只是圍繞着數據來轉。

你可能圍繞着這些服務開始思考構建或重構大家的系統，一些服務在受關注的 ，可重用，原子性方面作得比較好，其它應用能夠很好的使用，可是沒有提供點對點的方式，這是最短的有意義的定義。

若是一個系統的功能知足這3點要求：

• I nteresting（受關注的）
• R eusable（可重用）
• A tomic（原子的）

那麼做爲給其它系統使用的一項服務已經作得很是好了，雖然不直接。

咱們經過幾個示例來討論IRA:

Variable	Notes
環境	一個電力公司的CRM
功能	返回2012年第三季度自助服務門戶 系統中活躍的客戶列表
受關注嗎？	很是有用，可能用來生成各類有用的報表和統計數據
可複用嗎？	不行，雖然你能夠設計成獲取全年的數據，但到2018年你是不會須要查看這項數據了吧
原子的嗎？	極有可能啊，若是還有其它季度相似的服務，總部須要這些數據來統計整年的狀況
怎樣設計成IRA?	*用起止時間代替某一季度. *容許接收一個參數表達某種應用，而不是把自助服務門戶硬編碼到系統中

Variable	Notes
環境	電子商務網站
功能	返回以前收集到的給定用戶的全部信息
受關注嗎？	有用，你總能從完整信息中挑出你真正須要的那部分
可複用嗎？	可能吧，若是你想獲得用戶的全部信息，但多數狀況下你只是想取其中的部分信息
原子的嗎？	不是的，這個巨大的函數必然由幾十個較小函數組成
怎樣設計成IRA?	* 拆分得小一點，想一下怎麼描述一個客戶，每一個客戶有地址，聯繫方式，依賴的服務等等 *完整信息 放在ESB中實現

Variable	Notes
環境	任意CRM系統
功能	在創建一個帳號時更新C_NAZ_AJ表的CUST_AR_ZN列
受關注嗎？	這是CRM的內部函數，沒有誰想要處理如此低級別的函數
可複用嗎？	看上去是能夠重用的，帳號可以經過多種渠道創建
原子的嗎？	彷佛是的，只是簡單的更新一個表裏的一列
怎樣設計成IRA?	不要試圖將這個函數放到服務裏，業務上不關心這個接口，沒人想要知道系統內表和列的相關細節。因此即便知足 reusable 及atomic，你也不能夠將其加入對外的服務中，該功能由CRM 內部負責，別想着有誰能夠分擔這個責任。

Variable	Notes
環境	一個移動電話公司
功能	在計費系統中給預付費卡充值
受關注嗎？	頗有用啊，每一個人都會去使用，經過短信，語音服務中心，官方網站等等。
可複用嗎？	該功能能夠集成到各類高級別的流程中
原子的嗎？	是的，從調用應用的角度看，由計費系統經過一系列不相關的步驟來實現。從業務角度看，是計費系統提供的一項服務
怎樣設計成IRA?	已是IRA了

若是你50年左右的編程經驗，如今你能清晰精確的知道應該暴露給其它系統什麼樣的API.僅有的區別在於你不用處理單個系統的模塊，你會站在多種不一樣的系統的高度來考慮問題。

在SOA,ESB上構建可用的服務

你明白了系統間不能直接交換信息以及每一個服務是作什麼的，那麼你能夠開始使用ESB構建了。

如今ESB的任務是展現以及調用服務，大多數狀況下，在系統和ESB間只須要定義一個訪問方法，一個接口。
如上圖所示，你有8個系統，16個接口（方向不一樣）負責創建，維護，管理
若是不使用ESB你就須要（7*8）56個接口來處理（每一個系統都要和其它系統交互）

更少的接口能夠省時省錢。這個事實應該足夠讓你考慮引入ESB了吧。

若是一個系統經歷太重寫，更換開發團隊，部門或廠商，引入ESB能夠處理好這些變化。沒有其它系統會注意到這些變化 ，由於其它系統只和ESB打交道。

當你在平常工做中就是基於IRA的，你能夠開始思考整合

還記得上文提到的「給我你能給的這個客戶的全部信息」嗎？
這樣作很差但你有時會有這種需求，引入ESB後的作法是在ESB中整合這些數據返回給客戶。

隨着時間的推移，整個公司開始明白不必瞭解數據庫中的表、文件、批處理、函數、路由或記錄。只須要知道這是由ESB架構集中提供的符合IRA的服務。

再也不有人思考應用或系統發送一些東西從一個到另外一個。他們只要知道ESB做爲統一訪問網關提供了他們感興趣的接口，他們再也不困擾接口由誰提供，他們只須要和ESB打交道。

全部這一切須要時間，耐心和協調能力，最重要的是的確可行。

注意事項

一個最大的錯誤是覺得引入SOA,ESB後因此問題會本身消失。想法很好，但只是簡單的安裝ESB並不會解決問題。

舉個最好的例子，把髒東西掃到地毯下面，像下面的圖這樣，將什麼問題也解決不了。

管理部門剛開始還能容忍ESB,由於這是個新事物，但慢慢的這會成爲一個笑柄「這是新的銀彈？哈哈哈」
若是ESB不作爲項目計劃中的一部分，這樣的後果就不可避免。

ESB只適用於銀行類行業嗎？

不是的。只要是須要使用多數據源以及多個訪問方法一塊兒獲取感興趣的結果狀況下ESB都是不錯的選擇。

例如，獲取熱傳感器上最新的數據並經過幾種不一樣的方式發佈，如E-mail告警，通知IPhone app，就像一個聚合平臺那樣。

按期採集和監視關鍵應用的全部實例是否可用，若是當機了，除了發送短信給管理員還執行一個預先定義好的腳本。

全部東西都須要整合在清晰，定義良好的環境中，這對實現ESB頗有用，這作起來不少時候是靠經驗，但在Zato後的團隊能夠幫助你。

我據說的SOA都是些XML,SOAP和web services

是的，這是某些人給你的感受。
若是你的工做是將CSV文件用BSAE64編碼的而後經過安全的SAML2 SOAP消息取回來，這很容易理解，你可能以前就作過

XML,SOAP和web service有他們的用途，但也和其它東西同樣，可能被濫用 。

SOA是一個乾淨的和可管理的架構。 一個服務使不使用SOAP都可有可無。做爲一個架構的方法，即便沒有SOAP，SOA仍然有用。

若是一個設計師設計一座漂亮的建築，在室內粉刷顏色選擇上不會做出要求。

因此，你能夠在SOA中使用XML,SOAP和web services這些技術，但這不是SOA的所有

建議你引導你的同事閱讀這篇文檔，讓他們明白真實的SOA。

更多的內容

這一章涉及的內容是最基本的，僅在讓你更清楚的明白ESB和SOA是什麼。

下面列出沒有覆蓋的其它主題，包涵但不限於：

• 管理ESB時怎樣獲取相關支持
• 怎樣培養SOA架構師及分析團隊
• 在組織中引入典型的數據模型（CDM）
• 關鍵績效指標（KPI），如今你有一套統一的提供跨系統服務的方法，你應該開始監視和評價真正交付給你的是什麼
• 業務流程管理(BPM)，怎樣及什麼時候選擇一個BPM平臺去編排這些流程（回答-不用太早，等你先熟悉怎樣去構建漂亮可敬的流程後再說）
• 當系統沒有提供API時怎麼作？例如，由ESB直接訪問他們的數據庫（回答-視狀況而定，這裏沒有都適用的方法）

那麼，Zato究竟是什麼？
Zato是一個由Python實現的ESB和應用服務器，可以用來構建中間件和後端系統。他是一款開源的商業軟件，提供商業支持。Python是一種著名的編程語言，很容易使用而且很高效。

使用Python和Zato意味着你能更高效以及在麻煩的事情上花費更少的時間。

Zato由實用主用者開發，不是由其它系統打補丁而成，也不是由某廠商炒做ESB/SOA概念所做

事實上，Zato誕生於解決一些系統中緊急問題的實際經驗，真的，在這以前Zato做者花費了大量時間處理惡劣環境中的問題，而如今能夠對這些問題免疫了。

這樣的環境造就了Zato以及其與其它相似解決方案不一樣的無與倫比的高效率和易用性。