萬字詳解自動駕駛中SOA面向服務的分散式架構

SOA作為一種面向服務的架構，是一種軟體架構設計的模型和方法論。從業務角度來看，一切以最大化“服務”的價值為出發點，SOA利用企業現有的各種軟體體系，重新整合並構建起一套新的軟體架構。這套軟體架構能夠隨著業務的變化，隨時靈活地結合現有服務，組成新軟體，共同服務於整個企業的業務體系。簡單的理解，我們可以把SOA看作是模組化的組件，每個模組都可以實現獨立功能，而不同模組之間的結合則可以提供不同的服務，模組之間的介面遵循統一標準，可以實現低成本的重構和重組。在SOA的技術框架下，可以把雜亂無章的龐大系統整合成一個全面有序的系統，從而增加企業在業務發展過程中應用系統的靈活性，實現最大的IT資產利用率。

SOA詳細定義

面向服務的體系結構（SOA）是一個元件模型，它將應用程式的不同功能單元（稱為服務）透過這些服務之間定義良好的接口和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在各種這樣的系統中的服務可以以一種統一和通用的方式進行互動。

這種具有中立的介面定義（沒有強制繫結到特定的實現上）的特徵稱為服務之間的松耦合。松耦合系統的好處有兩點，一點是它的靈活性，另一點是，當組成整個應用程式的每個服務的內部結構和實現逐漸地發生改變時，它能夠繼續存在。而另一方面，緊耦合意味著應用程式的不同元件之間的介面與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時，它們就顯得非常脆弱。

對松耦合系統的需要來源於業務應用程式需要，根據業務的需要變得更加靈活，以適應不斷變化的環境，比如經常改變的政策、業務級別、業務重點、合作伙伴關係、行業地位以及其他與業務有關的因素，這些因素甚至會影響業務的性質。我們稱能夠靈活地適應環境變化的業務為按需業務，在按需業務中，一旦需要，就可以對完成或執行任務的方式進行必要的更改。

雖然面向服務的體系結構不是一個新鮮事物，但它卻是更傳統的面向物件的模型的替代模型，面向物件的模型是緊耦合的，已經存在二十多年了。雖然基於 SOA 的系統並不排除使用面向物件的設計來構建單個服務，但是其整體設計卻是面向服務的。由於它考慮到了系統內的物件，所以雖然 SOA 是基於物件的，但是作為一個整體，它卻不是面向物件的。不同之處在於介面本身。SOA 系統原型的一個典型例子是通用物件請求代理體系結構，它已經出現很長時間了，其定義的概念與 SOA 相似。然而，現在的 SOA 已經有所不同了，因為它依賴於一些更新的進展，這些進展是以可擴充套件標記語言（eXML）為基礎的。

在SOA架構風格中，服務是最核心的抽象手段，業務被劃分（元件化）為一系列粗粒度的業務服務和業務流程。業務服務相對獨立、自包含、可重用，由一個或者多個分佈的系統所實現，而業務流程由服務組裝而來。一個“服務”定義了一個與業務功能或業務資料相關的介面，以及約束這個介面的契約，如服務質量要求、業務規則、安全性要求、法律法規的遵循、關鍵業績指標（Key Performance Indicator，KPI）等。介面和契約採用中立、基於標準的方式進行定義，它獨立於實現服務的硬體平臺、作業系統和程式語言。這使得構建在不同系統中的服務可以以一種統一的和通用的方式進行互動、相互理解。除了這種不依賴於特定技術的中立特性，透過服務註冊庫（Service Registry）加上企業服務匯流排（Enterprise Service Bus）來支援動態查詢、定位、路由和中介（Mediation）的能力，使得服務之間的互動是動態的，位置是透明的。技術和位置的透明性，使得服務的請求者和提供者之間高度解耦。這種松耦合系統的好處有兩點：一點是它適應變化的靈活性；另一點是當某個服務的內部結構和實現逐漸發生改變時，不影響其他服務。而緊耦合則是指應用程式的不同元件之間的介面與其功能和結構是緊密相連的，因而當發生變化時，某一部分的調整會隨著各種緊耦合的關係引起其他部分甚至整個應用程式的更改，這樣的系統架構就很脆弱了。

