作者｜郝炎峰

編輯｜小智

本文將介紹微服務架構的演進、優缺點和微服務應用的設計原則，然后著重介紹作為一個“微服務應用平臺”需要提供哪些能力、解決哪些問題才能更好的支撐企業應用架構。

注：本文轉載自公眾號 EAWorld，已獲授權。

寫在前面

微服務架構現在是談到企業應用架構時必聊的話題，微服務之所以火熱也是因為相對之前的應用開發方式有很多優點，如更靈活、更能適應現在需求快速變更的大環境。

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

微服務架構演進過程

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

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

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

微服務架構的好處

　　我們總結了四個方面的優點，分別如下：

是每個微服務組件都是簡單靈活的，能夠獨立部署。不再像以前一樣，應用需要一個龐大的應用服務器來支撐。

可以由一個小團隊負責更專注專業，相應的也就更高效可靠。

微服務之間是松耦合的，微服務內部是高內聚的，每個微服務很容易按需擴展。

微服務架構與語言工具無關，自由選擇合適的語言和工具，高效的完成業務目標即可。

看到這里，大家會覺得微服務架構挺不錯，然而還會有一些疑問，什么樣的應用算是一個微服務架構的應用？該怎樣設計一個微服務架構的應用？那我們來一起看看我們推薦的微服務應用的設計原則。

微服務應用 4 個設計原則

　　我們總結了四個原則推薦給大家：

AKF 拆分原則

前后端分離

無狀態服務

Restful 通信風格

AKF 拆分原則

AKF 擴展立方體（參考《The Art of Scalability》），是一個叫 AKF 的公司的技術專家抽象總結的應用擴展的三個維度。理論上按照這三個擴展模式，可以將一個單體系統，進行無限擴展。

X 軸 ：指的是水平復制，很好理解，就是講單體系統多運行幾個實例，做個集群加負載均衡的模式。

Z 軸 ：是基于類似的數據分區，比如一個互聯網打車應用突然或了，用戶量激增，集群模式撐不住了，那就按照用戶請求的地區進行數據分區，北京、上海、四川等多建幾個集群。

Y 軸 ：就是我們所說的微服務的拆分模式，就是基于不同的業務拆分。

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

前后端分離

前后端分離原則，簡單來講就是前端和后端的代碼分離也就是技術上做分離，我們推薦的模式是最好直接采用物理分離的方式部署，進一步促使進行更徹底的分離。不要繼續以前的服務端模板技術，比如 JSP ，把 Java JS HTML CSS 都堆到一個頁面里，稍復雜的頁面就無法維護。這種分離模式的方式有幾個好處：

前后端技術分離，可以由各自的專家來對各自的領域進行優化，這樣前端的用戶體驗優化效果會更好。

分離模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口簡潔明了，更容易維護。

前端多渠道集成場景更容易實現，后端服務無需變更，采用統一的數據和模型，可以支撐前端的 web UI 移動 App 等訪問。

無狀態服務

對于無狀態服務，首先說一下什么是狀態：如果一個數據需要被多個服務共享，才能完成一筆交易，那么這個數據被稱為狀態。進而依賴這個“狀態”數據的服務被稱為有狀態服務，反之稱為無狀態服務。

那么這個無狀態服務原則并不是說在微服務架構里就不允許存在狀態，表達的真實意思是要把有狀態的業務服務改變為無狀態的計算類服務，那么狀態數據也就相應的遷移到對應的“有狀態數據服務”中。

場景說明：例如我們以前在本地內存中建立的數據緩存、Session 緩存，到現在的微服務架構中就應該把這些數據遷移到分布式緩存中存儲，讓業務服務變成一個無狀態的計算節點。遷移后，就可以做到按需動態伸縮，微服務應用在運行時動態增刪節點，就不再需要考慮緩存數據如何同步的問題。

Restful 通信風格

