基於SpringCloud微服務系統設計,5萬字總結！

1.微服務本質

微服務架構從本質上說其實就是分佈式架構， 與其說是一種新架構， 不如說是一種 微服

務架構風格。

簡單來講， 微服務架構風格是要開發一種由 多個小服務組成 的應用。 每一個服務運 行於獨立的進程 ，而且採用 輕量級交互 。多數狀況下是一個 *HTTP* 的資源 *API*。這些服務 具有獨立業務能力 並能夠經過 自動化部署 方式 獨立部署 。這種風格使 最小化集中管理 ，從而可使用多種 不一樣的編程語言和數據存儲技術 。

對於微服務架構系統， 因爲其服務粒度小， 模塊化清晰， 所以首先要作的是對系 統總體進行功能、服務規劃 ，優先考慮如何在交付過程當中，從 工程實踐出發，組織好代碼結構、配置、測試、部署、運維、監控 的整個過程，從而有效體現微服務的獨立性與可部署性。

本文將從微服務系統的設計階段、開發階段、測試階段、部署階段進行綜合闡述。

理解微服務架構和理念是核心。

2.系統環境

3.微服務架構的挑戰

可靠性：

因爲採用遠程調用的方式， 任何一個節點、 網絡出現問題， 都將使得服務調用失敗，隨着微服務數量的增多，潛在故障點也將增多。

也就是沒有充分的保障機制，則單點故障會大量增長。

運維要求高：

系統監控、高可用性、自動化技術

分佈式複雜性：

網絡延遲、系統容錯、分佈式事務

部署依賴性強：

服務依賴、多版本問題

性能（服務間通信成本高） ：

無狀態性、進程間調用、跨網絡調用

數據一致性：

分佈式事務管理須要跨越多個節點來保證數據的瞬時一致性， 所以比起傳統的單體架構的事務，成本要高得多。另外， 在分佈式系統中，一般會考慮經過數據的最終一致性來解決數據瞬時一致帶來的系統不可用。

重複開發：

微服務理念崇尚每一個微服務做爲一個產品看待， 有本身的團隊開發， 甚至能夠有本身徹底不一樣的技術、 框架， 那麼與其餘微服務團隊的技術共享就產生了矛盾， 重複開發的工做即產生了。

4.架構設計

4.1. 思惟設計

微服務架構設計的根本目的是實現價值交付， 微服務架構只有遵循 *DevOps* 理念方可進行的更順暢，思惟方式的轉變是最重要的。

實現微服務技術架構， 現有產品須要進行技術上的改進以及相關配套服務的實現，段實施、以及試點產品優先實施的策略 ，主要包括以下：

1、技術上的改進：

一、先後端分離， web 前端經過 Http/Https 協議調用微服務的 API 網關，由API 網關再通過路由服務調用相應的微服務

二、不一樣微服務之間經過 REST方式互相調用

三、微服務之間經過消息中間件實現消息交互機制

2、配套服務與功能實現 ：

一、須要進行相應的自動化服務實現， 包括自動化構建、 自動化安裝部署、 自動化測試、自動化平臺發佈（ Docker 實現）

二、管理服務，對於微服務架構，必須配套相應的監控與管理服務、日誌管理服務等

三、協做服務，運用 DevOps 思想提高開發、測試、運維的高效溝通與協做，實現開發與運維的一體化

4.3. 微服務架構設計

一、咱們把整個系統根據業務拆分紅若干個子系統或微服務。

二、每一個子系統能夠部署多個應用，多個應用之間使用負載均衡。

三、須要一個服務註冊中心 Eureka，全部的服務都在註冊中心註冊，負載均衡也是經過在註冊中心註冊的服務來使用必定策略來實現。*Eureka*可部署多個，進行高可用保證。

四、全部的客戶端都經過同一個網關地址訪問後臺的服務，經過路由配置 ZUUL 網關來判斷一個 URL請求由哪一個服務處理。請求轉發到服務上的時候使用負載均衡 Ribbon。

五、服務之間採用 feign 進行調用。

六、使用斷路器 hystrix ，及時處理服務調用時的超時和錯誤， 防止因爲其中一個服務的問題而致使總體系統的癱瘓。

七、還須要一個監控功能，監控每一個服務調用花費的時間等。

八、使用 SpringCloud Config 進行統一的配置管理，須要考慮與公司的配置管理平臺如何配合使用。

