本文來自談數據，作者：石秀峰。

縱覽企業信息化建設的歷史，我們可以發現：企業應用集成技術是伴隨著企業信息系統的發展而產生和演變的。企業的價值取向是推動應用集成技術發展的原動力，而通過應用集成技術所實現的價值反過來也驅動著公司的競爭優勢的提升。隨著新技術的發展和企業業務需求的變化，數據集成架構也跟著發生著變遷。數據集成架構的發展可以分為四個階段：點對點集成，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集成。

寫在最后的話

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

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

注：本文節選自《一本書講透數據治理》，機械工業出版社。下附京東5折優惠購書鏈接，截止目前最低價：