為什麼需要註冊中心
隨著單體應用拆分，首當面臨的第一份挑戰就是服務例項的數量較多，並且服務自身對外暴露的訪問地址也具有動態性。可能因為服務擴容、服務的失敗和更新等因素，導致服務例項的執行時狀態經常變化，如下圖:
商品詳情需要呼叫營銷、訂單、庫存三個服務，存在問題有:
1.營銷、訂單、庫存這三個服務的地址都可能動態的發生改變，單存只使用配置的形式需要頻繁的變更，如果是寫到配置檔案裡面還需要重啟系統，這對生產來說太不友好了;
2.服務是叢集部署的形式呼叫方負載均衡如何去實現；
解決第一個問題辦法就是用我們用偉人說過一句話，沒有什麼是加一箇中間層解決不了的，這個中間層就是我們的註冊中心；
解決第二問題就是關於負載均衡的實現，這個需要結合我們中間層老大哥來實現；
接下來我們聊聊如何解決兩個問題吧；
如何實現一個註冊中心
對於如何實現註冊中心這個問題，首先將服務之間是如何互動的模型抽象出來，我們結合實際的案例來說明這個問題，以商品服務來，
1.當我們搜尋商品的時候商品服務就是提供者；
2.當我們查詢商品詳情的時候即服務的提供者又是服務的消費者，消費是訂單、庫存等服務；
由此我們需要引入的三個角色就是:中間層(註冊中心)、生產者、消費者，如下圖:
整體的執行流程如下:
1.在服務啟動時，服務提供者通過內部的註冊中心客戶端應用自動將自身服務註冊到註冊中心，包含主機地址、服務名稱等等資訊；
2.在服務啟動或者發生變更的時候，服務消費者的註冊中心客戶端程式則可以從註冊中心中獲取那些已經註冊的服務例項資訊或者移除已下線的服務；
上圖還多一個設計快取本地路由，快取本地路由是為了提高服務路由的效率和容錯性，服務消費者可以配備快取機制以加速服務路由。更重要的是，當服務註冊中心不可用時，服務消費者可以利用本地快取路由實現對現有服務的可靠呼叫。
在整個執行的過程中，其中有點有一點是比較難的，就是服務消費者如何及時知道服務的生產者如何及時變更的，這個問題也是經典的生產者消費者的問題，解決的方式有兩種:
1.釋出-訂閱模式，服務消費者能夠實時監控服務更新狀態，通常採用監聽器以及回撥機制，經典的案例就是Zookeeper；
2.主動拉取策略，服務的消費者定期呼叫註冊中心提供的服務獲取介面獲取最新的服務列表並更新本地快取,經典案例就是Eureka；
對於如何選擇這兩種方式，其實還有一個資料一致性問題可以聊聊，比如選擇定時器肯定就拋棄了一致性，最求的是最終一致，這裡就不深入展開了，另外你可能還會說服務的移除等等這些功能都沒介紹，在我看來那只是一個附加功能，註冊中心重點還是在於服務註冊和發現，其他都是錦上添花罷了。後面我再出個輪子系列，把註冊中心的基礎功能都實現一下；
如何解決負載均衡的問題
負載均衡的實現有兩種方式:
1.服務端的負載均衡；
2.客戶端的負載均衡;
對於實現的方案來說本質上是差不多的，只是說承接的載體不一樣，一個是服務端，一個客戶端，如下圖:
服務端的負載均衡，給服務提供者更強的流量控制權，但是無法滿足不同的消費者希望使用不同負載均衡策略的需求。客戶端的負載均衡則提供了這種靈活性，並對使用者擴充套件提供更加友好的支援。但是客戶端負載均衡策略如果配置不當，可能會導致服務提供者出現熱點，或者壓根就拿不到任何服務提供者。
服務端負載均衡典型的代表就是Nginx，客戶端負載均衡典型代表是Ribbon，每種方式都有經典的代表，我們都是可以深入學習的，後續的章節也會有這些框架原理層的解密，歡迎大家點點關注。
常見的負載均衡器的演算法的實現，常見的演算法有以下六種:
1.輪詢法
將請求按順序輪流地分配到後端伺服器上，它均衡地對待後端的每一臺伺服器，而不關心伺服器實際的連線數和當前的系統負載。
2.隨機法
通過系統的隨機演算法，根據後端伺服器的列表大小值來隨機選取其中的一臺伺服器進行訪問。由概率統計理論可以得知，隨著客戶端呼叫服務端的次數增多；其實際效果越來越接近於平均分配呼叫量到後端的每一臺伺服器，也就是輪詢的結果。
3.雜湊演算法
雜湊的思想是根據獲取客戶端的IP地址，通過雜湊函式計算得到的一個數值，用該數值對伺服器列表的大小進行取模運算，得到的結果便是客服端要訪問伺服器的序號。採用源地址雜湊法進行負載均衡，同一IP地址的客戶端，當後端伺服器列表不變時，它每次都會對映到同一臺後端伺服器進行訪問。
4.加權輪詢法
不同的後端伺服器可能機器的配置和當前系統的負載並不相同，因此它們的抗壓能力也不相同。給配置高、負載低的機器配置更高的權重，讓其處理更多的請；而配置低、負載高的機器，給其分配較低的權重，降低其系統負載，加權輪詢能很好地處理這一問題，並將請求順序且按照權重分配到後端。
5.加權隨機法
與加權輪詢法一樣，加權隨機法也根據後端機器的配置，系統的負載分配不同的權重。不同的是，它是按照權重隨機請求後端伺服器，而非順序。
6.最小連線數法
最小連線數演算法比較靈活和智慧，由於後端伺服器的配置不盡相同，對於請求的處理有快有慢，它是根據後端伺服器當前的連線情況，動態地選取其中當前
積壓連線數最少的一臺伺服器來處理當前的請求，儘可能地提高後端服務的利用效率，將負責合理地分流到每一臺伺服器。
註冊中心選型
現在註冊中心的選擇也是五花八門，現階段比較流程有以下幾種:
在介紹這個之前大家有些需要了解的知識有CAP、Paxos、Raft演算法這裡我就不進行過多介紹了。開始介紹以上5種實現註冊中心的方式:
Zookeeper: 這個說起來有點意思的是官方並沒有說他是一個註冊中心，但是國內Dubbo場景下很多都是使用Zookeeper來完成了註冊中心的功能。
當然這有很多歷史原因，這裡我們就不追溯了，我還是來聊聊作為註冊中心使用的情況下，Zookeeper有哪些表現吧。
Zookeeper基礎概念:
三種角色:
Leader 角色:一個Zookeeper叢集同一時間只會有一個實際工作的Leader，它會發起並維護與各Follwer及Observer間的心跳。所有的寫操作必須要通過Leader完成再由Leader將寫操作廣播給其它伺服器。
Follower角色:一個Zookeeper叢集可能同時存在多個Follower，它會響應Leader的心跳。Follower可直接處理並返回客戶端的讀請求，同時會將寫請求轉發給Leader處理，並且負責在Leader處理寫請求時對請求進行投票。
Observer角色:與Follower類似，但是無投票權。
四種節點：
1.PERSISTENT-持久節點除非手動刪除，否則節點一直存在於Zookeeper上
2.EPHEMERAL-臨時節點臨時節點的生命週期與客戶端會話繫結，一旦客戶端會話失效，那麼這個客戶端建立的所有臨時節點都會被移除。
3.PERSISTENT_SEQUENTIAL-持久順序節點基本特性同持久節點，只是增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
4.EPHEMERAL_SEQUENTIAL-臨時順序節點基本特性同臨時節點，增加了順序屬性，節點名後邊會追加一個由父節點維護的自增整型數字。
一種機制:
Zookeeper的Watch機制，是一個輕量級的設計。因為它採用了一種推拉結合的模式。一旦服務端感知主題變了，那麼只會傳送一個事件型別和節點資訊給關注的客戶端，而不會包括具體的變更內容，所以事件本身是輕量級的，這就是推的部分。然後，收到變更通知的客戶端需要自己去拉變更的資料，這就是拉的部分。
Zookeeper如何實現註冊中心?
簡單來講，Zookeeper可以充當一個服務登錄檔（Service Registry），讓多個服務提供者形成一個叢集，讓服務消費者通過服務登錄檔獲取具體的服務訪問地址（ip+埠）去訪問具體的服務提供者。如下圖所示：
每當一個服務提供者部署後都要將自己的服務註冊到zookeeper的某一路徑上: /{service}/{version}/{ip:port}, 比如我們的HelloWorldService部署到兩臺機器，那麼Zookeeper上就會建立兩條目錄：分別為/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。這麼描述有點不好理解，下圖更直觀，
在Zookeeper中，進行服務註冊，實際上就是在Zookeeper中建立了一個Znode節點，該節點儲存了該服務的IP、埠、呼叫方式(協議、序列化方式)等。該節點承擔著最重要的職責，它由服務提供者(釋出服務時)建立，以供服務消費者獲取節點中的資訊，從而定位到服務提供者真正IP，發起呼叫。通過IP設定為臨時節點，那麼該節點資料不會一直儲存在 ZooKeeper 伺服器上。當建立該臨時節點的客戶端會話因超時或發生異常而關閉時，該節點也相應在 ZooKeeper 伺服器上被刪除，剔除或者上線的時候會觸發Zookeeper的Watch機制，會傳送訊息給消費者，因此就做到消費者資訊的及時更新。
Zookeeper從設計上來說的話整體遵循的CP的原則，在任何時候對 Zookeeper 的訪問請求能得到一致的資料結果，同時系統對網路分割槽具備容錯性，在使用 Zookeeper 獲取服務列表時，如果此時的 Zookeeper 叢集中的 Leader 當機了，該叢集就要進行 Leader 的選舉，又或者 Zookeeper 叢集中半數以上伺服器節點不可用（例如有三個節點，如果節點一檢測到節點三掛了 ，節點二也檢測到節點三掛了，那這個節點才算是真的掛了），那麼將無法處理該請求。所以說，Zookeeper 不能保證服務可用性。
Eureka: Eureka 2.x目前是閉源的，但是Ereka 1.x 任然是比較活躍的，所以大家還是可以考慮這款產品的，Netflix我感覺應該是在醞釀更好的東西的，下面我們重點還是來介紹Ereka 1.x相關的設計。
Eureka由兩個元件組成：Eureka伺服器和Eureka客戶端。Eureka伺服器用作服務註冊伺服器。Eureka客戶端是一個java客戶端，用來簡化與伺服器的互動、作為輪詢負載均衡器，並提供服務的故障切換支援。
Eureka的基本架構，由3個角色組成：
1、Eureka Server
提供服務註冊和發現功能；
2、Service Provider
服務提供方，將自身服務註冊到Eureka，從而使服務消費方能夠找到；
3、Service Consumer
服務消費方，從Eureka獲取註冊服務列表，從而能夠消費服務；
Eureka 在設計時就緊遵AP原則，Eureka Server 可以執行多個例項來構建叢集，解決單點問題，例項之間通過彼此互相註冊來提高可用性，是一種去中心化的架構，無 master/slave 之分，每一個例項 都是對等的，每個節點都可被視為其他節點的副本。
在叢集環境中如果某臺 Eureka Server 當機，Eureka Client 的請求會自動切換到新的 Eureka Server 節點上，當當機的伺服器重新恢復後，Eureka 會再次將其納入到伺服器叢集管理之中。當節點開始接受客戶端請求時，所有的操作都會在節點間進行復制操作，將請求複製到該 Eureka Server 當前所知的其它所有節點中。
當一個新的 Eureka Server 節點啟動後，會首先嚐試從鄰近節點獲取所有註冊列表資訊，並完成初始化。Eureka Server 通過 getEurekaServiceUrls() 方法獲取所有的節點，並且會通過心跳契約的方式定期更新。
預設情況下，如果 Eureka Server 在一定時間內沒有接收到某個服務例項的心跳（預設週期為30秒），Eureka Server 將會登出該例項（預設為90秒， eureka.instance.lease-expiration-duration-in-seconds 進行自定義配置）；
當 Eureka Server 節點在短時間內丟失過多的心跳時，那麼這個節點就會進入自我保護模式，這個測試環境的時候需要注意一下，
Eureka的叢集中，只要有一臺Eureka還在，就能保證註冊服務可用，只不過查到的資訊可能不是最新的（不保證強一致性）。除此之外，Eureka還有一種自我保護機制，如果在15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：
Eureka不再從登錄檔中移除因為長時間沒有收到心跳而過期的服務；Eureka仍然能夠接受新服務註冊和查詢請求，但是不會被同步到其它節點上（即保證當前節點依然可用）；當網路穩定時，當前例項新註冊的資訊會被同步到其它節點中。
Nacos:Nacos是阿里開源的，作為後起之秀，想要勝過前輩自然是需要很多亮點的，
1.Nacos 無縫支援一些主流的開源生態,如下圖:
2.Nacos 致力於幫助您發現、配置和管理微服務。Nacos 提供了一組簡單易用的特性集，幫助您快速實現動態服務發現、服務配置、服務後設資料及流量管理。
3.Nacos 幫助您更敏捷和容易地構建、交付和管理微服務平臺。 Nacos 是構建以“服務”為中心的現代應用架構 (例如微服務正規化、雲原生正規化) 的服務基礎設施。
4.Nacos除了服務的註冊發現之外，還支援動態配置服務。動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴充套件變得更容易。
Nacos特點:
1.服務發現和服務健康監測
Nacos 支援基於 DNS 和基於 RPC 的服務發現。服務提供者使用 原生SDK、OpenAPI、或一個獨立的Agent TODO註冊 Service 後，服務消費者可以使用DNS TODO 或HTTP&API查詢和發現服務。
Nacos 提供對服務的實時的健康檢查，阻止向不健康的主機或服務例項傳送請求。Nacos 支援傳輸層 (PING 或 TCP)和應用層 (如 HTTP、MySQL、使用者自定義）的健康檢查。 對於複雜的雲環境和網路拓撲環境中（如 VPC、邊緣網路等）服務的健康檢查，Nacos 提供了 agent 上報模式和服務端主動檢測2種健康檢查模式。Nacos 還提供了統一的健康檢查儀表盤，幫助您根據健康狀態管理服務的可用性及流量。
2.動態配置服務
動態配置服務可以讓您以中心化、外部化和動態化的方式管理所有環境的應用配置和服務配置。
動態配置消除了配置變更時重新部署應用和服務的需要，讓配置管理變得更加高效和敏捷。
配置中心化管理讓實現無狀態服務變得更簡單，讓服務按需彈性擴充套件變得更容易。
Nacos 提供了一個簡潔易用的UI (控制檯樣例 Demo) 幫助您管理所有的服務和應用的配置。Nacos 還提供包括配置版本跟蹤、金絲雀釋出、一鍵回滾配置以及客戶端配置更新狀態跟蹤在內的一系列開箱即用的配置管理特性，幫助您更安全地在生產環境中管理配置變更和降低配置變更帶來的風險。
3.動態 DNS 服務
動態 DNS 服務支援權重路由，讓您更容易地實現中間層負載均衡、更靈活的路由策略、流量控制以及資料中心內網的簡單DNS解析服務。動態DNS服務還能讓您更容易地實現以 DNS 協議為基礎的服務發現，以幫助您消除耦合到廠商私有服務發現 API 上的風險。
Nacos 提供了一些簡單的 DNS APIs TODO 幫助您管理服務的關聯域名和可用的 IP:PORT 列表.
4.服務及其後設資料管理
Nacos 能讓您從微服務平臺建設的視角管理資料中心的所有服務及後設資料，包括管理服務的描述、生命週期、服務的靜態依賴分析、服務的健康狀態、服務的流量管理、路由及安全策略、服務的 SLA 以及最首要的 metrics 統計資料。
5.Nacos支援外掛管理
關於Nacos資料的儲存來說，支援臨時也支援持久化。
關於設計來說支援CP也支援AP，對他來說只是一個命令的切換，隨你玩，還支援各種註冊中心遷移到Nacos，反正一句話，只要你想要的他就有。
Consul:
Consul是HashiCorp公司推出的開源工具，Consul由Go語言開發，部署起來非常容易，只需要極少的可執行程式和配置檔案，具有綠色、輕量級的特點。Consul是分散式的、高可用的、 可橫向擴充套件的用於實現分散式系統的服務發現與配置。
Consul的特點:
1.服務發現（Service Discovery）：Consul提供了通過DNS或者HTTP介面的方式來註冊服務和發現服務。一些外部的服務通過Consul很容易的找到它所依賴的服務。
2.健康檢查（Health Checking）：Consul的Client可以提供任意數量的健康檢查，既可以與給定的服務相關聯(“webserver是否返回200 OK”)，也可以與本地節點相關聯(“記憶體利用率是否低於90%”)。操作員可以使用這些資訊來監視叢集的健康狀況，服務發現元件可以使用這些資訊將流量從不健康的主機路由出去。
3.Key/Value儲存：應用程式可以根據自己的需要使用Consul提供的Key/Value儲存。 Consul提供了簡單易用的HTTP介面，結合其他工具可以實現動態配置、功能標記、領袖選舉等等功能。
4.安全服務通訊：Consul可以為服務生成和分發TLS證照，以建立相互的TLS連線。意圖可用於定義允許哪些服務通訊。服務分割可以很容易地進行管理，其目的是可以實時更改的，而不是使用複雜的網路拓撲和靜態防火牆規則。
5.多資料中心：Consul支援開箱即用的多資料中心. 這意味著使用者不需要擔心需要建立額外的抽象層讓業務擴充套件到多個區域。
Consul支援多資料中心，在上圖中有兩個DataCenter，他們通過Internet互聯，同時請注意為了提高通訊效率，只有Server節點才加入跨資料中心的通訊。
在單個資料中心中，Consul分為Client和Server兩種節點（所有的節點也被稱為Agent），Server節點儲存資料，Client負責健康檢查及轉發資料請求到Server；Server節點有一個Leader和多個Follower，Leader節點會將資料同步到Follower，Server的數量推薦是3個或者5個，在Leader掛掉的時候會啟動選舉機制產生一個新的Leader。
叢集內的Consul節點通過gossip協議（流言協議）維護成員關係，也就是說某個節點了解叢集內現在還有哪些節點，這些節點是Client還是Server。單個資料中心的流言協議同時使用TCP和UDP通訊，並且都使用8301埠。跨資料中心的流言協議也同時使用TCP和UDP通訊，埠使用8302。
叢集內資料的讀寫請求既可以直接發到Server，也可以通過Client使用RPC轉發到Server，請求最終會到達Leader節點，在允許資料延時的情況下，讀請求也可以在普通的Server節點完成，叢集內資料的讀寫和複製都是通過TCP的8300埠完成。
Consul其實也可以在應用內進行註冊，後續採用Spring Cloud全家桶這套做負載
我們這裡聊聊關於Consul的應用外的註冊，
上圖主要多出來兩個元件，分別是Registrator和Consul Template，接下來我們介紹下這兩個元件如何結合可以實現在應用發進行服務發現和註冊:
Registrator：一個開源的第三方服務管理器專案，它通過監聽服務部署的 Docker 例項是否存活，來負責服務提供者的註冊和銷燬。
Consul Template：定時從註冊中心服務端獲取最新的服務提供者節點列表並重新整理 LB 配置（比如 Nginx 的 upstream），這樣服務消費者就通過訪問 Nginx 就可以獲取最新的服務提供者資訊,達到動態調節負載均衡的目的。
整體架構圖可能是這樣:
我們用Registrator來監控每個Server的狀態。當有新的Server啟動的時候，Registrator會把它註冊到Consul這個註冊中心上。由於Consul Template已經訂閱了該註冊中心上的服務訊息，此時Consul註冊中心會將新的Server資訊推送給Consul Template，Consul Template則會去修改nginx.conf的配置檔案，然後讓Nginx重新載入配置以達到自動修改負載均衡的目的。
Kubernetes註冊與發現
Kubernetes是一個輕便的和可擴充套件的開源平臺，用於管理容器化應用和服務。通過Kubernetes能夠進行應用的自動化部署和擴縮容。在Kubernetes中，會將組成應用的容器組合成一個邏輯單元以更易管理和發現。Kubernetes積累了作為Google生產環境執行工作負載15年的經驗，並吸收了來自於社群的最佳想法和實踐。Kubernetes經過這幾年的快速發展，形成了一個大的生態環境，Google在2014年將Kubernetes作為開源專案。Kubernetes的關鍵特性包括：
1.自動化裝箱：在不犧牲可用性的條件下，基於容器對資源的要求和約束自動部署容器。同時，為了提高利用率和節省更多資源，將關鍵和最佳工作量結合在一起。
2.自愈能力：當容器失敗時，會對容器進行重啟；當所部署的Node節點有問題時，會對容器進行重新部署和重新排程；當容器未通過監控檢查時，會關閉此容器；直到容器正常執行時，才會對外提供服務。
3.水平擴容：通過簡單的命令、使用者介面或基於CPU的使用情況，能夠對應用進行擴容和縮容。
4.服務發現和負載均衡：開發者不需要使用額外的服務發現機制，就能夠基於Kubernetes進行服務發現和負載均衡。
5.自動釋出和回滾：Kubernetes能夠程式化的釋出應用和相關的配置。如果釋出有問題，Kubernetes將能夠迴歸發生的變更。
6.保密和配置管理：在不需要重新構建映象的情況下，可以部署和更新保密和應用配置。
7.儲存編排：自動掛接儲存系統，這些儲存系統可以來自於本地、公共雲提供商（例如：GCP和AWS）、網路儲存(例如：NFS、iSCSI、Gluster、Ceph、Cinder和Floker等)。
Kubernetes屬於主從分散式架構，主要由Master Node和Worker Node組成，以及包括客戶端命令列工具Kubectl和其它附加項。
Master Node：作為控制節點，對叢集進行排程管理，Master主要由三部分構成:
1.Api Server相當於 K8S 的閘道器，所有的指令請求都必須經過 Api Server;
2.Scheduler排程器，使用排程演算法，把請求資源排程到某個 Node 節點;
3.Controller控制器，維護 K8S 資源物件（CRUD：新增、刪除、更新、修改）;
4.ETCD儲存資源物件（可以服務註冊、發現等等）;
Worker Node：作為真正的工作節點，執行業務應用的容器；Worker Node主要包含五部分:
1.Docker是執行容器的基礎環境，容器引擎;
2.Kuberlet 執行在 Node 節點上的資源操作，Scheduler 把請求交給Api ，然後 Api Sever 再把資訊指令資料儲存在 ETCD 裡，於是 Kuberlet 會掃描 ETCD 並獲取指令請求，然後去執行;
3.Kube-proxy是代理服務，起到負載均衡作用；
4.Fluentd採集日誌;
5.Pod：Kubernetes 管理的基本單元（最小單元），Pod 內部是容器。Kubernetes 不直接管理容器，而是管理 Pod;
我們重點要介紹一下Pod相關的知識:
1.Pod 相當於一個容器，Pod 有獨立的 Ip 地址，也有自己的 Hostname，利用 Namespace 進行資源隔離，相當於一個獨立沙箱環境。
2.Pod 內部承載的是容器，可以包含多個容器；
3.Pod 內部的容器之間是通過 localhost 進行訪問；
Kubernetes如何做註冊與發現?
關於這個問題還需要引入一個Service的概念:
Service是Kubernetes的核心資源型別之一，Service資源基於標籤選擇器將一組Pod定義成一個邏輯組合，並通過自己的IP地址和埠排程代理請求到組內的Pod物件，如下圖所示，它向客戶端隱藏了真是的，處理使用者請求的Pod資源，使得從客戶端上看，就像是由Service直接處理並響應一樣。
Service物件的IP地址也稱為Cluster IP，它位於為Kubernetes叢集配置指定專用的IP地址範圍之內，是一種虛擬的IP地址，它在Service物件建立之後保持不變，並且能夠被同一叢集中的Pod資源所訪問。Service埠用於接受客戶端請求，並將請求轉發至後端的Pod應用的相應埠。Pod通過標籤與Service進行關聯，一個Service只能關聯一組標籤相同的Pod。
關於Service如何實現服務的註冊與發現，主要流程是這樣的Kube-proxy 通過Watch機制監聽Apiserver中有關Service的變動資訊(Pod建立或者銷燬)，獲取任何一個與Service資源相關的變動狀態(Pod建立或者銷燬)，一旦有Service資源相關的變動和建立，Kube-proxy都要轉換為當前節點上的能夠實現資源排程規則。
總結一下:
1.高可用
這幾款開源產品都已經考慮如何搭建高可用叢集，這個地方有些差別而已；
2.關於CP還是AP的選擇
對於服務發現來說，針對同一個服務，即使註冊中心的不同節點儲存的服務提供者資訊不盡相同，也並不會造成災難性的後果。但是對於服務消費者來說，如果因為註冊中心的異常導致消費不能正常進行，對於系統來說是災難性，因此我覺得對於註冊中心選型應該關注可用性，而非一致性，所以我選擇AP。
3.技術體系
對於語言來說我們都是Java技術棧，從這點來說我們更傾向於Eureka、Nacos;如果公司內部有專門的中介軟體或者運維團隊的可以Consul、Kubernetes，畢竟Kubernetes才是未來，我們追求的就是框架內解決這些問題，不要涉及到應用內的業務開發，我們其實後者是有的，只是可能不能達到能自主研發程度，這樣只能要求自己走的遠一些。應用內的解決方案一般適用於服務提供者和服務消費者同屬於一個技術體系；應用外的解決方案一般適合服務提供者和服務消費者採用了不同技術體系的業務場景。
關於Eureka、Nacos如何選擇，這個選擇就比較容易做了，那個讓我做的事少，我就選擇那個，顯然Nacos幫我們做了更多的事。
4.產品的活躍度
這幾款開源產品整體上都比較活躍；
結束
歡迎大家點點關注，點點贊，感謝!