SOA架構的優點

SOA的主要優點概括為：IT能夠更好更快地提供業務價值（Business Centric）、快速應變能力（Flexibility）、重用（Reusability）

也可以細分為以下幾個方面：

服務之間透過簡單、精確定義的介面進行通訊，不涉及底層程式設計介面和通訊模型。

粗粒度性：粗粒度服務提供一項特定的業務功能，採用粗粒度服務介面的優點在於使用者和服務層之間不必再進行多次的往復，一次往復就足夠了。

松耦合性：松耦合性要求SOA架構中的不同服務之間應該保持一種松耦合的關係，也就是應該保持一種相對獨立無依賴的關係。這樣的好處有兩點，首先是具有靈活性，其次當組成整個應用程式的服務內部結構和實現逐步地發生變化時，系統可以繼續地獨立存在。而緊耦合意味著應用程式的不同元件之間的介面與其功能和結構是緊密相連的，因而當需要對部分或整個應用程式進行某種形式的更改時這種結構就顯得非常脆弱。

位置透明性：位置透明性要求SOA系統中的所有服務對於其呼叫者來說都是位置透明的，也就是說，每個服務的呼叫者只需要知道想要呼叫的是哪一個服務，但並不需要知道所呼叫服務的物理位置在哪。

協議無關性：協議無關性要求每一個服務都可以透過不同的協議來呼叫。

另外，在許多傳統的IT系統的內在部分採用的是硬連線，這種結構很難讓企業快速響應市場的變化，而SOA能夠重複利用企業現有的資源，可以減輕企業運營成本，提升資源的使用效率，並且減輕企業維護人員的工作量，減少潛在的風險以及管理費用。在業務方面和IT方面帶來許多優勢：

服務給精確的業務流程帶來靈活性；

使用服務來改善客戶服務，而不必擔心底層複雜的IT基礎架構；

可以迅速建立新的業務流程和複雜的應用程式，以適應市場變化；

藉助安全、易管理的整合環境，成為響應能力更強的IT組織；

透過使用預裝的、可重複使用的服務構建模組，縮短開發和部署週期；

透過使用服務來降低複雜性和維護成本；

是增強而不是替換現有的IT系統。

SOA架構詳解

如何形象理解SOA

事實上，SOA的思想我國很早就有了，印刷術的發展過程其思想就完整體現了SOA的核心含義。

印刷的內容――文字，在秦始皇統一六國之前，各國的文字是不統一的，據說許多常用的文字有十幾種寫法和讀音，妨礙了各國之間的文化交流，就象SOA之前，各種軟體平臺、各種開發工具和各種介面的元件之間，沒有統一的標準，對軟體系統之間的整合造成巨大的困難。

因此，偉大的始皇帝統一了六國文字，“書同文、車同軌”就是透過標準解決“複用”和“互操作”等問題。這也為大規模的印刷和文明發展提供了一個良好的基礎，這種“統一封裝”的文字，對文化交流起到了一個“互操作”的標準作用。

SOA的形象解析

在沒有印刷術之前，書籍要依賴於手工抄寫，這樣效率當然是非常低下，而且質量也不能獲得一致性的保證，也就是書籍還無法“複用”。中國人首先發明瞭刻版印刷術，就是將書籍刻成一塊一塊的凸字版，然後就可以大規模進行印刷了，當印刷出來的書籍脫銷時，下次還可以繼續使用，大大提高了效率，這就是“複用”，軟體透過元件的封裝，也可以達到重複和在不同場合多次使用的“複用”效果。

