一文get转转RPC框架开发实践经验
发布时间：2022-03-26 21:48:55 所属栏目：业界 来源：互联网
导读：随着公司规模的扩大以及业务量与用户量的激增，为了满足系统高可用、高并发的要求，单体应用逐步演化为服务 / 微服务的架构模式。此时，我们急需一种高效的应用程序之间的通讯手段来满足这种需求，因此 RPC 得以大显身手。 RPC 即远程过程调用协议（Remote P
|
随着公司规模的扩大以及业务量与用户量的激增，为了满足系统高可用、高并发的要求，单体应用逐步演化为服务 / 微服务的架构模式。此时，我们急需一种高效的应用程序之间的通讯手段来满足这种需求，因此 RPC 得以大显身手。 RPC 即远程过程调用协议（Remote Procedure Call Protocol），可以让我们像调用本地对象一样发起远程调用。RPC 凭借其强大的治理功能，成为解决分布式系统通信问题的一大利器。 然而，怎样选择一个合适的 RPC 框架依然是个令人困扰的问题。虽然社区里已经有很多开源的 RPC 项目，它们简单易用，但从框架特性、性能、成熟度、技术支持、社区活跃度等等方面综合考虑，适合自己的却很少。而开发一个完整的 RPC 框架，对于大部分中小团队来说，人力成本和时间成本都是无法接受的。 InfoQ：既然有了 HTTP，为什么还需要 RPC 框架呢？ 王建新：仅从通信的角度来讲，直接使用 HttpClient 和 RPC 框架是没有什么区别的，而且有的 RPC 框架底层还支持使用 HTTP 协议进行通信，比如 Spring Cloud Feign 和 Dubbo。RPC 框架的侧重点在于，它不仅仅是为了通信，还是为了更简单、更易用地通信。RPC 框架通过动态代理技术，实现了调用远程方法和调用本地方法同样的体验，不需要手动构造请求体，也不需要考虑参数和返回值的序列化，这一切都被 RPC 框架进行了很好地封装。 许多 RPC 框架都设计了私有的通信协议，和 HTTP 协议相比更加紧凑，传输数据量更小，请求耗时更短。在某些复杂链路中可能会有几千次的 RPC 请求，高性能的 RPC 框架对效率的提升是很可观的。而且私有的 RPC 协议往往支持连接的多路复用，减少连接数量，节省系统资源。 RPC 框架内部往往也集成了更多的高级功能，比如 Router、Filter、LoadBalance 等，并且允许用户自由扩展，以实现更加高级的功能。更完善一些的系统还包括监控、分布式调用跟踪、统一服务治理平台等。可以说 RPC 框架并不是仅仅为了满足通信的需求，更是可以提供一个体系支撑。 InfoQ：在 RPC 框架重构过程中你面临的最大困难是什么？是通过怎样的努力解决的？有哪些沉淀和启发？ 王建新：RPC 框架重构面临的最大困难就是兼容问题。我们要保证 RPC 框架的新增功能尽量不破坏现有的 API，如果确实无法避免不兼容的情况出现，也要尽量减少对业务的影响，减少 RD 的修改成本。 对于已知的不兼容情况，在发版之前，我们会对全公司的代码仓库进行扫描，提前通知服务负责人，并给出解决方案。对于无法提前预料的不兼容情况，我们先对服务进行等级划分，从重要到不重要分为 A、B、C、D、E、F 六个等级。每个等级的 POM 文件使用不同版本的 parent，在 parent 中规定了 RPC 框架的版本号。工程效率部门在进行项目编译时，禁止直接在项目中指定 RPC 框架的版本号。 这种技术方案可以实现 RPC 框架的无感知升级，每次进行 RPC 框架发版都从不重要的服务开始进行灰度发布，逐渐过渡到重要的服务。如果有不兼容的情况或者出现 bug，也能在低等级的服务上提前发现，减少损失。 RPC 框架作为公司的基础设施，可谓牵一发而动全身。在转转 RPC 框架升级过程中，我们也曾遇到过线上事故。事后我们进行了深入思考、复盘，制定了一系列的流程规范（包括上述的服务等级划分）以及出现事故后的快速响应机制，来避免下一次事故的发生，并能够做到及时止损。  （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