九、 Hystrix，監控和斷路器。咱們只須要在服務接口上添加 Hystrix 標籤，就能夠實現對這個接口的監控和斷路器功能。

十、Hystrix Dashboard ，監控面板，他提供了一個界面，能夠監控各個服務上的服務調用所消耗的時間等。

十一、 Turbine，監控聚合，使用 Hystrix 監控，咱們須要打開每個服務實例的監控信息來查看。而 Turbine 能夠幫助咱們把全部的服務實例的監控信息聚合到一個地方統一查看。

這樣就不須要挨個打開一個個的頁面一個個查看。

架構的可靠性保證：

在關鍵節點作主備、集羣部署，防止單點故障。

待後續確認問題：

一、 Access Control： Zuul網關提供了相關控制功能，與我司CAS如何結合使用

二、 Config Server： Spring Cloud 提供了遠程配置中心，與我司的配置管理平臺如何結合使用

5.設計階段

5.1. 整體設計

一、功能規劃 ：對產品功能進行拆分，拆分爲若干個微服務；一個功能能夠建立多個微服務並部署在多個服務器節點上，以便進行負載均衡。

二、設計 原子服務層 ，梳理和抽取核心應用、公共應用，做爲獨立的服務下沉到核心和公共能力層，逐漸造成穩定的服務中心，使應用能更快速的響應多變的客戶需求。

三、爲每一個服務 設計 *API* 接口 （ REST方式）

四、爲不一樣的 服務進行分類 ，不一樣類型的服務須要的資源不一樣，能夠配置不一樣的資源，包括 CPU、內存、存儲等。

5.2. 服務拆分原則

*1*、粒度微小：

根據業務功能劃分服務粒度，總的原則是服務內部高內聚，服務之間低耦合。

*2*、責任單一：

每一個服務只作一件事，即單一職責原則。

*3*、隔離性原則：

每一個服務相互隔離，且不互相影響

*4*、業務無關優先原則：

基礎服務，是一些基礎組件，與具體的業務無關。好比：短信服務、郵件服務。這裏的服務最容易劃分出來作微服務，也是咱們第一優先級分離出來的服務。

5.3. 服務規劃

爲實現負載均衡， 容許相同的服務在多個節點註冊相同的服務名， 不一樣的端口。 若是沒有前期的規劃， 不一樣的服務提供者可能會註冊相同的服務名， 致使消費者調用服務時產生調用混亂。

所以，需進行服務名的統一規劃：

一、規劃期統一制定每一個服務提供者的服務名或者模塊標示。

二、服務名的命名規則:ModuleName_ServiceName，且 全部字符小寫，不一樣單詞之間如下劃線分隔 。如用戶管理模塊提供了獲取用戶信息的服務，則命名爲：user_get_info 。

三、新增服務名時，須要提出申請， 審批經過後方可以使用 ，爲減小審批覆雜度，可只審批 ModuleName ，即在模塊內部能夠自由增長服務名，不須要進行審批。

沒有最好的，只有最適合本身的。

5.4. 開發策略

整體原則：不一樣的微服務需進行 物理隔離。

一、 SVN 策略： SVN上建立 獨立的分支 ，不一樣微服務的代碼提交不受相互影響；

*---*由配置管理員統一控制。

問題：開發分支與集成分支，都將增長不少，維護工做量增長。

二、編譯策略：代碼編譯時，各個微服務獨立編譯、打包， 杜絕直接的依賴 ；

三、工程構建：代碼開發時，各微服務 建立獨立的工程 ，工程之間不能產生直接依賴

四、持續集成：每一個微服務 獨立執行持續集成 。

五、版本集成：由統一的集成工具，實現自動化的版本集成，將全部微服務集成到統一的版本發佈包中。

5.5. 版本策略

每一個微服務能夠獨立製做版本，伴隨着服務的增多， SVN分支增多，版本也將增多，版本管理的複雜度將成指數級增長。 在服務之間依賴較多時， 每一個服務的升級或降級都將影響其餘服務的正常運行。

所以需執行以下策略：

一、全部服務的版本製做交由專業的版本管理員執行。

二、採用自動化的版本製做策略，最大程度的減小人工操做。

三、每一個服務的版本必須有詳細的版本計劃、版本說明，對於版本說明要制定模板，明確須要提交的內容、版本號、 SVN標籤等。

四、對項目經理的要求提高，需對總體的版本計劃有嚴格的制定，尤爲是版本之間的依賴關係要很是明確，版本升級、降級的 風險評估 需徹底充分。