作為一個原則來講本來應該是個“無狀態通信原則”，在這里我們直接推薦一個實踐優選的 Restful 通信風格 ，因為他有很多好處：

無狀態協議 HTTP，具備先天優勢，擴展能力很強。例如需要安全加密是，有現成的成熟方案 HTTPS 可用。

JSON 報文序列化，輕量簡單，人與機器均可讀，學習成本低，搜索引擎友好。

語言無關，各大熱門語言都提供成熟的 Restful API 框架，相對其他的一些 RPC 框架生態更完善。

當然在有些特殊業務場景下，也需要采用其他的 RPC 框架，如 thrift、avro-rpc、grpc。但絕大多數情況下 Restful 就足夠用了。

微服務架構帶來的問題

做到了前面講的四個原則，那么就可以說是構建了一個微服務應用，感覺上也不復雜。但實際上微服務也不是個萬金油，也是有利有弊的，接下來我們來看看引入微服務架構后帶來的問題有哪些。

依賴服務變更很難跟蹤，其他團隊的服務接口文檔過期怎么辦？依賴的服務沒有準備好，如何驗證我開發的功能。

部分模塊重復構建，跨團隊、跨系統、跨語言會有很多的重復建設。

微服務放大了分布式架構的系列問題，如分布式事務怎么處理？依賴服務不穩定怎么辦？

運維復雜度陡增，如：部署物數量多、監控進程多導致整體運維復雜度提升。

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

這些解決方案折騰到最后終于搞明白了，原來我們是需要一個微服務應用平臺才能整體性的解決這些問題。

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

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

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

團隊協作環境：主要是 DevOps 領域的范疇，負責從需求到計劃任務，團隊協作，再到質量管理、持續集成和發布。

個人基礎環境：就是本文介紹的微服務應用平臺，他的目標主要就是要支撐微服務應用的設計開發測試，運行期的業務數據處理和應用的管理監控。

IT 基礎設施：就是我們通常說的各種運行環境支撐如 IaaS (VM 虛擬化) 和 CaaS (容器虛擬化) 等實現方式。

微服務應用平臺總體架構

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

開發集成：主要是搭建一個微服務平臺需要具備的一些工具和倉庫

運行時：要有微服務平臺來提供一些基礎能力和分布式的支撐能力，我們的微服務運行容器則會運行在這個平臺之上。

監控治理：則是致力于在運行時能夠對受管的微服務進行統一的監控、配置等能力。

服務網關： 則是負責與前端的 WEB 應用 移動 APP 等渠道集成，對前端請求進行認真鑒權，然后路由轉發。

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

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

微服務平臺的設計目標

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

微服務開發：前端、后端、混合

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

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

服務契約與 API 管理

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

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

　　服務契約與服務模擬

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

根據契約生成模擬服務也就是我們常說的服務擋板，這樣即使依賴的其他服務還無法提供功能，我們也可以通過擋板來進行聯調測試。

服務契約與服務編排

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

服務編排的作用和意義很大，可以快速的將已經提供的微服務能力進行組合發布，非常適合業務的快速創新。

但是大家要注意，邏輯流編排的是業務流程，盡量能夠簡單明了，一眼看上去就明白業務含義。而業務規則推薦采用服務內部進行編碼實現。千萬不要將我們的 “邏輯流” 圖形化服務編排完全取代程序編碼，這樣就會可能會走入另外一個極端，比如設計出像蜘蛛網一樣的邏輯流圖，簡直就是災難。

微服務容器

我們再來看一下微服務運行容器的一個邏輯圖，大家可以看到，我們要做微服務架構的應用，可靠高效的微服務應用，實際上我們需要做的事情還是非常多的。如果沒有一個統一的微服務容器，這些能力在每個微服務組件中都需要建設一遍，而且會五花八門，也很難集成到一起。有了統一的微服務運行容器和一些公共的基礎服務，前面所提到的微服務架構下部分組件重復建設的問題也迎刃而解。

三方能力集成說明

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

