資料治理：資料整合架構的演進

縱覽企業資訊化建設的歷史，我們可以發現：企業應用整合技術是伴隨著企業資訊系統的發展而產生和演變的。企業的價值取向是推動應用整合技術發展的原動力，而透過應用整合技術所實現的價值反過來也驅動著公司的競爭優勢的提升。隨著新技術的發展和企業業務需求的變化，資料整合架構也跟著發生著變遷。資料整合架構的發展可以分為四個階段：點對點整合，EDI星型整合，SOA整合，網際網路整合，如下圖所示：

01 點對點整合架構

點對點整合是最早出現的應用整合模式，採用點對點的方式開發介面程式，把需要進行資訊交換的系統一對一地整合起來，從而實現整合應用的目標。點對點的連線方式在連線物件比較少的時候，確實是一種簡單和高效的連線方式，具有開發週期短、技術難度低的優勢。但其最大的問題是，當連線物件多的時候，連線路徑會以指數方式劇增。

連線路徑數與連線物件數之間的關係是：連線路徑數=(連線物件數 ×(連線物件數-1))÷ 2

點對點的整合有著明顯的缺陷：

當需要連線的應用系統越來越多時，點對點整合方式將把整個企業資訊系統介面變成無法管理的“混亂的線團”。

點對點的整合架構不能集中管理和監控介面服務，僅支援一對一的資料交換，如果交換協議不一致，開發則非常困難。即，如果溝通的語言、文字、格式、方法等有差異，則每一個連線方都要同時支援和維護多種連線方式。

點對點的整合是緊耦合的，當一個連線變化時，所有與其相關的介面程式都需要重新開發或除錯。

基於以上幾點，在多點互連的情況下，點對點連線方式成本高，可用性和可維護性低，顯然不是一個好的連線方式。

02 匯流排整合架構

隨著應用整合技術的發展，基於EDI(電子資料交換系統)的中介軟體方式逐漸取代了點對點的整合模式。基於EDI中介軟體的整合規則在中介軟體上進行定義和執行，其拓撲結構不再是點對點整合形成的無規則網狀，而主要是中心輻射型的(Hub型)星型結構或匯流排結構。由於資訊系統的標準不一致，星型架構採用介面卡的方式與應用系統進行對接，每個介面卡適用於一種型別的資料來源。

匯流排結構透過與點對點整合架構相比，採用匯流排架構可以顯著減少編寫的專用整合程式碼量，提升了整合介面的可管理性。不同連線物件如果連線方式有差異，可以透過匯流排完全遮蔽掉，做到對連線物件透明，無需各個連線物件關心。

匯流排的連線方式最早在許多硬體設計上得到廣泛的使用。如處理晶片的資料匯流排，網路節點的交換機，大型計算機系統處理器與外圍儲存裝置連線的集線器等。透過匯流排結構，把原來複雜的網狀結構變成簡單的星形結構，極大提高了硬體的可靠性和可用性。

但由於標準的匱乏，匯流排整合架構的缺陷逐漸暴露出來。各廠商的中介軟體多采用其專有協議或介面規範，開放程度非常低，一經採用，資訊系統升級、完善的成本很高，週期很長，直接導致了企業管理流程受到系統固化，出現企業管理隨著資訊化應用的深化反而管理流程被動僵化。

這是由於多個異構系統透過EDI相互關聯，單個系統的完善或升級受到關聯絡統的牽制，結果是資訊整合度越高，系統升級和資料維護越困難，從而直接導致管理改進的困難、運營效率降低和成本的上升，企業資訊化的自由度就大大受限，同時也會付出更高的技術成本;由於受中介軟體具體產品功能的限制，在開展業務流程整合時，由於整合邏輯需要在中介軟體上透過變成完成定義與執行，具有較高的技術難度和複雜度，很難實現較複雜的流程整合，因而也就不能迅速滿足業務變化提出的資訊系統調整的需求。

03 SOA型整合架構

隨著Web服務規範的日漸成熟，Web技術被應用於企業內部的應用整合，一種面向服務的整合架構(Service Oriented Architecture，簡稱：SOA)成為了企業應用整合的主流。SOA架構的其主要特徵是基於一系列Web標準或規範來開發介面程式，包括UDDI、SOAP、WSDL、XML，並採用支援這些規範的中介軟體產品作為整合平臺，從而實現了一種開放而富有彈性的應用整合方式。SOA是一種開發思想，是一種松耦合的框架，其主要特點是：

SOA是實現IT和業務同步的先進可行技術，它將企業應用中離散的業務功能提取出來，並將其組織成可互動的，基於標準的服務。

SOA以提供服務的方式向企業提供了靈活、快捷的系統整合選擇，它將模組化和便攜化的服務在複合應用中組合和重用，以更為快速的滿足業務需求。

SOA本身配備的完整、成熟的安全管理保障體系滿足了客戶進行松耦合整合實施時所提出的安全需求。

在面向服務的整合架構中，ESB(企業服務匯流排)扮演著重要的角色，甚至有人認為ESB是SOA架構落地的基礎。ESB是一個具有標準介面、實現了互連、通訊、服務路由。它提供訊息驅動、事件驅動和文字導向的處理模式，支援基於內容的服務路由。SOA架構將各應用系統上的各種服務連線到服務匯流排上，支援分散式的儲存及分散式的處理、非同步處理。為資訊系統的真正松耦合提供了架構保障。簡化了企業整個資訊系統的複雜性，提高了資訊系統架構的靈活性，降低企業內部資訊共享的成本。

