为什么说要搞定微服务架构，先搞定RPC框架？

今天开始聊一些微服务的实践，第一块，RPC框架的原理及实践，为什么说要搞定微服务架构，先搞定RPC框架呢？

一、需求缘起

服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现大公司跨团队的技术解耦，如下图：

服务A是欧洲团队提供服务，欧洲团队的技术背景是Java，可以用Java实现服务；

服务B是美洲团队提供服务，可以用C++实现服务；

服务C是中国团队提供服务，可以用Go实现服务；

服务的上游调用方，按照接口、协议即可完成对远端服务的调用。

但实际上，99.9%的公司的团队规模有限，技术团队人数也有限，基本是使用同一套技术体系来调用和提供服务的：

这样的话，如果没有统一的服务框架，RPC框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的