在學習微服務的時候，我們都會聽到兩個詞：注冊中心、配置中心。
什么是注冊中心呢？
解釋這個問題前，要先了解下什么是微服務結構，就我個人的理解，以前一個大型項目，有許多模塊，例如用戶管理模塊、系統管理模塊、訂單模塊、商品模塊、庫存模塊.........，整個項目可能單單java文件就能有幾百上千個。這種大項目打一次war包可能就要幾十分鍾甚至幾個小時，而且這種大項目在一個服務器上跑，浪費的資源是十分大的，而且訪問量也低，這就是早期的單體項目。后來人們將這個大項目按模塊拆開，各個模塊自己作為一個web項目，彼此之間通過網絡進行服務器間的通訊（RPC、webservice、HTTP等），各個模塊自己隨意部署，就漸漸演變成分布式項目。微服務和分布式其實是差不多的東西，都是將大項目拆解成小項目。
各個項目模塊間通過網絡進行通信，那各個項目就必須知道其他項目運行那哪一個機器上，IP是多少，端口是多少。如果我們部署的機器不多，而且都很固定，那我們可以直接寫死在程序里。但是煩人的運維總是說機器性能不行，要把某個模塊的項目部署多幾個機器上，這樣就又出現了一個新名詞：集群。
這樣子多部署幾個項目雖然解決了性能和訪問量的問題，但是頻繁加機器減機器，就使得管理IP和端口變成了噩夢。於是乎，技術大佬們就開始想：能不能每次啟動一個項目，就讓他自己獲取IP和端口，然后丟到網絡上的某個地方，其他項目要用時就自己去取呢？為解決這個問題，大佬自己打算自己擼一個項目。這個項目就叫“IP端口管理中心”，只提供兩個接口：1、接收別人發送的ip和端口信息並存儲起來。2、查詢並返回相應的IP和端口信息。其他人想要用我這玩意，就必須引入我提供的客戶端jar，並在啟動時調用我的客戶端方法，去獲取本機IP和端口，然后發送給“IP端口管理中心”。你要用時自己請求“IP端口管理中心”獲取信息。
其實這個“IP端口管理中心”就是最原始版本的注冊中心。其實這玩意並不復雜，只是現在市面上常用的注冊中心都加入了很多功能，並且進行了性能優化，跟自己手擼的簡單版本還是會有不少差距的。
市面上常見的注冊中心有下面這幾種：
其實注冊中心在我們的開發使用上是非常簡單的，注冊中心實際上就是一個項目（或者說一個軟件），我們使用它的步驟都很固定：
- 下載對應的注冊中心
- 修改注冊中心的配置文件
- 啟動注冊中心
- 我們的開發項目中引入注冊中心的客戶端jar
- 我們的代碼上加入相應的注解或者配置
- 啟動我們的項目
另外有一點要注意的是，eureka並不提供完整可運行的軟件或者項目，eureka的依賴分成客戶端依賴和服務端依賴，我們需要自己手動建一個新項目，如果加入eureka的服務端依賴，配置，然后啟動這個項目，這個就是注冊中心了。
這五種注冊中心，consul、eureka、nacos是提供了管理頁面的，zookeeper沒有提供，coreDNS不知道，沒用過。
nacos是阿里的產品，提供中文文檔，其他都是英文文檔。
eureka好像不再繼續開發了。
我這里只說說Nacos的基本使用，其他注冊中心自己網上百度。
Nacos的使用是非常簡單的，基本上看看官網，跟着教程走一下，你就算入門了，熟練了。
官網：https://nacos.io/zh-cn/docs/what-is-nacos.html
官網上的下載地址時GitHub的，小水管，其他地方收費，自己上傳雲盤了，下載地址：https://wws.lanzous.com/ii7UVhrn8di
nacos下載后運行我曾出現了這個問題：
然后就是一閃而過，自動關閉。
看日志給我顯示這玩意：
還以為是數據庫連接問題，后來發現是因為nacos默認下載下來就是以cluster的方式運行的，並不是單機形式運行
打開bin/startup.cmd，進行編輯，修改MODE模式為standalone就可以正常啟動了
具體的部署自己跟着官網走，我不多廢話，https://nacos.io/zh-cn/docs/deployment.html
也可以看這篇文檔https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-discovery 更簡單明了
另外nacos的一些參數配置可以看這個地址，https://nacos.io/zh-cn/docs/system-configurations.html
這是我自己玩的時候寫的一些注釋
# Spring Cloud Alibaba Nacos Config 目前提供了三種配置能力從 Nacos 拉取相關的配置。
# A: 通過 spring.cloud.nacos.config.shared-configs[n].data-id 支持多個共享 Data Id 的配置
# B: 通過 spring.cloud.nacos.config.extension-configs[n].data-id 的方式支持多個擴展 Data Id 的配置，或者ext-config
# C: 通過內部相關規則(應用名、應用名+ Profile )自動生成相關的 Data Id 配置
# 當三種方式共同使用時，他們的一個優先級關系是:A < B < C 注意：只會使用優先級最高的那個配置，低優先級的配置不加載
cloud:
nacos:
config:
enabled: true # 開啟配置中心功能
server-addr: 127.0.0.1:8848
file-extension: yml # 如果配置后綴名不是properties，就必須聲明
namespace: a4d88caf-5c3e-45f5-9021-04ec354b99ad # 指定命名空間，如果不是public，那么必須指定命名空間的id，注意，不是空間名
refresh-enabled: true # 運行自動刷新配置
group: DEFAULT_GROUP # 指定組
extension-configs: # 如果需要指定多個配置，可以使用這種方法
- dataId: test1.yml
- dataId: test2.yml
group: HONGCHENG_GROUP
refresh: true
# 配置項參考地址 https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-discovery
discovery:
enabled: true # 開啟注冊中心功能
server-addr: 127.0.0.1:8848
# service: hongcheng # 服務名，默認為spring.application.name
group: hong # 服務分組名
weight: 4 # 負載均衡時的權重，1 ~ 100
# network-interface: # 當IP未配置時，注冊的IP為此網卡所對應的IP地址，如果此項也未配置，則默認取第一塊網卡的地址
# ip: 127.0.0.1 # 指定當前機器所在的ip地址，優先級最高，不寫的話自動獲取
# port: 9999 # 指定當應用使用的端口，優先級最高，不寫的話自動獲取
namespace: a4d88caf-5c3e-45f5-9021-04ec354b99ad # 命名空間id，不同命名空間的服務不能相互調用
說完注冊中心，再說說配置中心
前面說過注冊中心是因為機器數量過多，不易於管理而出現的，同樣配置中心也是因為這種原因而誕生。
springboot的出現，本身就已經減少了我們的配置量，但是仍舊還是存在配置。在我們將大項目拆分成小項目后，我們的配置文件也同樣裂變成了好幾份，即便你兩個小項目用的是同樣的配置，你也要復制兩次。一旦我們的小項目數量多了起來，那么管理這些配置將會讓運維想跳樓。
而且一旦某個項目部署了十幾二十個機器上后，你開發修改了某一個配置項，那就意味這必須重啟這十幾二十個機器上的項目。這時候運維可能在提刀過來砍你的路上。為了避免這種事情的發生，大佬又使出了第二套武功秘籍：再做一個項目專門管理配置項，也就是配置中心。
配置中心只需要做三件事就行：1、存儲配置項。2、提供接口返回配置項。3、通過接口通知應用放棄之前的環境，重新根據配置項生成一個新的環境。市面上也有不少配置中心的產品，他們增加了挺多的擴展功能，我們直接用就好。
網上偷一張圖說說各配置中心對比：
Spring Cloud Config 我覺得使用起來比較麻煩，而且他需要依賴git來存儲配置文件，我不是很喜歡。
Apollo是攜程的，不過我沒用過。
Nacos是阿里的，可以做注冊中心也可以做配置中心，用起來很簡單，配置可以存在文件、MySQL、Redis中。
Nacos的配置中心文檔可以看這個：https://github.com/alibaba/spring-cloud-alibaba/wiki/Nacos-config 通俗易懂，簡單直接，用了你就會愛上
配置中心的使用步驟也很固定，跟使用注冊中心的步驟完全一樣的：
- 下載對應的配置中心
- 修改配置中心的配置文件
- 啟動配置中心
- 我們的開發項目中引入配置中心的客戶端jar
- 我們的代碼上加入相應的注解或者配置
- 啟動我們的項目
給你們看看nacos的管理界面