第一，ESB是一個服務管理中心，服務的消費方無需關係服務實際的生產方，包括生產方的服務名稱、物理位置、傳輸協議和介面定義等，這些都是由ESB平臺進行包裝和中央的釋出式定義。

第二，ESB是服務的中介平臺，提供服務的可靠性保證，負載均衡，流量控制，快取，事務控制，加密傳輸，支援服務的監控、異常處理、服務呼叫及訊息資料記錄，系統及服務的狀態監控等。

第三，ESB是一個轉換和解耦的平臺，支援協議轉換，如WebService，Http，JMS等;支援訊息轉換，如訊息的轉換 、過濾、填充等;支援訊息路由，如同步/非同步、釋出/訂閱、基於內容路由、分支與聚合等。

最後，ESB是一個服務編排和重組的平臺，支援按業務的要求將多個服務編排為一個新的服務，正是ESB的這種靈活的服務編排功能，使得ESB具備了隨需應變的能力。

ESB將多個業務子系統的公共呼叫部分抽離整合為一個共用系統，減少了呼叫鏈路的複雜性，其服務編排能力增加業務的隨需應變的靈活性。但是ESB本質上是一個匯流排型或星型的結構，所有服務的對接需要依賴於這個“中心化”的匯流排。一旦ESB在資料量過大時候會成為效能瓶頸，或者ESB當機會導致多個系統無法正常提供服務。

當然，SOA時代的典型元件除了ESB，還有Portal、BPM、ETL、MDM、DW等，我們後邊慢慢分解!

04 微服務整合架構

網際網路是IT業的重大革命性創新，隨著移動互聯、網際網路的發展，為加快web和移動應用的開發程式，出現了一種“去中心化的”新型的架構——微服務架構。微服務架構強調“業務需求徹底的元件化及服務化”，這將成為企業IT架構的發展方向。原單個業務系統會被拆分為多個可以獨立開發、設計、部署執行的小應用，這些小應用間透過服務化完成互動和整合。

微服務出現後人們總會拿它與SOA比較，甚至有的人認為微服務架構將取代SOA，這樣的觀點似乎有些偏激。微服務與SOA中的服務最大的區別是它可以獨立部署、獨立執行，不依賴與其他服務，並且是一個分散式架構。每個微服務各自為政，做好自己的事情，即使自己出問題也只會影響有直接呼叫的服務，靈活彈性擴縮容。微服務架構與SOA相比具備更好的可靠性，出現單點故障不會對其他微服務造成影響。嚴格意義上說，SOA是面向整合的架構是面向系統級、面向整合的，而微服務是面向服務，透過一系列鬆散耦合的服務去實現滿足業務需求的應用，目的是縮短複雜應用從開發到部署的時間。

SOA注重服務的重用，但微服務本質是對服務的重寫，儘管微服務也需要整合。微服務通常由重寫一個模組開始，企業向微服務遷移的時候通常從耦合度最低的模組或對擴充套件性要求最高的模組開始，把它們一個一個剝離出來用敏捷方法、微服務技術進行重寫，然後單獨佈署。

微服務整合架構提升了全域性穩定性。由於每個服務負責的功能單一，各服務的資源需求也相對更低。從而可以選擇將服務分散的部署到多臺中低配的伺服器上，而不是一臺高配的機器上。如果某個機器上的服務故障，譬如說記憶體洩漏，故障只會影響該機器上的某一個或幾個服務，對全域性影響不大。

微服務的整合主要涉及以下四個層面的整合：

· 介面整合

介面整合是服務之間整合的最常見手段，通常基於業務邏輯的需要進行整合。RPC、REST、訊息傳遞和服務匯流排都可以歸為這種整合方式。微服務使用REST API和輕量級訊息系統實現系統整合。其中，訊息系統僅提供可靠的非同步訊息傳輸通道，而不參與訊息路由、編排、轉換等環節，也不在訊息系統中包含業務邏輯。

· 資料整合

資料整合同樣可以用於微服務之間的互動，聯邦資料庫是一個選擇，但也可以透過資料複製的方式實現資料整合。

· 介面整合

由於微服務是一個能夠獨立執行的整體，有些微服務會包含一些UI介面，這也意味著微服務之間也可以透過UI介面進行整合。

· 外部整合

這裡把外部整合單獨剝離出來的原因在於現實中很多服務之間的整合需求來自於與外部服務的依賴和整合，而在整合方式上也可以綜合採用介面整合、資料整合和UI整合。

寫在最後的話

在數字化、智慧化時代，資料成為企業的重要基礎設施，無論是技術還是應用都將圍繞資料進行。合理地利用資料將為企業創造極大的價值，而在這一過程中，資料整合技術將為更好地利用資料提供支撐。

未完待續。下篇我們重點分享下資料整合的集中典型的應用模式，例如：聯邦資料庫，主資料管理、資料倉儲、資料湖。

注：本文節選自《一本書講透資料治理》