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