RPC协议设计

底层通信选型

设计一个微服务框架的起始点，是确定底层通信的方式。因为上层的服务治理，都是建立在这个基础之上。

可行的选择是：

• 直接使用 gRPC直接
• 使用 HTTP
• 设计自己的 RPC 协议：实践中建议直接使用 gRPC 或者 HTTP
• 

RPC要解决的核心问题

RPC的全称是Remote Procedure Call，即远程过程调用。核心就是：如同本地调用一般调用服务器上的方法。

调用信息

要完成这种映射，首先要解决第一个问题：映射什么？

举个例子，假如说我们在客户端调用的是userService.GetByld，传入的参数是 int 类型的值 123。那么服务端究竟怎么知道客户端调用的是userService.GetByld，参数是 int 类型的 123?

那么调用信息需要包含什么?
服务名:也就是userService
方法名：GetByld
参数值：123
要不要参数类型？如果你在支持重载的语言上设计微服务框架，并且决定支持重载，那么你就需要传递参数类型，否则你不需要传递参数类型。

重载是什么？同名方法，有不同参数

RPC协议 不需要传参数类型，如果硬要传就可以实现重载的功能。

服务名是什么？
以前Dubbo 接口名注册 gRPC 应用名注册

客户端捕捉本地调用

既然要传递调用信息,那么问题就在于:RPC 客户端怎么获得这些调用信息？这个问题是指:用户调用的是userService.GetByld(123)，我底层框架怎么知道 userService, GetByld, 123这种信息？

做法1: 代码生成策略，如gRPC、go-micro

代码生成策略，代码写死的

做法2: 代理机制，如Dubbo

Go不支持动态代理，不支持动态生成新的类型，不支持动态加载。

代理模式

这里就要用到代理模式了：
定义一个结构体，为结构体里面的方法类型字段，注入调用逻辑。

要记住，Go 是没有办法修改方法实现的，所以我们只能迂回救国

我们约定：

• 方法参数的第一个必须是 context.Context，
  第二个就是请求结构体指针，
  并且只有这两个参数；

• 方法返回值的第一个是响应，并且必须是指针，
  第二个是 error，
  并且只有这两个返回值。

这种限制主要就是为了简化微服务框架的代码，在真实生产里面，你可以保持这个限制，也可以考虑去掉。