吐槽公司自研RPC框架

2019年7月底入职了新的公司，是一家创业公司，在架构组负责一些架构方面的工作。公司人员流动略大，公司自研的RPC框架是前人留下的坑，开发团队已全部跑路，因为最近也是第一次接触，写一下自己的吐槽与思考

吐槽点

微服务框架为什么要自研

我觉得没理由，目前开源成熟的服务框架非常多，具有代表性的：

• spring-cloud体系：强大且易用
• dubbo(可接入spring-cloud)：阿里多年前开源的SOA框架，被很多大公司所用，已是apache顶级项目
• servicecomb：华为的开源项目，已是apache顶级项目

成熟的开源产品完全能满足一般创业公司的使用，因此，对于现公司，我觉得完全没有理由自研一套

自研却缺少文档

自研也就算了，没有任何使用说明文档，入门时一脸懵逼，加上开发团队全部跑路，只能向使用过的同学学习如何使用

自研的非常差

自研就自研，但是能不能做好一点呢？从该rpc报出的异常栈以及调用方式就能看出其实现非常粗糙丑陋，毫无优雅性可言

这里先说一说微服务框架的几个考虑点，自底向上分别是：

• 序列化/反序列化
• 服务端/客户端的抽象，用于处理接受请求与发送请求，封装request/response语义
• 通信协议，可选择基于tcp或者http，或者其它
• RPC协议，定义RPC过程中的数据传输方式，支持多种调用方式，比如同步调用，异步调用，不关心返回值以及是否成功的调用等
• 对集群的抽象，封装负载均衡与失败处理，负载均衡可使用roundover, hash等，失败处理可提供failover, failfast等方式，现在的服务框架的负载均衡都使用了软负载
• 服务主册与服务发现
• api/stub/与已有框架的结合等
• 服务治理

但该rpc完全没有考虑上述问题，或者说考虑的非常之少，该rpc的相关情况：

• 序列化/反序列化：json，半自动化，往往还需要人工做json反序列化
• 服务端/客户端的抽象：几乎没有，使用静态方法调用，也没有IO处理，依赖应用本身的tomcat，不是说这样不行，但是太粗糙
• 通信协议：基于http，依赖应用的tomcat以及8080端口，不是说不能使用http协议，使用http协议是没问题的，但是依赖应用的tomcat并不是一个好的方案，因为这样导致应用系统需要关心rpc框架的细节，比如想要写一个Servlet Filter对请求进行拦截，我们需要考虑该Filter会不会拦截到rpc请求
• 负载均衡与失败处理：无考虑，根据异常栈就能看出该rpc的服务注册与服务发现过于粗糙，它是通过域名做http调用，负载均衡依赖nginx，没有软负载，不支持失败处理
• 服务注册与服务发现：基于域名的而不是基于服务的，粒度太粗了，这就导致没法实现对服务的精细化管控，比如A/B测试，兼容性的平滑处理等
• api实现极其丑陋，没有stub或者远程代理这样的概念，rpc的调用是纯手动处理的json，调用方式如下：

String jsonResult = RemoteClientUtil.callRpc(”appName.serviceName“, JSON.toJsonString(params));
Result result = JSON.parseObject(jsonResult, Result.class);

• 完全没有服务治理能力，且没法接入spring-cloud体系，利用spring-cloud的相关能力

毫无扩展性

该自研的rpc框架非常不完善，并且很难与已有的开源项目结合，对于流程管控、服务治理的需求，该rpc框架难以满足
如果要重构，那基本上是重写，目前大量系统在使用，涉及到的系统改造非常大，基本上不现实

总结

对于这样的rpc框架，如果只论技术，它做的非常差，在rpc框架中，它就是demo级别的存在，不有参考价值。
当然，你可以说小公司不需要dubbo，不需要spring-cloud，但是我不这样认为，我认为我们当前对spring-cloud中的组件还是有需求的，但是该rpc没有考虑如何融入到成熟的微服务体系，抬高了我们使用这些成熟组件的门槛

虽然我没有自研过rpc框架，但见到该rpc框架后也要吸取教训，自研基础组件一定要考虑周全，尽量避免与应用共享资源，需要考虑扩展性

最后建议优先选择开源体系作为微服务架构的基础，如果有不满足公司特定需求的可基于开源组件改造