五、接口管理： 嚴格執行接口管理制度， 任何接口的變動必須進行審批、 發公告等流程。

5.6. 數據庫挑戰與策略

每一個微服務都有本身獨立的數據庫， 那麼後臺管理的聯合查詢怎麼處理？這應該是你們會廣泛遇到的一個問題，有三種處理方案。

1）嚴格按照微服務的劃分來作，微服務相互獨立，各微服務數據庫也獨立，後臺須要展現數據時， 調用各微服務的接口來獲取對應的數據， 再進行數據處理後展現出來， 這是標準的用法，也是最麻煩的用法。

2) 將業務高度相關的表放到一個庫中，將業務關係不是很緊密的表嚴格按照微服務模式來拆分，這樣既可使用微服務，也避免了數據庫分散致使後臺系通通計功能難以實現，是一個折中的方案。

3）數據庫嚴格按照微服務的要求來切分，以知足業務高併發，實時或者準實時將各微服務數據庫數據同步到 NoSQL 數據庫中，在同步的過程當中進行數據清洗，用來知足後臺業務系統的使用，推薦使用 MongoDB 、HBase 等。

第一種方案適合業務較爲簡單的小公司； 第二種方案， 適合在原有系統之上， 慢慢演化爲微服務架構的公司；第三種適合大型高併發的互聯網公司。

建議，咱們當前採用第二種方案。

5.7. 負載均衡

再也不採用通常的增長負載均衡服務器的方式進行負載均衡，如 F五、 Nginx、 LVS 等，而是把負載均衡的功能 以庫的方式集成到服務消費方的進程內 ，這種方案稱爲 軟負載均衡（ Soft Load Balancing）或者客戶端負載均衡。 在 Spring Cloud 中配合 Eureka 的服務註冊功能，Ribbon 子項目則爲 REST客戶端實現了負載均衡。

	使用 Ribbon 進行負載均衡，其工做原理能夠歸納爲下面四個步驟：
1.	Ribbon 首先根據其所在 Zone 優先選擇一個負載較少的 Eureka Server;
2.	按期從 Eureka Server 更新並過濾服務實例列表 ;
3.	根據指定的負載均衡策略，從可用的服務器列表中選擇一個服務實例的地址	;
4	而後經過 RestClient 進行服務調用。

Ribbon 自己提供了下面幾種負載均衡策略：

RoundRobinRule:輪詢策略，Ribbon以輪詢的方式選擇服務器，這個是默認值。因此示例中所啓動的兩個服務會被循環訪問 ;

RandomRule: 隨機選擇，也就是說 Ribbon 會隨機從服務器列表中選擇一個進行訪問

BestAvailableRule: 最大可用策略，即先過濾出故障服務器後，選擇一個當前併發請求數最小的;

WeightedResponseTimeRule: 帶有加權的輪詢策略， 對各個服務器響應時間進行加權處理，而後在採用輪詢的方式來獲取相應的服務器 ;

AvailabilityFilteringRule: 可用過濾策略，先過濾出故障的或併發請求大於閾值一部分服務實例，而後再以線性輪詢的方式從過濾後的實例清單中選出一個 ;

ZoneAvoidanceRule: 區域感知策略， 先使用主過濾條件 （區域負載器， 選擇最優區域）對全部實例過濾並返回過濾後的實例清單，依次使用次過濾條件列表中的過濾條件對主過濾條件的結果進行過濾，判斷最小過濾數（默認 1）和最小過濾百分比（默認 0），最後對知足條件的服務器則使用 RoundRobinRule( 輪詢方式 ) 選擇一個服務器實例。

5.8. 性能策略

一、網絡優化：優化組網結構，提高網絡間通信性能；

二、配置優化：優化 Spring Cloud 組件集以及其餘組件的配置信息，使得性能最大化。

5.9. 技術管理策略

微服務的架構理念中指出各微服務能夠 獨立建設，可使用不一樣的技術、語言、框架等，以便能更快速的使用新技術、 新框架等響應特定客戶需求， 解決單體應用架構更新技術、更新框架時面臨的困難或阻礙。

但這也同時帶來了諸多問題，以下：

一、各服務是否能夠任意使用本身的技術、本身的組件、框架呢？若是這樣，勢必帶來更大的管理困難、維護困難、技術共享困難。

