題目
在微服務系統中，當服務達到一定數量時，通常需要引入【注冊中心】組件，以方便服務發現。
大家有沒有思考過，注冊中心存在的最根本的原因是什么呢？注冊中心在企業中的最佳實踐是怎樣的？注冊中心的服務發現有兩大模式，分別是：【客戶端發現模式】和【服務端發現模式】，這兩者之間有怎樣的區別呢？
下面關于【注冊中心】的描述中，說法正確的有哪幾項？
A. 注冊中心存在的本質原因是為了降低【服務提供方】和【服務消費方】之間的耦合性，避免兩者循環依賴的問題；
B. 在大中型微服務系統中，【注冊中心】通常需要和 “服務管理平臺” 配合完成 服務的注冊和訂閱，而【注冊中心】專注于 “服務節點的注冊” 和 “服務節點的發現”；
C.【客戶端發現模式】的注冊中心相對直接，因為客戶端知曉可用的服務實例，能針對特定應用實現智能負載均衡；Consul Template 是客戶端發現模式的典型范例；
D.【服務端發現模式】的注冊中心最大的優點是客戶端無需關注服務發現的細節，減少了編程語言框架需要完成的服務發現邏輯；這種模式對部署環境的依賴較強，Netflix Eureka 是服務端發現模式的典型范例。
解析
一、先討論注冊中心存在的本質原因
舉例，服務消費方 X 遠程調用服務提供方 Y，如下圖所示。我們說，服務 X 依賴于服務 Y；也就是說，服務 X 知道服務 Y 的存在性， 而服務 Y 不知道服務 X 的存在性。當服務 Y 集群擴容一個節點或縮容一個節點時，服務 Y 就需要把這種情況同步告之服務 X，也就是說，服務 Y 需要知道服務 X 的存在性。
言外之意，從服務調用上來說，服務 X 依賴于服務 Y，但是從服務管理上來說，服務 Y 又需要依賴于服務 X。此時，服務消費方和服務提供方之間形成了一種循環依賴的局面。怎么解決這個問題呢？這就是【注冊中心】這個組件存在的根本原因了，如下圖所示。
為了避免服務提供方 Y 對服務消費方 X 的依賴，服務 Y 只需把自己注冊到【注冊中心】即可，然后哪個服務對 Y 感興趣，自己去【注冊中心】發現和獲取就好了，服務 Y 不用關注。因此：注冊中心存在的本質原因是為了降低【服務提供方】和【服務消費方】之間的耦合性，避免兩者之間循環依賴的問題。
二、再說注冊中心在企業應用的一種最佳實踐。
如下圖所示，【服務管理平臺】用于對服務集群信息（比如：服務名稱、服務負責人、服務歸屬部門、服務吞吐量等）和服務訂閱信息進行管理，側重于對服務集群的管理；【注冊中心】用于對服務節點的注冊、健康檢查、提供節點查詢和變更通知等，側重于對服務節點的管理。
基本的服務流程如下：
-
服務負責人在對外發布服務時，需要首先在【服務管理平臺】上對服務進行注冊；
-
服務消費方服務的負責人，如果要調用其他服務，需要在【服務管理平臺】上發起調用申請，即 “訂閱服務”申請；該申請被審批通過后，方可生效，畢竟如果是高吞吐的調用，是需要服務提供方集群進行擴容的；
-
服務提供方服務集群中的每一個節點，在啟動的時候，將自己注冊到【注冊中心】；并且每一個節點在宕機或假死時，注冊中心都可以通過 “健康檢查” 及時獲取到；
-
服務消費方服務集群中的每一個節點，在啟動的時候或啟動之后，都可以到【注冊中心】獲取到已經訂閱的服務提供方集群中還活躍的服務節點列表；如果服務提供方集群節點列表有任何變化，【注冊中心】都可以及時將 “變更信息” 通知到服務消費方集群中的每一個節點；
-
最后，服務消費方集群中的每一個節點，向服務提供方集群中的每一個節點發起 【RPC】調用。
三、我們再討論注冊中心服務發現的兩大模式：【客戶端發現模式】和【服務端發現模式】。
【客戶端發現模式】更為常見，如下圖所示。服務提供方向注冊中心進行注冊，每一個服務消費方節點從注冊中心獲取服務提供方服務集群的節點列表，并且對請求實現負載均衡。
【客戶端發現模式】的注冊中心相對直接一些，因為客戶端知曉可用的服務實例，能針對特定應用實現智能負載均衡；這種模式的缺點就是客戶端與服務注冊綁定，要針對服務端用到的每個編程語言和框架，實現客戶端的服務發現邏輯；Netflix Eureka ?是客戶端發現模式的典型范例。
【服務端發現模式】如下圖所示，客戶端直接將請求打在 服務端的 “負載均衡” 組件上，“負載均衡” 組件查詢【注冊中心】獲取服務提供方節點列表，然后將請求轉發到其中一個節點上。
【服務端發現模式】最大的優點就是客戶端無需關注服務發現的細節，只需要簡單地直接向負載均衡器發送請求即可，這減少了編程語言框架需要完成的服務發現邏輯；不過，這種模式需要部署環境提供這樣的 “負載均衡”組件方可，對部署環境的依賴較強；Consul Template 是服務端發現模式的典型范例。（關于Consul Template 我們會在后續進行詳細分析！）
參考答案
AB
