RPC选型思考

一、背景

市面上开源RPC框架非常多，有技术实力的公司大部分都是采用自研，还有部分公司受历史项目影响，一直都是老旧的框架

常见RPC框架：

1. RMI(淘汰)

2. Restful + http(1.1~3) + tls

3. gRPC

4. motan

5. tars

6. thrift

7. SOFA-RPC

8. Dubbo(1~3)

9. Hessian

   ...

接着上文，因为技术在不断迭代，佬框架如果没有维护，那么就会慢慢被历史淘汰（没错，说的就是Dubbo），新框架崛起，那对于企业来说切换成本的考虑，技术风险都是非常重要的，现在k8s是事实上的容器编排标准，作为谷歌的亲儿子gRPC越来越到欢迎，只要是跟k8s关联，都要主动接入gRPC，基于DNS的注册发现都是RPC框架需要考虑的。

大企业的技术迭代也不是一步到位，要在不断迭代，演进式发展，毕竟初创企业能付出的成本是非常小。

二、选型

技术选型考虑点：

1. 初期团队技术实力弱，开发周期短，RPC必须足够简单
2. 后期切换RPC要足够简单，改动代码要少
3. RPC的性能要承载业务未来发展
4. 未来技术要能兼容

路线：restful + http -> dubbo

对于IDL的定义，个人对于gRPC的proto定义和代码生成机制比较反感，我选择Java IDL的方式定义接口，项目初期使用feign定义接口，后期通过替换feign的target实现类来完成RPC升级，dubbo3虽然在Triple性能未来性能会越来越好，但是还是弱于tcp类的RPC，协议层就决定了

Dubbo基准测试

Dubbo官网