隨著企業資訊化程度的不斷提高，越來越多的資訊系統逐漸上線，這些系統在為企業帶來效益的同時，也帶來了一些讓開發及維護人員頭痛不已的問題，主要表現在系統分散，資訊孤島，互動複雜，維護成本太高。
    多說無益，直接上乾貨，請看下圖：

 
假設現在有A、B、C、D、E、F、G 7個業務系統。
各系統均為獨立的業務系統，系統的開發語言、所使用的資料庫、所需要的執行環境也不盡相同。有些為自主開發，有些為外部採購。
根據業務需求各系統間需要有各式的資料互動。
為了更加直觀，現將其假設為華信內部常用的系統名稱。（實際上公司內部的系統要遠遠多於上述內容，並且關係更為複雜）。
舉例來說： 假設A系統為HR系統，系統B為OA系統、C為ERP系統等等。

為了與其他系統互動，各系統均提供webservice介面，用來接收處理資料。每個系統在傳送資料時需要呼叫其他系統的介面，以HR系統為例：當有新員工入職時，首先將員工資訊錄入到本地系統中，然後分別通知，PM、OA、CAPA、CRM等等系統，要求對方也同時追加該員工的相關資訊，並根據需要向其他系統返回相應資訊。於是一張密密麻麻的蜘蛛網就成型了。
直觀一點，我們看一下現在HR系統需要呼叫的介面：
編號    目標系統    資料方向    介面內容
1    PM    輸出    人員基本資訊、人員職位、人員組織。。。
2    OA    輸出    人員基本資訊、人員職位、人員組織。。。
3    ERP    輸出    人員基本資訊、人員職位、人員組織。。。
4    CAPA    輸出    人員基本資訊、人員職位、人員組織。。。
5    EMAIL    輸出    人員基本資訊、人員職位、人員組織。。。
6    CRM    輸出    人員基本資訊、人員職位、人員組織。。。
7    Consume    輸出    人員基本資訊、人員職位、人員組織。。。

既然有輸出，就一定還會有輸入，這裡就不再列舉。
每個系統都會提供很多的介面，可以想象，現在的資料互動這部分的複雜程度和程式碼量。對編碼人員和業務人員這都是一個很殘酷的考驗。每次新增一個系統或者改動某些現有業務就是一次噩夢。

現在我們需要改變，我們目標是：
以面向服務的方式，實現異構、分散式應用系統之間鬆散耦合的整合共享、互聯互通的訊息傳送平臺
直觀些，我們想要這樣的東西：

 

值得慶幸的是，之前的結構看起來雖然很亂，但是他們是基於SOA的。

現在重新梳理一下我們面對的問題和需求：
    多對多的資料交換，牽一髮動全身
    各業務系統的介面對外公開，安全性差
    業務邏輯多處重複，浪費開發資源
    難以進行的業務修改，無法快速推出新業務
    開發質量難以控制
    業務系統工作量很大
簡單說：我是一個業務系統，我不想同時和那麼多業務系統打交道，多了我會暈的，我只想跟一個系統有互動。舉個貼近生活的例子：我是名普通員工，我今天刷卡不好用了，你不能讓我分別去跟OA、PM、消費等等那些相關人員去打交道，我只想跟一個人說一遍，然後等候結果就行了。
這個中間的訊息平臺應該是什麼呢？沒錯，就是她ESB。

 
ESB的特點
1.    面向服務的架構 - 分散式的應用由可重用的服務組成；
2.    面向訊息的架構 - 應用之間通過ESB傳送和接受訊息；
3.    事件驅動的架構 - 應用之間非同步地產生和接收訊息；
ESB就是在SOA架構中實現服務間智慧化整合與管理的中介。
這簡直就是為了解決我的問題而生的東西。

現在看一看我們都需要做什麼：
1、    接收資料：接收各系統傳送過來的資料，這裡採用對外發布webservice的方式。
2、    處理資料：對接收的資料進行相應的轉換處理，以匹配不同的目標系統。舉例：A系統中的性別欄位中儲存的是0，1 而B系統中是男，女。
3、    傳送資料：根據業務規則將其傳送給相關係統，呼叫對方提供的服務。
 

現在看起來好多了。現在各業務系統只需要對外公開資料接收的服務就可以了。並且只需要呼叫ESB提供的一套webservice就可以，不用依次去呼叫每個系統的webservice。工作量大幅減少。為了讓ESB知道我的資料要傳送給那個系統，在ESB接收端有一個標識 TargetSystem用以標識目標系統。
好了，大家都很開心，但是，這樣做真的已經很好了嗎？我們通過對比來看一下。
    改造前    改造後
