點擊上方“程序猿技術大咖”，關注加羣討論
在當今微服務架構興起的時代，微服務架構的軟件產品數不甚數。在面對初步接觸、從0到1開始的團隊或個人，將面臨很大的難題與困惑，技術框架如何選擇、核心基礎模塊如何建設、都包含哪些東西，如何規範化等等問題。本文將針對微服務架構下面臨的種種問題，一一羅列，提供整套解決方案，供大家參考。
1. 企業IT建設的三大基礎環境
團隊協作環境：主要是DevOps領域的範疇，負責從需求到計劃任務，團隊協作，再到質量管理、持續集成和發佈。
個人基礎環境：就是本文介紹的微服務應用平臺，他的目標主要就是要支撐微服務應用的設計開發測試，運行期的業務數據處理和應用的管理監控。
IT基礎設施：就是我們通常說的各種運行環境支撐如IaaS (VM虛擬化)和CaaS (容器虛擬化)等實現方式。
2. 微服務應用平臺總體架構
主要是從開發集成、微服務運行容器與平臺、運行時監控治理和外部渠道接入等維度來劃分的。
開發集成：主要是搭建一個微服務平臺需要具備的一些工具和倉庫
運行時：要有微服務平臺來提供一些基礎能力和分佈式的支撐能力，我們的微服務運行容器則會運行在這個平臺之上。
監控治理：則是致力於在運行時能夠對受管的微服務進行統一的監控、配置等能力。
服務網關：則是負責與前端的WEB應用 移動APP 等渠道集成，對前端請求進行認真鑑權，然後路由轉發。
3. 微服務應用平臺的運行視圖
在運行期，作爲一個微服務架構的平臺與業務系統，除了業務應用本身外，還需要有接入服務、統一門戶、基礎服務等平臺級服務來保障業務系統的可靠運行。圖中的公共服務就是業務處理過程中需要用到的一些可選服務。
4. 微服務平臺的設計目標
支撐微服務應用的全生命週期管理，包括從需求、設計、開發、測試、發佈（自動打包管理和敏捷可靠發佈）和運營（全面監控管理、標準數據採集和運營驅動創新）。
5. 微服務開發：前端、後端和混合
混合項目則是爲了兼容傳統模式而保留的，爲企業應用向微服務架構演進提供過渡方案。
6. 服務契約與API管理
對於前面提到的微服務帶來的依賴管理問題，我們可以通過平臺提供的API管理能力來解決。服務契約有點類似於web service的wsdl描述，主要描述服務接口的輸入輸出規格標準和一些服務調用集成相關的規格內容。
7. 服務契約和服務模擬
有了服務契約，我們就可以根據契約自動生成服務的文檔和服務模擬測試環境。這樣，開發者就可以及時獲取依賴服務的變化，調整自己的程序，並且能夠方便的進行模擬測試驗證。
根據契約生成模擬服務也就是我們常說的服務擋板，這樣即使依賴的其他服務還無法提供功能，我們也可以通過擋板來進行聯調測試。
8. 服務契約與服務編排
編排能夠很大程度上簡化分佈式服務調用的複雜度，如同步、異步、異步模擬同步、超時重試、事務補償等，均有服務編排引擎完成。
服務編排的作用和意義很大，可以快速的將已經提供的微服務能力進行組合發佈，非常適合業務的快速創新。
但是大家要注意，邏輯流編排的是業務流程，儘量能夠簡單明瞭，一眼看上去就明白業務含義。而業務規則推薦採用服務內部進行編碼實現。千萬不要將我們的 “邏輯流” 圖形化服務編排完全取代程序編碼，這樣就會可能會走入另外一個極端，比如設計出像蜘蛛網一樣的邏輯流圖，簡直就是災難。
9. 微服務容器
如果沒有一個統一的微服務容器，這些能力在每個微服務組件中都需要建設一遍，而且會五花八門，也很難集成到一起。有了統一的微服務運行容器和一些公共的基礎服務，前面所提到的微服務架構下部分組件重複建設的問題也迎刃而解。
10. 三方能力集成說明
API Doc: Swagger UI
API Mock: Swagger Mock API
AOP基礎框架：Spring Framework
微服務容器：Spring Boot
服務發佈：Spring Web MVC
服務註冊中心：Spring Cloud - Eureka
服務路由：Spring Cloud - Ribbon
服務調用：Spring Cloud - Feign
服務熔斷器：Spring Cloud - Hystrix
安全認證：Spring Cloud - Security
服務配置中心：Apollo，Spring Cloud - Config
服務監控：Spring Boot Admin
11. 服務註冊發現路由
以前的單塊應用之間互相調用時配置個IP就行了，但在微服務架構下，服務提供者會有很多，手工配置IP地址又變成了一個不可行的事情。那麼服務自動註冊發現的方案就解決了這個問題。
我們的服務註冊發現能力是依賴SpringCloud Eureka組件實現的。服務在啓動的時候，會將自己要發佈的服務註冊到服務註冊中心，運行時，如果需要調用其他微服務的接口，那麼就要先到註冊中心獲取服務提供者的地址，拿到地址後，通過微服務容器內部的簡單負載均衡期進行路由用。
12. 統一認證鑑權
安全認證方面，我們基於Spring Security結合Auth2再加上JWT(Json web token)做安全令牌，實現統一的安全認證與鑑權，使得微服務之間能夠按需隔離和安全互通。後續在統一認證和權限方面我們產品會陸續推出較完善並且擴展性良好的微服務組件，可以作爲微服務平臺的公共的認證和鑑權服務。認證鑑權一定是個公共的服務。
13. 日誌與流水設計
先來看日誌，平臺默認回會提供的日誌主要有三種，系統日誌，引擎日誌還有跟蹤日誌。有了這些日誌，在出問題的時候能夠幫助我們獲取一些關鍵信息進行問題定位。
系統日誌：格式化日誌，記錄系統邊界報文日誌，即微服務接入，接出的請求、響應報文明細信息
引擎日誌：格式化日誌，記錄微服務內部的關鍵模塊的處理情況、上下文狀態、耗時等信息；邏輯處理、SQL、服務調用
跟蹤日誌：非格式化日誌，用以開發測試期排錯，上線後默認記錄異常
要想做到出了問題能夠追根溯源，流水號的設計也是非常重要的，日誌與各種流水號配合，能夠讓我們快速定位問題發生的具體時間地點以及相關信息，能夠快速還原業務交易全鏈路。
GlobalId: 全局流水號，需保證全局唯一，用於標識一次完整的端到端交易
BusinessId：交易流水號，業務域內唯一，用於標識一次接收到的交易請求
AppUniqueId：業務處理流水號，應用內部唯一，標識微服務內部收到請求後的一次完整的處理過程
RequestId：請求消息編號，唯一確定一個請求報文
ResponseId：響應消息編號，唯一確定一個響應報文
AppId：應用編號，一個微服務應用集羣唯一
ProcessId：進程編號，微服務集羣內唯一
14. 集中配置管理
配置文件主要有運行前的靜態配置和運行期的動態配置兩種。靜態配置通常是在編譯部署包之前設置好。動態配置則是系統運行過程中需要調整的系統變量或者業務參數。
就是需要運行時需要有個配置中心來統一管理業務系統中的配置信息，這個就需要平臺來提供配置中心服務和配置管理門戶。
15. 統一管理門戶
微服務架構下，一個大的EAR、WAR應用被拆爲了多個小的可獨立運行的微服務程序，通常這些微服務程序都不再依賴應用服務器，不依賴傳統應用服務器的話，應用服務器提供管理控制檯也就沒得用了，所以微服務的運行時管理需要有統一的管理門戶來支撐。我們規劃了的統一集中的微服務門戶，可以支撐 應用開發、業務處理、應用管理、系統監控等。
16. 分佈式事務問題
我們這裏說的事務一致性，不是傳統說的基於數據庫實現的技術事務。微服務之間是獨立的、調用協議也是無狀態的，因此數據庫事務方案在一開始就已經不再我們考慮的範圍內。我們要解決的是一定時間後的數據達到最終一致狀態，準確的說就是採用傳統的業務補償與衝正方式。
推薦的事務一致性方案有三種：
可靠事件模式：即事件的發送和接收保障高可靠性，來實現事務的一致性。
補償模式：Confirm Cancel ，如果確認失敗，則全部逆序取消。
TCC模式：Try Confirm Cancel ，補償模式的一種特殊實現 通常轉賬類交易會採用這種模式。
17. 分佈式同步調用問題
如何在不確定的環境中交付確定的服務
這句話可以簡單理解爲，我所依賴的服務的可靠性是無法保證的情況下，我如何保證自己能夠正常的提供服務，不被我依賴的其他服務拖垮?
我們推薦SEDA架構來解決這個問題。
SEDA : staged event-driven architecture本質上就是採用分佈式事件驅動的模式，用異步模擬來同步，無阻塞等待，再加上資源分配隔離結起來的一個解決方案。
18. 持續集成與持續交付設計
在運維方面，首先我們要解決的就是持續集成和持續交付，而微服務應用平臺的職責範圍目前規劃是隻做持續集成，能夠方便的用持續集成環境把程序編譯成介質包和部署包。
19. 微服務平臺與容器雲、DevOps的關係
就微服務應用平臺本身來說，並不依賴DevOps和容器雲，開發好的部署包可以運行在物理機、虛擬機或者是容器中。
然而當微服務應用平臺結合了DevOps和容器雲之後，我們就會發現，持續集成和交付變成了一個非常簡單便捷並且又可靠的過程。
簡單幾步操作，整套開發、測試、預發或者生產環境就能夠搭建完成。整個過程的複雜度都由平臺給屏蔽掉了，通過三大基礎環境的整合，我們能夠使分散的微服務組件更簡單方便的進行統一管理和運維交付。
喜歡就點個"在看"唄，留言、轉發朋友圈