• 企業內的整合架構
• 去中心架構不適合應用整合
• 系統安全對去中心架構的限制
• 透過分割槽多中心來降低集中負載
• 透過資料冗餘來提高查詢類服務效率
• 企業內分散式多中心架構
• 能力中心的基本邏輯結構
• 網際網路開放平臺
• 其餘各中心能力簡介
• 小結

---

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