微服務架構和企業實施策略

下周二晚上我將在CIO時代APP做一個在線的講座分享，主題就是微服務架構和企業實施策略。有興趣聽的可以先提前安裝CIO時代這個APP，上面還有很多大數據，云計算，SOA和微服務架構，企業架構已經各個大的垂直行業的講座和實踐分享。

本次講座我主要講三個方面的內容：

1. 微服務架構的核心思想，以及從SOA到微服務架構的演進過程，兩者的區別。

2. 微服務架構實現中的核心部件微服務網關的核心功能分析和說明

3. 企業進行微服務架構實施可行的演進路線，以及在實施過程中可能存在的潛在風險分析。

首先來看下微服務架構核心思想部分的內容

在講微服務架構之前首先還是要介紹下SOA核心架構思想，微服務架構本身也是從SOA架構思想演進過來的。對于SOA經常說的定義就是，將支持企業IT的業務系統分解為多個組件，讓每個組件都獨立提供離散，自治，可復用的服務能力；同時通過服務的組合和編排來實現上層的業務流程。

這里面有兩個重點，其一就是找到服務，其二就是組合和組裝服務。對應到企業里面的實踐也可以總結為業務能力組件化，組件能力服務化，服務能力可編排化。

我們來看一個新公司注冊的例子來說明下SOA的核心，你要完成一個新公司注冊一定涉及到根工商，稅務，銀行多個政府部門和金融單位業務協同才能完成。要完成協同首先各個業務部門要將自己能力暴露為服務，即找到服務的過程。

找到服務后，我們再跟進業務流程需要將服務組裝起來，形成一個完整流程。

常規我們談SOA的時候都是談業務系統間的服務共享和集成，即最小管理單位是業務系統，如采購系統，ERP系統。但是如果進一步我們將管理最小單元變化為組件，即采購系統里面的采購訂單組件，供應商組件，那這就是SOA思想進一步內化到業務系統內部。而正是由于此，引出了微服務架構。

對于微服務你可以理解為將傳統單體應用打散為多個松耦合微服務模塊構成的架構模式，微服務模塊完全獨立自治，并通過輕量的HTTP API接口進行業務和數據協同。

所以要解釋微服務架構，首先你要看傳統單體應用究竟存在什么問題，如上面的圖。

很多單體應用有時候也在強調是基于組件化和模塊化的開始思路開發的，或者說是基于SOA架構開發，那從運行態和設計態分別來看的話可以看到。

從運行態的視角：

1. DB走HA或RAC集群，但是擴展性是大問題，很多應用后期即使走了RAC也無法解決性能問題。

2. 部署的是一個大WAR包，無法分模塊獨立分開部署。

3. WAR部署當前可以是物理機，也可以是虛擬機，但是WAR包偏重，很少直接部署到Docker容器的。

4. Application Server層的性能可以通過負載均衡方式進行水平擴展。

從設計態的視角：

1. DB本身是無法拆分的，各個模塊的數據庫，視圖全在一個大的SID或Schema里面。

2. 模塊之間的交互除了通過邏輯層外，還有些是直接通過DB層的跨表連接完成的。

3. 邏輯層的模塊和模塊之間往往是緊耦合的，相互間的調用隨意，很多都是內部API或方法調用。

不管是從運行態還是設計態來看，傳統的單體應用最大的問題就是各個組件和模塊之間緊耦合，而這種耦合帶來的問題就是擴展困難，升級和變更困難（模塊間相互影響大）。

其次，傳統單體應用面臨的第二個問題是展現層和邏輯層的緊耦合，而實際在當前應用架構設計和開發中，可以看到需要同時滿足電腦，平板，手機APP終端等多種前端展現和訪問。而這種訪問必須是支持分布式的接口服務訪問模式。傳統單體應用要做到這點也只有進行改造，比如再單獨增加一個服務代理組件來發布服務。

傳統單體應用到微服務架構

正是由于傳統單體應用存在的一些問題，微服務架構提出了將傳統單體應用打散為多個離散，自治的獨立組件。這些組件你可以稱呼它為微服務模塊，這些微服務模塊本身需要滿足的就是從數據庫，到邏輯層，到界面展現層都能夠是獨立的一套；微服務模塊能夠從需求，設計，開發，測試，部署上線和運維都相對獨立。

這個思想本質仍然是SOA架構思想和組件化思想在業務系統內部應用的體現。基于以上思考，傳統單體應用轉變為微服務架構后如下圖所示：

