每天都在談SOA和微服務，但你真的理解什么是服務嗎？

服務的技術架構之爭

服務應該去版本化，不管是微服務還是SOA

任何架構的調整只是拆了東墻補西墻，無法解決效率問題

先厘清服務治理與組織架構的關系，再來談微服務吧

由于我們一直從事的是傳統企業的架構改造工作，所以對新興的互聯網企業如何實施微服務架構并沒有實踐過。在寫這一章之前，我在架構群里和曾經實施過微服務架構的互聯網企業的架構師進行了交流，結果是深深的失望。我看到互聯網企業為了快而失去的那些我覺得必不可少的能力，看到了以“簡單即美”為借口的粗糙。

為此，我重寫了這一章。在這之前的章節是將整個架構割裂開來，分別孤立的來探討分析。這一章我希望能盡我所能融合傳統服務體系與微服務于一體，構造一個平衡的、安全的、易于擴展的、易于維護的、高效的企業內服務架構。

企業內的集成架構

企業內部對待新建系統和存量系統在技術上的需求是不同的，往往已經建好的系統希望盡可能的穩定不進行大的架構和技術改變，同時還希望這些存量系統能夠盡可能的發揮作用；而新建的系統則希望在穩定可靠的基礎上盡可能的采用先進的技術和架構，以適應未來的發展不會很快落后過時。這樣的一種策略，必然的造成企業內部系統都是異構的，所以從長期看我們關注異構系統之間的應用集成架構，從短期看我們關注當期的新建系統的統一應用開發架構。

去中心架構不適合應用集成

企業內部的應用集成架構的需求是將現存的所有異構服務系統通過非侵入的適配技術手段進行整合，并對服務的消費者按需的提供接口。應用集成架構的這種需求決定了去中心架構不能適用。

去中心架構在集成架構中并無實際的意義，因為傳統的應用在沒有集成之前就已經是去中心架構的點對點網狀連接，正是這種異構系統之間雜亂的點對點網狀連接才催生了集成架構的出現。如果強行的將集成適配器分散到每一個應用形成應用前置的話，相當于為每一個應用獨立的部署了一套ESB，這樣做除了增加開銷之外完全看不出有什么實際的價值。

即便我們不考慮實際的價值，去中心的集成架構還是需要一個物理上的調度中心用以實現可能需要的服務組合。因為在任何一個應用的適配前置上都不具備實現組合的合理性（雖然應用架構師可以強行的選擇在某個或某幾個前置上實現）。

系統安全對去中心架構的限制

我們在第四章討論本征服務的時候給出了一個本征化后的微服務架構圖，如下：

我說看著細細的藍線條覺得不夠優雅，這里我們來看看傳統企業的部署架構示意圖：

其實，我是鼓足了勇氣來質疑這一件事情，在寫這篇文章之前我咨詢了做互聯網的朋友們，確信了在互聯網企業中是沒有DMZ區的，所有的應用都是混雜在一個區的，包括數據庫（當然，由于作者沒有互聯網公司的從業經驗，而通常互聯網公司都是自己做架構設計，所以我也沒有機會參與互聯網公司的架構設計，這一切只是道聽途說）。DMZ的具體作用相信大家都明白，當然不明白的可以去找一下相關的資料。因為安全原因一般WEBUI層都是部署在DMZ區的，我不想為了微服務而打破這一優良的設計，所以第四章的圖就變成這樣：

這幅圖里為了方便我把網關和組合服務容器放到了一起，其實他們可以分開部署（這不重要），重要的是這個架構已經回歸了ESB中心交換模式。其實傳統的SOA架構最終在企業內部也是這樣的，因為客戶數據的安全性永遠是第一位的。

那么我們擔心的淘寶級交易量怎么解決？我想說的是，犧牲客戶數據安全性來換取效率是絕對不可取得，幾千個應用部署在一個區內，怎么也無法保證每個應用都是堅固可靠、無懈可擊的，一旦肉機被攻破那么災難就來了，甚至惡意的程序員可以人為的制造肉機，這根本就防不住的。

如果無法提高算法效率，又無法通過削弱安全指標來提升效率，那么就只能拿資源來換了。為了保證客戶的利益，錢是要舍得花的，要么就別做這個業務。

通過分區多中心來降低集中負載

上圖中，通過將業務按條線進行不同的分區，每個分區用獨立的ESB集群進行集成。這樣，每個前端系統調用后臺服務的時候，就可以把訪問壓力分散到不同的分中心上，從而通過增加資源來提高訪問效率。

