?

作者 | 耿立超

責編 | 晉兆雨

來源 |?《大數據平臺架構與原型實現：數據中臺建設實戰》

SOA 所有的理念都是基于現有應用系統展開的，不管是對服務的梳理還是服務之間的交互，都是以現有應用系統為載體的，中臺不同于SOA 的地方在于：中臺是一種平臺化思維，它并不是從系統集成的角度去思考問題，而是從架構層面上重構了整個IT 生態。

相比之下，中臺無疑是一種更深刻、更底層的變革，因為它完全破除了應用之間的壁壘，把企業的核心業務能力“中心化”，把它們提煉并沉淀到中臺的各個業務中心上，而不是面向單一業務方向或渠道的應用系統上。這在SOA 架構下是很難實現的，因為中臺的業務中心與SOA 的服務載體（即應用系統）之間有著本質區別，它們的定位和服務對象都不同，這些區別決定了SOA 依然是一種相對松散的分治式的架構，很難與中臺這種更加中心化、更為強力的架構體系相抗衡。

煙囪式的生態系統并不是今天才突顯出來的，很多企業已經被這個問題困擾多年了，并且嘗試過各種措施試圖進行改善。回顧企業的IT 生態變遷史，一段不得不提的歷程就是SOA（面向服務的架構）。本文核心觀點援引自作者所著的《大數據平臺架構與原型實現：數據中臺建設實戰》一書，全書對數據中臺的理念、架構和具體實現做了詳細論述。

大概在2005 年前后的七八年間，隨著SOA 理念和相關技術（如ESB）的不斷發展和完善，SOA 在當時被認為是改善僵化的IT 生態、解決煙囪架構等弊病的終極方案而被業界寄予厚望，很多企業在那個時期紛紛上馬SOA 項目，希望憑借SOA 將企業的IT生態拉回到一種理想的狀態。十多年后回首當初那場SOA 熱潮，我們發現最終在SOA 改造上取得成功的企業少之又少，即使曾經取得了一定的成效，伴隨后來新業務系統的沖擊，當年辛苦建立的SOA 生態也大都名存實亡，是什么原因導致了這樣的結果呢？

人們很早就意識到點對點式的系統間交互是非常糟糕的，在SOA 起源之前，已經出現了基于消息隊列的“消息總線”架構，各個應用系統與消息總線連通，由消息總線負責將消息路由到接收方，從而讓應用系統通過中心化的消息總線完成交互，這樣就可以消除點對點式的系統交互。但是消息總線用于系統集成時在某些方面依然有所欠缺，例如消息都是靜態的、預定義的、無法自描述的，消息接口無法被注冊和發現。同時，另外一種以“服務”為視角看待和思考系統間交互的架構思想一直在不斷地發展，后來，隨著Web 服務（Web Service）技術的興起，IT 系統的對外接口逐漸向平臺中立的第一代Web 服務標準（WSDL+SOAP）靠攏，這為實施這一架構打開了大門，這就是SOA。

從系統集成的角度看，SOA 是一種非常理想的方案，SOA 體系的兩大核心如下：

• 對系統提供的對外交互進行提煉、組織和梳理，通過封裝、組合與編排，將接口以“服務”的形式發布出去；

• 系統間的交互統一通過中心化的企業服務總線（ESB）完成。?

典型的SOA 架構如圖1所示。

圖1 典型的SOA 架構

?SOA 成功的基礎是對“服務”的提煉、組織和梳理，只有服務足夠靈活才能支撐各種外部系統的復雜需求，而這一工作需要建立在對業務的深入了解之上，同時要融合良好的設計思想才能達到要求。?

SOA 中的“服務”在技術上以Web Service 為載體，但是在粒度（或者說抽象程度）上會有所不同，主要有如下三種粒度的服務：?

• 基礎服務：最細粒度的服務，最基本、最原子的服務都會在這一層，從服務數量上看，這一層也是最多的；

• 復合服務：是基于多個基礎服務組合疊加而成的粗粒度服務，多用于封裝并簡化由多個基礎服務組合實現的共性服務；

