服務配置：服務配置介紹與Nacos核心
我們實現(xiàn)了用戶微服務、商品微服務和訂單微服務之間的遠程調(diào)用，并且實現(xiàn)了服務調(diào)用的負載均衡。
基于阿里開源的Sentinel實現(xiàn)了服務的限流與容錯，并詳細介紹了Sentinel的核心技術(shù)與配置規(guī)則。簡單介紹了服務網(wǎng)關(guān)，并對SpringCloud Gateway的核心架構(gòu)進行了簡要說明，也在項目中整合了SpringCloud Gateway網(wǎng)關(guān)實現(xiàn)了通過網(wǎng)關(guān)訪問后端微服務。
同時，也基于SpringCloud Gateway整合Sentinel實現(xiàn)了網(wǎng)關(guān)的限流功能，詳細介紹了SpringCloud Gateway網(wǎng)關(guān)的核心技術(shù)。在鏈路追蹤章節(jié)，我們開始簡單介紹了分布式鏈路追蹤技術(shù)與解決方案，隨后在項目中整合Sleuth實現(xiàn)了鏈路追蹤，并使用Sleuth整合ZipKin實現(xiàn)了分布式鏈路追蹤的可視化 。
在消息服務章節(jié)，我們介紹了MQ的使用場景，引入MQ后的注意事項以及MQ的選型對比，在項目中整合了RocketMQ，并給大家介紹了RocketMQ的核心技術(shù)。
本章總覽
群魔亂舞(配置散落存儲)
當我們的項目采用微服務架構(gòu)后，原本單一的項目會被拆分為一個個小的微服務。原來項目中的配置文件就需要在每個微服務下都要存儲一份，這些配置文件中的內(nèi)容大部分都是相同的，只有個別的配置項不同。就拿數(shù)據(jù)庫配置來說吧，如果每個微服務使用的技術(shù)棧都是相同的，則每個微服務中關(guān)于數(shù)據(jù)庫的配置幾乎都是相同的，有區(qū)別的地方可能就是：數(shù)據(jù)庫連接，用戶名和密碼。
當項目采用微服務架構(gòu)后，原本在單體項目中的配置文件就會散落在各個微服務中，如果不對這些散落的配置文件進行處理，就會造成各種各樣的問題?？偨Y(jié)起來，這些問題主要體現(xiàn)在如下幾個方面。
(1)配置文件散落在各個微服務項目中，隨著整體項目的業(yè)務越來越復雜，后續(xù)會新增更多的微服務項目，微服務項目越來越多，則散落在微服務中的配置文件也會越來越多，后續(xù)會變得難以統(tǒng)一維護和管理。
(2)配置文件散落在各個微服務項目中，還有一個非常棘手的問題，那就是修改配置文件非常麻煩。需要我們手動去修改每個微服務下的配置文件，稍有不慎，還會增加微服務項目出錯的風險。
(3)一般情況下，企業(yè)的項目發(fā)布環(huán)境包含開發(fā)環(huán)境、測試環(huán)境、預發(fā)布環(huán)境、生產(chǎn)環(huán)境。每個環(huán)境都需要對應不同的配置文件，如果不對這些配置文件進行統(tǒng)一管理，則每次發(fā)布到不同的環(huán)境時，都需要我們手動去修改每個微服務的配置文件，維護起來也是非常繁瑣的。
(4)在微服務中，手動修改了配置文件之后，修改后的具體的配置項無法在微服務項目中實時更新。每次修改配置文件后，都需要重新啟動微服務項目。不管是從開發(fā)角度，還是從運維角度，都是非常不友好的。
分久必合(配置中心)
基于上面的種種原因，我們絕不允許配置文件長期在各個微服務項目中分散存儲，那有沒有什么辦法將這些配置文件統(tǒng)一存放和管理呢?答案就是使用配置中心。
這里，冰河先用自己的大白話給配置中心下個定義吧。
配置中心就是在微服務項目中，統(tǒng)一管理和維護項目配置信息的地方，它支持配置信息的集中存儲，對外提供統(tǒng)一的接口獲取配置，支持各個微服務主動調(diào)用配置中心的接口獲取配置，也支持當配置信息發(fā)生變更時，由配置中心實時并且主動向各個微服務通知服務配置發(fā)生了變更，使其同步最新的配置信息。
哎，說好的大白話，讀起來還是有點“官腔”，算了，不管它了，大家能夠看懂就好。
在對配置中心的定義中，涵蓋了三項重要內(nèi)容。
(1)配置中心將各個微服務中的配置進行統(tǒng)一集中管理和維護，并且對外提供統(tǒng)一的接口獲取相關(guān)配置。
(2)配置中心支持微服務主動調(diào)用配置中心的接口獲取配置信息。
(3)配置信息發(fā)生變更時，配置中心能夠?qū)崟r并且主動向各個微服務通知服務配置發(fā)生了變更，使其同步最新的配置信息。
這里，我們還是以商城微服務化后為例，當引入配置中心后，數(shù)據(jù)庫配置信息，如下圖所示。
可以看到，在微服務中引入配置中心后，配置信息不再存儲到各個微服務項目中，也不用再手動修改每個微服務項目中的配置信息。而是在配置中心統(tǒng)一進行管理和維護。各個微服務會調(diào)用配置中心的接口獲取配置信息。當配置中心的配置信息發(fā)生變更時，配置中心會主動并且實時通知各個微服務，使其獲取配置中心的最新配置信息。
配置中心解決方案
針對項目采用微服務架構(gòu)后的配置文件的存儲與管理問題，業(yè)界也提出了不少解決方案，也開源出了很多不錯的優(yōu)秀項目，這里就給大家簡單列舉幾個。
配置中心 | 說明 |
Consul | 谷歌基于Go語言開發(fā)出的一款支持服務動態(tài)發(fā)現(xiàn)的配置管理中心服務。在Consul中，內(nèi)置了服務注冊與發(fā)現(xiàn)功能，實現(xiàn)了分布式一致性協(xié)議，支持Key-Value存儲，支持多數(shù)據(jù)中心。 |
Apollo | 協(xié)程開源的一款支持分布式的配置中心。支持修改后的配置動態(tài)實時生效，對項目的配置進行版本化管理，對配置的修改支持審計，支持項目的灰度發(fā)布。 |
Disconf | 百度開源的一款支持分布式的配置中心，主要是利用Zookeeper實現(xiàn)配置信息變更后，實時通知各個微服務，使變更后的配置信息生效。 |
SpringCloud Config | SpringCloud技術(shù)棧中自帶的配置中心組件，支持使用Git倉庫存儲配置信息，不支持配置信息變更后實時生效。 |
Nacos | SpringCloud Alibaba技術(shù)棧中的一個在微服務環(huán)境下，支持分布式服務注冊與發(fā)現(xiàn)，支持服務元數(shù)據(jù)及流量管理，支持分布式配置中心的組件。使用Nacos可以輕松實現(xiàn)服務的注冊與發(fā)現(xiàn)，以及分布式配置中心功能。 |
Nacos配置中心概念
核心概念 | 中文說明 | 概念說明 |
Namespace | 命名空間 | 主要用于不同環(huán)境下的配置隔離，不同的環(huán)境會被劃分到不同的命名空間中。 |
Group | 配置分組 | 主要用于將不同的微服務劃分到同一個分組中。通常情況下，會將組成整體項目的各個微服務的配置統(tǒng)一劃分到同一個分組中。 |
Data ID | 配置集 ID | 通常情況下，在系統(tǒng)中，一個配置文件就是一個配置集，在這個配置文件中，能夠包含系統(tǒng)各個方面的配置信息。配置集ID就是某個配置集的ID，也就是系統(tǒng)中某個配置文件的ID。 |
