本文轉自：http://developer.51cto.com/art/201709/552085.htm
微服務架構現在是談到企業應用架構時必聊的話題，微服務之是以火熱也是因為相對之前的應用開發方式有很多優點，如更靈活、更能适應現在需求快速變更的大環境。
本文将介紹微服務架構的演進、優缺點和微服務應用的設計原則，然後着重介紹作為一個“微服務應用平台”需要提供哪些能力、解決哪些問題才能更好的支撐企業應用架構。
微服務平台也是我目前正在參與的，還在研發過程中的平台産品，平台是以SpringCloud為基礎，結合了普元多年來對企業應用的了解和産品的設計經驗，逐漸孵化的一個微服務應用平台。
一、微服務架構演進過程
近年來我們大家都體會到了網際網路、移動互聯帶來的好處，作為IT從業者，在生活中時刻感受網際網路好處的同時，在工作中可能感受的卻是來自自網際網路的一些壓力，那就是我們傳統企業的IT建設也是迫切需要轉型，需要面向外部客戶，我們也需要應對外部環境的快速變化、需要快速創新，那麼我們的IT架構也需要向網際網路企業學習作出相應的改進，來支撐企業的數字化轉型。
我們再看一下應用架構的演進過程，回憶一下微服務架構是如何一步一步進化産生的，最早是應用是單塊架構，後來為了具備一定的擴充和可靠性，就有了垂直架構，也就是加了個負載均衡，接下來是前幾年比較火的SOA，主要講了應用系統之間如何內建和互通，而到現在的微服務架構則是進一步在探讨一個應用系統該如何設計才能夠更好的開發、管理更加靈活高效。
微服務架構的基本思想就是“圍繞業務領域元件來建立應用，讓應用可以獨立的開發、管理和加速”。
二、微服務架構的好處
我們總結了四個方面的優點，分别如下：
是每個微服務元件都是簡單靈活的，能夠獨立部署。不再像以前一樣，應用需要一個龐大的應用伺服器來支撐。
可以由一個小團隊負責更專注專業，相應的也就更高效可靠。
微服務之間是松耦合的，微服務内部是高内聚的，每個微服務很容易按需擴充。
微服務架構與語言工具無關，自由選擇合适的語言和工具，高效的完成業務目标即可。
看到這裡，大家會覺得微服務架構挺不錯，然而還會有一些疑問，什麼樣的應用算是一個微服務架構的應用?該怎樣設計一個微服務架構的應用?那我們來一起看看我們推薦的微服務應用的設計原則。
三、微服務應用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就足夠用了。
四、微服務架構帶來的問題
做到了前面講的四個原則，那麼就可以說是建構了一個微服務應用，感覺上也不複雜。但實際上微服務也不是個萬金油，也是有利有弊的，接下來我們來看看引入微服務架構後帶來的問題有哪些。
依賴服務變更很難跟蹤，其他團隊的服務接口文檔過期怎麼辦?依賴的服務沒有準備好，如何驗證我開發的功能。
部分子產品重複建構，跨團隊、跨系統、跨語言會有很多的重複建設。
微服務放大了分布式架構的系列問題，如分布式事務怎麼處理?依賴服務不穩定怎麼辦?
運維複雜度陡增，如：部署物數量多、監控程序多導緻整體運維複雜度提升。
上面這些問題我們應該都遇到過，并且也會有一些解決方案，比如提供文檔管理、服務治理、服務模拟的工具和架構; 實作統一認證、統一配置、統一日志架構、分布式彙總分析; 采用全局事務方案、采用異步模拟同步;搭建持續內建平台、統一監控平台等等。
這些解決方案折騰到最後終于搞明白了，原來我們是需要一個微服務應用平台才能整體性的解決這些問題。
五、微服務平台的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 ，補償模式的一種特殊實作 通常轉賬類交易會采用這種模式。
曉晨的補充：還有 最大努力型、異步確定、2PC、3PC
17.分布式同步調用問題
微服務架構下，相對于傳統部署方式，存在更多的分布式調用，那麼“如何在不确定的環境中傳遞确定的服務”，這句話可以簡單了解為，我所依賴的服務的可靠性是無法保證的情況下，我如何保證自己能夠正常的提供服務，不被我依賴的其他服務拖垮?
我們推薦SEDA架構來解決這個問題。
SEDA : staged event-driven architecture本質上就是采用分布式事件驅動的模式，用異步模拟來同步，無阻塞等待，再加上資源配置設定隔離結起來的一個解決方案。
18.持續內建與持續傳遞設計
在運維方面，首先我們要解決的就是持續內建和持續傳遞，而微服務應用平台的職責範圍目前規劃是隻做持續內建，能夠友善的用持續內建環境把程式編譯成媒體包和部署包。(目前規劃持續部署由DevOps平台提供相應能力，微服務平台可與DevOps平台內建)
這裡要厘清一個概念：媒體，是源碼編譯後的産物，與環境無關，多環境下應該是可以共用的，如：jar、dockerfile;配置：則是環境相關的資訊。配置+媒體=部署包。
擷取到部署包之後，微服務應用平台的職責就完成了，接下來就是運維人員各顯神通來進行上線部署操作。
19.微服務平台與容器雲、DevOps的關系
就微服務應用平台本身來說，并不依賴DevOps和容器雲，開發好的部署包可以運作在實體機、虛拟機或者是容器中。
然而當微服務應用平台結合了DevOps和容器雲之後，我們就會發現，持續內建和傳遞變成了一個非常簡單便捷并且又可靠的過程。
簡單幾步操作，整套開發、測試、預發或者生産環境就能夠搭建完成。整個過程的複雜度都由平台給屏蔽掉了，通過三大基礎環境的整合，我們能夠使分散的微服務元件更簡單友善的進行統一管理和運維傳遞。
目前學習.NET Core 最好的教程 .NET Core 官方教程 ASP.NET Core 官方教程
.NET Core 交流群：923036995 歡迎加群交流
如果您認為這篇文章還不錯或者有所收獲，您可以點選右下角的【推薦】支援，或請我喝杯咖啡【贊賞】，這将是我繼續寫作，分享的最大動力！
作者：曉晨Master（李志強）
聲明：原創部落格請在轉載時保留原文連結或者在文章開頭加上本人部落格位址，如發現錯誤，歡迎批評指正。凡是轉載于本人的文章，不能設定打賞功能，如有特殊需求請與本人聯系！