***Chapter[《为什么要服务化以及Servitization解决什么问题》]第二章[《微服务服务粒度选择》]今天讲一些微服务的实践，第一块，RPC框架的原理和实践，为什么说先搞定微服务架构，先搞定RPC框架呢？1、基于服务的需求发起的好处之一就是不限制服务商使用的技术选型，可以实现大公司跨团队的技术解耦，如下图：服务A由欧洲团队提供，技术背景为Java，可以用Java实现服务；服务B由美国团队提供，服务可以用C++实现；服务C是中国团队提供的服务，可以用Go实现；服务的上游调用者可以根据接口和协议完成对远程服务的调用。但实际上，99.9%的公司团队规模有限，技术团队数量有限，基本都是使用同一个技术体系来调用和提供服务：这种情况下，如果没有统一的服务框架，RPC框架，每个团队的服务提供者都需要实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务外”的重复性技术劳动，导致整体效率低下。因此，将上述“业务外”技术劳动统一起来的统一RPC框架是服务中首先要解决的问题。在达成“使用统一的RPC框架才是正路”的共识的前提下，本文希望用通俗易懂的语言简要描述一个通用的RPC框架的技术要点和实现。2.RPC背景及流程什么是RPC（RemoteProcedureCallProtocol），远程过程调用？我们先来看看什么是局部函数调用。当我们写：intresult=Add(1,2);这段代码的时候，我们知道传入了1和2两个入参，在本地代码段调用了一个Add函数，得到了结果输出参数。此时传入数据、传出数据和代码段在同一个进程空间，是一个本地函数调用。有什么方法可以让我们跨进程调用一个函数（所以叫“远程”，一般情况下，这个进程部署在另一台服务器上）？最容易想到的是两个进程约定一个协议格式，使用Socket通信，传递[输入参数][调用哪个函数][传出参数]。假设请求消息协议是一个11字节的字节流：(1)前3个字节填写函数名(2)中间4个字节填写最后一个参数(3)最后4个字节填写在第二个参数中将响应消息协议设计为一个4字节的字节流：处理结果。调用者的代码可能变成：request=MakePacket(“add”,1,2);SendRequest_ToService_B(request);response=R??ecieveRespnse_FromService_B();intresult=unMakePacket(respnse);简要说明：（1）讲传入参数变成字节流（2）把字节流发送给服务B（3）从服务B接收返回字节流（4）把返回字节流变成传出参数代码服务器的请求可能变为：request=RecieveRequest();args/function=unMakePacket(request);result=Add(1,2);response=MakePacket(result);SendResponse(response);这个过程也很好理解：（1）服务端收到字节流（2）将字节流转换成函数名和参数（3）在本地调用函数得到结果（4）将结果转换成字节流（5)发送字节流给调用者这个过程用一张图描述如上，调用者和服务端的处理步骤很清楚。这个过程中最大的问题是什么？答：调用者太麻烦了，每次都要关注很多底层细节（1）输入参数到字节流的转换，即应用层协议细节的序列化（2）socket发送，即即网络传输协议的细节（3）socket接受（4）字节流到输出参数的转换，即反序列化应用层协议的细节。调用层能不注意这个细节吗？答：是的，RPC框架就是针对这个问题的解决方案，它允许调用者“像调用本地函数一样调用远程函数（服务）”。3.RPC框架的职责通过上面的讨论，RPC框架应该为调用者屏蔽各种复杂性，同时也为服务提供者屏蔽各种复杂性：（1）调用者感觉像是在调用本地函数（2）服务的provider感觉就像实现了一个本地函数来实现服务，所以整个RPC框架分为client部分和server部分，负责屏蔽整个非(1)(2)的复杂性。这些复杂性就是RPC框架。责任。更详细一点，客户端还包括：序列化、反序列化、连接池管理、负载均衡、故障转移、队列管理、超时管理、异步管理等等。服务器端包括：服务器端组件、服务器端收发包队列、io线程、工作线程、序列化与反序列化、上下文管理器、超时管理、异步回调等。但限于篇幅，这些细节就不展开深入了。4.结论(1)RPC框架是架构微服务的首要基础组件，可以大大降低架构微服务的成本，提高调用方和服务提供方的研发效率，屏蔽所有功能（服务）跨进程调用。类复杂细节（2）RPC框架的职责是：让调用者感觉像调用本地函数一样调用远程函数，让服务提供者感觉像实现本地函数一样实现服务TheArchitect'sWay”
