今天準備再聊下在當前微服務，中臺和雲原生技術下，傳統的SOA是否已經過時這個話題。現在出去跟別人交流，談到SOA的時候有些客戶直接的反饋就是過時的技術怎麼還在用？或者一說到SOA就認為過時了沒必要採用，因此今天還是有必要就SOA是否過時進一步說明。
SOA的基本概念我們可以來看下SOA本身的定義，即：
SOA是一種架構方法，將傳統的單片式應用打破，分解為離散的、自治的業務服務，利用標準提升他們的互操作性，從而可以更好地共享、重用和組裝，快速構建複合的應用從而滿足業務需求的變化。
在面對企業遺留IT系統架構的時候，SOA本身實際也是做兩個重要的事情，其一是找到各個遺留系統共性的可複用的業務能力；其次就是在構建上層業務流程的時候透過服務組裝和編排來完成。
因此SOA更多的是一種架構思想，進一步總結是：
基於遺留系統已有可複用的能力，分層組裝的方式來構建上層業務應用。
只要我們在架構設計的時候符合這個思想即是SOA。
當天在談SOA的時候一般會將SOA和ESB服務匯流排結合起來談。即認為SOA即是一個類似ESB匯流排的進行業務系統間介面整合和統一管控的整合平臺。
而ESB匯流排僅僅是實現SOA架構思想的一個工具，在前面談SOA架構思想談到一個是識別可重用的介面服務並統一管理，這個即是需要ESB匯流排來完成；另外一個就是對可複用的服務進行服務組裝或編排，而這個能力往往透過BPEL或BPM來完成。
如下圖所示：
即SOA架構思想的實現涉及到ESB匯流排和BPM產品的使用。同時介面的識別和定義是依託在遺留IT系統已有的能力暴露，而不是新產生的能力。
因此ESB匯流排一般也用於多個遺留系統之間的介面服務整合和統一管理。
從SOA到微服務首先看下微服務的一個定義，如下：
微服務可以在“自己的程式”中執行，並透過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。透過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序。
在原來的文章中我曾經談到過SOA和微服務的區別，即：
微服務架構強調的第一個重點就是原來的單體業務系統需要徹底的元件化和服務化，原有的單個業務系統會拆分為多個可以獨立開發，設計，執行和運維的小應用。這些小應用之間透過服務完成互動和整合。每個小應用從前端web ui，到控制層，邏輯層，資料庫訪問，資料庫都完全是獨立的一套。在這裡我們不用元件而用小應用這個詞更加合適，每個小應用除了完成自身本身的業務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發布為服務。
如果一句話來談SOA和微服務的區別，即微服務不再強調傳統SOA架構裡面比較重的ESB企業服務匯流排，同時SOA的思想進入到單個業務系統內部實現真正的元件化。
對於微服務實際本身又強調了幾個重點，簡單總結如下：
拆分後的微服務從資料庫，邏輯層到前端都完全獨立松耦合。微服務間透過輕量HTTP API介面互動微服務間以去中心化方式呼叫，不需要中心化匯流排平臺上面三點實際上是我們談微服務的時候經常會談到的三點。而對於微服務這個概念本身實際包括了微服務模組和微服務API介面兩個部分內容，即：
傳統單體=拆分多個微服務（微服務模組+暴露Http API介面）
當談微服務的時候一定是和傳統的單體應用對比來說的，如果沒有傳統單體應用，也沒有當前的微服務的概念。單體應用太大，太重了所以需要拆分，同時拆分微服務還需要透過輕量高效能的介面完成互動和協同。
當把這個理解清楚後，你會看到SOA和微服務實際出發點和目標完全是不同的，雖然兩者都會針對傳統的單體應用或遺留系統來談，但是要達到的效果不同。
SOA和ESB：遺留單體應用暴露可複用介面，並透過介面完成多系統整合微服務：遺留單體應用進行拆分，拆分為多個微服務，再去中心化整合如果從一個單體應用改造為微服務，那麼微服務將透過類似服務註冊中心等去中心化的方式完成整合。但是如果一個單體應用需要類似APP應用等前端訪問，往往仍然需要一個統一的代理閘道器來對外暴露介面，這個即常說的API閘道器。
API閘道器可以理解為一個輕量的ESB匯流排能力實現。
API閘道器不僅僅實現了服務代理和API介面的位置透明，同時也實現了類似服務安全，限流熔斷，日誌，監控等關鍵的服務治理管控能力。
SOA是否過時？再回到這篇文章的主題，即在微服務和雲原生時代，微服務是否過時的問題。在前面已經解釋了SOA和微服務的一些概念和區別。實際上你會看到SOA和微服務反而不是同一個層面的兩個概念。原來業務系統構建中的元件化才是和微服務對等的一個概念。
在雲計算不斷髮展演進過程中，整個IT架構也在不斷地發展演進，新的技術也在層出不窮，有些老的技術過時也是常見現象。但是當前實際是很多人連SOA是什麼都還沒有搞清楚，就在說SOA已經過時，這種人就是典型的追熱點，炒概念的人。
包括最近已經聽到很多人在說中臺過時了，阿里在拆中臺了，同樣這些人連中臺究竟是什麼？中臺思想本質在哪裡都沒有搞清楚就在批評中臺。包括有些提供中臺服務的廠商，把中臺吹得天花亂墜，無所不能，結果一到了客戶內部最終建設實施發現無法落地，發現原來的業務問題同樣無法解決，反而引入了更加難以管理的IT複雜度。
任何一個概念重點是理解思想，基於思想來考慮如何應用和落地實踐。
對於SOA，經常看到的過時說法主要包括如下幾點：
微服務是去中心化的，SOA還是中心化整合老架構微服務是Http API輕量介面，SOA下還是SOAP WS介面SOA和ESB很重並緊耦合，而微服務下輕量整合並松耦合當然還有其他的一些說法，重點都是在強調SOA中心化，SOA架構是很重的架構不再能夠靈活地適應業務變化和擴充套件。
因此，基於以上問題，再逐一展開分析和描述。
ESB匯流排和API閘道器注意API閘道器本身也是一箇中心化的API介面整合架構。
在微服務架構體系下本身是去中心化的架構，透過服務註冊中心來實現服務註冊發現和消費呼叫，那麼為何又需要使用API閘道器？
在傳統的ESB匯流排進行服務整合的時候我們就經常談到一個概念就是位置透明，即需要遮蔽底層業務模組提供API介面服務地址資訊，並實現多個微服務API介面的統一出口。即類似設計模式裡面經常談到的門面模式。
如何給API閘道器一個定義？
簡單來說API閘道器就是將所有的微服務提供的API介面服務能力全部匯聚進來，統一接入進行管理，也正是透過統一攔截，就可以透過閘道器實現對API介面的安全，日誌，限流熔斷等共性需求。如果再簡單說下，透過閘道器實現了幾個關鍵能力。
內部的微服務對外部訪問來說位置透明，外部應用只需和閘道器互動統一攔截介面服務，實現安全，日誌，限流熔斷等需求從這裡，我們就可以看到API閘道器和傳統架構裡面的ESB匯流排是類似的，這些關鍵能力本身也是ESB服務匯流排的能力，但是ESB服務匯流排由於要考慮遺留系統的接入，因此增加了：
大量介面卡實現對遺留系統的遺留介面適配，多協議轉換能力進行資料的複製對映，路由等能力對於兩者，我原來做過一個簡單的對比，大家可以參考。
因此一個應用內部的微服務模組之間可以去中心化整合，但是這個應用需要和傳統的遺留IT系統，需要和外部APP等進行介面整合的時候，往往就需要藉助API閘道器的能力來完成。
API閘道器本身也是中心化的架構。
即使對於一個應用內部，只要存在類似外部APP前端需要訪問後端服務介面，那麼就引入了API閘道器，整個架構就很難說是一個完全意義上的去中心化架構。
因此，簡單地說微服務完全去中心化，這個說法是不成立的。
新老架構並存時仍然需要ESB匯流排
同時在微服務架構實施過程中，一個微服務應用本身還需要和傳統的遺留IT系統之間整合，只要還存在這種傳統的遺留IT系統，那麼這種整合場景就存在，仍然需要透過類似ESB匯流排或輕量的SOA服務匯流排來完成介面整合和管控工作。
我們以一個整合場景來進行說明，即企業遺留系統整合採用ESB服務匯流排，而對於新建設的一個微服務應用採用API閘道器，那麼就存在兩者協同和整合的過程，整體整合架構如下：
可以看到，在這種整合架構下，微服務整體應用系統中所有的需要和遺留系統互動的介面全部首先接入和註冊到API閘道器，同時API閘道器暴露的服務進一步整合和註冊到ESB服務匯流排，形成兩級服務整合的方式。
在這種兩級服務整合模式下好處包括
微服務應用體系裡面的各個微服務僅僅需要暴露特定的API介面到閘道器和ESB內部微服務間的Rest API互動仍然可以走註冊中心，而且對外透明可以進一步使用ESB匯流排協議轉換和適配能力，完成SOAP和Rest介面轉換和適配雖然兩級整合模式下增加了一定的效能損耗，也拉長了整個服務呼叫鏈路。但是在新舊架構並存的過程中，這種兩級整合仍然是我們推薦採用的方式。既滿足了微服務應用內部的微服務治理要求，又實現了和外圍系統間的整合。
全微服務化應用構建場景接著再談下如果一個企業所有的IT系統都全新構建，同時都採用微服務架構方式進行構建。那麼這個時候是否可以做到完全意義上的去中心化架構，所有的微服化間都透過註冊中心去中心化的方式呼叫和整合。
對於企業資訊化來說，即使全微服務化，那麼傳統應用的虛擬邊界還在，這個短期並不能馬上改變。即類似供應鏈應用，合同應用，HR應用都採用微服務架構開發，但是這個應用的虛擬邊界還在，這個應用邊界存在的作用包括了：
透過應用需要劃分不同的開發組織或開發團隊應用之間是粗粒度的API介面整合，而非整個微服務整合當談到這裡的時候，你會看到仍然存在多個應用之間的整合問題需要解決。這個整合即可以採用輕量的API閘道器來完成。
舉例來說，合同應用拆分為10個微服務，10個微服務間可以去中心化整合。同時其中有一個APP前端微服務，這個在合同應用建設中引入了微服務閘道器來解決統一代理和出口問題。同時合同應用自己搭建了服務註冊中心，服務限流熔斷能力等。
在合同應用內部，管控的粒度是到微服務粒度即可。
但是當合同應用需要和供應鏈應用互動的時候，這個時候不可能將某個合同的微服務模組完全暴露給供應鏈應用，而是隻能夠暴露一個個粗粒度的API介面服務。
如果合同，供應鏈，HR三個應用只搭建一個類似Eureka服務註冊中心，那麼三個應用之間的訪問和邊界將出現完全混淆和不可控。這個不僅僅是安全類問題，也同樣存在介面亂用導致的緊耦合整合等問題。
從一個企業整個IT應用架構來看，打破虛擬應用的邊界，做到完全去中心化是一個艱難並漫長的過程。這個涉及到組織級IT管控治理能力成熟度，組織，開發，運維各個過程間的標準規範制定等。
所以不要簡單地說全新架構和全微服務化後，整個應用域就能夠做到完全的去中心化。實際上每個應用之間仍然難以去中心化，最佳的方式仍然是透過API閘道器或SOA匯流排來完成整合和互動。
SOA思想從來沒有過時對於SOA來說，重點不是ESB匯流排引擎，而是SOA參考架構思想。SOA架構思想裡面雖然也有遺留系統的適配和整合，但是更加重要的是從傳統的豎嚮應用構建思路轉變為橫向分層構建思路，同時抽取和識別可重用服務，透過服務組裝來滿足上層業務應用。
在談中臺的時候我就指出過，中臺思想實際上SOA思想和微服務兩者的融合。為何這樣講，我們來講中臺思想和中臺實現兩個層面來說。
共性可複用業務能力下沉，並提供給前臺應用使用=》SOA思想共效能力構建時候儘量大拆小，可擴充套件，松耦合=》微服務思想當前網際網路企業談的中臺基本就是SOA架構思想和微服務兩者的一個融合，既體現了共性業務能力下沉，又體現了共效能力要大拆小的微服務方式構建。如下圖：
當我們理解了這個核心概念後，我們才能夠認識到如下幾點關鍵認識。
中臺是一個業務層面概念，微服務是一個技術層面概念。中臺核心仍然是共性業務能力下沉和複用，只是網際網路企業在實現中臺架構的時候，將中臺技術實現和微服務做了融合。
因此企業內業務中臺實現，只要滿足共性業務能力統一提供給上層使用，即使底層提供能力的仍然是傳統遺留業務系統，那麼也可以將構建了一個業務服務能力中臺。
同時也可以看到微服務僅僅是中臺中應用到的一個技術實現，你可以在很多非中臺場景下采用微服務，小到原來一個業務系統拆分後全新構建這種場景。
在中臺構建中，中臺和前臺之間實際還需要一箇中臺提供的API介面服務的組裝和編排層，也可以理解為進一步的領域服務整合能力，而這個服務組合層，實際上和前面談到SOA裡面的服務組裝編排思想是完全一致的。
當重新思考中臺這個概念的時候，你會發現中臺本質還是SOA架構思想。在我們最終規劃和建設SOA整合平臺，ESB匯流排的時候就希望構建一個企業內部的服務能力共享平臺，為新的應用構建提供可複用介面服務能力。
這個和當前中臺思路是完全一致的。也就是說企業傳統SOA架構規劃實施中都難以落地實施的事情，絕對不是簡單地將概念包裝為中颱就能夠落地的，包括當前中臺還涉及到傳統IT架構的微服務化，更加難以推進。這個也是大量中臺專案建設失敗或夭折的原因。
結語最後簡單總結下前面談到的內容，即：
SOA架構思想從來就不存在過時的說法，同時當企業存在遺留IT系統，包括遺留IT系統逐步遷移和微服務的情況，往往同時存在ESB服務匯流排和API閘道器並存的情況。或者也可以採用ESB匯流排來提供API閘道器應該具備的能力。
隨著這個技術發展，企業IT治理管控能力加強，雲原生整體技術推進，治理能力的提升，才可能逐步做到完全的去中心化架構。
我們實施了很多大型的SOA整合平臺和ESB匯流排專案，同時也實施了微服務架構規劃諮詢和遷移類專案，更加認為企業IT架構微服務化是一個漫長過程，一定要圍繞業務目標驅動，逐步遷移和演進，最終達到一個目標架構。