二、公共的方法如何實現共享？如格式化時間的一個簡單方法須要共享，也須要封裝爲一個服務接口嗎？

管理策略：

一、整體原則：仍然須要進行統籌考慮，全部組件統一管理，組件放置在產品倉庫中，每一個產品或服務須要共享組件時，從產品倉庫獲取。

二、特殊狀況：特殊服務須要使用特殊的組件、框架，需提出申請，統籌規劃後進行決策。

6.開發階段

6.1. 服務的調用

6.1.1. AIP網關調用

全部服務經過 Zuul 網關進行調用，不容許直接調用微服務提供者。

Zuul 可能會成爲系統瓶頸，在項目複雜時可考慮爲 Zuul 進行主備或負載均衡處理。

6.1.2.同步調用

採用 HTTP REST方式進行調用， 針對業務需求能夠進行負載均衡， 負載均衡的調用方式有兩種：

一、 FeignClient

二、 RestTemplate

建議使用 *FeignClient*方式進行服務調用。

無論是什麼方式，他都是經過 REST接口調用服務的 http 接口，參數和結果默認都是經過 Jackson 序列化和反序列化。由於 Spring MVC 的 RestController 定義的接口，返回的數據都是經過 Jackson序列化成 JSON數據。

6.1.3.異步調用

rabbitMq 、 kafka、 Spring Cloud Stream 均是能夠選擇的方案。

Spring Cloud Stream ，基於 Redis、Rabbit 、Kafka 實現的消息微服務， 簡單聲明模型用以在Spring Cloud 應用中收發消息。

6.1.4. 服務間調用的權限驗證

通常咱們的 API接口都須要某種受權才能訪問， 登錄成功之後， 而後經過 token 或者 cookie等方式才能調用接口。使用 Spring Cloud Netfix 框架的話，登陸的時候，把登陸請求轉發到相應的用戶服務上，登錄成功後， 會設置 cookie 或 header token 等。而後客戶端接下來的請求就會帶着這些驗證信息，從 Zuul 網關傳到相應的服務上進行驗證。

Zuul 網關在把請求轉發到後臺的服務的時候，會默認把一些 header 傳到服務端，如：Cookie、Set-Cookie、Authorization 。這樣， 客戶端請求的相關 headers 就能夠傳遞到服務端，服務端設置的 cookie 也能夠傳到客戶端。

可是，若是你想禁止某些 header 透傳到服務端，能夠在 Zuul 網關的 application.yml 配置裏經過下面的方式禁用：

剛纔說了咱們的某個服務有時候須要調用另外一個服務，這時候，這個請求不是客戶端發起，他的請求的 header 裏面也不會有任何驗證信息。這時候，要麼，經過防火牆等設置，保證服務間調用的接口，只能某幾個地址訪問；要麼，就經過某種方式設置 header 。

同時，若是你想在某個服務裏面得到這個請求的真是 IP ，（由於請求的經過網關轉發而來，你直接經過 request 得到 ip獲得的是網關的 IP ），就能夠從 headerX-Forwarded-Host 得到。若是想禁用這個 header，也能夠：

若是你使用 RestTemplate 的方式調用，能夠在請求裏面添加一個有 header 的 Options 。也能夠經過以下的攔截器的方式設置，它對 RestTemplate 方式和 FeignClient 的方式均可以起做用：

@Bean

public RequestInterceptor requestInterceptor() {

return new RequestInterceptor() {

@Override
public void apply(RequestTemplate template) {
String authToken = getToken();
template.header(AUTH_TOKEN_HEADER, authToken);

}
};
}

6.1.5.服務編排

主要的做用是減小項目中的相互依賴。好比如今有項目 a 調用項目 b，項目 b 調用項目c...一直到 h，是一個調用鏈，那麼項目上線的時候須要先更新最底層的 h 再更新 g...更新 c更新 b 最後是更新項目 a。這只是這一個調用鏈，在複雜的業務中有很是多的調用，若是要記住每個調用鏈對開發運維人員來講就是災難。

有這樣一個好辦法能夠儘可能的減小項目的相互依賴， 就是服務編排， 一個核心的業務處理項目，負責和各個微服務打交道。好比以前是 a 調用 b， b 掉用 c， c 調用 d，如今統一在一個核心項目 W 中來處理， W 服務使用 a 的時候去調用 b，使用 b 的時候 W 去調用 c。

