1.RPC框架的評測
Martin Flower定義的微服務是基於REST,Spring cloud就是其標準的實現,通用但HTTP協議比較冗餘,短連接建立也較耗時,消息體一般基於JSON串行化反串行化, 性能肯定一般。
而Dubbo默認是用netty長連接,和hession lite二進制串行化, 按理說應該比spring cloud性能要好些。
參考下turbo-rpc作者的測評 https://www.jianshu.com/p/cdd94d0853c3
結果傻眼了,阿里系的dubbo和sofa好弱，微博的motan, springwebflux都穩贏。評測都預熱的了,dubbo應該是2.7,sofa是5.5都比較新的版本,不過基本都是默認配置, 但是也基本反映dubbo, sofa的RPC是改進空間的, 在阿里內部應該屬於上一代的架構了。
而讓人意外的是出自華為之手的servicecomb(配置hightway私有串行化協議), 穩在第一階梯。
2.Dubbo為什麼會慢?
dubbo客戶端調用需要傳遞過多信息給服務提供方,帶類名的methodName加上參數類型,參數值等,和http+json的方式比起來沒好多少。
public class RpcInvocation implements Invocation, Serializable {
private static final long serialVersionUID = -4355285085441097045L; private String methodName;
private Class>[] parameterTypes;
private Object[] arguments;
private Map<string> attachments; /<string>
private transient Invoker> invoker;
}
還有一些點可能就是反串行化,入參拷貝損耗, 反射調用服務等細節問題, turbo-rpc的作者也提到這些改進點,如果有時間,筆者後面再跟進源碼解讀。
3.為什麼使用servicecomb?
servicecomb實際不單單是一個RPC框架, 它定位為全棧式的微服務解決方案。dubbo其實只是一個RPC框架, 和servicecomb對等的應該是spring cloud, sofastack和spring cloud for alibaba。
如果從穩定,性能來說,servicecomb應該是首選, 分佈式事務saga和tcc都支持而且都經過華為實際場景驗證過的, etcd based service center, circuit breaker, edge service基本想要都優化了一套,pom.xml引入對應的handler,micorservice.yaml配置下基本就能用了,蠻傻瓜。sofastack其實也蠻穩,不過開源出來的算是HSF Lite版本,dubbo或spring cloud for alibaba還是尚待穩定和優化。
尚且不說阿里開源這些是不是KPI項目, 但後勁還是很足的, 例如新的註冊和配置中心Nacos, dubbo3.x持續改進, Seata分佈式事務框架等。
servicecomb蠻好, 但推廣得確實比較差, 剛出來的時候還有個汙點, 它的go版本涉及抄襲go micro, 具體見 https://mp.weixin.qq.com/s?__biz=MjM5MzM3NjM4MA==&mid=2654688638&idx=1&sn=ac267eeabd5e5992f203bde4b5b06dbf&chksm=bd58046d8a2f8d7b86dcd26a798ef80a290ee66bba7b8eb24b794b9c894a30fa1ba431c984f2&mpshare=1&scene=23&srcid=0209MWU5zk5rmTwJGgjpNXyr#rd
老外比較在意那些公司資助的開源, 借鑑也好參考也罷, 遵守遊戲規則就好。
不過每個公司選擇服務化框架也有自己的考慮,有點規模的公司有時不想依賴阿里的技術棧,可能有時就直接用中立些的spring cloud,或者自造適合自己體系的框架或組件。利益相關不大的金融公司為了穩定甚至購買阿里穩定些的商用版sofastack, 畢竟螞蟻金服實踐過。開源有時也是一個造勢和影響力了。
4. 有沒更猛的框架?
有的, https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=db 這個評測網算是權威, rust寫的actix網絡框架常年刷榜, rust真會有一席之地。
閱讀更多 耕雲不盡釣月無痕 的文章
