golang|grpc 最佳实践 - Golang教程网

grpc 最常见的使用场景是：微服务框架下。多种语言只见的交互，将手机服务、浏览器连接至后台。产生高校的客户端库。（维基百科）
低延迟，高可用，分布式系统；移动客户端和云端通讯；跨语言协议；独立组件方便扩展，例如认证，负载均衡，和监控（来自grpc官方文档，最后一项翻译可能不准确）。
grpc的创建是非常简单的：
1. proto文件

math.protoService Math {
 rpc Div (Request) returns (Response)()
}message Request {
 int64 divedend =1 ;

 int64 divisor =2;

}message Response {
 int64 quotient =1 ;

 int64 remainder =2;

}

2.生成服务端代码

math.gotype server struct{}func (s *server) Div (ctx context.Context, in *pb.Request)
(*pb.Response,error) {n,d := in.Dividened, in.Divisor
if d == 0 {
return nil , status. Errof(codes.InvalidArgumnet, "division by 0")
}
return &pb.Response{
Quotient: int64(n / d)
Reainder: int64(n % d)
},nil
}func main() {
lis, _ := net.Listen("tcp",port)
s:= grpc.NewServer()
pb.RegisterMathServer(s,&server())
s.Serve(lis) 
}

服务的创建是非常容易的但是，真正需要在生产环境中用好还是非常有挑战的：

可靠性
安全性
性能
错误处理
监控
负载均衡
日志
QOS
...

API 设计之幂等
需要实现接口的可重入。
例如转钱：
不好的设计：

message Request {
 string from =1;

 string to= 2;

 float amount = 3;

}message Response {
 int64 confirmations= 1;

}

好的设计：

message Request {
 string from =1;

 string to= 2;

 float amount = 3;

 int64 timestamp =4 ;

}message Response {
 //每次相同的请求的到相同的结果
 int64 confirmations= 1;

}

API设计之性能
重复的地方：
Requests: 有可能有无限多的请求，需要设置限制；
Response: 需要支持分页；
避免耗时较的操作：
时间越长，重试概率越大；
在后台处理，异步发送执行结果。（callback , email , pubsub, etc）, 或者tracking token。
API设计之默认值
定义更加敏感的默认信息。
尽量将未知的，未定义的作为默认值
向后兼容
API设计之错误处理
错误：
是grpc独立的一个类别，不要把错误信息放在响应内容中。否则判断是否成功的逻辑会非常复杂。因为需要读出响应内容进行判断。不如一开始就将错误统一定义好。
避免批量运行独立的操作：
例如：一次性更新多个表。
错误处理非常复杂。
如果确实需要，使用stream 或者multiple call。
错误处理之 - DON'T PANIC
尽最大努力优雅的处理错误
panic只适合机器内部故障：内存泄露，内存用完，imminetn data corruption
除了上述error, 剩下都返回i给调用者。
当心空指针。使用proto的getter方式是nil安全的。
错误处理之-合理转换
别直接把其他服务的错误返回。这样不利于调试

res , err := client.Call(...)
if err!= nil {
s,ok := status.FromError(err)
if !ok {
return status.Errorf(codes.Internal, "client.Call:unkown error:%v",err)
}
switch s.Code() {
case code.InvalidArgument:
return ....
}
}

DeadLines
客户端：
一般需要设置，这样客户端才能知道什么时候放弃操作。一定要使用DEADLINE
使用带有deadline的ctx
res , err := client.Call( ctx, req)
服务端：
也比较关注DEADLINE
超市时间太短：不够执行对应操作，过早失败；
超时时间太长：消耗用户的其他资源。

func (s *Server) MyRequestHandler(ctx contes.Contex, ...) (*Res,error) {
d,ok := ctx.Deadline()
if ！ok {
return staus.Error {...}
}
timeout := d.Sub(time.Now())
if timeout < 5*time.Second || timeout > 30*time.Secone {
return status.Error (...)
}
 
}

如果可以的话，尽量为不同请求创建各自的ctx 和 ctx的超时时间。
限流
服务端“

import "golang.org/x/time/rate"...
s := grpc.NewServer (grpc.InTapHadle(rateLimiter))
...func rateLimiter (ctx context.Context, info *tap.Info) (contex.Context, error) {
if m[user] == nil { // 
m[user] = rate.newLimiter(5,1)
}
if !m[user].Allow() {
return nil, status.Eoorof(codes....)
}
return ctx, nil
}

好的客户端也需要限流

import "golang.org/x/time/rate"...
s := grpc.NewServer (grpc.InTapHadle(rateLimiter))
...func Myhandler (ctx contex.Context , req Request) (Response,err) {
if err := limiter.Wait(ctx);
 err != nil {
return nil , err
}
return c.Call(ctx, req)
}

重试
官方特性说明： gRRFC A6
. 可以通过服务端的配置
支持：按失败顺序重试或者并发重试。
同样需要考虑ctx中过期时间的问题。
通用的框架

func (c *client) ChildRpc (ctx contex.Context , name string , f func(contes.Contex) error){
for attempts := 1;
 attempts <= c.maxAttempts;
 attempts++ {
if err := c.limiter.Wait(ctx);
 err != nil {
return c.limiterErr(...)
}
if err := f(ctx);
 err == nil {
return nil
} else if !c.retry (err) {
return c.convertErr (name , err, attensm)
}
}
return c.TomanyRetry
})var res Responseerr := c.ChildRpc (ctx , "SendMony", func(ctx context.Contex)(err error){
res , err := sendMondClient.SendMoney(ctx, req)
return
})

内存管理
方法一：

import "golang.org/x/net/netutil"listener := netutil.LimitListener(listener, connectionLimit)grpc.NewServer(grpc.MaxConcurrentStream(streamsLimit))

方法二：
user Tap Handler, 当过多的rpc连接或者内存比较低。
方法三：
health 报告机制
限制服务的请求数据大小：
grpc.NewServer(grpc.MaxRecvMsgSize(4096 /* bytes*/))
小的请求可能有大的数据响应：
eg : database query
api design issue:
使用 streaming response
按照数据最大限制进行分页。
日志
多打印吧，方便调试，以及监控发出警告
监控
【golang|grpc 最佳实践】。。。