普通springcloud eureka 和 spring cloud Alibaba nacos 註冊中心

  -------------------------------------普通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其中一臺掛掉後,還沒有同步配置信息,

    就可能發生配置不一致的情況., 配置中心的配置變更是服務端有監聽器,配置中心發生配置變化,

    然後服務端會監聽到配置發生變化,從而做出改變

 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章