其實能夠理解爲面向對象的設計， 減小方法之間的一層層嵌套調用， 而採起一個方法進行業務流程的串聯，如方法 W 實現一個完整的業務處理，則採起下面方式：

function w （）

{

一、調用方法 a；

二、調用方法 b；

三、調用方法 c；

}

6.2. 服務的熔斷處理

在服務之間進行調用時， 因爲各類緣由會致使遠程 服務不可用 或壓力過載等異常致使的故障蔓延 ，此時須要有一種機制進行保護處理。 Spring Cloud 經過 Netflix 的 Hystrix 組件實現熔斷和降級 處理解決此問題。斷路器 (Cricuit Breaker) 是一種可以在遠程服務不可用時自動熔斷(打開開關 )，並在遠程服務恢復時自動恢復 (閉合開關 )的設施， Spring Cloud 經過 Netflix 的Hystrix 組件提供斷路器、資源隔離與自我修復功能。

6.3. 統一日誌管理

不一樣微服務部署在不一樣節點上， 登陸每一個節點查看日誌是比較麻煩的， 同時對於須要關聯多個微服務日誌聯合查看分析的狀況將更加麻煩。 伴隨節點數量的增長， 若是沒有合適的管理機制與工具，定位問題、發現問題的複雜性將愈來愈大， 將成指數級增加，所以須要進行統一日誌管理。

一、創建統一的日誌管理規範；

二、開發並使用統一的日誌組件，爲全部微服務提供統一的日誌服務，由 log4j 或 Blitz4j封裝；

三、在每一個服務節點上部署日誌採集 Agent 組件，由此 Agent 進行日誌的採集與轉發；

四、創建統一的日誌中心，全部日誌寫入日誌中心。

說明：上述日誌的實現由公司的「日誌管理平臺」進行實現，採用的是 ELK集合框架。

6.4. 統一監控管理

使用 Hystrix 組件進行服務的監控，使用 Nagios 進行服務器等資源的監控。

一、 Hystrix ，監控和斷路器。咱們只須要在服務接口上添加 Hystrix 標籤，就能夠實現對這個接口的監控和斷路器功能。

二、 Hystrix Dashboard ，監控面板，他提供了一個界面，能夠監控各個服務上的服務調用所消耗的時間等。

三、 Turbine，監控聚合，使用 Hystrix 監控，咱們須要打開每個服務實例的監控信息來查看。而 Turbine 能夠幫助咱們把全部的服務實例的監控信息聚合到一個地方統一查看。

這樣就不須要挨個打開一個個的頁面一個個查看。

6.5. 統一配置管理

實現各微服務的 統一參數配置以及版本管理 ，可採用公司的配置管理平臺或者 SpringCloud Config 配置中心。

pring Cloud Config 就是咱們一般意義上的配置中心。 Spring Cloud Config- 把應用本來放在本地文件的配置抽取出來放在中心服務器， 本質是配置信息從本地遷移到雲端 。從而可以提供更好的管理、發佈能力。

Spring Cloud Config 分服務端和客戶端， 服務端負責將 git （svn ）中存儲的配置文件發佈成 REST接口 ，客戶端能夠從服務端 REST接口獲取配置。但 客戶端並不能主動感知到配置的變化 ，從而主動去獲取新的配置，這須要 每一個客戶端經過 POST 方法觸發各自的/refresh。爲解決配置信息能及時通知到各服務， 同時減小每一個微服務處理配置信息更新的複雜度，

爲此咱們經過消息總線來解決此問題，方案以下：

​

1.	Git 倉庫、 Config Server	、以及微服務「 Service A 」、 「Service B」的實例中都
	引入了 Spring Cloud Bus	，因此他們都鏈接到了	RabbitMQ 的消息總線上。
2.	從 Git 倉庫中配置的修改到發起 /bus/refresh	的 POST請求這一步能夠經過	Git 倉庫

3.	/bus/refresh	請求再也不發送到具體服務實例上，而是發送給	Config Server ，並經過
	destination	參數來指定須要更新配置的服務或實例。
4.	因爲全部鏈接到消息總線上的應用都會接受到更新請求，因此在	WebHook 中就不須要
	維護全部節點內容來進行更新，從而解決了經過	Web Hook 來逐個進行刷新的問題。

6.6. 分佈式 session

採用 Redis 做爲緩存組件以及 session 的共享組件。

6.7. REST 資源響應結構

制定規範和解析方法。

6.8. API 調用鏈追蹤

