企業應用架構之微服務架構

微服務架構如今是談到企業應用架構時必聊的話題，微服務之因此火熱也是由於相對以前的應用開發方式有不少優勢，如更靈活、更能適應如今需求快速變動的大環境。

本文將介紹微服務架構的演進、優缺點和微服務應用的設計原則，而後着重介紹做爲一個「微服務應用平臺」須要提供哪些能力、解決哪些問題才能更好的支撐企業應用架構。

微服務平臺也是我目前正在參與的，還在研發過程當中的平臺產品，平臺是以SpringCloud爲基礎，結合了普元多年來對企業應用的理解和產品的設計經驗，逐步孵化的一個微服務應用平臺。

目錄：
1、微服務架構演進過程
2、微服務架構的好處
3、微服務應用4個設計原則
4、微服務架構帶來的問題
5、微服務平臺的19個落地實踐
6、總結展望

1、微服務架構演進過程

近年來咱們你們都體會到了互聯網、移動互聯帶來的好處，做爲IT從業者，在生活中時刻感覺互聯網好處的同時，在工做中可能感覺的倒是來自自互聯網的一些壓力，那就是咱們傳統企業的IT建設也是迫切須要轉型，須要面向外部客戶，咱們也須要應對外部環境的快速變化、須要快速創新，那麼咱們的IT架構也須要向互聯網企業學習做出相應的改進，來支撐企業的數字化轉型。

咱們再看一下應用架構的演進過程，回憶一下微服務架構是如何一步一步進化產生的，最先是應用是單塊架構，後來爲了具有必定的擴展和可靠性，就有了垂直架構，也就是加了個負載均衡，接下來是前幾年比較火的SOA，主要講了應用系統之間如何集成和互通，而到如今的微服務架構則是進一步在探討一個應用系統該如何設計纔可以更好的開發、管理更加靈活高效。

微服務架構的基本思想就是「圍繞業務領域組件來建立應用，讓應用能夠獨立的開發、管理和加速」。

2、微服務架構的好處

咱們總結了四個方面的優勢，分別以下：

• 是每一個微服務組件都是簡單靈活的，可以獨立部署。再也不像之前同樣，應用須要一個龐大的應用服務器來支撐。
• 能夠由一個小團隊負責更專一專業，相應的也就更高效可靠。
• 微服務之間是鬆耦合的，微服務內部是高內聚的，每一個微服務很容易按需擴展。
• 微服務架構與語言工具無關，自由選擇合適的語言和工具，高效的完成業務目標便可。

看到這裏，你們會以爲微服務架構挺不錯，然而還會有一些疑問，什麼樣的應用算是一個微服務架構的應用？該怎樣設計一個微服務架構的應用？那咱們來一塊兒看看咱們推薦的微服務應用的設計原則。

3、微服務應用4個設計原則

咱們總結了四個原則推薦給你們：

• AKF拆分原則
• 先後端分離
• 無狀態服務
• Restful通訊風格

1.AKF拆分原則

AKF擴展立方體（參考《The Art of Scalability》），是一個叫AKF的公司的技術專家抽象總結的應用擴展的三個維度。理論上按照這三個擴展模式，能夠將一個單體系統，進行無限擴展。
X 軸 ：指的是水平復制，很好理解，就是講單體系統多運行幾個實例，作個集羣加負載均衡的模式。
Z 軸 ：是基於相似的數據分區，好比一個互聯網打車應用忽然或了，用戶量激增，集羣模式撐不住了，那就按照用戶請求的地區進行數據分區，北京、上海、四川等多建幾個集羣。
Y 軸 ：就是咱們所說的微服務的拆分模式，就是基於不一樣的業務拆分。

場景說明：好比打車應用，一個集羣撐不住時，分了多個集羣，後來用戶激增仍是不夠用，通過分析發現是乘客和車主訪問量很大，就將打車應用拆成了三個乘客服務、車主服務、支付服務。三個服務的業務特色各不相同，獨立維護，各自均可以再次按需擴展。

2.先後端分離

先後端分離原則，簡單來說就是前端和後端的代碼分離也就是技術上作分離，咱們推薦的模式是最好直接採用物理分離的方式部署，進一步促使進行更完全的分離。不要繼續之前的服務端模板技術，好比JSP ，把Java JS HTML CSS 都堆到一個頁面裏，稍複雜的頁面就沒法維護。這種分離模式的方式有幾個好處：

