今天準備再聊下在當前微服務(wù)，中臺和云原生技術(shù)下，傳統(tǒng)的SOA是否已經(jīng)過時這個話題?，F(xiàn)在出去跟別人交流，談到SOA的時候有些客戶直接的反饋就是過時的技術(shù)怎么還在用？或者一說到SOA就認為過時了沒必要采用，因此今天還是有必要就SOA是否過時進一步說明。

我們可以來看下SOA本身的定義，即：

SOA是一種架構(gòu)方法，將傳統(tǒng)的單片式應(yīng)用打破，分解為離散的、自治的業(yè)務(wù)服務(wù)，利用標準提升他們的互操作性，從而可以更好地共享、重用和組裝，快速構(gòu)建復(fù)合的應(yīng)用從而滿足業(yè)務(wù)需求的變化。

image.png

在面對企業(yè)遺留IT系統(tǒng)架構(gòu)的時候，SOA本身實際也是做兩個重要的事情，其一是找到各個遺留系統(tǒng)共性的可復(fù)用的業(yè)務(wù)能力；其次就是在構(gòu)建上層業(yè)務(wù)流程的時候通過服務(wù)組裝和編排來完成。

因此SOA更多的是一種架構(gòu)思想，進一步總結(jié)是：

基于遺留系統(tǒng)已有可復(fù)用的能力，分層組裝的方式來構(gòu)建上層業(yè)務(wù)應(yīng)用。

只要我們在架構(gòu)設(shè)計的時候符合這個思想即是SOA。當在談SOA的時候一般會將SOA和ESB服務(wù)總線結(jié)合起來談。即認為SOA即是一個類似ESB總線的進行業(yè)務(wù)系統(tǒng)間接口集成和統(tǒng)一管控的集成平臺。

而ESB總線僅僅是實現(xiàn)SOA架構(gòu)思想的一個工具，在前面談SOA架構(gòu)思想談到一個是識別可重用的接口服務(wù)并統(tǒng)一管理，這個即是需要ESB總線來完成；另外一個就是對可復(fù)用的服務(wù)進行服務(wù)組裝或編排，而這個能力往往通過BPEL或BPM來完成。

如下圖所示：

image.png

即SOA架構(gòu)思想的實現(xiàn)涉及到ESB總線和BPM產(chǎn)品的使用。同時接口的識別和定義是依托在遺留IT系統(tǒng)已有的能力暴露，而不是新產(chǎn)生的能力。

因此ESB總線一般也用于多個遺留系統(tǒng)之間的接口服務(wù)集成和統(tǒng)一管理。

image.png

微服務(wù)可以在“自己的程序”中運行，并通過“輕量級設(shè)備與HTTP型API進行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運行。通過這一點我們就可以將服務(wù)公開與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個API）區(qū)分開來。在服務(wù)公開中，許多服務(wù)都可以被內(nèi)部獨立進程所限制。如果其中任何一個服務(wù)需要增加某種功能，那么就必須縮小進程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進程。

在原來的文章中我曾經(jīng)談到過SOA和微服務(wù)的區(qū)別，即：

微服務(wù)架構(gòu)強調(diào)的第一個重點就是原來的單體業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化，原有的單個業(yè)務(wù)系統(tǒng)會拆分為多個可以獨立開發(fā)，設(shè)計，運行和運維的小應(yīng)用。這些小應(yīng)用之間通過服務(wù)完成交互和集成。每個小應(yīng)用從前端web ui，到控制層，邏輯層，數(shù)據(jù)庫訪問，數(shù)據(jù)庫都完全是獨立的一套。在這里我們不用組件而用小應(yīng)用這個詞更加合適，每個小應(yīng)用除了完成自身本身的業(yè)務(wù)功能外，重點就是還需要消費外部其它應(yīng)用暴露的服務(wù)，同時自身也將自身的能力朝外部發(fā)布為服務(wù)。

如果一句話來談SOA和微服務(wù)的區(qū)別，即微服務(wù)不再強調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時SOA的思想進入到單個業(yè)務(wù)系統(tǒng)內(nèi)部實現(xiàn)真正的組件化。

