我對分散式多中心架構的幾點看法

• 2019 年 10 月 29 日
• 筆記

來源：http://t.cn/EtvljIz

• 企業內的集成架構
• 去中心架構不適合應用集成
• 系統安全對去中心架構的限制
• 通過分區多中心來降低集中負載
• 通過數據冗餘來提高查詢類服務效率
• 企業內分散式多中心架構
• 能力中心的基本邏輯結構
• 互聯網開放平台
• 其餘各中心能力簡介
• 小結

每天都在談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環境實現基於服務品質的高靈敏度動態伸縮能力，從而能夠快速的響應突發網路並發的衝擊。