• 先後端技術分離，能夠由各自的專家來對各自的領域進行優化，這樣前端的用戶體驗優化效果會更好。
• 分離模式下，先後端交互界面更加清晰，就剩下了接口和模型，後端的接口簡潔明瞭，更容易維護。
• 前端多渠道集成場景更容易實現，後端服務無需變動，採用統一的數據和模型，能夠支撐前端的web UI 移動App等訪問。

3.無狀態服務

對於無狀態服務，首先說一下什麼是狀態：若是一個數據須要被多個服務共享，才能完成一筆交易，那麼這個數據被稱爲狀態。進而依賴這個「狀態」數據的服務被稱爲有狀態服務，反之稱爲無狀態服務。

那麼這個無狀態服務原則並非說在微服務架構裏就不容許存在狀態，表達的真實意思是要把有狀態的業務服務改變爲無狀態的計算類服務，那麼狀態數據也就相應的遷移到對應的「有狀態數據服務」中。

場景說明：例如咱們之前在本地內存中創建的數據緩存、Session緩存，到如今的微服務架構中就應該把這些數據遷移到分佈式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移後，就能夠作到按需動態伸縮，微服務應用在運行時動態增刪節點，就再也不須要考慮緩存數據如何同步的問題。

4.Restful通訊風格

做爲一個原則來說原本應該是個「無狀態通訊原則」，在這裏咱們直接推薦一個實踐優選的Restful 通訊風格 ，由於他有不少好處：

• 無狀態協議HTTP，具有先天優點，擴展能力很強。例如須要安全加密是，有現成的成熟方案HTTPS可用。
• JSON 報文序列化，輕量簡單，人與機器都可讀，學習成本低，搜索引擎友好。
• 語言無關，各大熱門語言都提供成熟的Restful API框架，相對其餘的一些RPC框架生態更完善。

固然在有些特殊業務場景下，也須要採用其餘的RPC框架，如thrift、avro-rpc、grpc。但絕大多數狀況下Restful就足夠用了。

4、微服務架構帶來的問題

作到了前面講的四個原則，那麼就能夠說是構建了一個微服務應用，感受上也不復雜。但實際上微服務也不是個萬金油，也是有利有弊的，接下來咱們來看看引入微服務架構後帶來的問題有哪些。

• 依賴服務變動很難跟蹤，其餘團隊的服務接口文檔過時怎麼辦？依賴的服務沒有準備好，如何驗證我開發的功能。
• 部分模塊重複構建，跨團隊、跨系統、跨語言會有不少的重複建設。
• 微服務放大了分佈式架構的系列問題，如分佈式事務怎麼處理？依賴服務不穩定怎麼辦？
• 運維複雜度陡增，如：部署物數量多、監控進程多致使總體運維複雜度提高。

上面這些問題咱們應該都遇到過，而且也會有一些解決方案，好比提供文檔管理、服務治理、服務模擬的工具和框架； 實現統一認證、統一配置、統一日誌框架、分佈式彙總分析； 採用全局事務方案、採用異步模擬同步；搭建持續集成平臺、統一監控平臺等等。

這些解決方案折騰到最後終於搞明白了，原來咱們是須要一個微服務應用平臺才能總體性的解決這些問題。

5、微服務平臺的19個落地實踐

1.企業IT建設的三大基礎環境

咱們先來宏觀的看一下，一個企業的IT建設很是重要的三大基礎環境：團隊協做環境、我的基礎環境、IT基礎設施。

• 團隊協做環境：主要是DevOps領域的範疇，負責從需求到計劃任務，團隊協做，再到質量管理、持續集成和發佈。
• 我的基礎環境：就是本文介紹的微服務應用平臺，他的目標主要就是要支撐微服務應用的設計開發測試，運行期的業務數據處理和應用的管理監控。
• IT基礎設施：就是咱們一般說的各類運行環境支撐如IaaS (VM虛擬化)和CaaS (容器虛擬化)等實現方式。

2.微服務應用平臺整體架構

微服務應用平臺的整體架構，主要是從開發集成、微服務運行容器與平臺、運行時監控治理和外部渠道接入等維度來劃分的。