從運行態的視角：

1. 數據庫在部署的時候是可物理拆分的，即不同微服務模塊的數據庫可以獨立部署。

2. 微服務模塊的應用組件包是獨立部署的。

3. WAR包由于已經按模塊拆分為多個，因此每個WAR包相對來說更加輕，而容易部署到類似Docker容器上。

4. 由于WAR包之間有接口交互和協同，需要增加微服務網關實現服務管理和治理。

 

1. 數據庫，邏輯層和界面展現在設計的時候就是完全相對獨立的一套。

2. 邏輯層的各個組件之間只能通過Service API接口進行交互，微服務架構下推薦輕量Http Rest接口。

3. 邏輯層各個模塊之間徹底實現松耦合。各個模塊本身也更加輕量。

基于上面的分析可以看到，微服務架構本質仍然是SOA架構思想在業務系統內部的實施，即SOA思想不再是局限在業務系統間，而是已經顯性表現在了業務系統內部的各個業務組件間。但是SOA架構思想又不是微服務架構全部，里面還涉及很多組件化和領域建模思路，這個在考慮系統間集成的SOA項目中往往并不會太多涉及。

因此你可以將微服務架構思想理解為 SOA架構思想+組件化思想+領域建模思想的組合。我們很多時候在談微服務架構的時候都在談是否用了Spring Cloud, Spring Boot框架，是否走的Http Rest接口服務，這些都是技術層面的內容，如果前面這些組件劃分和領域服務識別定義這些工作沒做好，那實際上是一種假的微服務架構。正如原來很多人認為用了WebService接口就是SOA一樣的道理。

從ESB企業服務總線到微服務網關

我們在實施SOA項目時候，談的最多的就是基于ESB服務總線的集成平臺或服務共享平臺。ESB服務總線可以理解為將傳統的單點集成轉化為總線式集成的核心部件，它是企業內部業務系統間業務協同和數據集成的高速公路，通過將所有的服務注冊和接入，來實現對所有服務運行的管理和監控，在這個過程中提供了服務注冊，適配器，協議轉換，消息格式轉換，消息集成，數據映射，簡單服務編排，安全認證，日志，流控等多種能力。

而對于微服務架構下一樣，仍然需要對微服務架構進行統一管理，只是在微服務架構架構下都是標準的Http Rest接口和AMQP消息接口了，對于傳統的服務適配和協議轉換等沒有了，同時對于服務的編排這種重的能力也不再需要。那么更多的將體現在對服務的管理能力上。這種管理能力包括了服務的統一注冊和發現，服務安全，服務集群和路由，服務限流，日志等能力上。

在談微服務架構的核心組件的時候，有文章會把服務注冊和發現，微服務網關，服務限流和容錯能力并列，而實際上我們完全可以將上述能力全部做為微服務網關應該具備的能力。這些能力有些是在引擎層面的，有些是在管控層面的，都必須要具備。

對于微服務網關涉及的內容今天不做太詳細的展開，只講一些核心功能組件和要點說明。

首先看下服務注冊和發現功能，即網關要提供一個功能將微服務模塊暴露的Http Rest API接口能夠快速的注冊和接入，以變提供統一的服務目錄庫能力。對于服務注冊可以是手工注冊，但是也可以是動態自動注冊，特別是微服務架構和Docker容器結合的時候，必須要實現服務動態注冊過程，即當動態自動擴展部署了一個新的微服務模塊集群節點的時候，這個節點提供的微服務接口能實現自動注冊到微服務網關上。

在服務調用的時候可以看到，首先查詢服務注冊中心，在從服務注冊中心查詢拿到地址后發起對目標系統的服務調用。這種模式下可以看到鑒權和獲取服務地址過程與實際的服務接口調用過程是分離的，也就是說控制流和數據流是分離的。類似Dubbo總線的實現即是上面這種模式。

在這種模式下雖然微服務網關的性能很高，但是有兩個大缺點，其一是無法對數據流日志進行詳細監控，其二是源服務接口IP仍然向外暴露，無法真正做到SOA思想常說的訪問位置透明。如果是涉及到外面互聯網接口協同，這種模式存在很大安全隱患。

微服務網關統一接入和注冊服務后，自然提供對外統一的服務目錄庫，即在SOA里面常說的服務代理能力，將源服務簡單代理再包一層厚發布為統一IP地址的服務目錄庫。如下：

