普通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服務調用

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其中一台挂掉後,還沒有同步配置資訊,

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

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