大家好，我是六月天天。如题所述，从今天开始，我将和大家一起逐步完成一个微服务框架。
整个迭代过程会围绕着两个核心思想进行：
- 关注技术选型背后的思想。虽然最终某个技术选型的可能并不是你喜欢的方案（如RPC、日志、数据库等，你可以fork后自行调整），但我们更关注各个技术组件背后的原理与思想，选择的过程比结果更重要；
- 聚焦于简单，关注可维护性。技术框架是项目的基础设施，也是排查复杂业务问题的根本，所以框架层的功能会尽量考虑简单易用，可以让我们花更多的心思在业务开发中。许多开源库提供了大量扩展功能，但我们使用时会尽量克制，减少学习和排查问题时的成本。
微服务框架系列重点介绍框架的搭建过程，期间对一些细节技术点的讲解，会在另一个系列Go语言技巧系列中展开。
v0.1.0：搭建gRPC+HTTP的双重网关服务
项目链接 https://github.com/Junedayday/micro_web_service/tree/v0.1.0
gRPC-gateway官方Github https://github.com/grpc-ecosystem/grpc-gateway
有很多朋友更喜欢使用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函数
1. protobuffer定义IDL
我们先看一下项目中的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。
2. buf工具生成Go代码
我们通过运行项目根目录中的gen.sh，会在gen目录下生成对应的Go语言代码。
这部分是自动化的工作，每次修改proto文件后需要运行。
buf工具的安装请参考README.md，它是protoc的演进版本，不再需要大量flag参数，更加简单易用。
注意，如果修改了模块名，buf工具第一次初始化建议使用 buf beta mod init 指令
3.Go项目实现RPC服务
我们梳理一下整个逻辑，来看看这个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函数中注册两个服务，分别为：- gRPC -
demo.RegisterDemoServiceServer(s, &server.Server{}) - HTTP -
demo.RegisterDemoServiceHandlerFromEndpoint(ctx, mux, *grpcServerEndpoint, opts)
- gRPC -
- 在
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
建议用编辑工具全量替换
新增接口示例
添加proto定义
message EmptyMessage {
}
// Empty 空接口
rpc Empty(EmptyMessage) returns (EmptyMessage) {
option (google.api.http) = {
post : "/apis/empty"
body : "*"
};
}
生成Go文件
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方案还有很多很棒的特性，我会在后续逐一介绍并引入。
