CE这就存在一个问题，我们是怎么把.Net 应用平滑地切换到 Java 上呢？原本是.Net 应用之间的互相调用，需要改成.Net 跟 Java 之间互相通信。为了解决这个问题，我们当时选择了一个比较古老的 RPC 框架 ICE（https://zeroc.com），可能现在很多人都没有听说过了。Hessian后面使用 Java 开发应用的机会越来越多，而且随着 Spring 开发方式的大流行，在 Java 应用里面使用 ICE 来完成应用之间的 RPC 调用就变得比较鸡肋了。所以当时我们用了一种新的 RPC 框架 Hessian（http://hessian.caucho.com/），这时我们就把 Java 应用之间的 RPC 调用方式改成了 Hessian 方式。用 Hessian 的原因就是因为它可以很好地跟 Spring 进行集成，对 Spring 项目的开发人员来说，开发一个 RPC 接口就变得很容易了，我们可以直接把 Java 类对外进行暴露，用作 RPC 接口的定义，而不需要像 ICE 一样先定义 Stub。单纯的从 RPC 框架角度出发，Hessian 是一款很优秀的产品，即使放到今天，它的性能和鲁棒性都有着很强的参考意义。但当业务发展壮大到一定程度后，应用之间的调用就不仅仅需要考虑用什么 RPC 框架了，更多的是需要考虑怎么去完成服务治理。另外一个原因就是因为 Hessian 是没有服务发现功能的，我们只能通过 VIP 暴露的方式完成调用，我们需要给每个应用分配一个 VIP，把同一接口的所有服务提供方实例挂载到同一个 VIP 上。这种集中式流量转发架构就会使得提供 VIP 服务的 LVS 存在很大的压力，而且集中式流量的转发会让调用方响应时间相对变长。Dubbo为了解决类似 Hessian 这种集中式问题，实现大规模应用服务化的落地，国内的 RPC 框架 Dubbo 的做法就显得比较先进了。随着业务越来越复杂，应用之间的调用关系也就变得更加错综复杂，所以后面我们也是选择基于 Dubbo 进行扩展，以完成 RPC 通信，而服务发现则通过接入 Zookeeper 集群来完成。通过这种现有框架的搭配，我们完成了应用服务化的快速落地，也同时完成了统一公司内部所有应用 RPC 框架的目标。但随着微服务理念越来越流行，很多应用的接口也是越拆越细，导致我们 Zookeeper 集群需要接入的接口数量越来越多；还有就是因为我们每年的业务量是成倍增长，为了让应用能够抗足够的调用量应用，我们也需要经常扩容，从而导致 Zookeeper 集群接入的 IP 实例数也是呈数量级增长的，这使得我们的 Zookeeper 集群负荷特别重。再有就是 Dubbo 相对有点复杂，而且性能还有提高空间，这使得我们不得不考虑新的方案。自研 RPC在这种背景下，我们决定自行研发一套适合自己业务场景的微服务解决方案，包括 RPC 框架、服务治理以及多语言解决方案。至此我们自研的 RPC 就一直平稳地支持着公司内的各种业务。这几年，在以 K8S 为代表的基础设施演进过程中，一个重要的关键词就是应用基础设施能力的下沉。在过去我们给应用提供 RPC 能力的时候，都是需要应用引入 Jar 包方式来解决的，在 RPC 里面，我们要把服务发现、路由等一整套 RPC 解决方案都融入到这个 Jar 里面去。未来目前，K8S 已成为基础设施的事实标准。而原先通过 Jar 包的方式封装的各种基础设施能力，现在全都被 K8S 项目从应用层拽到了基础设施中。那对于我们 RPC 来说也是一样，我们需要把非业务功能从传统的 RPC 框架中剥离出来，下沉到基础设施并且融入基础设施，然后通过 Mesh 去连接应用和基础设施。这也是 RPC 发展的下一个阶段，完成所有应用的 Mesh 化。所以说，RPC 这条路没有尽头，只有不断的挑战和乐趣。希望你也能爱上它！那最后我还想和你谈谈我对 RPC 的看法。可能大家在谈论 RPC 时候，都想着 RPC 只是解决应用之间调用的工具。从本质上来讲，这没有什么问题，但在现实中，我们需要 RPC 解决更多的实际问题，比如服务治理，这些东西都是在使用 RPC 的过程中需要考虑的问题，所以我个人认为 RPC 应该是一个比较泛的概念。当然，可能我们中大多数人现在是没有机会去完整实现一个新的 RPC 的，这不仅是精力的问题，更多是实际需求的问题，那为什么我们还需要学好 RPC 呢？我的想法很简单也非常实在，就是因为 RPC 是我们构建分布式系统的基石，就好比我们每次都是从 Hello World 开始学习一门新的编程语言。期待你能打牢这个基础，总有一天你会体验到它的能量！