Spring Cloud Sleuth 主要功能就是在分佈式系統中提供追蹤解決方案，而且兼容支持了 zipkin ，你只須要在 pom 文件中引入相應的依賴便可。

6.9. 單元測試

作微服務架構， 進行系統測試的複雜度較大， 爲保證產品質量與開發、 測試效率， 單元測試是必不可少的。

可採用 Mock 方式進行測試模擬， 由持續集成進行自動化單元測試的執行以及結果輸出。

6.10. 代碼調試

對於單體架構系統， 可直接本地化調試， 但對於微服務架構， 接口間的調用需採用遠程通信的方式， 也就是說被調用的服務必須啓動後方可被調用， 所以當微服務增多時， 你可能須要啓動大量的微服務或者 web 服務器，這給本地化調用與調試帶來了困難。

解決方案待研究。

7.測試

7.1. 自動化測試

單元測試：

由開發人員實現。

採用 Mock 方式進行測試模擬， 由持續集成進行自動化單元測試的執行以及結果輸出。

業務測試：

開發進行實現，測試也需考慮如何實現。將多個服務或業務單元進行串聯， 測試一個完整的業務， 甚至是不一樣業務之間組成的系統測試，須要採用相關的自動化測試框架執行，如 RobotFramework 自動化測試框架。

7.2. 依賴測試

也能夠稱爲接口測試或者契約測試， 在微服務逐漸增多的狀況下， 如何有效保證服務之間可以按照接口的約定正常工做， 即符合契約， 成爲微服務實施過程當中， 測試面臨的主要挑戰。

1、 開發自動化的接口測試工具，

一、檢測接口是否知足約定

二、檢測接口是否發生變化

三、檢測接口是否能夠正常被調用。

2、測試方法：

採起基於消費者驅動的契約測試，測試架構以下：

其優點以下：

從價值實現的角度定義契約從消費者使用契約的角度出發， 首先保證消費者基於此契約是能夠實現價值的， 有了這個前提，再使用契約來驗證提供者， 若是提供者提供的契約同定義的契約一致，則證實提供者提供的契約是可以實現服務消費者的。 經過這種方式， 使得更聚焦於如何從價值實現出發。

隔離消費者和提供者的測試對於契約的消費者和提供者能夠分開獨立測試， 有效解決傳統集成測試服務架構的弊端，將微服務的接口測試成本降到最低。

3、測試工具：

*Pact*、 *Janus*、 *Pacto*等。

7.3. 系統測試

7.4. 熔斷測試

一、經過中止微服務的方式測試服務路由的正確性

二、經過壓力測試，將某個微服務產生過載等異常，測試服務熔斷或降級

三、經過壓力測試，測試負載均衡策略的正確性

7.5. 性能測試

原有本地化的 api 調用將會變成 REST的遠程調用，調用速度勢必受到影響，所以須要對系統性能進行考慮以及性能測試，主要影響因素以下：

一、網絡：遠程調用時受到網絡通信速度的影響，這涉及到網絡速度、網絡部署以及系統架構，有相互依賴的服務應採起 就近部署原則 。

二、服務器：受到遠程服務所在服務器性能的影響。

三、數據量： 數據量這裏指的是數據大小以及數據傳輸的次數以及頻率， 此時 REST調用方式會產生瓶頸，固然， 最好的方式是避免此種狀況發生 ，此種場景採起消息中間件的方式異步通信。

8. 持續集成

一、持續集成：每一個微服務獨立執行持續集成。

二、版本集成：由統一的集成工具，實現自動化的版本集成，將全部微服務集成到統一

的版本發佈包中。

三、持續集成可製做多種場景的版本，包括測試環境、開發環境、生產環境。

四、統計測試覆蓋率等指標數據。

五、工具： Jenkins、 Sonar 等。

9.持續部署

1經過持續集成自動製做發佈版本的 Docker 鏡像；

2將 docker 鏡像自動上傳到 docker 容器中。

10.運維階段

10.1. 遠程升級

微服務不斷增長後， 意味着部署容器也在同步增長， 對於後續升級維護的工做量將會逐漸增長，開發統一管理中心，支持遠程維護與升級將可減小運維的複雜度。

10.2. 統一配置中心

使用 Spring Cloud Config 或者配置管理平臺進行統一的配置管理。

10.3. 統一日誌中心

使用日誌管理平臺進行統一的日誌採集、日誌分析。