刻版印刷術有個很大的問題就是文字之間是緊耦合的，同樣一個字，在另一部書之中是不能“複用”的，必須重新雕刻，也就是說刻版印刷是沒有“編排”特性的。就如軟體技術中微軟VB開發的Com+元件就只能在Windows環境之中使用，它不能與Java開發的EJB元件進行復用和編排，因為他們與開發環境和執行環境是緊耦合的，要在UNIX環境下使用，必須重新開發（相當於重新“刻版”）。活字印刷就是透過文字與版面之間的松耦合，透過“排版”來實現一部書的印刷版面的，這種松耦合就大大提高了文字的字模之間的複用和編排效率。我們標準封裝的“服務”就類似一個一個的字模，透過服務編排（“排版”）來實現業務流程。

統一文字和活字印刷促進了人類文明進步，而SOA促進全球IT架構和應用的革命。

SOA的核心要素

要準確全面理解SOA，首先必須理解SOA的核心要素：

SOA的核心要素

SOA的目標就是實現靈活可變的IT系統。要達到靈活性，透過三個途徑來解決：標準化封裝、複用、松耦合可編排。

互操作（標準化封裝）、複用、松耦合等SOA技術的內在機制，也是中介軟體技術和產品的本質特徵。

標準化封裝（互操作性）

傳統軟體架構，因為封裝的技術和平臺依賴性，一直沒有徹底解決互操作問題。網際網路前所未有的開放性意味著各節點可能採用不同的元件、平臺技術，對技術細節進行了私有化的約束，構件模型和架構沒有統一標準，從而導致架構平臺自身在元件描述、釋出、發現、呼叫、互操作協議及資料傳輸等方面呈現出巨大的異構性。各種不良技術約束的結果是軟體系統跨互聯網進行互動變得困難重重，最終導致了跨企業/部門的業務整合和重組難以靈活快速的進行。

在軟體的互操作方面，傳統中介軟體只是實現了訪問互操作，即透過標準化的API實現了同類系統之間的呼叫互操作，而連線互操作還是依賴於特定的訪問協議，如JAVA使用RMI，CORBA使用IIOP等。而SOA透過標準的、支援Internet、與作業系統無關的SOAP協議實現了連線互操作。而且，服務的封裝是採用XML協議，具有自解析和自定義的特性，這樣，基於SOA的中間件還可以實現語義互操作。

SOA要實現互操作，就是透過一系列的標準族，來實現訪問、連線和語義等各種層面的互操作。

軟體複用

軟體複用，即軟體的重用，也叫再用，是指同一事物不作修改或稍加改動就多次重複使用。從軟體複用技術的發展來看，就是不斷提升抽象級別，擴大複用範圍。最早的複用技術是子程式，人們發明子程式，就可以在不同系統之間進行復用了。但是，子程式是最原始的複用，因為這種複用範圍是一個可執行程式內複用，靜態開發期複用，如果子程式修改，意味著所有呼叫這個子程式的系統必須重新編譯、測試和釋出。

SOA的複用

為了解決這個問題，人們發明了元件（或者叫控制元件），如MS作業系統下的DLL元件。元件將複用提升了一個層次，因為元件可以在一個系統內複用（同一種作業系統），而且是動態、執行期複用。這樣元件可以單獨發展，元件與元件呼叫者之間的耦合度降低。

為解決分散式網路計算之間的元件複用，人們發明了企業物件元件，如（Com+，。NET，EJB等），或者叫分散式元件。透過遠端物件代理，來實現企業網路內複用，不同系統之間複用。

傳統架構的核心是元件物件的管理。但分散式元件也是嚴重依賴其計算環境，由於構件實現和執行支撐技術之間存在著較大的異構性，不同技術設計和實現的構件之間無法直接組裝式複用。

而現代SOA的重要特徵就是以服務為核心，如WebService，SCA/SDO等。透過服務，或者服務元件來實現更高層次的複用、解耦和互操作，即SOA架構中介軟體。

因為服務是透過標準封裝，服務元件之間的組裝、編排和重組，來實現服務的複用。而且這種複用，可以在不同企業之間，全球複用，達到複用的最高級別，並且是動態可配置的複用。