對于微服務(wù)實際本身又強調(diào)了幾個重點，簡單總結(jié)如下：

拆分后的微服務(wù)從數(shù)據(jù)庫，邏輯層到前端都完全獨立松耦合。

微服務(wù)間通過輕量HTTP API接口交互

微服務(wù)間以去中心化方式調(diào)用，不需要中心化總線平臺

上面三點實際上是我們談微服務(wù)的時候經(jīng)常會談到的三點。而對于微服務(wù)這個概念本身實際包括了微服務(wù)模塊和微服務(wù)API接口兩個部分內(nèi)容，即：
傳統(tǒng)單體=拆分多個微服務(wù)（微服務(wù)模塊+暴露Http API接口）

當談微服務(wù)的時候一定是和傳統(tǒng)的單體應(yīng)用對比來說的，如果沒有傳統(tǒng)單體應(yīng)用，也沒有當前的微服務(wù)的概念。單體應(yīng)用太大，太重了所以需要拆分，同時拆分微服務(wù)還需要通過輕量高性能的接口完成交互和協(xié)同。

當把這個理解清楚后，你會看到SOA和微服務(wù)實際出發(fā)點和目標完全是不同的，雖然兩者都會針對傳統(tǒng)的單體應(yīng)用或遺留系統(tǒng)來談，但是要達到的效果不同。

SOA和ESB：遺留單體應(yīng)用暴露可復(fù)用接口，并通過接口完成多系統(tǒng)集成

微服務(wù)：遺留單體應(yīng)用進行拆分，拆分為多個微服務(wù)，再去中心化集成

如果從一個單體應(yīng)用改造為微服務(wù)，那么微服務(wù)將通過類似服務(wù)注冊中心等去中心化的方式完成集成。但是如果一個單體應(yīng)用需要類似APP應(yīng)用等前端訪問，往往仍然需要一個統(tǒng)一的代理網(wǎng)關(guān)來對外暴露接口，這個即常說的API網(wǎng)關(guān)。

API網(wǎng)關(guān)可以理解為一個輕量的ESB總線能力實現(xiàn)。

API網(wǎng)關(guān)不僅僅實現(xiàn)了服務(wù)代理和API接口的位置透明，同時也實現(xiàn)了類似服務(wù)安全，限流熔斷，日志，監(jiān)控等關(guān)鍵的服務(wù)治理管控能力。
SOA是否過時？
再回到這篇文章的主題，即在微服務(wù)和云原生時代，微服務(wù)是否過時的問題。在前面已經(jīng)解釋了SOA和微服務(wù)的一些概念和區(qū)別。實際上你會看到SOA和微服務(wù)反而不是同一個層面的兩個概念。原來業(yè)務(wù)系統(tǒng)構(gòu)建中的組件化才是和微服務(wù)對等的一個概念。

在云計算不斷發(fā)展演進過程中，整個IT架構(gòu)也在不斷地發(fā)展演進，新的技術(shù)也在層出不窮，有些老的技術(shù)過時也是常見現(xiàn)象。但是當前實際是很多人連SOA是什么都還沒有搞清楚，就在說SOA已經(jīng)過時，這種人就是典型的追熱點，炒概念的人。

包括最近已經(jīng)聽到很多人在說中臺過時了，阿里在拆中臺了，同樣這些人連中臺究竟是什么？中臺思想本質(zhì)在哪里都沒有搞清楚就在批評中臺。包括有些提供中臺服務(wù)的廠商，把中臺吹得天花亂墜，無所不能，結(jié)果一到了客戶內(nèi)部最終建設(shè)實施發(fā)現(xiàn)無法落地，發(fā)現(xiàn)原來的業(yè)務(wù)問題同樣無法解決，反而引入了更加難以管理的IT復(fù)雜度。

任何一個概念重點是理解思想，基于思想來考慮如何應(yīng)用和落地實踐。

對于SOA，經(jīng)?？吹降倪^時說法主要包括如下幾點：

微服務(wù)是去中心化的，SOA還是中心化集成老架構(gòu)

微服務(wù)是Http API輕量接口，SOA下還是SOAP WS接口

SOA和ESB很重并緊耦合，而微服務(wù)下輕量集成并松耦合