SpringCloud 在微服務平臺中的定位是基礎框架，本文重點是要介紹一個企業級的微服務平臺在落地過程中的一些設計原則和解決方案。具體 Spring Cloud 相關的技術就不在文中多做介紹了，大家可以在我們的公眾號里面查看相關文章。

服務注冊發現路由

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

我們的服務注冊發現能力是依賴 SpringCloud Eureka 組件實現的。服務在啟動的時候，會將自己要發布的服務注冊到服務注冊中心，運行時，如果需要調用其他微服務的接口，那么就要先到注冊中心獲取服務提供者的地址，拿到地址后，通過微服務容器內部的簡單負載均衡期進行路由用。

一般情況，系統內微服務的調用都通過這種客戶端負載的模式進行，否則就需要有很多的負載均衡進程。跨業務系統的服務調用，也可以采用這種去中心化的路由方式。當然采用 SOA 的模式，由中心化的服務網管來管理系統間的調用也是另一種選擇，要結合企業的 IT 現狀和需求來決定。

統一認證鑒權

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

日志與流水設計

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

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

集中配置管理

微服務分布式環境下，一個系統拆分為很多個微服務，一定要告別投產或運維手工修改配置配置的方式。需要采用集中配置管理的方式來提升運維的效率。

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

是配置與介質分離，這個就需要通過制定規范的方式來控制。千萬別把配置放在 Jar 包里；

是配置的方式要統一，格式、讀寫方式、變更熱更新的模式盡量統一，要采用統一的配置框架；

就是需要運行時需要有個配置中心來統一管理業務系統中的配置信息，這個就需要平臺來提供配置中心服務和配置管理門戶。

統一管理門戶

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

分布式事務問題

微服務架構的系統下，進程成倍增多，那么也分布式事務一致性的問題也就更加明顯。我們這里說的事務一致性，不是傳統說的基于數據庫實現的技術事務。微服務之間是獨立的、調用協議也是無狀態的，因此數據庫事務方案在一開始就已經不再我們考慮的范圍內。我們要解決的是一定時間后的數據達到最終一致狀態，準確的說就是采用傳統的業務補償與沖正方式。

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

可靠事件模式：即事件的發送和接收保障高可靠性，來實現事務的一致性。

補償模式：Confirm Cancel ，如果確認失敗，則全部逆序取消。

TCC 模式：Try Confirm Cancel ，補償模式的一種特殊實現 通常轉賬類交易會采用這種模式。

分布式同步調用問題

微服務架構下，相對于傳統部署方式，存在更多的分布式調用，那么“如何在不確定的環境中交付確定的服務”，這句話可以簡單理解為，我所依賴的服務的可靠性是無法保證的情況下，我如何保證自己能夠正常的提供服務，不被我依賴的其他服務拖垮？

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

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

持續集成與持續交付設計

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

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

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

微服務平臺與容器云、DevOps 的關系

就微服務應用平臺本身來說，并不依賴 DevOps 和容器云，開發好的部署包可以運行在物理機、虛擬機或者是容器中。

然而當微服務應用平臺結合了 DevOps 和容器云之后，我們就會發現，持續集成和交付變成了一個非常簡單便捷并且又可靠的過程。

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

總結展望

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

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

最后，我們一起看一下普元正在研發的新一代 The Platform 平臺。

上圖紅框中的內容是與我們今天分享的微服務應用平臺相關的部分。整個 The Platform 平臺是我們站在企業整體架構規劃的角度，從多個維度入手，目標是為企業搭建一個持續發展的 IT 生態環境，加速企業的數字化型。

作者介紹

郝炎峰，現任普元 SOA& 云計算產品部 產品架構師。主要負責普元流程產品的核心架構設計與產品版本發展規劃，先后參與了國家電網 BPM、BAM 平臺、浦發銀行新一代流程平臺等大型平臺項目建設與實施 。

程序員該如何面對職場挫折？