耦合關係

SOA架構在松耦合解耦過程也發展到了最後的境界。傳統軟體將軟體之中核心三部分網路連線、資料轉換、業務邏輯全部耦合在一個整體之中，形成“鐵板一塊”的軟體， “牽一髮而動全身”，軟體就難以適應變化。分散式物件技術將連線邏輯進行分離，訊息中介軟體將連線邏輯進行非同步處理，增加了更大的靈活性。訊息代理和一些分布式物件中介軟體將資料轉換也進行了分離。而SOA架構，透過服務的封裝，實現了業務邏輯與網路連線、資料轉換等進行完全的解耦。

SOA不斷解耦的過程

總之，從科學哲學的角度來看，SOA是一個不斷解構的過程，傳統軟體強調系統性，耦合度過高，所以需要松耦合（解耦）；SOA也是一個元件粒度的平衡，積體電路趨勢是整合度越來越高，軟體發展的趨勢是相反的過程；SOA是架構，更是方法，反映了人們對哲學思想的追求的原動力。

按照這個特性，SOA基本上來說與WebService並不是同一個概念，SOA並不一定需要WebService實現，理論上可以在其他技術體系下，實現SOA。但事實上，到目前為止，能夠實現SOA架構風格的技術就是WebService，因為它的特性和廠商的支援力度，使得WebService成為了實現SOA實現技術的事實標準。也正因為WebService技術的成熟，才使得已經提出10多年了的 SOA思想和概念，得以能夠實現落地，成為一種可以使用的技術。這也就是回答了SOA和WebService的關係。

SOA的架構框架

（Framework） SOA的核心主體是服務。所謂“服務（Service）” ，從業務角度而言，服務是一個可重複的經過標準封裝的任務，例如：檢查帳號餘額；開新帳戶等等…SOA的目標是透過服務的流程化來實現業務的靈活性，所謂流程（Process）是由一系列相互關聯的任務所組成，實現一個具體的業務功能。一個流程可以由一系列服務來實現。

SOA治理

服務就像一堆“元器件”，這些元器件透過封裝形成標準服務，他們有相同的介面和語義表達規則。但服務要組裝成一個流程和應用，還需要有效的“管理”，包括如何註冊服務、如何發現服務、如何包裝服務的安全性和可靠性，這些就是SOA治理。SOA 治理乃是將SOA這一堆元器件，進行有效組裝，形成一個“產品”的關鍵，否則它永遠是一堆器件，而無法形成一個有機整體。

SOA治理的方法和體系，就是區別於一般元件開發的技術的重要區別和特徵。

一個正確的框架，是指導我們開發和實施SOA架構的基礎。由IBM提案，國際開放群組（The Open Group）提出了一個SOA架構的參考模型，這個架構框架目前是產業界最權威和嚴謹的SOA架構標準。The Open Group是一個非營利標準化組織，是一個廠商中立和技術中立的機構，致力於提出各種技術框架和理論結構，致力於促進全球市場的業務效率。The Open Group已有超過20年的標準制定與推廣歷史。在1996年，由X/Open與Open Software Foundation合併組成。The Open Group最有名是作為UNIX商標的認證機構。在過去，協會最出名的是其出版的Single UNIX Specification，它擴充了POSIX標準而且是 UNIX的官方定義，其成員包括IT使用者、供應商以及政府機構。The Open Group在中國的創始會員為金蝶集團，金蝶集團負責成立了中國分會。TOG在1993年提出的The Open Group Architecture Framework （TOGAF）架構框架，是一套行之有效的企業架構。歷經15年9個版本發展，支援開放、標準的SOA參考架構，已被80％的福布斯（ Forbes）全球排名前50的公司使用。

這個SOA參考模型為：

SOA標準模型

根據這個模型，完整的SOA架構由五大部分組成，分別是：基礎設施服務、企業服務匯流排、關鍵服務元件、開發工具、管理工具等。

