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所示。
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/ 作者著有《大數據平臺架構與原型實現：數據中臺建設實戰》一書，該書已在京東和噹噹上線。