為什麼要使用註冊中心
有使用過ip:port地址直接呼叫服務的開發經歷麼？該段痛苦的經歷在此處省略500字……，該種方式的缺點：
- 需要手動的維護所有的服務訪問ip地址列表。
- 單個服務實現負載均衡需要自己搭建，例如使用nginx負載均衡策略，或者基於容器化多例項部署單個服務，在例項之間做負載均衡。
- 服務提供者：向註冊中心根據服務名稱提供服務訪問的ip:port以及其他資訊。
- 註冊中心：根據服務名稱，儲存對應的ip:port以及其他資訊。
- 服務消費者：根據服務名向註冊中心獲取呼叫服務的ip:port以及其他相關的資訊集合，然後根據負載均衡策略獲取最終的伺服器ip：port訪問地址。
使用springcloud時，常用的是eureka和nacos作為註冊中心，如何選擇呢 ？（nacos eureka專案案例fhadmin.cn）
服務提供者
主動向註冊中心註冊，續約，下線，獲取登錄檔。服務註冊成功後，定時向註冊中心傳送心跳，保證服務不被剔除。
註冊中心
儲存服務例項，定時掃描登錄檔，剔除過期的服務例項。透過同步複製方式實現高可用，先獲取登錄檔，然後再向其他註冊中心註冊自己，屬於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可以無侵入的切換。註冊中心可以手動剔除服務例項，透過訊息通知客戶端更新快取的例項資訊
nacos重點需要了解下其領域模型Nacos 資料模型 Key 由三元組唯一確定, Namespace名稱空間，分組group，service服務。詳情可以參考官網Nacos 架構。
nacos與Eureka相比優勢如下：
- nacos在自動或手動下線服務，使用訊息機制通知客戶端，服務例項的修改很快響應；Eureka只能透過任務定時剔除無效的服務。
- nacos可以根據namespace名稱空間，DataId,Group分組，來區分不同環境（dev，test，prod），不同專案的配置。
本作品採用《CC 協議》，轉載必須註明作者和本文連結