當然還有其他的一些說法，重點都是在強調(diào)SOA中心化，SOA架構(gòu)是很重的架構(gòu)不再能夠靈活地適應(yīng)業(yè)務(wù)變化和擴展。

因此，基于以上問題，再逐一展開分析和描述。

image.png

在微服務(wù)架構(gòu)體系下本身是去中心化的架構(gòu)，通過服務(wù)注冊中心來實現(xiàn)服務(wù)注冊發(fā)現(xiàn)和消費調(diào)用，那么為何又需要使用API網(wǎng)關(guān)？

在傳統(tǒng)的ESB總線進行服務(wù)集成的時候我們就經(jīng)常談到一個概念就是位置透明，即需要屏蔽底層業(yè)務(wù)模塊提供API接口服務(wù)地址信息，并實現(xiàn)多個微服務(wù)API接口的統(tǒng)一出口。即類似設(shè)計模式里面經(jīng)常談到的門面模式。

如何給API網(wǎng)關(guān)一個定義？

簡單來說API網(wǎng)關(guān)就是將所有的微服務(wù)提供的API接口服務(wù)能力全部匯聚進來，統(tǒng)一接入進行管理，也正是通過統(tǒng)一攔截，就可以通過網(wǎng)關(guān)實現(xiàn)對API接口的安全，日志，限流熔斷等共性需求。如果再簡單說下，通過網(wǎng)關(guān)實現(xiàn)了幾個關(guān)鍵能力。

內(nèi)部的微服務(wù)對外部訪問來說位置透明，外部應(yīng)用只需和網(wǎng)關(guān)交互

統(tǒng)一攔截接口服務(wù)，實現(xiàn)安全，日志，限流熔斷等需求

從這里，我們就可以看到API網(wǎng)關(guān)和傳統(tǒng)架構(gòu)里面的ESB總線是類似的，這些關(guān)鍵能力本身也是ESB服務(wù)總線的能力，但是ESB服務(wù)總線由于要考慮遺留系統(tǒng)的接入，因此增加了：
大量適配器實現(xiàn)對遺留系統(tǒng)的遺留接口適配，多協(xié)議轉(zhuǎn)換能力

進行數(shù)據(jù)的復(fù)制映射，路由等能力

對于兩者，我原來做過一個簡單的對比，大家可以參考。

image.png

因此一個應(yīng)用內(nèi)部的微服務(wù)模塊之間可以去中心化集成，但是這個應(yīng)用需要和傳統(tǒng)的遺留IT系統(tǒng)，需要和外部APP等進行接口集成的時候，往往就需要借助API網(wǎng)關(guān)的能力來完成。

API網(wǎng)關(guān)本身也是中心化的架構(gòu)。

即使對于一個應(yīng)用內(nèi)部，只要存在類似外部APP前端需要訪問后端服務(wù)接口，那么就引入了API網(wǎng)關(guān)，整個架構(gòu)就很難說是一個完全意義上的去中心化架構(gòu)。

因此，簡單地說微服務(wù)完全去中心化，這個說法是不成立的。

新老架構(gòu)并存時仍然需要ESB總線

同時在微服務(wù)架構(gòu)實施過程中，一個微服務(wù)應(yīng)用本身還需要和傳統(tǒng)的遺留IT系統(tǒng)之間集成，只要還存在這種傳統(tǒng)的遺留IT系統(tǒng)，那么這種集成場景就存在，仍然需要通過類似ESB總線或輕量的SOA服務(wù)總線來完成接口集成和管控工作。

我們以一個集成場景來進行說明，即企業(yè)遺留系統(tǒng)集成采用ESB服務(wù)總線，而對于新建設(shè)的一個微服務(wù)應(yīng)用采用API網(wǎng)關(guān)，那么就存在兩者協(xié)同和集成的過程，整體集成架構(gòu)如下：

image.png

可以看到，在這種集成架構(gòu)下，微服務(wù)整體應(yīng)用系統(tǒng)中所有的需要和遺留系統(tǒng)交互的接口全部首先接入和注冊到API網(wǎng)關(guān)，同時API網(wǎng)關(guān)暴露的服務(wù)進一步集成和注冊到ESB服務(wù)總線，形成兩級服務(wù)集成的方式。

