CAP理論
RuoYiplus 使用Eureka做爲註冊中心，說到註冊中心首先想到的應該是‘’分佈式」，分佈式系統有個著名的理論—CAP理論【Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性）】git
著名的CAP理論指出，一個分佈式系統不可能同時知足C(一致性)、A(可用性)和P(分區容錯性)。因爲分區容錯性在是分佈式系統中必需要保證的，所以咱們只能在A和C之間進行權衡。Eureka保證的是AP，Zookeeper則保證的是CP。github
- 一致性（C）：在分佈式系統中的全部數據備份，在同一時刻是否一樣的值。（等同於全部節點訪問同一份最新的數據副本）
- 可用性（A）：在集羣中一部分節點故障後，集羣總體是否還能響應客戶端的讀寫請求。（對數據更新具有高可用性）
- 分區容忍性（P）：以實際效果而言，分區至關於對通訊的時限要求。系統若是不能在時限內達成數據一致性，就意味着發生了分區的狀況，必須就當前操做在C和A之間作出選擇。 （當分區數據不一致時，要保證系統的正常運行）
Zookeeper(CP)
zk使用的是ZAB協議（Zookeeper 原子廣播協議），ZooKeeper它所作的就是確保對數據的修改都會被複制到集合體中超過半數的節點上。若是少於半數的機器出現故障，則最少有一臺機器會保存最新的狀態，那麼這臺機器就是咱們的Leader。其他的副本最終也會更新到這個狀態。若是 Leader掛了，因爲其餘機器保存了Leader的副本，那就能夠從中選出一臺機器做爲新的Leader繼續提供服務。
從原則上來講,zookeeper保證了強一致性,但實際上寫操做的2pc提交不須要全部的節點都投票經過,而是超過半數的節點投票經過便可,那麼有的節點有可能沒有第一時間接收到寫操做的同步而leader已經經過該寫操做,這樣的話鏈接到該節點的服務只能說獲得了數據單調一致性的保障,而不是強一致性的保障。可是總的來講，zookeeper是至關偏向於一致性而非可用性的服務註冊與管理中間件，須要注意的是這也會大幅度增長寫入數據的性能成本，可是通常狀況下做爲服務中心寫入的數據並很少，還在可接受的範圍內。（以上爲網上資料）redis
Eureka(AP)
相對於zookeeper，eureka至關偏向於A而非C，便是說一臺鏈接不到集羣的eureka節點依然能夠對外提供服務,即便提供的數據不必定是最新的,可是在某些狀況下總比服務之間宕機要好。spring
在eureka集羣中，若是某個節點發生宕機，eureka不會有相似zookeeper選舉的行爲,即不會對外中止服務。客戶端請求會切換到別的eureka節點，當宕機的服務器從新恢復後會被再次加入集羣管理中同步別的eureka server保存的註冊信息。當網絡分割故障發生時，每一個eureka server節點都能繼續對外提供服務。後端
eureka server還有心跳機制，默認狀況下eureka server一段時間內沒有接受服務提供者發送的心跳就會將其剔除，可是也有多是eureka server發生了網絡分區故障。若是eureka server在一段時間內丟失了大量心跳，那麼會進入自我保護模式，此時有如下行爲模式：
一、Eureka Server再也不從註冊列表中移除由於長時間沒收到心跳而應該過時的服務。
二、Eureka Server仍然可以接受新服務的註冊和查詢請求，可是不會被同步到其它節點上，保證當前節點依然可用。
三、當網絡穩定時，當前Eureka Server新的註冊信息會被同步到其它節點中。
所以Eureka Server能夠很好的應對因網絡故障致使部分節點失聯的狀況，而不會像ZK那樣若是有一半不可用的狀況會致使整個集羣不可用而變成癱瘓。設計模式
eureka client還擁有緩存功能，即便全部的eureka server都不可用，那麼client依然可以使用本地緩存鏈接已緩存的一些服務。 （以上爲網上資料）緩存
總結
- Eureka更偏向AP，注重服務的可用性。zk更偏向CP，注重服務的一致性。至於才用那種，須要看具體業務，例如支付相關，相比一致性纔是更重要。
- 就做者而言，兩種註冊中都是使用過，感受來講。zk太笨重，Eureka輕巧好用。
- 如今的互聯網應用，正逐漸全面走向微服務架構，Eureka是spring cloud的一員，相比來講，將來的擴展前景會更好。
RuoYiPlus開源
本項目由 SMP 多商戶權限管理系統 + API 接口服務組成，是在開源項目 RuoYi4.0（若依） 的基礎上升級調整的微服務體系，項目基於 SpringBoot2.x，springcloudG 版本 eureka、hystrix、feign、config、gateway 微服務架構，集成 redis、tk.mybatis、lombok、各類設計模式等，是可選性後臺管理系統或後端接口服務。服務器
源碼地址
- Gitee(主)：https://gitee.com/aimeng2017/RuoYi-plus
- Github(輔)：https://github.com/zebra-ruoyi-plus/ruoyi-plus
加入社區
