-------------------------------------普通springcloud eureka 1 .eureka 注冊中心：做了兩個eureka服務，以此類推可以做多個，互相注冊，高可用，集群部署 2. zipkin跟蹤服務：分布式跟蹤日志,基于記憶體存盤記錄 3 .zuul網關路由服務：分發請求，統一管理過濾，結合 ribbon 負載均衡、 hystrix斷路器 4. springboot-admin 監控中心服務：統一界面管理，查看各個服務運行狀態 actuator健康檢查
---------------------------------spring cloud Alibaba nacos 注冊中心 fhadmin.cn
1 .nacos 阿里注冊中心：官方eureka停止更新，目前比較好的取代者就是nacos 2. zipkin 跟蹤服務：分布式跟蹤日志,基于記憶體存盤記錄 3 .gateway 網關路由服務：分發請求，統一管理過濾，結合 LoadBalancer負載均衡、 feign服務呼叫 4. springboot-admin 監控中心服務：統一界面管理，查看各個服務運行狀態 actuator健康檢查 5. sentinel 高可用流量管理框架： 以流量為切入點，限流、流量整形、熔斷降級、系統負載保護、熱點防護 nacos和eureka注冊中心對比1. CP 和 AP不可能同時滿足
2.P代表磁區容錯, 在整個分布式系統中某個節點服務掛掉了,并不影響整個系統的運作和使用，
因為他可以在稍后或者通過切換可用節點立即恢復使用
3.C: 寫操作之后的讀操作，必須回傳該值，
注冊中心集群中: leader的作用, 所有的寫操作都依賴于leader來完成,為了保證資料的一致性, leader只有一個
假如: 沒有leader,首先加入我們新加入一臺資料處理服務,就會向注冊中心1進行注冊,注冊中心1寫入資料處理服務的ip
等等基本資訊,并且準備同步給其他注冊中心節點, 結果這個在還沒發生同步的程序中,注冊中心1掛掉了,
然后客戶端準備呼叫資料中心寫入,這個時候就因為注冊中心1掛掉了,就直接切到了注冊中心2,但是注冊中心2沒有
收到資料處理服務的添加請求,所以沒有這個服務,這個時候就對客戶端顯示不可用了.
4. A: 沒有leader,可以很容易的切換到可用的注冊中心,對于客戶端的呼叫總是及時反應, 在上述C操作的例子中,
對于向服務注冊,獲取服務注冊的基本資訊,比如ip來說,基本不會存在,因為像Eureka來說,我們的服務可以
向所有的注冊中心節點發起注冊請求, 這樣就不會存在注冊中心節點服務串列不一致的情況
阿里的nacos : 性能最好 fhadmin.cn
他同時支持AP和CP模式,他根據服務注冊選擇臨時和永久來決定走AP模式還是CP模式,
他這里支持CP模式對于我的理解來說,應該是為了配置中心集群,因為nacos可以同時作為注冊中心和配置中心,
因為他的配置中心資訊是保存在nacos里面的,假如因為nacos其中一臺掛掉后,還沒有同步配置資訊,
就可能發生配置不一致的情況., 配置中心的配置變更是服務端有監聽器,配置中心發生配置變化,
然后服務端會監聽到配置發生變化,從而做出改變
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/315860.html
標籤：Java