整个迭代过程会围绕着两个核心思想进行:
微服务框架系列重点介绍框架的搭建过程,期间对一些细节技术点的讲解,会在另一个系列Go语言技巧系列中展开。
项目链接
gRPC-gateway官方Github
有很多朋友更喜欢使用Gin框架,但我依然选择了gRPC-gateway。 主要在于gRPC-gateway方案对接Google提供的各种开源插件生态都很棒。大家会在后面框架的迭代过程中慢慢体会到它的特性。 后续我也会对Gin做一些分析。
完成RPC服务的框架的搭建
protobuffer
定义IDL(Interface Definition Language 接口定义语言)buf
工具生成Go
代码(包括数据结构和RPC相关服务)Go
项目实现RPC服务(实现RPC接口)--- micro_web_service 项目目录
|-- gen 从idl文件夹中生成的文件,不可手动修改
|-- idl 对应idl文件夹
|-- demo 对应idl/demo服务
|-- demo.pb.go demo.proto的基础结构
|-- demo.pb.gw.go demo.proto的HTTP接口,对应gRPC-Gateway
|-- demo_grpc.pb.go demo.proto的gRPC接口代码
|-- idl 原始的idl定义
|-- demo 业务package定义
|-- demo.proto protobuffer的原始定义
|-- internal 项目的内部代码,不对外暴露
|-- server 服务器的实现
|-- demo.go server中对demo这个服务的接口实现
|-- server.go server的定义,须实现对应服务的方法
|-- buf.gen.yaml buf生成代码的定义
|-- buf.yaml buf工具安装所需的工具
|-- gen.sh buf生成的shell脚本
|-- go.mod Go Module文件
|-- main.go 项目启动的main函数
我们先看一下项目中的demo.proto
文件,重点关注 rpc Echo(DemoRequest) returns (DemoResponse) 这个定义。
message DemoRequest {
string value = 1;
}
message DemoResponse {
int32 code = 1;
}
// 样例服务
service DemoService {
// Echo 样例接口
rpc Echo(DemoRequest) returns (DemoResponse) {
option (google.api.http) = {
post : "/apis/demo"
body : "*"
};
}
}
今天我们暂时不对protobuffer
的语法做扩展讲解,只需要简单地了解下它的请求结构体DemoRequest
和响应结构体DemoResponse
。
我们通过运行项目根目录中的gen.sh
,会在gen
目录下生成对应的Go语言代码。
这部分是自动化的工作,每次修改proto
文件后需要运行。
buf工具的安装请参考README.md,它是protoc的演进版本,不再需要大量flag参数,更加简单易用。 注意,如果修改了模块名,buf工具第一次初始化建议使用 buf beta mod init 指令
我们梳理一下整个逻辑,来看看这个Go
程序是怎么提供RPC服务的。
buf.gen.yaml
中定义了生成的2种服务, go-grpc
和 grpc-gateway
,分别表示gRPC
和HTTP
demo.proto
通过脚本,在gen/idl/demo
生成了2个文件,*_grpc.pb.go
和*.pb.gw.go
,分别表示gRPC
和HTTP
main
函数中注册两个服务,分别为:demo.RegisterDemoServiceServer(s, &server.Server{})
demo.RegisterDemoServiceHandlerFromEndpoint(ctx, mux, *grpcServerEndpoint, opts)
internal/server/server.go
中,server.Server
需要实现proto
中定义的方法,所以我们加入接口定义demo.UnsafeDemoServiceServer
internal/server/demo.go
中,实现一个func (s *Server) Echo(ctx context.Context, req *demo.DemoRequest) (*demo.DemoResponse, error)
方法我们用简单的命令来运行,并用RPC访问
# 编译并运行
go build && ./micro_web_service
# 模拟HTTP请求
curl --location --request POST 'http://127.0.0.1:8081/apis/demo'
# 收到返回值 {"code":0}
# 而gRPC比较麻烦,是私有协议,我们查看一下对应的网络端口,发现正在监听,也就意味着正常运行
netstat -an | grep 9090
tcp4 0 0 127.0.0.1.9090 127.0.0.1.49266 ESTABLISHED
tcp4 0 0 127.0.0.1.49266 127.0.0.1.9090 ESTABLISHED
tcp46 0 0 *.9090 *.* LISTEN
由于本项目只是一个框架,如果你希望修改为个人的项目,主要改动点在两处:
go.mod
里的模块名,以及Go
代码内部的importproto
文件中定义的go_package
建议用编辑工具全量替换
message EmptyMessage {
}
// Empty 空接口
rpc Empty(EmptyMessage) returns (EmptyMessage) {
option (google.api.http) = {
post : "/apis/empty"
body : "*"
};
}
bash gen.sh
这时候,我们会发现main.go
中有报错,即提示server.Server
这个对象需要实现Empty
方法。于是,我们在internal/server/demo.go
里添加
func (s *Server) Empty(ctx context.Context, req *demo.EmptyMessage) (*demo.EmptyMessage, error) {
return &demo.EmptyMessage{}, nil
}
# 编译并运行
go build && ./micro_web_service
# 模拟HTTP请求
curl --location --request POST 'http://127.0.0.1:8081/apis/empty'
# 返回 {}
v0.1.0
版本是一个非常简单的web框架,只有样例的RPC接口。
开放HTTP
接口是为了兼容传统方案,而gRPC
则提供了高性能、跨语言的通信方案。从整个实现过程来看,我们只编写了一个具体的实现、也就是Echo
这个方法,就完成了两种通信方式的兼容。
gRPC-Gateway
方案还有很多很棒的特性,我会在后续逐一介绍并引入。
Github: https://github.com/Junedayday/code_reading Blog: http://junes.tech/ Bilibili: https://space.bilibili.com/293775192 公众号: golangcoding