在這種兩級服務(wù)集成模式下好處包括

微服務(wù)應(yīng)用體系里面的各個微服務(wù)僅僅需要暴露特定的API接口到網(wǎng)關(guān)和ES

內(nèi)部微服務(wù)間的Rest API交互仍然可以走注冊中心，而且對外透明

可以進一步使用ESB總線協(xié)議轉(zhuǎn)換和適配能力，完成SOAP和Rest接口轉(zhuǎn)換和適配

雖然兩級集成模式下增加了一定的性能損耗，也拉長了整個服務(wù)調(diào)用鏈路。但是在新舊架構(gòu)并存的過程中，這種兩級集成仍然是我們推薦采用的方式。既滿足了微服務(wù)應(yīng)用內(nèi)部的微服務(wù)治理要求，又實現(xiàn)了和外圍系統(tǒng)間的集成。

image.png

對于企業(yè)信息化來說，即使全微服務(wù)化，那么傳統(tǒng)應(yīng)用的虛擬邊界還在，這個短期并不能馬上改變。即類似供應(yīng)鏈應(yīng)用，合同應(yīng)用，HR應(yīng)用都采用微服務(wù)架構(gòu)開發(fā)，但是這個應(yīng)用的虛擬邊界還在，這個應(yīng)用邊界存在的作用包括了：

通過應(yīng)用需要劃分不同的開發(fā)組織或開發(fā)團隊

應(yīng)用之間是粗粒度的API接口集成，而非整個微服務(wù)集成

當談到這里的時候，你會看到仍然存在多個應(yīng)用之間的集成問題需要解決。這個集成即可以采用輕量的API網(wǎng)關(guān)來完成。
舉例來說，合同應(yīng)用拆分為10個微服務(wù)，10個微服務(wù)間可以去中心化集成。同時其中有一個APP前端微服務(wù)，這個在合同應(yīng)用建設(shè)中引入了微服務(wù)網(wǎng)關(guān)來解決統(tǒng)一代理和出口問題。同時合同應(yīng)用自己搭建了服務(wù)注冊中心，服務(wù)限流熔斷能力等。

在合同應(yīng)用內(nèi)部，管控的粒度是到微服務(wù)粒度即可。

但是當合同應(yīng)用需要和供應(yīng)鏈應(yīng)用交互的時候，這個時候不可能將某個合同的微服務(wù)模塊完全暴露給供應(yīng)鏈應(yīng)用，而是只能夠暴露一個個粗粒度的API接口服務(wù)。

如果合同，供應(yīng)鏈，HR三個應(yīng)用只搭建一個類似Eureka服務(wù)注冊中心，那么三個應(yīng)用之間的訪問和邊界將出現(xiàn)完全混淆和不可控。這個不僅僅是安全類問題，也同樣存在接口亂用導(dǎo)致的緊耦合集成等問題。

從一個企業(yè)整個IT應(yīng)用架構(gòu)來看，打破虛擬應(yīng)用的邊界，做到完全去中心化是一個艱難并漫長的過程。這個涉及到組織級IT管控治理能力成熟度，組織，開發(fā)，運維各個過程間的標準規(guī)范制定等。

所以不要簡單地說全新架構(gòu)和全微服務(wù)化后，整個應(yīng)用域就能夠做到完全的去中心化。實際上每個應(yīng)用之間仍然難以去中心化，最佳的方式仍然是通過API網(wǎng)關(guān)或SOA總線來完成集成和交互。

對于SOA來說，重點不是ESB總線引擎，而是SOA參考架構(gòu)思想。SOA架構(gòu)思想里面雖然也有遺留系統(tǒng)的適配和集成，但是更加重要的是從傳統(tǒng)的豎向應(yīng)用構(gòu)建思路轉(zhuǎn)變?yōu)闄M向分層構(gòu)建思路，同時抽取和識別可重用服務(wù)，通過服務(wù)組裝來滿足上層業(yè)務(wù)應(yīng)用。

