go-zero（rpc服务）

syntax = "proto3";

package user;


option go_package="./user";

message UserInfoRequest{
  uint32 user_id=1;
}

message UserInfoResponse{
  uint32 user_int=1;
  string username=2;
}


message UserCreateRequest{
  string username=1;
  string password=2;
}

message UserCreateResponse{
  string err=1;
}

service user{
  rpc UserInfo(UserInfoRequest) returns(UserInfoResponse);
  rpc UserCreate(UserCreateRequest)returns(UserCreateResponse);
}

//goctl rpc protoc user.proto --go_out=./types --go-grpc_out=./types --zrpc_out=.

首先是proto文件，用于快速生成一个简单规范的rpc服务

syntax="proto3"：声明语法版本固定值

package user：指定当前proto文件所属的包名

option：指定生成后的golang代码所属的包

message：定义请求体（和api中的type类似，语法有些不一样）

service：定义一个服务，其中rpc UserInfo(UserInfoRequest) returns (UserInfoResponse)表示定义一个rpc服务，接受一个UserInfoRequest请求，响应为UserinfoResponse

根据proto生成go代码

goctl rpc protoc user.proto --go_out=./types --go-grpc_out=./types --zrpc_out=.

go_out：指定go语言生成目录

go-grpc_out：指定grpc服务所在目录

添加-m可以转换为多个服务

根据上面的代码就会生成这样的一个目录结构：

其中etc文件和internal文件和根据api生成的文件作用和结构几乎都是差不多的

rpc和gorm框架的结合使用总体上是差不多的，都是在config里面导入gorm.DB获取到mysql的链接然后再去logic进行具体的业务逻辑操作

rpc和api之间代码上的交互逻辑：

首先是rpc，rpc配置文件里面多了一项etcd，etcd目前我理解为类似于redis用于记录某etcd服务所存在的端口的，业务处理在rpc端

api端主要是起一个接口的作用，根据配置文件，获取到对应的rpc链接，然后再转发请求到rpc服务，最终rpc端处理并相应