governance.png
背景
- 隨著微服務的發(fā)展,我們的難免會引入一些rpc框架去幫我處理遠程調用,今天簡單介紹一下背后的實現和發(fā)展
rpc
-
因為服務化的出現,我們調用其他服務的方法可能就不再是本地調用方法那么簡單,之前一個簡單的方法調用,如今變成了遠程調用,最直白的方法就是在本地創(chuàng)建一個遠程服務的動態(tài)代理,現在我們一般都是基于spring框架開發(fā)的,所以一般這個遠程服務的動態(tài)代理是在spring容器啟動的時候基于遠程接口生成的,然后注冊到spring 容器中,當我們調用遠程服務方法時,其實調用的是本地的動態(tài)代理,然后本地動態(tài)代理里面去做調用遠程的服務,比如通過netty 調用遠程某個端口,或者通過http等等。
rpc.png -
但是上面的rpc調用有很多問題,因為是分布式系統(tǒng)間的調用,所以可能會有很多問題 掰盘， 比如
- 對方服務掛
- 我們這邊流量太大對方扛不住
- 我們一直請求對方的某個節(jié)點服務造成流量不均衡
- 對方的服務ip地址變了
- 我們請求超時了(是失敗了還是成功了 未知)
等等很多很多問題;那么如果按照上面那個最原始的rpc調用可能會出很多問題,因此分布式系統(tǒng)中引入了一些服務治理的方案
- 引入了服務注冊和發(fā)現(一般是基于分布式服務注冊中心)
- 引入了熔斷限流 方便服務降級
- 引入了重試 解決了可能會出現的網絡超時摄悯、抖動等問題(需要接口支持冪等)
-
引入了負載均衡策略(解決了可能會出現的流量不均衡)
rpc_with_governance.png
總結
- 分布式系統(tǒng)中的通信都需要rpc框架的支持,比如服務和很多中間件的通信底層的都需要rpc的支持,比如kafka broker 和 producer、consumer的通信 , redis client 和 redis cluster 的通信愧捕、elasticsearch client 和對應集群的通信奢驯、配置中心client 和 集群的通信 ，有些需要高性能 在netty上做了一些開發(fā)作為節(jié)點間的通信,有的為了簡單直接用http,但是都會遇到一些流控等問題次绘，也就是上下游速率不平衡 以及負載均衡
