webservice使用xml，服務之間的依賴比較強，數據包比較大，編譯和解析因爲xml的遞歸解析形式，性能不好
dubbo、hsf是基於RPC，dubbo強語言依賴，發送方是什麼語言寫的，服務方就要用什麼語言解析。dubbo就是在兩端開websocket，用於建立兩點之間的通信，傳的是序列化好的對象。
Dubbo 底層原理
分佈式系統調用：
把服務放在另一個節點上計算，減輕當前節點上的運算壓力。
相當於提供方將接口文檔打一個jar包，提供給調用方
網絡發包只能發byte數組，所以要序列化成二進制
SpringCloud
SpringCloud和Dubbo的區別
Dubbo是遠程服務中的RPC，長連接，是自定義的協議
SpringCloud是Http協議，
rpc和http相比，rpc的效率更高。但rpc要求請求雙方實現語言相同。而http的序列化和反序列化是基於字符串的，使用json傳遞。好處是跨語言。
http要發心跳包，所以要耗費一些資源，但是相比語言的解耦，這些資源消耗是可以接受的。
示例
Consumer
Provider
UserAPI接口被Consumer項目實現。可以提供給Consumer
OpenFeign用來讀懂API的SpringMVC的註解
Feign可以通過聲明式（自己定義）遠程服務調用的方式，在調用方的代碼
測試效果
SpringCloud提供了一套服務降級的服務框架Hystrix，包括：服務降級、服務熔斷、資源隔離
服務降級
所有服務都調不通，就降低服務標準，但仍然能提供服務，而不是直接調用失敗，拋出異常。
服務熔斷
如果每一次都調用失敗，這段時間內就不再進行這個服務的調用了，直接去調用別的服務。
服務的上下線（對於註冊中心來說）
如果能提供服務，會在註冊中心列表中標記，標記的是網絡狀態。註冊中心進行定時的心跳包檢測。
如果服務雖然在，但無法提供服務，可以主動上報
如果調用失敗，不應該從註冊中心列表中剔除。可能只是網絡抖動、網絡分區造成的調用失敗。
（CAP中的P：分區容錯性）
重試策略：默認6秒，記錄在調用方，而不是記錄在註冊中心。
示例
再加入一個91的服務
隔離
限制調用次數。可以使用線程池。
Hytrix怎麼實現的？
try{
// 調用服務
}catch{
//熔斷降級/資源隔離/加入不調列表，設置一個超時時間;
//調用降級方法;
}
ribbon
來幫我們選擇服務器，內置了選取策略
其它
微服務目前很火，可能慢慢會被servicemesh取代，因爲只需要關注業務邏輯，不用關注服務治理