關於企業管理系統集成那些事

咱們處於惡性循環中，不能自拔

　　咱們在努力，一直在努力向前奔跑，但隨着日積月累的承載，咱們跑不動了，並非咱們偷懶了，而是咱們肩負着太多、太多。該停下來，停下來思考了。

　　部門經理來了，怎麼回事？爲何系統又奔潰了，大家的年終獎別想要了。該停下來，停下來思考了。

　　客服反應，大家的系統讓用戶焦慮了，我成了出氣筒，我不幹了。該停下來，停下來思考了。

　　是啊，以上的種種，時常在咱們身邊演繹着，做爲架構師，做爲項目經理，做爲研發人員，做爲測試人員的你、你還有你，該停下來，停下來好好思考了。。。

1、案發現場，事件回放

咱們不是故意的，咱們很努力在作

　　上圖是我從早期系統中抽出來的三個子系統，卻很好的暴露了問題。系統很脆弱，一碰就碎，需求稍微一變更，咱們就得抓狂。

　　上圖中，咱們應變信息孤島主要採用的技術手段：

　　一、數據庫視圖

　　二、Web服務（RPC，RESTful）

　　問題來了：

　　一、沒有標準，服務滿天飛，很差管理，沒法重用，並且各類技術交叉使用，混亂；

　　二、系統間耦合度高，一個系統奔潰，另外一個系統也罷工了，一個系統對另外一個系統依賴性很強。

　　三、系統間業務缺乏原子性操做，老是發生莫名其妙的錯誤，老是多些莫名奇妙的數據，更重要的是，一筆錯誤的業務數據，給企業帶來的災難，比沒有數據更大；

　　四、不穩定、沒有容錯能力，用戶提心吊膽地使用，一錯就得重來，沒有商量的餘地；

　　五、擴展性差，業務需求變更，大改特改，系統遇到性能瓶頸時，沒法橫向擴展；

　　六、異常很難跟蹤，錯誤發生了，每每須要投入大量的人力、物力，成本直線上升；

　　七、系統間是透明的，團隊間協做開發，必須進行大量溝通、會議，才能確保對接接口正常工做；

　　八、咱們對研發人員要求過度了，咱們的研發人員既要掌握數據庫方面的技術，又要去研究Web服務技術。過度，學、學、學吧；

　　好吧，給用戶添了這麼多堵，咱們很抱歉，咱們積極改善。

2、轉變

　　若是，若是公司業務再也不變化，若是用戶仍是那麼具備耐心、好的脾氣，那麼，那麼咱們一直這樣，也不會出現大的紕漏。好吧，咱們就等着失業吧，沒有咱們，系統也能跑下去。或許，咱們應該感謝業務的變更，這樣咱們纔有機會停下來思考，去彌補不足。

　　2012年，企業發生了重大的事件，與同行業另外一家公司合併了，現有的系統已經遠遠不能知足業務變動了。原本還滿心歡喜，坐等加薪的心情，一下晴天霹靂了。很明顯，內部錯綜複雜的系統很難去適應如此傷筋動骨的變更了，即便慢慢來，那也是一動百動，牽一髮而動全身。怎麼辦？想辦法。

　　其實，咱們已經有一個好的轉變，早期項目，採用的是數據庫視圖來解決系統間集成，然後期的項目則採用了Web服務，儘管，只是向前跨了小小一步，沒起到多大做用。視圖，若是僅僅是用來與第三方系統作數據對接，還能應變自如，但當大量系統間發生業務往來，這時，只能望而生畏，況且還有個不一樣數據源需求在那窺視着。Web服務在系統集成方面起了很大做用，你只要發佈個服務，遵循協議下，則能夠很好地作到多個系統交互，處理相關的業務。

3、應對之道

咱們已經迷失了方向

　　正如上圖所示，咱們應用了Web服務，解決了多個系統間的業務集成問題，但隨着業務增加，項目成長很快，咱們的web服務出現於各個業務系統中，他們不受制約，他們開始橫行鄉里，從而致使系統結構錯綜複雜，超出管控。

　　咱們該作點什麼了，管理好咱們的服務，得讓他們認識到法律，奉公守法。

什麼表情，也阻止不了咱們的決心

　　服務到處見，凌亂不堪，若是咱們遷移了一臺系統服務器，會發生什麼？其餘系統找不到調用服務了，改下注冊服務的配置文件就行，分分鐘的事。是這樣嗎？哪些系統調用了這個服務？這些操做，人爲去作，想不出錯，很難。

咱們一直都在

　　咱們須要一種機制，一種可以統一管理服務的機制。咱們不用去關心服務最終會部署到哪裏，不用關心服務如何被調用，換言之，咱們只應向外發佈一些的消息，或者訂閱咱們關心的信息，其餘的全部一切，都應該讓這個機制幫助咱們去處理。終於能夠撥開雲霧見月明瞭，上面所描述機制的產物，他有一個名字，叫ESB。

　　ESB全稱爲Enterprise Service Bus，即企業服務總線。它是傳統中間件技術與XML、Web服務等技術結合的產物。ESB提供了網絡中最基本的鏈接中樞，是構築企業神經系統的必要元素。ESB的出現改變了傳統的軟件架構，能夠提供比傳統中間件產品更爲廉價的解決方案，同時它還能夠消除不一樣應用之間的技術差別，讓不一樣的應用服務器協調運做，實現了不一樣服務之間的通訊與整合。從功能上看，ESB提供了事件驅動和文檔導向的處理模式，以及分佈式的運行管理機制，它支持基於內容的路由和過濾，具有了複雜數據的傳輸能力，並能夠提供一系列的標準接口（引用自百科）。

　　看完定義，咱們知道，ESB應該具有提供可靠消息傳輸、服務接入、協議轉換、數據格式轉換、基於內容的路由等功能。在此基礎上，咱們的業務功能可以被髮布、封裝和提高爲服務；服務應該能夠被編排，以達到複用的效果。

　　僅僅這些，還不夠，咱們須要一套管理工具，咱們要隨時跟蹤、查看服務的狀態，咱們要對服務瞭如指掌，一出問題，立馬解決；對於網絡忽然中斷咱們應該提供一個反覆嘗試功能，而對於斷電或一切不可抗力形成的系統中斷，咱們應該提供必定的容錯能力。

　　若是容許，咱們還應該擁有一套開發工具，來快速構建模型、開發服務。

咱們時刻準備着

　　如上圖，咱們大概的輪廓已經出來了，咱們須要依靠他去把系統構建得更可靠、穩定、健壯，至少要讓用戶大膽地使用。

4、技術選型

　　咱們的項目，大多數是基於微軟.Net平臺開發的，使用的是C#語言，而且，咱們要作的是改造，而不是推倒重來（想都別想）。

　　開發語言肯定下來後，咱們的工做有如下幾種選擇：

　　一、自主研發出一套平臺

　　二、找開源項目，基於它作二次開發

　　三、購買第三方的平臺

　　暫到這裏吧，不知不覺囉嗦了這麼多。

　　未完待續……

 ——Aaron.Pan 2014-08-21:20