• 業務流程：是通過工作流引擎將多個服務編排起來，形成一個完整的業務流程，這是一種粒度更粗的服務，常用于實現一個標準的、可復用的大尺度業務流程，如審批等。?

在應用系統之間，SOA 依靠ESB 實現系統集成，ESB 是治理點對點式的系統集成的核心手段，它肩負著如下重擔：?

• 實現系統間的連通；

• 數據轉換；

• 智能路由；

• 安全控制；

• 可靠性控制；

• 服務管理；

• 監控與日志。?

以上是對SOA 的一個基本介紹，SOA 針對煙囪架構的治理主要依賴于兩個方面：?

• 一方面立足于每個應用系統，要求系統對提供的“服務”進行提煉和抽象，確保其靈活、可重用，這是讓服務滿足外部復雜需求的根本保障；

• 另一方面是通過中心化的交互媒介——ESB 來約束系統間的交互，消除點對點式集成的負面影響。?

但令人感慨的是：走到今天，SOA 已經很少被人提及了，回看企業曾經在SOA 上做出的嘗試和努力，最后的效果多數都不夠理想。在完成SOA 改造之后的若干年間，受到后續各種新系統的沖擊，很多企業都沒能堅守住自己的SOA 體系，最終又回到了煙囪架構下的野蠻生長狀態，這其中的原因主要是：?

• 溝通與協作成本高：新系統迫于業務需求和市場壓力，急需上線，對負責的團隊而言，與周邊系統的對接和調試屬于外部不可控因素，團隊總是傾向于在內部可控的范圍內解決問題，因此會刻意避開對外部服務的依賴，選擇自建相關功能，這樣一來，系統間的交互會向著衰減的方向發展，重復建設也因此隨之蔓延；

• 組織架構制約：團隊往往缺乏為響應其他系統的訴求而改造和升級自身服務的意愿，因為新系統與他們沒有直接的利益關系，企業也缺乏適當的獎懲機制促使各團隊之間的積極協作，本質上，這是組織架構決定的；

• 缺乏長效機制：SOA 改造常常是作為一個項目實施的，項目結束之后就不再有專門的組織和團隊對SOA 架構進行持續把控了，后續新的系統在融入SOA 生態時受到的支持就減弱了，而新系統本身提供的服務也缺乏必要的梳理和管控，有的新系統甚至不對外提供服務。?

這些問題并不是SOA 自身的問題，而是一些普遍的現實問題，也是治理煙囪架構過程中遇到的深層次問題，這些問題阻礙了SOA 在企業的落地和持續發展。所以說SOA 是曾經的“救贖”，企業IT 生態現在面臨的問題依然沒有得到很好的解決。

?

關于作者：耿立超，架構師，14年IT系統開發和架構經驗，對大數據、企業級應用架構、SaaS、分布式存儲和領域驅動設計有豐富的實踐經驗，熱衷函數式編程。目前負責企業數據中臺的架構設計和開發工作，對Hadoop/Spark 生態系統有深入和廣泛的了解，參與過Hadoop商業發行版的開發，曾帶領團隊建設過數個完備的企業數據平臺，個人技術博客：https://laurence.blog.csdn.net/ 作者著有《大數據平臺架構與原型實現：數據中臺建設實戰》一書。

?

該書已在京東和當當上線，掃描圖中二維碼了解詳情

更多推薦閱讀

• 沒想到！！Unicode 字符還能這樣玩？
  

• MongoDB 計劃從“Data Sprawl”中逃脫
  

• 推特驚爆史詩級漏洞，App 惡意竊取用戶隱私，云端安全路向何方？
  

• 開發者批評蘋果商店傭金過高，庫克將面臨立法者質疑；花唄接入央行征信；GitHub 發布更新| 極客頭條
  

• 那個從深圳流水線去了紐約做程序員的女工，最近失業了
  

總結

以上是生活随笔為你收集整理的SOA为什么不“香”了？ | 大咖说中台的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。