• 開發集成：主要是搭建一個微服務平臺須要具有的一些工具和倉庫
• 運行時：要有微服務平臺來提供一些基礎能力和分佈式的支撐能力，咱們的微服務運行容器則會運行在這個平臺之上。
• 監控治理：則是致力於在運行時可以對受管的微服務進行統一的監控、配置等能力。
• 服務網關： 則是負責與前端的WEB應用 移動APP 等渠道集成，對前端請求進行認真鑑權，而後路由轉發。

3.微服務應用平臺的運行視圖

參考上圖，在運行期，做爲一個微服務架構的平臺與業務系統，除了業務應用自己外，還須要有接入服務、統一門戶、基礎服務等平臺級服務來保障業務系統的可靠運行。圖中的公共服務就是業務處理過程當中須要用到的一些可選服務。

4.微服務平臺的設計目標

微服務平臺的主要目標主要就是要支撐微服務應用的全生命週期管理，從需求到設計開發測試，運行期的業務數據處理和應用的管理監控等，後續將從應用生命週期的幾個重要階段切入，結合前面提到的設計原則和問題，介紹平臺提供的能力支撐狀況。

5.微服務開發：前端、後端、混合

咱們一塊兒看一下咱們正在開發中的微服務應用平臺EOS8.0的一些開發工具截圖，瞭解一下開發期提供了哪些關鍵的能力支撐。

前面的設計原則中提到了一個先後端分離的原則，那麼咱們的開發環境中，目前支持建立前端項目、後端項目和混合項目。其中前端項目、後端項目就對應先後端分離的原則，利用平臺中集成的開發工具和框架能夠作到先後端開發分離，利用持續集成工具能夠方便的將前端、後端項目編譯打包成可獨立運行的程序。混合項目則是爲了兼容傳統模式而保留的，爲企業應用向微服務架構演進提供過渡方案。

6.服務契約與API管理

對於前面提到的微服務帶來的依賴管理問題，咱們能夠經過平臺提供的API管理能力來解決。說到API管理，那首先就用提到服務契約。平臺開發工具中提供了方便的服務發佈能力，可以快速的將業務功能對外發布，生成服務的規格契約，固然也能夠先設計服務契約，在根據契約來生成服務的默認實現代碼。

這裏強調一下，咱們提到的服務契約是一個很重要的東西，他有點相似web service的wsdl描述，主要描述服務接口的輸入輸出規格標準和其餘一些服務調用集成相關的規格內容。

7.服務契約與服務模擬

有了服務契約，咱們就能夠根據契約自動生成服務的文檔和服務模擬測試環境，這樣，開發者就能夠方便的獲取到依賴服務變動的狀況，可以及時的根據依賴服務的變化調整本身的程序，而且可以方便的進行模擬測試驗證。

根據契約生成模擬服務也就是咱們常說的服務擋板，這樣即便依賴的其餘服務還沒法提供功能，咱們也能夠經過擋板來進行聯調測試。

8.服務契約與服務編排

有了服務契約，那就有了服務接口的輸入輸出規格，那麼restful的服務編排也就變得可行。在咱們設計的契約標準中，還定義了調用集成相關的內容，好比服務支持的事務模式等等。經過這些約定，咱們就能夠採用簡單圖形化的方式來對業務服務流程進行編排。編排可以很大程度上簡化分佈式服務調用的複雜度，如同步、異步、異步模擬同步、超時重試、事務補償等，均有服務編排引擎完成，再也不徹底依賴老師傅的編碼能力。

服務編排的做用和意義很大，能夠快速的將已經提供的微服務能力進行組合發佈，很是適合業務的快速創新。

可是你們要注意，邏輯流編排的是業務流程，儘可能可以簡單明瞭，一眼看上去就明白業務含義。而業務規則推薦採用服務內部進行編碼實現。千萬不要將咱們的 「邏輯流」 圖形化服務編排徹底取代程序編碼，這樣就會可能會走入另一個極端，好比設計出像蜘蛛網同樣的邏輯流圖，簡直就是災難。

9.微服務容器

咱們再來看一下微服務運行容器的一個邏輯圖，你們能夠看到，咱們要作微服務架構的應用，可靠高效的微服務應用，實際上咱們須要作的事情仍是很是多的。若是沒有一個統一的微服務容器，這些能力在每一個微服務組件中都須要建設一遍，並且會五花八門，也很難集成到一塊兒。有了統一的微服務運行容器和一些公共的基礎服務，前面所提到的微服務架構下部分組件重複建設的問題也迎刃而解。

