1.協議
dubbo是基於rpc協議，基於接口的遠程調用；不能跨平臺
Cloud是http協議的，restful風格的，可以實現跨平臺調用
rpc協議是基於更底層的TCP協議，數據不需要通過http協議包裝，實踐性能更好。
2.使用方式
dubbo一般是xml配置的方式，cloud是boot基於註解的
3.註冊發現
dubbo使用的是zookeeper，在分佈式系統中，zookeeper更加關注一致性，和容錯性；當zookeeper主節點掛掉會有一個30~120s的選舉時間，期間服務是不可用的。
cloud的註冊中心使用的是EureKa,更加關注的是可用性，和分區容錯，多個eureka不存在單點問題；
4.容錯原理
Eureka server默認情況下在一定時間內沒有收到某個微服務實例的心跳，eureka會註銷該實例（90s）,但當網絡發生分區故障時，微服務與Eureka無法正常通信，不應該註銷。通過自我保護來解決這個問題.
Eureka自我保護模式
當Eureka Server節點在短時間內發生丟失過多的客戶端（可能是網絡分區故障），那麼這個節點就會進入自我保護模式，一旦進入該模式，Eureka Server就會保護註冊表中的信息，不再刪除註冊表中的數據，即不再註銷任何微服務，當網絡恢復後。eureka節點會自動退出自我保護模式。
zookeeper和dubbo默認建立的是臨時節點 當多了一個服務端 zookeeper會心跳通知消費端 讓消費端在本地緩存存儲該地址， 其中有一個服務提供者下線也是同理 zookeeper會讓通知dubbo消費端清除那個失效的緩存 ，消費端調用服務端是查找本地緩存的地址的。
服務提供者向註冊中心註冊服務，消費者從註冊中心訂閱所需要的服務，但不是所有的服務，當新的提供者出現或者現有的提供者宕機，註冊中心都會盡早發現，並更新提供者的列表，推送給對應的消費者。有了這種機制，dubbo才能做到failover,而failover的時效性，由註冊中心的實現決定