我對分佈式多中心架構的幾點見解

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

服務的技術架構之爭

服務應該去版本化，無論是微服務仍是SOA

任何架構的調整隻是拆了東牆補西牆，沒法解決效率問題

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

因爲咱們一直從事的是傳統企業的架構改造工做，因此對新興的互聯網企業如何實施微服務架構並無實踐過。在寫這一章以前，我在架構羣裏和曾經實施過微服務架構的互聯網企業的架構師進行了交流，結果是深深的失望。我看到互聯網企業爲了快而失去的那些我以爲必不可少的能力，看到了以「簡單即美」爲藉口的粗糙。

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

企業內的集成架構

企業內部對待新建系統和存量系統在技術上的需求是不一樣的，每每已經建好的系統但願儘量的穩定不進行大的架構和技術改變，同時還但願這些存量系統可以儘量的發揮做用；而新建的系統則但願在穩定可靠的基礎上儘量的採用先進的技術和架構，以適應將來的發展不會很快落後過期。這樣的一種策略，必然的形成企業內部系統都是異構的，因此從長期看咱們關注異構系統之間的應用集成架構，從短時間看咱們關注當期的新建系統的統一應用開發架構。

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

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

去中心架構在集成架構中並沒有實際的意義，由於傳統的應用在沒有集成以前就已是去中心架構的點對點網狀鏈接，正是這種異構系統之間雜亂的點對點網狀鏈接才催生了集成架構的出現。若是強行的將集成適配器分散到每個應用造成應用前置的話，至關於爲每個應用獨立的部署了一套ESB，這樣作除了增長開銷以外徹底看不出有什麼實際的價值。

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

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

咱們在第四章討論本徵服務的時候給出了一個本徵化後的微服務架構圖，以下：

我說看着細細的藍線條以爲不夠優雅，這裏咱們來看看傳統企業的部署架構示意圖：

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

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

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

若是沒法提升算法效率，又沒法經過削弱安全指標來提高效率，那麼就只能拿資源來換了。爲了保證客戶的利益，錢是要捨得花的，要麼就別作這個業務。

經過分區多中心來下降集中負載

上圖中，經過將業務按條線進行不一樣的分區，每一個分區用獨立的ESB集羣進行集成。這樣，每一個前端系統調用後臺服務的時候，就能夠把訪問壓力分散到不一樣的分中心上，從而經過增長資源來提升訪問效率。

經過數據冗餘來提升查詢類服務效率

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

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

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

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

二、ODS方式須要應用改變查詢邏輯從而增長系統間的耦合度，大多數應用只會關注本身的數據庫，若是在應用內部採用訪問ODS的方式來提升查詢效率的話，會形成應用依賴於外部的數據庫，從而形成從開發到運行整個應用生命週期內的效率下降。

形成先後臺大量交互問題的根源在於」前端展示系統須要後臺服務系統的數據」。爲何會這樣呢？其實，這是OOAD給咱們帶來的誤區。傳統的面向對象的方法告訴咱們，咱們會把屬性和方法封裝成一個對象，以便於針對對象的一致性操做，因而咱們會給「客戶」這個對象封裝上建立和查詢兩個方法，這很是符合直觀的邏輯。可是，這樣作真的合理嗎？

從面向服務的方法來看，查詢客戶信息這樣的服務真的不必定要客戶信息系統來實現，實際上任何一個系統來實現這個服務都是可能的。在現實社會中，每一個人的信息在各個地方都存在不一樣的副本，好比在派出所存在，在人才中心存在，在你所在的公司也存在，其實當有人須要查詢你的我的信息的時候，基本會採用就近查詢的原則。面向對象的方法給咱們形成一個誤區，這個誤區就是全部的行爲都是和實體封裝綁定的，因此咱們實現服務的時候也是將行爲依附於實體。在這裏順便給你們推薦一個架構交流羣：617434785，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源。相信對於已經工做和遇到技術瓶頸的碼友，在這個羣裏會有你須要的內容。

其實，現實社會的作法是，（信息）行爲會更靠近需求者和使用者。換句話說，咱們應該在前端應用裏創建要展示數據的副本，並在前端系統中提供查詢服務，由於只有前端系統纔會更加頻繁的使用這些服務，簡單的說大家公司會給你創建我的信息副本，不然就要不斷的去戶籍所去查詢你的信息，我確信這不是開玩笑。以下圖，在前端系統創建對象經裁剪的的副本，就消除了系統間海量查詢的需求。

不過須要注意的是，因爲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++與分佈式多中心架構的結合，賦予了微服務新的特性和更廣闊的前景：

一、微服務本徵化，完全實現微應用解耦，並大大簡化微服務開發和運維的難度。

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

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

四、S++並行組合的理論，將賦予微服務更高的性能和事務一致性保障，從而使得微服務能夠更普遍的應用於各個領域。

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

最後，咱們將在最後一章節探討S++化的微服務如何幫助PaaS環境實現基於服務質量的高靈敏度動態伸縮能力，從而可以快速的響應突發網絡併發的衝擊。