我們實現了用戶微服務、商品微服務和訂單微服務之間的遠程調用，并且實現了服務調用的負載均衡。

基于阿里開源的Sentinel實現了服務的限流與容錯，并詳細介紹了Sentinel的核心技術與配置規則。簡單介紹了服務網關，并對SpringCloud Gateway的核心架構進行了簡要說明，也在項目中整合了SpringCloud Gateway網關實現了通過網關訪問后端微服務。

同時，也基于SpringCloud Gateway整合Sentinel實現了網關的限流功能，詳細介紹了SpringCloud Gateway網關的核心技術。在鏈路追蹤章節，我們開始簡單介紹了分布式鏈路追蹤技術與解決方案，隨后在項目中整合Sleuth實現了鏈路追蹤，并使用Sleuth整合ZipKin實現了分布式鏈路追蹤的可視化 。

在消息服務章節，我們介紹了MQ的使用場景，引入MQ后的注意事項以及MQ的選型對比，在項目中整合了RocketMQ，并給大家介紹了RocketMQ的核心技術。

本章總覽

群魔亂舞(配置散落存儲)

當我們的項目采用微服務架構后，原本單一的項目會被拆分為一個個小的微服務。原來項目中的配置文件就需要在每個微服務下都要存儲一份，這些配置文件中的內容大部分都是相同的，只有個別的配置項不同。就拿數據庫配置來說吧，如果每個微服務使用的技術棧都是相同的，則每個微服務中關于數據庫的配置幾乎都是相同的，有區別的地方可能就是：數據庫連接，用戶名和密碼。

當項目采用微服務架構后，原本在單體項目中的配置文件就會散落在各個微服務中，如果不對這些散落的配置文件進行處理，就會造成各種各樣的問題?？偨Y起來，這些問題主要體現在如下幾個方面。

(1)配置文件散落在各個微服務項目中，隨著整體項目的業務越來越復雜，后續會新增更多的微服務項目，微服務項目越來越多，則散落在微服務中的配置文件也會越來越多，后續會變得難以統一維護和管理。

(2)配置文件散落在各個微服務項目中，還有一個非常棘手的問題，那就是修改配置文件非常麻煩。需要我們手動去修改每個微服務下的配置文件，稍有不慎，還會增加微服務項目出錯的風險。

(3)一般情況下，企業的項目發布環境包含開發環境、測試環境、預發布環境、生產環境。每個環境都需要對應不同的配置文件，如果不對這些配置文件進行統一管理，則每次發布到不同的環境時，都需要我們手動去修改每個微服務的配置文件，維護起來也是非常繁瑣的。

(4)在微服務中，手動修改了配置文件之后，修改后的具體的配置項無法在微服務項目中實時更新。每次修改配置文件后，都需要重新啟動微服務項目。不管是從開發角度，還是從運維角度，都是非常不友好的。

分久必合(配置中心)

基于上面的種種原因，我們絕不允許配置文件長期在各個微服務項目中分散存儲，那有沒有什么辦法將這些配置文件統一存放和管理呢?答案就是使用配置中心。

這里，冰河先用自己的大白話給配置中心下個定義吧。

配置中心就是在微服務項目中，統一管理和維護項目配置信息的地方，它支持配置信息的集中存儲，對外提供統一的接口獲取配置，支持各個微服務主動調用配置中心的接口獲取配置，也支持當配置信息發生變更時，由配置中心實時并且主動向各個微服務通知服務配置發生了變更，使其同步最新的配置信息。

哎，說好的大白話，讀起來還是有點“官腔”，算了，不管它了，大家能夠看懂就好。

在對配置中心的定義中，涵蓋了三項重要內容。

(1)配置中心將各個微服務中的配置進行統一集中管理和維護，并且對外提供統一的接口獲取相關配置。

(2)配置中心支持微服務主動調用配置中心的接口獲取配置信息。

(3)配置信息發生變更時，配置中心能夠實時并且主動向各個微服務通知服務配置發生了變更，使其同步最新的配置信息。

這里，我們還是以商城微服務化后為例，當引入配置中心后，數據庫配置信息，如下圖所示。

可以看到，在微服務中引入配置中心后，配置信息不再存儲到各個微服務項目中，也不用再手動修改每個微服務項目中的配置信息。而是在配置中心統一進行管理和維護。各個微服務會調用配置中心的接口獲取配置信息。當配置中心的配置信息發生變更時，配置中心會主動并且實時通知各個微服務，使其獲取配置中心的最新配置信息。

配置中心解決方案

針對項目采用微服務架構后的配置文件的存儲與管理問題，業界也提出了不少解決方案，也開源出了很多不錯的優秀項目，這里就給大家簡單列舉幾個。

Nacos配置中心概念