不知道有沒有考慮過這樣一個問題，爲什麼要註冊中心呢？以及註冊中心該如何的選擇呢？還是默認的哪個是最新的，哪個用的人多，就選用哪個呢？
服務之間的互相調用時，需要服務端開啓服務，客戶端進行對接。但是，想一下，客戶端想要發送一個請求到服務端的時候，需要什麼數據呢？ ip地址，端口號等等吧。在只有一個客戶端和一個服務端的情況下，這些ip地址可以在客戶端的配置文件中寫死即可。
如果是多個服務端進行發佈服務呢？或者如果在配置文件中寫死的server3宕機了呢？那是不是需要再次修改配置文件中的ip呢？這樣一來，註冊中心就解決了這個問題，客戶端調用的時候去註冊中心獲取服務端信息（ip，端口等等），獲取信息之後，再進行調用，如果需要加服務，或者服務宕機，只需要修改註冊中心的信息即可。
註冊中心就是存儲一些服務信息，負責服務的註冊與發現。有新的服務啓動即在註冊中心填寫自己服務的基本信息。有服務宕機，註冊中心通過自己的一些機制，把宕機的服務信息進行剔除，通過這樣的方式讓客戶端動態的知道服務的最新信息。但是一旦註冊中心出現問題，比如斷網了，或者宕機了，那麼整個服務的調度就會出問題，這一塊也需要注意一下。
1.常見的註冊中心
1.1 Zookeeper
我覺得現在如果還是在用dubbo框架的公司註冊中心基本上都是zk作爲註冊中心。畢竟是官方推薦使用的註冊中心。
zookeeper是一個基於CP設計的，zookeeper提供了watch機制，watch機制是一個發佈訂閱的功能。觀察者訂閱自己感興趣的主題，比如訂閱服務器節點的變化。如果zookeeper節點發生變化，會推送給訂閱了此節點的觀察者。通過這種方式，實現了服務器宕機，或者新的服務註冊進來告訴客戶端更新服務端信息。
優點就是數據一致性做的好，缺點當然也有。zookeeper集羣中有三種角色（zookeeper服務器節點），它們分別是：羣首（leader），追隨者（follower），觀察者（observer）。在leader宕機之後，總要選擇出一個leader來領導大家工作呀，這個時候需要選舉出一個新的leader。在選舉的這段時間整個集羣的狀態是不可用的。
1.2 Eureka
dubbo推薦用zookeeper作爲註冊中心，spring cloud推薦的是Eureka。都是官方推薦的註冊中心，想必這兩個一定各有優點。
eureka是基於AP設計的。eureka集羣是一個去中心化的架構，沒有master/slave的區分。這樣的好處就是即使eureka集羣中有一個服務不可用了，那麼其他的服務還是可以進行工作的。
缺點就是eureka沒有類似zookeeper中的watch機制，服務的註冊與發現是通過心跳來判斷的。就比如服務端有新增或者剔除操作，客戶端需要隔一段時間才能知道。
2. Nacos的不同之處
Nacos 默認登錄密碼 nacos/nacos
Nacos提供了可視化管理頁面，Nacos 控制檯主要旨在於增強對於服務列表，健康狀態管理，服務治理，分佈式配置管理等方面的管控能力，以便進一步幫助用戶降低管理微服務應用架構的成本，將提供包括下列基本功能:
- 配置管理
- 多種配置格式編輯
- 編輯DIFF
- 示例代碼
- 推送狀態查詢
- 配置版本及一鍵回滾
- 服務管理
- 服務列表及服務健康狀態展示
- 服務元數據存儲及編輯
- 服務流量權重的調整
- 服務優雅上下線
- 命名空間
- 登錄管理
2.1 Nacos配置管理
如果有如下需求
- 服務不能重啓，修改限流數量。
- 服務太多了，如果數據庫連接信息在各個服務中配置，如果有改動怎麼辦?每個服務都改一下？如果服務不能重啓，可不可以實現呢？
- 有測試環境，生產環境，要配置的東西太多了，可不可以統一管理一下呀。
- 配置文件的內容可不可以實現實時的修改呢？
如果只是普通的業務開發，這些需求可能不需要關心，技術大佬想怎麼配置就怎麼配置，小弟默默跟隨就好，但是如果是站在架構師的角度上，這些東西不得不考慮。Nacos提供了配置管理，可以更方便的實現動態更新。
2.1.1 配置列表
zookeeper一般只是用來服務的註冊，eureka有config組件，但是沒有可視化的配置。
Nacos可視化配置頁面
在右邊加號即可新增配置或者修改配置
- data Id：Nacos 中的某個配置集的 ID。配置集 ID 是組織劃分配置的維度之一。Data ID 通常用於組織劃分系統的配置集。一個系統或者應用可以包含多個配置集，每個配置集都可以被一個有意義的名稱標識。Data ID 通常採用類 Java 包（如 com.taobao.tc.refund.log.level）的命名規則保證全局唯一性。此命名規則非強制。
- group: Nacos 中的一組配置集，是組織配置的維度之一。通過一個有意義的字符串（如 Buy 或 Trade ）對配置集進行分組，從而區分 Data ID 相同的配置集。當您在 Nacos 上創建一個配置時，如果未填寫配置分組的名稱，則配置分組的名稱默認採用 DEFAULT_GROUP 。配置分組的常見場景：不同的應用或組件使用了相同的配置類型，如 database_url 配置和 MQ_topic 配置。
官方這麼說，搞的我也是有點夢。還是直接上手吧，自己玩玩就直到咋回事了。
有如上配置
dataId：example.properties
group：DEFAULT_GROUP
內容：didispace.title=spring-cloud-alibaba-learning123123
md5: 這個是用來校驗客戶端配置文件是否與註冊中心一致用的，這個不需要我們來修改。（快速比對兩條消息是否一致，可以通過消息的hash值來比對，也可以使用md5來比對）
如果想要獲取這些配置需要先修改bootstrap.properties,這裏注意是哪個配置文件，別改成application.properties了。
#這裏是註冊中心的地址 spring.cloud.Nacos.config.server-addr=127.0.0.1:8848 #data ID的名字要和這裏這兩個對應起來，如果是yml格式下面也要改成yml spring.application.name=example spring.cloud.Nacos.config.file-extension=properties
啓動：
@SpringBootApplication
public class NacosConfigApplication {
public static void main(String[] args) {
SpringApplication.run(NacosConfigApplication.class, args);
}
@RestController
@RefreshScope
static class TestController {
@Value("${didispace.title}")
private String title;
@GetMapping("/test")
public String hello() {
return title;
}
}
}
通過如上代碼即可進行測試。我在這裏不多解釋，官網直接下載即可使用。
2.1.2 歷史版本
Nacos通過提供配置版本管理及其一鍵回滾能力，幫助用戶改錯配置的時候能夠快速恢復，降低微服務系統在配置管理上的一定會遇到的可用性風險。
不知道是我版本的bug還是哪裏的問題，這裏必須要輸入data Id和group 才能查詢到版本歷史，默認的列表是沒有信息的。
2.1.3 監聽者查詢
Nacos提供配置訂閱者即監聽者查詢能力，同時提供客戶端當前配置的MD5校驗值，以便幫助用戶更好的檢查配置變更是否推送到 Client 端。
可以通過md5或者hash值來快速比對兩條數據是否一致。
2.2 Nacos服務管理
服務列表幫助用戶以統一的視圖管理其所有的微服務以及服務健康狀態。整體界面佈局是左上角有服務的搜索框和搜索按鈕，頁面中央是服務列表的展示。服務列表主要展示服務名、集羣數目、實例數目、健康實例數目和詳情按鈕五個欄目。
2.2.1 服務流量權重支持及流量保護
Nacos 爲用戶提供了流量權重控制的能力，同時開放了服務流量的閾值保護，以幫助用戶更好的保護服務服務提供者集羣不被意外打垮。如下圖所以，可以點擊實例的編輯按鈕，修改實例的權重。如果想增加實例的流量，可以將權重調大，如果不想實例接收流量，則可以將權重設爲0。
2.2.2 服務元數據管理
Nacos提供多個維度的服務元數據的暴露，幫助用戶存儲自定義的信息。這些信息都是以K-V的數據結構存儲，在控制檯上，會以k1=v1,k2=v2這樣的格式展示。類似的，編輯元數據可以通過相同的格式進行。例如服務的元數據編輯，首先點擊服務詳情頁右上角的“編輯服務”按鈕，然後在元數據輸入框輸入：version=1.0,env=prod。
2.2.3 服務優雅上下線
Nacos還提供服務實例的上下線操作，在服務詳情頁面，可以點擊實例的“上線”或者“下線”按鈕，被下線的實例，將不會包含在健康的實例列表裏。
官方資料：