為什麼要使用注冊中心
有使用過ip:port位址直接調用服務的開發經曆麼？該段痛苦的經曆在此處省略500字......，該種方式的缺點：
需要手動的維護所有的服務通路ip位址清單。
單個服務實作負載均衡需要自己搭建，例如使用nginx負載均衡政策，或者基于容器化多執行個體部署單個服務，在執行個體之間做負載均衡。
使用注冊中心能夠實作服務治理，服務動态擴容，以及服務調用的負載均衡，完整調用鍊路示例如下：
服務提供者：向注冊中心根據服務名稱提供服務通路的ip:port以及其他資訊。
注冊中心：根據服務名稱，存儲對應的ip:port以及其他資訊。
服務消費者：根據服務名向注冊中心擷取調用服務的ip:port以及其他相關的資訊集合，然後根據負載均衡政策擷取最終的伺服器ip：port通路位址。
使用springcloud時，常用的是eureka和nacos作為注冊中心，如何選擇呢？
推薦一個 Spring Boot 基礎教程及實戰示例：
https://github.com/javastacks/spring-boot-best-practiceEureka注冊中心
架構原理圖如下：
服務提供者
主動向注冊中心注冊，續約，下線，擷取系統資料庫。服務注冊成功後，定時向注冊中心發送心跳，保證服務不被剔除。
注冊中心
存儲服務執行個體，定時掃描系統資料庫，剔除過期的服務執行個體。通過同步複制方式實作高可用，先擷取系統資料庫，然後再向其他注冊中心注冊自己，屬于AP模式。在實際項目中，會根據環境，例如dev,test,prod配置不同的注冊中心叢集，如果不同的項目使用統一的注冊中心，隻能根據服務名稱做區分。
重點介紹一下Eureka自我保護機制。如果出現大量的服務執行個體過期被剔除，則注冊中心進入自我保護模式，系統資料庫中資訊不再被剔除，目的是提高eureka的可用性。預設情況下，統計心跳失敗比例在 15 分鐘之内是否低于 85%，如果低于 85%，Eureka Server 會将這些執行個體保護起來，讓這些執行個體不會過期。
講述一次慘痛的上線經曆，錯誤描述如下：
當時服務部署成功，在Eureka注冊中心已經顯示該服務已經注冊成功，但是，前端請求經過網關再轉發到該服務時，一直就沒有反應，服務調用一直不成功。nginx轉發，網關轉發都在确認問題到底發生在哪裡，幾經折磨，在網關直接通過ip位址轉發到上線的服務，快速的解決該問題。
後續，複盤，應該Eureka的自我保護機制，導緻的問題。在注冊中心注冊的服務是一個不可用的服務，但是，由于自我保護機制，Eureka Server沒有将無效的服務剔除。
後續的解決方法是，設定enableSelfPreservation=false關閉自我保護機制，把renewalPercentThreshold 比例降低，在Eureka Server端，如果出現無效的服務就會将該服務剔除。
nacos注冊中心
nacos是springcloud的擴充，注冊中心功能通過NacosDiscoveryClient 繼承DiscoveryClient，在springcloud中，與Eureka可以無侵入的切換。注冊中心可以手動剔除服務執行個體，通過消息通知用戶端更新緩存的執行個體資訊，完整調用鍊路示例如下：
在spring cloud中引入nacos時，參考官網比對具體的版本，如圖：
nacos重點需要了解下其領域模型Nacos 資料模型 Key 由三元組唯一确定, Namespace命名空間，分組group，service服務。詳情可以參考官網Nacos 架構。
nacos與Eureka相比優勢如下：
nacos在自動或手動下線服務，使用消息機制通知用戶端，服務執行個體的修改很快響應；Eureka隻能通過任務定時剔除無效的服務。
nacos可以根據namespace命名空間，DataId,Group分組，來區分不同環境（dev，test，prod），不同項目的配置。
原文連結：
https://blog.csdn.net/new_com/article/details/112633748版權聲明：本文為CSDN部落客「iloveoverfly」的原創文章，遵循CC 4.0 BY-SA版權協定，轉載請附上原文出處連結及本聲明