傳送資料    呼叫各系統提供的介面。    只調用ESB提供的介面。
接收資料    由自身提供    由自身提供
資料處理    業務系統自己處理    ESB統一處理
目標系統    按需直接呼叫對方介面    只需通知ESB
系統壓力    被呼叫時產生壓力    ESB接收端壓力巨大
日誌及錯誤    各系統自行處理    ESB處理
安全性    各系統間介面公開    介面僅對ESB公開
來一個實際的例子：
公司組織機構調整，此次涉及1000人，這些人不光人員組織資訊變動，還有職位資訊變動，還有部分人的基本資訊進行了變動（比如更換了手機號，增加了學歷資訊），此次資訊修改的發起者是HR系統，方式是在零時統一執行，接收方有10個系統。那麼未改造前HR會呼叫介面：1000人*3處變動*10個系統=30000次。
改造後HR會呼叫介面：1000人*3處變動*1個系統=3000次。
與此同時PM系統要對這些人所對應的專案資訊進行處理，並通知5個系統。假設平均每個人有2條專案資訊需要處理。那麼就是1000人*2處變動*5個系統=10000次呼叫。
改造後PM系統會呼叫：1000人*2處變動*1個系統=2000
變化非常的大，但是，但是。。。
改造後所有的壓力都轉到了ESB身上。上述兩步ESB的介面被直接呼叫了5000次。然後ESB再通過各種處理轉化，將這5000次的請求分別傳送到其他系統，系統的壓力非常大。並且這只是日常工作中的很常見的一種情況，很多時候，會有多個系統同時有大量資料的請求。ESB很容易因壓力過大而出現暫時停止響應的情況。
在安全性上，ESB的介面對外公佈，潛在的危險也很大。另外各個業務系統呼叫ESB介面時不瞭解ESB當時的壓力。如果某個業務系統出現bug，比如死迴圈呼叫，會導致ESB伺服器直接掛掉。各業務系統呼叫ESB介面的方式和錯誤處理方式都不同，很有可能造成許多未知的問題。當ESB停止響應時，所有業務系統都會報錯。在ESB尚未恢復期間可能有大量的資料丟失，且難以恢復。
另外一點，現在個業務系統都被動的被要求知道自己資料的流向，他必須知道我的資料要到達哪些系統，一旦有新系統或原有系統有變化工作量也很大。原則上，這不應該是業務系統本身應該考慮的問題。現在我們要把這個問題簡化，業務系統幹好自己該乾的事情，其他就不要操心了。
說了那麼多其實就是四點1、效能 2、安全性 3、容錯 4、資料流向處理
改進一下，解決上面的問題：
1、    效能：硬體支援。邏輯分層、物理分層。
2、    安全性：ESB接收資料由被動方式變為主動方式。
3、    容錯：統一業務系統的傳送端和接收端，業務系統端採用訊息佇列方式提供資料。
4、    資料流向：這個是業務問題，應該有專門的排程去處理，這部分功能加入到ESB中。

現在看一下改動過的效果：
 
傳送端元件：統一的資料傳送模式、統一的錯誤處理機制、日誌及其他。
訊息佇列：儲存業務系統需要傳送的資料，等待ESB的提取。
接收端元件：統一的接收模式、統一的錯誤處理機制、日誌及其他。
現在業務系統只需呼叫統一的元件即可。
再看ESB系統
 
收集服務：從各業務系統的獲取訊息佇列中獲取資料。
資料處理：根據需求進行資料的清洗、過濾、整合等等。
資料分發：根據規則將資料傳送到指定的業務系統中去。
以上三部分功能分別部署在三臺物理伺服器上，來提高各自的使用效率。
ESB由被動轉換為主動，現在我們可以根據ESB的負載情況來自動或手動的進行自我調節，甚至可以停止或啟用某些流程。某個業務系統出現問題，不會影響到其他系統的執行，ESB出現問題，業務系統也可以正常運轉，只是在ESB恢復正常之前他無法傳送或接收新的資料，當ESB恢復時，會自動將業務系統中的資料獲取併發送給相應目標。
下面給出一個相對完整的流程。
 
當然細節還有很多包括：
日誌記錄、錯誤處理、資料對映、流程管理、資料重發、規則管理等等。

經過上述改造，ESB系統已經可以輕鬆應對公司內部的各系統間的資料互動工作，由於將業務分發規則納入到系統中，可以動態的進行資料流程管理，各業務系統各司其職，系統開發和運維人員可以把精力完全投入在自身系統當中。系統的安全性、實時性、有效性和可擴充套件性都得到了很大的提高。






技術就像圍城：城外的人想進去，城裡的人真會玩！

BY      智商無下限

Mail:   [email protected]