1.3　SOA時(shí)代

為了對(duì)大型的單體系統(tǒng)進(jìn)行拆分，讓每一個(gè)子系統(tǒng)都能獨(dú)立地部署、運(yùn)行、更新，開發(fā)者們嘗試過很多種方案，這里列舉三種較有代表性的架構(gòu)模式，具體如下。

·煙囪式架構(gòu)（Information Silo Architecture）：信息煙囪又名信息孤島（Information Island），使用這種架構(gòu)的系統(tǒng)也被稱為孤島式信息系統(tǒng)或者煙囪式信息系統(tǒng)。它指的是一種與其他相關(guān)信息系統(tǒng)完全沒有互操作或者協(xié)調(diào)工作的設(shè)計(jì)模式。這樣的系統(tǒng)其實(shí)并沒有什么“架構(gòu)設(shè)計(jì)”可言。接著上一節(jié)中企業(yè)與部門的例子來說，如果兩個(gè)部門真的完全沒有任何交互，就沒有什么理由強(qiáng)迫它們必須在同一棟樓里辦公。兩個(gè)不發(fā)生交互的信息系統(tǒng)，讓它們使用獨(dú)立的數(shù)據(jù)庫和服務(wù)器即可實(shí)現(xiàn)拆分，而唯一的問題，也是致命的問題是，企業(yè)中真的存在完全沒有交互的部門嗎？對(duì)于兩個(gè)信息系統(tǒng)來說，哪怕真的毫無業(yè)務(wù)往來關(guān)系，但系統(tǒng)的人員、組織、權(quán)限等主數(shù)據(jù)會(huì)是完全獨(dú)立、沒有任何重疊的嗎？這樣“獨(dú)立拆分”“老死不相往來”的系統(tǒng)，顯然不可能是企業(yè)所希望見到的。

·微內(nèi)核架構(gòu)（Microkernel Architecture）：微內(nèi)核架構(gòu)也被稱為插件式架構(gòu)（Plug-in Architecture）。既然在煙囪式架構(gòu)中，沒有業(yè)務(wù)往來關(guān)系的系統(tǒng)也可能需要共享人員、組織、權(quán)限等一些公共的主數(shù)據(jù)，那不妨就將這些主數(shù)據(jù)，連同其他可能被各子系統(tǒng)用到的公共服務(wù)、數(shù)據(jù)、資源集中到一塊，組成一個(gè)被所有業(yè)務(wù)系統(tǒng)共同依賴的核心（Kernel，也稱為Core System），具體的業(yè)務(wù)系統(tǒng)以插件模塊（Plug-in Module）的形式存在，這樣也可提供可擴(kuò)展的、靈活的、天然隔離的功能特性，即微內(nèi)核架構(gòu)，如圖1-2所示。

圖1-2　微內(nèi)核架構(gòu)示意圖

這種模式很適合桌面應(yīng)用程序，也經(jīng)常在Web應(yīng)用程序中使用。任何計(jì)算機(jī)系統(tǒng)都是由各種軟件互相配合來實(shí)現(xiàn)具體功能的，本節(jié)列舉的不同架構(gòu)實(shí)現(xiàn)的軟件，都可視作整個(gè)系統(tǒng)的某種插件。對(duì)于平臺(tái)型應(yīng)用來說，如果我們希望將新特性或者新功能及時(shí)加入系統(tǒng)，微內(nèi)核架構(gòu)會(huì)是一種不錯(cuò)的選擇。微內(nèi)核架構(gòu)也可以嵌入其他架構(gòu)模式中，通過插件的方式來提供新功能的定制開發(fā)能力。如果你準(zhǔn)備實(shí)現(xiàn)一個(gè)能夠支持二次開發(fā)的軟件系統(tǒng)，微內(nèi)核也會(huì)是一種不錯(cuò)的選擇。

不過，微內(nèi)核架構(gòu)也有局限性，它假設(shè)系統(tǒng)中各個(gè)插件模塊之間互不認(rèn)識(shí)，且不可預(yù)知系統(tǒng)將安裝哪些模塊，因此這些插件可以訪問內(nèi)核中一些公共的資源，但不會(huì)直接交互。可是，無論是企業(yè)信息系統(tǒng)還是互聯(lián)網(wǎng)應(yīng)用，這一假設(shè)在許多場景中并不成立，所以我們必須找到辦法，既能拆分出獨(dú)立的系統(tǒng)，也能讓拆分后的子系統(tǒng)之間順暢地相互通信。