除了這個最基本能力外，微服務網關本身還提供如下能力：

• 服務反向路由 ，就是我上面談到的服務代理，提供統一服務目錄庫。
• 安全認證和防爬蟲 ，所有外部請求必須經過網關，網關可以集中對訪問進行安全控制，比如用戶認證和授權，同時還可以分析訪問模式實現防爬蟲功能，網關是連接企業內外系統的安全之門。
• 限流和容錯 ，在流量高峰期，網關可以限制流量，保護后臺系統不被大流量沖垮。對于容錯一方面是通過消息中間件緩存，一個是直接對服務進行熔斷處理。。
• 監控 ，網關可以集中監控訪問量，調用延遲，錯誤日志，集中化網關還可以監控數據日志。所有這些監控日志都是后續服務性能優化分析的重要參考。
• 其它能力 ：實現線上引流，線上壓測，線上調試(Surgical debugging)，金絲雀測試(Canary Testing)，數據中心雙活(Active-Active HA)等高級功能。

從這些能力提供來看，微服務網關相當強調了服務流量控制和容錯方面的能力，因為一旦這個能力實現的不好會導致整個處于中樞地位的微服務網關垮掉。基于上面講的內容，我們可以這樣理解ESB和微服務網關。

微服務網關 = 傳統ESB + 去掉了復雜服務適配和協議轉換 +去掉了服務編排 + 提升了限流容錯能力

 

由于微服務架構管理的粒度已經到了業務系統里面的一個個組件，因此企業在自身IT成熟度還沒有達到一定水平的時候，應該謹慎對待微服務架構，其核心原因就是

由于架構微服務化后會導致開發，集成，乃至后期的運維管控的復雜度呈指數級提升。即使企業本身有組件化和服務化的思想，但是也沒有能夠徹底構建微服務架構的能力。

任何事情都要考慮從簡單到復雜，通過迭代的方式逐步演進。對于可行切入點可以從以下幾方面考慮：

1. 共性技術服務能力下沉建設

企業在剛開始規劃建設，或者建設到一定階段后，都會涉及到一下基礎性的共性技術需求，類似消息管理，日志管理，文件存儲，共性的小應用組件（論壇，通訊錄，文檔在線閱讀）等。

這些共性能力既可以是技術服務，也可以是共性小應用程序，其最大的特點就是這些組件本身橫向交互相當少，而更多的是將自己的能力向上提供暴露和集成。因此這類場景采用微服務架構方式來獨立構建并部署是合適的，這類模塊的上線和集成可以最大限度的減少對已有橫向業務的影響。

2. 基礎平臺層能力先行

企業在實施微服務架構的時候，一定要意識到對于4A+流程引擎這兩個能力需要提取進行平臺化和微服務模塊化。因為這兩個基礎能力往往是任何一個業務微服務模塊能夠運轉起來的基礎。正是由于這兩個基礎能力的平臺化，我們在構建新的微服務模塊的時候，才能夠將重心完全放在只關注業務實現上。

3. 新增模塊移出

如果企業已經實施了采購系統而且已經上線運行多年，那么在對采購系統出現大的模塊級需求的時候（例如需求在采購需求中增加招投標的功能），那么這種模塊需求就可以考慮移出采購系統，通過微服務架構的方式獨立構建，在構建完成后在和采購管理系統集成。

對于一個新增模塊是否能移出，重點還是要考慮該模塊和已有的遺留業務系統間的耦合性和集成度。耦合度越小，越容易單獨構建并后期集成。從這個角度來看對于哪些在原有業務系統中上游業務最適合移出，例如招投標模塊構建只是需要將合格供應商和采購物料清單信息傳遞到采購系統，而并不需要從已有的采購系統返回任何信息。

4. 大變更下模塊移出

企業在接收到新的變更需求處理時，當已有業務系統的某一個模塊出現重大變更時（比如變更內容和范圍超過了模塊本身30%-50%），在這種情況下可以考慮將變更模塊移出并進行微服務架構的改造。

要清楚在模塊大變更情況下，即使按原有模塊開發和處理，也會帶來巨大的模塊開發和集成，聯調和實施工作量，還還不如和企業微服務架構演進策略一起處理。兩次對業務的大影響變成一次影響，雖然增加了復雜度，但是實際上是降低了整體工作量和后期遷移難度。

 

 

來自：http://blog.sina.com.cn/s/blog_493a84550102wqso.html