10.三方能力集成說明

咱們的API管理契約文檔API模擬咱們是集成了Swagger的工具鏈。微服務應用平臺的基礎就是SpringCloud，從容器框架到註冊發現再到安全認證這些基礎方案均採用了他的能力來支撐。下面簡單看下咱們集成的一些開源框架和工具。

SpringCloud在微服務平臺中的定位是基礎框架，本文重點是要介紹一個企業級的微服務平臺在落地過程當中的一些設計原則和解決方案。具體Spring Cloud相關的技術就不在文中多作介紹了，你們能夠在咱們的公衆號裏面查看相關文章。

11.服務註冊發現路由

接下來咱們聊一下注冊發現，之前的單塊應用之間互相調用時配置個IP就好了，但在微服務架構下，服務提供者會有不少，手工配置IP地址又變成了一個不可行的事情。那麼服務自動註冊發現的方案就解決了這個問題。

咱們的服務註冊發現能力是依賴SpringCloud Eureka組件實現的。服務在啓動的時候，會將本身要發佈的服務註冊到服務註冊中心，運行時，若是須要調用其餘微服務的接口，那麼就要先到註冊中心獲取服務提供者的地址，拿到地址後，經過微服務容器內部的簡單負載均衡期進行路由用。

通常狀況，系統內微服務的調用都經過這種客戶端負載的模式進行，不然就須要有不少的負載均衡進程。跨業務系統的服務調用，也能夠採用這種去中心化的路由方式。固然採用SOA的模式，由中心化的服務網管來管理系統間的調用也是另外一種選擇，要結合企業的IT現狀和需求來決定。

12.統一認證鑑權

安全認證方面，咱們基於Spring Security結合Auth2再加上JWT（Json web token）作安全令牌，實現統一的安全認證與鑑權，使得微服務之間可以按需隔離和安全互通。後續在統一認證和權限方面咱們產品會陸續推出較完善而且擴展性良好的微服務組件，能夠做爲微服務平臺的公共的認證和鑑權服務。再囉嗦一句，認證鑑權必定是個公共的服務，而不是多個系統各自建設。

13.日誌與流水設計

做爲一個微服務應用平臺除了提供支撐開發和運行的技術組件和框架以外，咱們還提供一些運維友好的經驗總結，咱們一塊兒來看一下咱們推薦的日誌與流水實現，先來看日誌，平臺默認回會提供的日誌主要有三種，系統日誌，引擎日誌還有跟蹤日誌。有了這些日誌，在出問題的時候可以幫助咱們獲取一些關鍵信息進行問題定位。

要想作到出了問題可以追根溯源，那麼右邊的這些流水號的設計也是很是重要的，日誌與各類流水號配合，可以讓咱們快速定位問題發生的具體時間地點以及相關信息，可以快速還原業務交易全鏈路。對這些日誌與流水的細節處理，對於系統運維問題定位有很是大的幫助，沒有這些有用的日誌內容，ELK日誌收集套件搭建的再漂亮，收一對垃圾日誌也是沒用的。一般開源框架只是提供個框架有開發人員自由發揮，而設計一個平臺則必定要考慮直接提供統一規範的基礎能力。

14.集中配置管理

微服務分佈式環境下，一個系統拆分爲不少個微服務，必定要告別投產或運維手工修改配置配置的方式。須要採用集中配置管理的方式來提高運維的效率。

配置文件主要有運行前的靜態配置和運行期的動態配置兩種。靜態配置一般是在編譯部署包以前設置好。動態配置則是系統運行過程當中須要調整的系統變量或者業務參數。要想作到集中的配置管理，那麼須要注意如下幾點。

• 是配置與介質分離，這個就須要經過制定規範的方式來控制。千萬別把配置放在Jar包裏。
• 是配置的方式要統一，格式、讀寫方式、變動熱更新的模式儘可能統一，要採用統一的配置框架
• 就是須要運行時須要有個配置中心來統一管理業務系統中的配置信息，這個就須要平臺來提供配置中心服務和配置管理門戶。

15.統一管理門戶