SOA基礎實施是為整個SOA元件和框架提供一個可靠的執行環境，以及服務元件容器，它的核心元件是應用伺服器等基礎軟件支撐設施，提供執行期完整、可靠的軟體支撐。

企業服務匯流排是指由中介軟體基礎設施產品技術實現的、透過事件驅動和基於XML訊息引擎，為SOA提供的軟體架構的構造物。企業服務匯流排ESB提供可靠訊息傳輸、服務接入、協議轉換、資料格式轉換、基於內容的路由等功能，遮蔽了服務的物理位置，協議和資料格式。在SOA基礎實現的方案上，應用的業務功能能夠被髮布、封裝和提升（Promote）成為業務服務（Business Service）；業務服務的序列可以編排成為BPM的流程，而流程也可以被髮布和提升為複合服務（Composited Service），業務服務還可以被外部的SOA系統再次編排和組合。ESB是實現SOA治理的重要支撐平臺，是SOA解決方案的核心，從某種意義上說，如果沒有ESB，就不能算作嚴格意義上的SOA。

關鍵服務實現，是SOA在各種業務服務元件的分類。一般來說，一個企業級的SOA架構通常包括：互動服務、流程服務、信息服務、夥伴服務、企業應用服務和接入服務。這些服務可能是一些服務元件，也可能是企業應用系統（如ERP）所暴露的服務介面等等。這些服務都可以接入ESB，進行集中統一管理。

開發工具和管理工具：提供完善的、視覺化的服務開發和流程編排工具，涵蓋服務的設計、開發、配置、部署、監控、重構等完整的SOA專案開發生命週期。

按照這個模型，許多SOA解決方案是隻提供部分實現。這個行業中，許多國內的企業為了搭上SOA的便車，經常以偏概全，混繞概念。應該說真正按照SOA的思想和模型來構建整個企業的IT架構的案例是非常之少的。許多國外廠商的宣傳案例，基本上是停留在部署應用伺服器，開發了部分WebService元件，可以實現部分資料整合，這個層次而已，而這些WebService是部署在ESB平臺之上的，就已經很不錯了。實現了服務流程重組，實現SOA治理的案例就更是很少見到了。

國內有許多軟體企業開發的系統，宣傳是SOA架構的。基本上有幾種情況，其一，有些開發元件和開發平臺廠商，他們也自稱中介軟體企業，基本上是提供一個工作流平臺，許多還不支援BPEL的業務流程管理，只是傳統的XPDL/WfMC工作流平臺（Workflow不同於支援服務流程的Business Process），最常見的案例是OA辦公審批，或者服務元件開發工具，而所謂的 ESB產品大部分都是EAI的升級，可以與Webservice進行介面而已，就宣稱這是ESB產品了，基本的服務註冊、服務編排和安全管理都不具備。這些解決方案只是提供了許多WebService開發的元件，而不提供SOA治理的核心架構，相當於造了許多元器件，但還不能提供整機產品。

其二，許多宣稱SOA架構的應用軟體，基本上可以說是“支援”SOA，而不能稱為“基於SOA”架構。因為支援SOA一般是指可以將其某些功能，封裝為服務（WebService），可以在SOA架構之中進行管理，這比較容易達到。而“基於SOA”是指應用系統的業務功能都是封裝為服務，透過ESB進行集中管理，業務實現是透過BPEL業務流程管理進行編排，使用者互動是透過互動服務（如門戶）進行管理，整個解決方案可以達到標準服務封裝、服務複用、松耦合、服務編排與重組，並且基本符合TOGSOA的架構模型。

按照這個標準，IT使用者就可以瞭解到真正的SOA架構的框架模型，就可以識別是否是企業所需要的架構。

講到這裡，我們已經很清楚了，對於SOA的理解，有些學者或者諮詢公司強調SOA不是一種技術，也不是軟體，而是一種思想，一種架構風格。我認為這也是不完全準確的，這種觀點認為SOA僅僅是思想和方法，將使得SOA成為一種不可知論，飄在空中，很難落地。