通過數據冗余來提高查詢類服務效率

通常，一個優秀的商業ESB產品可以產生從幾毫秒到十幾毫秒的系統延遲，對于大多數應用幾十到幾百毫秒的業務處理時間來說影響是微小的。但是當應用的處理時間縮短到幾毫秒、同時又要求海量的并發能力的時候（比如簡單查詢），集成架構帶來的延遲就變得無法忍受了（除非科技進步導致微秒級別的ESB成為現實）。

傳統的應用架構下通過數據集成的方式形成ODS、數據倉庫和數據集市來解決數據的查詢、報表和在線分析等實時或非實時數據類請求對業務系統帶來的壓力；互聯網模式采用讀寫分離的方式來解決類似的實時數據查詢的問題。所以，在上述架構中我們也提到短路的方式可以用數據集成架構來替代。

用ODS的方式解決實時數據的查詢相比較于用讀寫分離的方式來說，具有明顯的缺陷：

1、ODS存儲的數據范圍過大，而讀寫分離針對的是有海量查詢需求的數據，所以數據的命中率更高，這樣在利用冗余來提高效率方面比ODS的性價比更高。

2、ODS方式需要應用改變查詢邏輯從而增加系統間的耦合度，大多數應用只會關注自己的數據庫，如果在應用內部采用訪問ODS的方式來提高查詢效率的話，會造成應用依賴于外部的數據庫，從而造成從開發到運行整個應用生命周期內的效率降低。

造成前后臺大量交互問題的根源在于”前端展現系統需要后臺服務系統的數據”。為什么會這樣呢？其實，這是OOAD給我們帶來的誤區。傳統的面向對象的方法告訴我們，我們會把屬性和方法封裝成一個對象，以便于針對對象的一致性操作，于是我們會給“客戶”這個對象封裝上創建和查詢兩個方法，這非常符合直觀的邏輯。但是，這樣做真的合理嗎？

從面向服務的方法來看，查詢客戶信息這樣的服務真的不一定要客戶信息系統來實現，實際上任何一個系統來實現這個服務都是可能的。在現實社會中，每個人的信息在各個地方都存在不同的副本，比如在派出所存在，在人才中心存在，在你所在的公司也存在，其實當有人需要查詢你的個人信息的時候，基本會采用就近查詢的原則。面向對象的方法給我們造成一個誤區，這個誤區就是所有的行為都是和實體封裝綁定的，所以我們實現服務的時候也是將行為依附于實體。

其實，現實社會的做法是，（信息）行為會更靠近需求者和使用者。換句話說，我們應該在前端應用里建立要展現數據的副本，并在前端系統中提供查詢服務，因為只有前端系統才會更加頻繁的使用這些服務，簡單的說你們公司會給你建立個人信息副本，否則就要不斷的去戶籍所去查詢你的信息，我確信這不是開玩笑。如下圖，在前端系統建立對象經裁剪的的副本，就消除了系統間海量查詢的需求。

不過需要注意的是，由于WEB層都在DMZ區，將查詢庫放在DMZ區帶來數據安全的風險，這個我們前面已經講到了。所以，通過這種方法只能解決非關鍵數據的查詢效率問題。

企業內分布式多中心架構

?

上圖是保險行業某大型企業的真實案例，在架構改造的咨詢過程中，我們根據客戶的現狀和未來的發展方向，提出了以能力建設和消費為主要業務目標的分布式架構。

通過分布式服務中心，將企業的內部業務能力、傳統合作伙伴提供的能力、數據能力以及互聯網整合的第三方能力統一起來，建立全新的互聯網生態圈，使得無論是內部的、外部的、合作伙伴的還是來自互聯網的開發者都能夠方便的了解和使用這些能力，幫助企業生態圈的快速建設和擴展。

在運行時，原本相互孤立的互聯網區、外聯區和內網區存在的服務可以通過全局路由的形式被方便的訪問，在邏輯上成為一個整體；在管理和治理上，所有的服務都按照統一的流程在一套管理平臺上進行管理和治理。

能力中心的基本邏輯結構

邏輯上，能力聚合中心分為三個主要的部分，各部分通過隊列進行異步通信：

Out：服務（接出）容器

Out是服務實體或服務適配器的部署容器，可以認為是服務的實現者。在全局，邏輯上一個服務只有一個實現者（多個實現者可以認為是服務的集群方式）。

In：服務（接入）容器

In是服務API（適配器）的部署容器，為了實現S++的服務訪問位置和協議透明，在Out容器中的服務實體是無法被中心外部的物理消費者直接訪問的，Out中的服務通過在In中發布多種不同的API，來適應采用不同的訪問協議的服務消費者。