微服務架構下，一個大的EAR、WAR應用被拆爲了多個小的可獨立運行的微服務程序，一般這些微服務程序都再也不依賴應用服務器，不依賴傳統應用服務器的話，應用服務器提供管理控制檯也就沒得用了，因此微服務的運行時管理須要有統一的管理門戶來支撐。咱們規劃了的統一集中的微服務門戶，能夠支撐 應用開發、業務處理、應用管理、系統監控等。上圖是應用管理頁面，就是對咱們傳統意義上的業務系統進行管理，點擊一個業務系統，咱們就可以看到系統下有哪些微服務，每一個微服務有幾個節點實例再運行，能夠監控微服務的子節點狀態，對微服務進行配置管理和監控。

16.分佈式事務問題

微服務架構的系統下，進程成倍增多，那麼也分佈式事務一致性的問題也就更加明顯。咱們這裏說的事務一致性，不是傳統說的基於數據庫實現的技術事務。微服務之間是獨立的、調用協議也是無狀態的，所以數據庫事務方案在一開始就已經再也不咱們考慮的範圍內。咱們要解決的是必定時間後的數據達到最終一致狀態，準確的說就是採用傳統的業務補償與衝正方式。

推薦的事務一致性方案有三種：

• 可靠事件模式：即事件的發送和接收保障高可靠性，來實現事務的一致性。
• 補償模式：Confirm Cancel ，若是確認失敗，則所有逆序取消。
• TCC模式：Try Confirm Cancel ，補償模式的一種特殊實現 一般轉帳類交易會採用這種模式。

17.分佈式同步調用問題

微服務架構下，相對於傳統部署方式，存在更多的分佈式調用，那麼「如何在不肯定的環境中交付肯定的服務」，這句話能夠簡單理解爲，我所依賴的服務的可靠性是沒法保證的狀況下，我如何保證本身能

賴的其餘服務拖垮？

咱們推薦SEDA架構來解決這個問題。

SEDA : staged event-driven architecture本質上就是採用分佈式事件驅動的模式，用異步模擬來同步，無阻塞等待，再加上資源分配隔離結起來的一個解決方案。

18.持續集成與持續交付設計

在運維方面，首先咱們要解決的就是持續集成和持續交付，而微服務應用平臺的職責範圍目前規劃是隻作持續集成，可以方便的用持續集成環境把程序編譯成介質包和部署包。（目前規劃持續部署由DevOps平臺提供相應能力，微服務平臺可與DevOps平臺集成）

這裏要釐清一個概念：介質，是源碼編譯後的產物，與環境無關，多環境下應該是能夠共用的，如：jar、dockerfile；配置：則是環境相關的信息。配置+介質=部署包。

獲取到部署包以後，微服務應用平臺的職責就完成了，接下來就是運維人員各顯神通來進行上線部署操做。

19.微服務平臺與容器雲、DevOps的關係

就微服務應用平臺自己來講，並不依賴DevOps和容器雲，開發好的部署包能夠運行在物理機、虛擬機或者是容器中。

然而當微服務應用平臺結合了DevOps和容器雲以後，咱們就會發現，持續集成和交付變成了一個很是簡單便捷而且又可靠的過程。

簡單幾步操做，整套開發、測試、預發或者生產環境就可以搭建完成。整個過程的複雜度都由平臺給屏蔽掉了，經過三大基礎環境的整合，咱們可以使分散的微服務組件更簡單方便的進行統一管理和運維交付。

6、總結展望

文章說到這裏也給你們推薦一個架構方面的交流學習羣650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源，如下腦圖資料在羣的共享區裏面免費分享給你們的，相信對於已經工做和遇到技術瓶頸的碼友，在這個羣裏會有你須要的內容。

最後咱們再來回顧一下，三大基礎環境的關係。微服務應用平臺負責應用開發、運行以及管理；DevOps負責項目管理、計劃管理、CI、CD和團隊溝通協做等；容器雲平臺則負責基礎設置管理，屏蔽環境的複雜度。

這三大基礎環境的建設狀況，直接反應出了企業IT能力水平。這三大基礎環境是技術人員和企業都但願擁有的，是企業贏得競爭、驅動業務創新的基礎，是企業加速數字化轉型的必由之路。

注：文章轉載自公衆號：EAWorld