SOA商業化實際運用

SOA將來真正推廣到企業中應用，要落地，就不能離開幾個基本的東西：支撐SOA的基礎中介軟體平臺、符合SOA架構的應用系統（如ERP等）、構建SOA的方法論。

SOA落地途徑

架構方法論

方法和工具構成了工程技術域，要構建SOA架構的企業資訊系統，確保業務和IT的真正匹配，首先必須從方法論入手。

許多企業的IT系統“孤島”現象嚴重，本質上是缺乏足夠有效的整體規劃或者架構規劃造成的。形象地說，構建企業IT大廈如同我們蓋房子是一樣的道理。我們許多企業建設資訊系統時就採用了蓋鄉村民宅的做法。蓋鄉村民宅不需要嚴謹的規劃，也沒有複雜的地下設施建設（如自來水供水、排水、供氣、地下停車場等），也沒有需要建設汙水處理、雨水收集等複雜的配套設施。而事實上，企業IT系統建設應該如城市建設，首先需要城市總體規劃，然後根據功能區規劃，設計和建設小區配套設施，“三通一平”實質就是構建建築之間的公共基礎設施，確保每棟建築之間不是“孤島”，然後每棟建築還需詳細的設計和工程施工。如果要消除資訊孤島，實現IT與業務的一致性，也需要有效的企業架構規劃和設計。

為什麼需要架構規劃

透過現象看本質，SOA代表著一種面向服務的IT架構風格，SOA的技術本質和出發點，在於IT架構。而IT架構，是組織的企業架構的重要組成部分，它和組織的戰略架構、業務架構一起，形成一個自上而下、緊密聯絡、相輔相成的有機整體。SOA代表著一種正在蓬勃興起的革命性IT架構理念，和傳統技術體系區別的關鍵特徵之一就在於SOA是戰略導向和業務驅動的。而國際和國內的各方面經驗都告訴我們，對於一個組織而言，捕獲戰略、梳理業務和IT的最有效的措施就是架構。

企業架構（Enterprise Architecture，EA），是從多個角度對組織的構件層次描述的規劃藍圖，從各個層面反映組織的願景、戰略、業務、服務、人員、技術和產品及其相互之間的關係，輔以其管控和演進的規則。

一個企業架構內容包括業務架構（Business Architecture）、應用架構（Application Architecture）、資訊架構（Information Architecture）、技術架構（Technology Architecture）等。

真正可以落地的SOA建設，必須且只能從架構出發。沒有架構，“SOA”將變成一盤無法真正解決各種運營問題的技術和產品的大雜燴。優良的架構填補了業務需求與實際資訊系統以及基礎設施設計之間難以逾越的鴻溝。

在所有的架構開發方法（ADM- Architecture Development Methods）之中，開放群組TOG的TOGAF是目前最權威和最有影響力的一種。The Open Group於1993年開始應客戶要求制定系統架構的標準，在1995年發表The Open Group Architecture Framework （TOGAF）架構框架。TOGAF的基礎是美國國防部的資訊管理技術架構（Technical Architecture for Information Management： TAFIM）。TOAGF是一個架構框架，簡而言之，TOGAF是一種協助開發、驗收、執行、使用和維護架構的工具，它是基於一個迭代（Iterative）的過程模型，支援最佳實踐和一套可重用的現有架構資產。它可設計、評估並建立組織的正確架構。TOGAF的關鍵是架構開發方法ADM：一個可靠的，行之有效的方法，以發展能夠滿足商務需求的企業架構。而2008 年釋出的TOGAF 9。0是符合SOA架構開發的最新版本。TOGAF所提出的“無邊界資訊流（Boundaryless Information Flow）”理念和願景，是解決目前企業資訊化孤島問題的最有效方式。

基於SOA的應用系統

基於SOA的應用系統構建方法與傳統軟體架構方法有所不同。

首先基於SOA的應用系統建模和管理的元件層次是服務：