·事件驅(qū)動(dòng)架構(gòu)（Event-Driven Architecture）：為了能讓子系統(tǒng)互相通信，一種可行的方案是在子系統(tǒng)之間建立一套事件隊(duì)列管道（Event Queue），來自系統(tǒng)外部的消息將以事件的形式發(fā)送至管道中，各個(gè)子系統(tǒng)可以從管道里獲取自己感興趣、能夠處理的事件消息，也可以為事件新增或者修改其中的附加信息，甚至可以自己發(fā)布一些新的事件到管道隊(duì)列中去。如此，每一條消息的處理者都是獨(dú)立的、高度解耦的，但又能與其他處理者（如果存在其他消息處理者的話）通過事件管道進(jìn)行交互，如圖1-3所示。

圖1-3　事件驅(qū)動(dòng)架構(gòu)示意圖

當(dāng)架構(gòu)演化至事件驅(qū)動(dòng)架構(gòu)時(shí)，在1.1節(jié)提到的第二條通往更大規(guī)模軟件的路徑，即仍在并行發(fā)展的遠(yuǎn)程服務(wù)調(diào)用也迎來了SOAP協(xié)議的誕生（詳見第2章），此時(shí)面向服務(wù)的架構(gòu)（Service Oriented Architecture，SOA）已經(jīng)有了登上軟件架構(gòu)舞臺(tái)所需要的全部前置條件。

SOA的概念最早由Gartner公司在1994年提出，當(dāng)時(shí)的SOA還不具備發(fā)展的條件，直至2006年IBM、Oracle、SAP等公司共同成立了OSOA（Open Service Oriented Architecture）聯(lián)盟，用于聯(lián)合制定和推進(jìn)SOA相關(guān)行業(yè)標(biāo)準(zhǔn)之后，情況才有所變化。2007年，在結(jié)構(gòu)化資訊標(biāo)準(zhǔn)促進(jìn)組織（Organization for the Advancement of Structured Information Standard，OASIS）的倡議與支持下，OSOA由一個(gè)軟件廠商組成的松散聯(lián)盟，轉(zhuǎn)變?yōu)橐粋€(gè)制定行業(yè)標(biāo)準(zhǔn)的國際組織，并聯(lián)合OASIS共同新成立了Open CSA（Open Composite Service Architecture）組織，這便是SOA的官方管理機(jī)構(gòu)。

軟件架構(gòu)來到SOA時(shí)代，其包含的許多概念、思想都已經(jīng)能在今天的微服務(wù)中找到對(duì)應(yīng)的身影了，譬如服務(wù)之間的松散耦合、注冊(cè)、發(fā)現(xiàn)、治理，隔離、編排等。這些在微服務(wù)中耳熟能詳?shù)母拍睿蠖鄶?shù)也是在分布式服務(wù)剛被提出時(shí)就已經(jīng)可以預(yù)見的困難點(diǎn)。SOA針對(duì)這些問題，甚至是針對(duì)“軟件開發(fā)”這件事情本身，都進(jìn)行了更具體、更系統(tǒng)的探索。

·“更具體”體現(xiàn)在盡管SOA本身還屬于抽象概念，而不是特指某一種具體的技術(shù)，但它比單體架構(gòu)和前面所列舉的三種架構(gòu)模式的操作性更強(qiáng)，已經(jīng)不能簡單視為一種架構(gòu)風(fēng)格，而是一套軟件設(shè)計(jì)的基礎(chǔ)平臺(tái)。它擁有領(lǐng)導(dǎo)制定技術(shù)標(biāo)準(zhǔn)的組織Open CSA；有清晰的軟件設(shè)計(jì)的指導(dǎo)原則，譬如服務(wù)的封裝性、自治、松耦合、可重用、可組合、無狀態(tài)，等等；明確了采用SOAP作為遠(yuǎn)程調(diào)用協(xié)議，依靠SOAP協(xié)議族（WSDL、UDDI和WS-*協(xié)議）來完成服務(wù)的發(fā)布、發(fā)現(xiàn)和治理；利用企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）的消息管道來實(shí)現(xiàn)各個(gè)子系統(tǒng)之間的交互，令各服務(wù)在ESB的調(diào)度下無須相互依賴就能相互通信，實(shí)現(xiàn)了服務(wù)松耦合，也為以后進(jìn)一步實(shí)施業(yè)務(wù)流程編排（Business Process Management，BPM）提供了基礎(chǔ)；使用服務(wù)數(shù)據(jù)對(duì)象（Service Data Object，SDO）來訪問和表示數(shù)據(jù)，使用服務(wù)組件架構(gòu)（Service Component Architecture，SCA）來定義服務(wù)封裝的形式和服務(wù)運(yùn)行的容器，等等。在這一套成體系的可以相互精密協(xié)作的技術(shù)組件支持下，若僅從技術(shù)可行性這一個(gè)角度來評(píng)判的話，SOA可以算是已經(jīng)成功解決了分布式環(huán)境中出現(xiàn)的主要技術(shù)問題。