為了實現服務訪問地址透明，每個中心的In容器（如有必要）既可以發布本中心部署的服務API，也可以發布其他中心部署的服務的API，所以無論消費者從任何一個中心的渠道接入，都可以透明的訪問全局所有的服務。

Router：服務路由器

為了實現服務訪問地址對消費者透明，能力中心必須實現消費者無論從那個渠道接入，都可以透明的訪問全局任何一個服務，所以全局路由器必須維持全局服務的路由地址表，將In接入的服務請求正確的路由到服務所部署的Out容器。

基本上，每個中心都是由這樣的邏輯組件作為基礎運行平臺的。除了基礎運行平臺外，每個中心會根據自己的業務需求，增加其他的組件，比如外聯平臺會有一整套完備安全組件；互聯網開放平臺提供自服務的開發者門戶、主數據交換中心提供數據準實時同步能力等等。

互聯網開放平臺

開放平臺用于向互聯網應用開放企業內部的服務，以及引入互聯網上的第三方服務，系統應能抵御互聯網各類網絡攻擊，建立應用授權認證機制和隔離機制，具備完善的故障隔離機制，保證系統平穩運行。開放平臺是基于云架構進行構建，主要包括以下功能模塊：

開發者門戶：平臺提供開發者門戶，作為開發自服務的界面，包含開發者注冊、社區、應用和服務的管理等；

服務網關：提供針對服務的路由，協議轉換、流量控制、日志流水等管理。

OAuth授權：提供對用戶訪問資源的的開放授權協議。

運維監控平臺：平臺提供統一的管理監控平臺，完成平臺相關參數的設計，各類申請的審核以及服務、應用的監控和統計分析。

我們在互聯網開放平臺中引入了微服務，微服務應用會被部署在PaaS私有云中實現應用的動態擴展。所有的微應用都會掛接到API網關上，并由API網關對內對外提供微服務的路由，這個架構與我們前面提出的理論架構是基本一致的。

理論上，所有的應用都可以部署到PaaS云上，但為什么實際上不這么做呢？因為傳統應用過于龐大，不利于PaaS的動態響應，同時由于傳統應用提供不了本征化的服務，會導致云環境伸縮策略過于復雜，并降低云環境的可靠性。本文的最后一個章節，我們會去討論PaaS云的問題。

其余各中心能力簡介

外聯能力中心主要提供企業與傳統合作伙伴互聯互通的能力，通常都是通過專有的通信渠道進行鏈接，使用各自不同的安全協議和報文格式。

主數據能力中心主要對內外部應用提供主數據發布和同步能力，采用服務主題訂閱的模式，保證異步送達到數據消費者系統。消費者在本地形成數據副本，從而減小對業務系統和網絡的壓力，并提高查詢效率。

組合服務中心提供基于業務服務的全局和局部組合能力，并將組合后的流程作為新的服務發布出來供渠道調用。組合服務中心并不一定是一個真實的物理中心，他可以內嵌于各個物理中心內部。

小結

本章用一個實際的案例，介紹了分布式多中心架構，限于篇幅原因很多設計和實現細節無法展開來講。

分布式多中心架構是一個非常靈活的架構，可以根據客戶的實際情況進行任意的裁剪。為適應客戶不同的組織架構，服務治理采用可現場定制的治理流程，能同時適應注冊制和核準制兩種模式。并且，S++與分布式多中心架構的結合，賦予了微服務新的特性和更廣闊的前景：

1、微服務本征化，徹底實現微應用解耦，并大大簡化微服務開發和運維的難度。

2、S++服務組合容器使得基于服務的流程編排更簡單、易于維護，甚至業務人員可以直接使用。

3、S++的徹底的業務與技術分離，使得微服務的治理更加簡單，從而實現真正的業務敏捷。

4、S++并行組合的理論，將賦予微服務更高的性能和事務一致性保障，從而使得微服務可以更廣泛的應用于各個領域。

5、分布式多中心的架構與S++的結合，不但避免了去中心架構難以管理的問題，更保證了系統的安全性和效率。

最后，我們將在最后一章節探討S++化的微服務如何幫助PaaS環境實現基于服務質量的高靈敏度動態伸縮能力，從而能夠快速的響應突發網絡并發的沖擊。

總結

以上是生活随笔為你收集整理的我对分布式多中心架构的几点看法的全部內容，希望文章能夠幫你解決所遇到的問題。

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