作者 | 耿立超
責編 | 晉兆雨
來源 | 《大數(shù)據(jù)平臺架構(gòu)與原型實現(xiàn)：數(shù)據(jù)中臺建設(shè)實戰(zhàn)》
SOA 所有的理念都是基于現(xiàn)有應(yīng)用系統(tǒng)展開的，不管是對服務(wù)的梳理還是服務(wù)之間的交互，都是以現(xiàn)有應(yīng)用系統(tǒng)為載體的，中臺不同于SOA 的地方在于：中臺是一種平臺化思維，它并不是從系統(tǒng)集成的角度去思考問題，而是從架構(gòu)層面上重構(gòu)了整個IT 生態(tài)。
相比之下，中臺無疑是一種更深刻、更底層的變革，因為它完全破除了應(yīng)用之間的壁壘，把企業(yè)的核心業(yè)務(wù)能力“中心化”，把它們提煉并沉淀到中臺的各個業(yè)務(wù)中心上，而不是面向單一業(yè)務(wù)方向或渠道的應(yīng)用系統(tǒng)上。這在SOA 架構(gòu)下是很難實現(xiàn)的，因為中臺的業(yè)務(wù)中心與SOA 的服務(wù)載體（即應(yīng)用系統(tǒng)）之間有著本質(zhì)區(qū)別，它們的定位和服務(wù)對象都不同，這些區(qū)別決定了SOA 依然是一種相對松散的分治式的架構(gòu)，很難與中臺這種更加中心化、更為強力的架構(gòu)體系相抗衡。
煙囪式的生態(tài)系統(tǒng)并不是今天才突顯出來的，很多企業(yè)已經(jīng)被這個問題困擾多年了，并且嘗試過各種措施試圖進行改善。回顧企業(yè)的IT 生態(tài)變遷史，一段不得不提的歷程就是SOA（面向服務(wù)的架構(gòu)）。本文核心觀點援引自作者所著的《大數(shù)據(jù)平臺架構(gòu)與原型實現(xiàn)：數(shù)據(jù)中臺建設(shè)實戰(zhàn)》一書，全書對數(shù)據(jù)中臺的理念、架構(gòu)和具體實現(xiàn)做了詳細論述。
大概在2005 年前后的七八年間，隨著SOA 理念和相關(guān)技術(shù)（如ESB）的不斷發(fā)展和完善，SOA 在當時被認為是改善僵化的IT 生態(tài)、解決煙囪架構(gòu)等弊病的終極方案而被業(yè)界寄予厚望，很多企業(yè)在那個時期紛紛上馬SOA 項目，希望憑借SOA 將企業(yè)的IT生態(tài)拉回到一種理想的狀態(tài)。十多年后回首當初那場SOA 熱潮，我們發(fā)現(xiàn)最終在SOA 改造上取得成功的企業(yè)少之又少，即使曾經(jīng)取得了一定的成效，伴隨后來新業(yè)務(wù)系統(tǒng)的沖擊，當年辛苦建立的SOA 生態(tài)也大都名存實亡，是什么原因?qū)е铝诉@樣的結(jié)果呢？
人們很早就意識到點對點式的系統(tǒng)間交互是非常糟糕的，在SOA 起源之前，已經(jīng)出現(xiàn)了基于消息隊列的“消息總線”架構(gòu)，各個應(yīng)用系統(tǒng)與消息總線連通，由消息總線負責將消息路由到接收方，從而讓應(yīng)用系統(tǒng)通過中心化的消息總線完成交互，這樣就可以消除點對點式的系統(tǒng)交互。但是消息總線用于系統(tǒng)集成時在某些方面依然有所欠缺，例如消息都是靜態(tài)的、預定義的、無法自描述的，消息接口無法被注冊和發(fā)現(xiàn)。同時，另外一種以“服務(wù)”為視角看待和思考系統(tǒng)間交互的架構(gòu)思想一直在不斷地發(fā)展，后來，隨著Web 服務(wù)（Web Service）技術(shù)的興起，IT 系統(tǒng)的對外接口逐漸向平臺中立的第一代Web 服務(wù)標準（WSDL+SOAP）靠攏，這為實施這一架構(gòu)打開了大門，這就是SOA。
從系統(tǒng)集成的角度看，SOA 是一種非常理想的方案，SOA 體系的兩大核心如下：
●對系統(tǒng)提供的對外交互進行提煉、組織和梳理，通過封裝、組合與編排，將接口以“服務(wù)”的形式發(fā)布出去；
●系統(tǒng)間的交互統(tǒng)一通過中心化的企業(yè)服務(wù)總線（ESB）完成。
典型的SOA 架構(gòu)如圖1所示。
圖1 典型的SOA 架構(gòu)
SOA 成功的基礎(chǔ)是對“服務(wù)”的提煉、組織和梳理，只有服務(wù)足夠靈活才能支撐各種外部系統(tǒng)的復雜需求，而這一工作需要建立在對業(yè)務(wù)的深入了解之上，同時要融合良好的設(shè)計思想才能達到要求。
SOA 中的“服務(wù)”在技術(shù)上以Web Service 為載體，但是在粒度（或者說抽象程度）上會有所不同，主要有如下三種粒度的服務(wù)：
●基礎(chǔ)服務(wù)：最細粒度的服務(wù)，最基本、最原子的服務(wù)都會在這一層，從服務(wù)數(shù)量上看，這一層也是最多的；
●復合服務(wù)：是基于多個基礎(chǔ)服務(wù)組合疊加而成的粗粒度服務(wù)，多用于封裝并簡化由多個基礎(chǔ)服務(wù)組合實現(xiàn)的共性服務(wù)；
●業(yè)務(wù)流程：是通過工作流引擎將多個服務(wù)編排起來，形成一個完整的業(yè)務(wù)流程，這是一種粒度更粗的服務(wù)，常用于實現(xiàn)一個標準的、可復用的大尺度業(yè)務(wù)流程，如審批等。
在應(yīng)用系統(tǒng)之間，SOA 依靠ESB 實現(xiàn)系統(tǒng)集成，ESB 是治理點對點式的系統(tǒng)集成的核心手段，它肩負著如下重擔：
●實現(xiàn)系統(tǒng)間的連通；
●數(shù)據(jù)轉(zhuǎn)換；
●智能路由；
●安全控制；
●可靠性控制；
●服務(wù)管理；
●監(jiān)控與日志。
以上是對SOA 的一個基本介紹，SOA 針對煙囪架構(gòu)的治理主要依賴于兩個方面：
一方面立足于每個應(yīng)用系統(tǒng)，要求系統(tǒng)對提供的“服務(wù)”進行提煉和抽象，確保其靈活、可重用，這是讓服務(wù)滿足外部復雜需求的根本保障；
另一方面是通過中心化的交互媒介——ESB 來約束系統(tǒng)間的交互，消除點對點式集成的負面影響。
但令人感慨的是：走到今天，SOA 已經(jīng)很少被人提及了，回看企業(yè)曾經(jīng)在SOA 上做出的嘗試和努力，最后的效果多數(shù)都不夠理想。在完成SOA 改造之后的若干年間，受到后續(xù)各種新系統(tǒng)的沖擊，很多企業(yè)都沒能堅守住自己的SOA 體系，最終又回到了煙囪架構(gòu)下的野蠻生長狀態(tài)，這其中的原因主要是：
溝通與協(xié)作成本高：新系統(tǒng)迫于業(yè)務(wù)需求和市場壓力，急需上線，對負責的團隊而言，與周邊系統(tǒng)的對接和調(diào)試屬于外部不可控因素，團隊總是傾向于在內(nèi)部可控的范圍內(nèi)解決問題，因此會刻意避開對外部服務(wù)的依賴，選擇自建相關(guān)功能，這樣一來，系統(tǒng)間的交互會向著衰減的方向發(fā)展，重復建設(shè)也因此隨之蔓延；
組織架構(gòu)制約：團隊往往缺乏為響應(yīng)其他系統(tǒng)的訴求而改造和升級自身服務(wù)的意愿，因為新系統(tǒng)與他們沒有直接的利益關(guān)系，企業(yè)也缺乏適當?shù)莫剳蜋C制促使各團隊之間的積極協(xié)作，本質(zhì)上，這是組織架構(gòu)決定的；
缺乏長效機制：SOA 改造常常是作為一個項目實施的，項目結(jié)束之后就不再有專門的組織和團隊對SOA 架構(gòu)進行持續(xù)把控了，后續(xù)新的系統(tǒng)在融入SOA 生態(tài)時受到的支持就減弱了，而新系統(tǒng)本身提供的服務(wù)也缺乏必要的梳理和管控，有的新系統(tǒng)甚至不對外提供服務(wù)。
這些問題并不是SOA 自身的問題，而是一些普遍的現(xiàn)實問題，也是治理煙囪架構(gòu)過程中遇到的深層次問題，這些問題阻礙了SOA 在企業(yè)的落地和持續(xù)發(fā)展。所以說SOA 是曾經(jīng)的“救贖”，企業(yè)IT 生態(tài)現(xiàn)在面臨的問題依然沒有得到很好的解決。
關(guān)于作者：耿立超，架構(gòu)師，14年IT系統(tǒng)開發(fā)和架構(gòu)經(jīng)驗，對大數(shù)據(jù)、企業(yè)級應(yīng)用架構(gòu)、SaaS、分布式存儲和領(lǐng)域驅(qū)動設(shè)計有豐富的實踐經(jīng)驗，熱衷函數(shù)式編程。目前負責企業(yè)數(shù)據(jù)中臺的架構(gòu)設(shè)計和開發(fā)工作，對Hadoop/Spark 生態(tài)系統(tǒng)有深入和廣泛的了解，參與過Hadoop商業(yè)發(fā)行版的開發(fā)，曾帶領(lǐng)團隊建設(shè)過數(shù)個完備的企業(yè)數(shù)據(jù)平臺，個人技術(shù)博客：https://laurence.blog.csdn.net/ 作者著有《大數(shù)據(jù)平臺架構(gòu)與原型實現(xiàn)：數(shù)據(jù)中臺建設(shè)實戰(zhàn)》一書。