·“更系統(tǒng)”指的是SOA的宏大理想，它的終極目標(biāo)是希望總結(jié)出一套自上而下的軟件研發(fā)方法論，做到企業(yè)只需要跟著SOA的思路，就能夠一攬子解決掉軟件開發(fā)過程中的全部問題，譬如該如何挖掘需求、如何將需求分解為業(yè)務(wù)能力、如何編排已有服務(wù)、如何開發(fā)/測試/部署新的功能，等等。這些技術(shù)問題確實(shí)是重點(diǎn)和難點(diǎn)，但也僅僅是其中的一個(gè)方面，SOA不僅關(guān)注技術(shù)，還關(guān)注研發(fā)過程中涉及的需求、管理、流程和組織。如果這個(gè)目標(biāo)真的能夠達(dá)成，軟件開發(fā)就有可能從此邁進(jìn)工業(yè)化大生產(chǎn)的階段。試想如果有一天開發(fā)符合客戶需求的軟件會(huì)像寫八股文一樣有跡可循、有法可依，那對(duì)軟件開發(fā)者來說也許是無趣的，但整個(gè)社會(huì)實(shí)施信息化的效率肯定會(huì)大幅提升。

SOA在21世紀(jì)最初的十年里曾盛行一時(shí)，有IBM等一眾行業(yè)巨頭廠商為其吶喊沖鋒，吸引了不少軟件開發(fā)商，尤其是企業(yè)級(jí)軟件開發(fā)商，但最終還是偃旗息鼓，沉寂了下去。在后面的2.1節(jié)中，筆者會(huì)提到SOAP協(xié)議被逐漸邊緣化的本質(zhì)原因：過于嚴(yán)格的規(guī)范定義帶來過度的復(fù)雜性，而構(gòu)建在SOAP基礎(chǔ)之上的ESB、BPM、SCA、SDO等諸多上層建筑，進(jìn)一步加劇了這種復(fù)雜性。開發(fā)信息系統(tǒng)畢竟不是作八股文章，過于精密的流程和理論需要懂得復(fù)雜概念的專業(yè)人員才能夠駕馭。SOA自誕生的那一天起，就已經(jīng)注定只能是少數(shù)系統(tǒng)陽春白雪式的精致奢侈品，它可以實(shí)現(xiàn)多個(gè)異構(gòu)大型系統(tǒng)之間的復(fù)雜集成交互，卻很難作為一種具有廣泛普適性的軟件架構(gòu)風(fēng)格來推廣。SOA最終沒有獲得成功的致命傷與當(dāng)年的EJB如出一轍，盡管有Sun和IBM等一眾巨頭在背后力挺，EJB仍然敗于以Spring、Hibernate為代表的“草根框架”，可見一旦脫離人民群眾，終究會(huì)淹沒在群眾的海洋之中，連信息技術(shù)也不曾例外。

讀到這里，你不妨回想下“如何使用多個(gè)獨(dú)立的分布式服務(wù)共同構(gòu)建一個(gè)更大型的系統(tǒng)”這個(gè)問題，再回想下1.1節(jié)中UNIX DCE中提出的分布式服務(wù)的設(shè)計(jì)主旨：“開發(fā)人員不必關(guān)心服務(wù)是遠(yuǎn)程還是本地，都能夠透明地調(diào)用服務(wù)或者訪問資源”。經(jīng)過三十年的技術(shù)發(fā)展，信息系統(tǒng)經(jīng)歷了巨石、煙囪、插件、事件、SOA等架構(gòu)模式，應(yīng)用受架構(gòu)復(fù)雜度的牽絆卻越來越大，已經(jīng)距離“透明”二字越來越遠(yuǎn)了，這是否算不自覺間忘掉了當(dāng)年的初心呢？接下來我們所談?wù)摰奈⒎?wù)時(shí)代，似乎正是帶著這樣的自省式的問句而開啟的。