在談中臺的時候我就指出過，中臺思想實際上SOA思想和微服務(wù)兩者的融合。為何這樣講，我們來講中臺思想和中臺實現(xiàn)兩個層面來說。

共性可復(fù)用業(yè)務(wù)能力下沉，并提供給前臺應(yīng)用使用=》SOA思想

共性能力構(gòu)建時候盡量大拆小，可擴展，松耦合=》微服務(wù)思想

當前互聯(lián)網(wǎng)企業(yè)談的中臺基本就是SOA架構(gòu)思想和微服務(wù)兩者的一個融合，既體現(xiàn)了共性業(yè)務(wù)能力下沉，又體現(xiàn)了共性能力要大拆小的微服務(wù)方式構(gòu)建。如下圖：

image.png

當我們理解了這個核心概念后，我們才能夠認識到如下幾點關(guān)鍵認識。

中臺是一個業(yè)務(wù)層面概念，微服務(wù)是一個技術(shù)層面概念。中臺核心仍然是共性業(yè)務(wù)能力下沉和復(fù)用，只是互聯(lián)網(wǎng)企業(yè)在實現(xiàn)中臺架構(gòu)的時候，將中臺技術(shù)實現(xiàn)和微服務(wù)做了融合。

因此企業(yè)內(nèi)業(yè)務(wù)中臺實現(xiàn)，只要滿足共性業(yè)務(wù)能力統(tǒng)一提供給上層使用，即使底層提供能力的仍然是傳統(tǒng)遺留業(yè)務(wù)系統(tǒng)，那么也可以將構(gòu)建了一個業(yè)務(wù)服務(wù)能力中臺。

同時也可以看到微服務(wù)僅僅是中臺中應(yīng)用到的一個技術(shù)實現(xiàn)，你可以在很多非中臺場景下采用微服務(wù)，小到原來一個業(yè)務(wù)系統(tǒng)拆分后全新構(gòu)建這種場景。

在中臺構(gòu)建中，中臺和前臺之間實際還需要一個中臺提供的API接口服務(wù)的組裝和編排層，也可以理解為進一步的領(lǐng)域服務(wù)整合能力，而這個服務(wù)組合層，實際上和前面談到SOA里面的服務(wù)組裝編排思想是完全一致的。

image.png

當重新思考中臺這個概念的時候，你會發(fā)現(xiàn)中臺本質(zhì)還是SOA架構(gòu)思想。在我們最終規(guī)劃和建設(shè)SOA集成平臺，ESB總線的時候就希望構(gòu)建一個企業(yè)內(nèi)部的服務(wù)能力共享平臺，為新的應(yīng)用構(gòu)建提供可復(fù)用接口服務(wù)能力。

這個和當前中臺思路是完全一致的。也就是說企業(yè)傳統(tǒng)SOA架構(gòu)規(guī)劃實施中都難以落地實施的事情，絕對不是簡單地將概念包裝為中臺就能夠落地的，包括當前中臺還涉及到傳統(tǒng)IT架構(gòu)的微服務(wù)化，更加難以推進。這個也是大量中臺項目建設(shè)失敗或夭折的原因。

結(jié)語

最后簡單總結(jié)下前面談到的內(nèi)容，即：

SOA架構(gòu)思想從來就不存在過時的說法，同時當企業(yè)存在遺留IT系統(tǒng)，包括遺留IT系統(tǒng)逐步遷移和微服務(wù)的情況，往往同時存在ESB服務(wù)總線和API網(wǎng)關(guān)并存的情況?；蛘咭部梢圆捎肊SB總線來提供API網(wǎng)關(guān)應(yīng)該具備的能力。

隨著這個技術(shù)發(fā)展，企業(yè)IT治理管控能力加強，云原生整體技術(shù)推進，治理能力的提升，才可能逐步做到完全的去中心化架構(gòu)。

我們實施了很多大型的SOA集成平臺和ESB總線項目，同時也實施了微服務(wù)架構(gòu)規(guī)劃咨詢和遷移類項目，更加認為企業(yè)IT架構(gòu)微服務(wù)化是一個漫長過程，一定要圍繞業(yè)務(wù)目標驅(qū)動，逐步遷移和演進，最終達到一個目標架構(gòu)。