| 编辑推荐: |
| 本文来自于技术网站，本文的素材来源于我们在开发中的一些最佳实践案例，从开发、监控、日志这三个角度介绍了一些我们基于Go技术栈的微服务构建经验。 |
|
在大型系统的微服务化构建中，一个系统会被拆分成许多模块。这些模块负责不同的功能，组合成系统，最终可以提供丰富的功能。在这种构建形式中，开发者一般会聚焦于最大程度解耦模块的功能以减少模块间耦合带来的额外开发成本。同时，微服务面临着如何部署这些大量的服务系统、如何运维这些系统等新问题。
本文的素材来源于我们在开发中的一些最佳实践案例，从开发、监控、日志这三个角度介绍了一些我们基于Go技术栈的微服务构建经验。
开发
微服务的开发过程中，不同模块由不同的开发者负责，明确定义的接口有助于确定开发者的工作任务。最终的系统中，一个业务请求可能会涉及到多次接口调用，如何准确清晰的调用远端接口，这也是一大挑战。对于这些问题，我们使用了gRPC来负责协议的制订和调用。
传统的微服务通常基于http协议来进行模块间的调用，而在我们的微服务构建中，选用了Google推出的gRPC框架来进行调用。下面这张简表比较了http
rpc框架与gRPC的特性：
gRPC的接口需要使用Protobuf3定义，通过静态编译后才能成功调用。这一特性减少了由于接口改变带来的沟通成本。如果使用http
rpc，接口改变就需要先改接口文档，然后周知到调用者，如果调用者没有及时修改，很可能会到服务运行时才能发现错误。而gRPC的这种模式，接口变动引起的错误保证在编译时期就能消除。
在性能方面，gRPC相比传统的http rpc协议有非常大的改善（根据这个评测：https://dev.to/plutov/benchmarking-grpc-and-rest-in-go-565，gRPC要快10倍）。gRPC使用http
2协议进行传输，相比较http 1.1，http 2复用tcp连接，减少了每次请求建立tcp连接的开销。需要指出的是，如果单纯追求性能，之前业界一般会选用构建在tcp协议上的rpc协议（Thrift等），但四层协议无法方便的做一些传输控制。相比而言，gRPC可以在http
header中放入控制字段，配合nginx等代理服务器，可以很方便的实现转发/灰度等功能。
接下来着重谈谈我们在实践中如何使用gRPC的一些特性来简化相关开发流程。
1. 使用Context来控制请求的生命周期
在gRPC的go语言实现中，每个rpc请求的第一个参数都是context。
http2协议会将context放在HEADER中，随着链路传递下去，因此可以为每个请求设置过期时间，一旦遇到超时的情况，发起方就会结束等待，返回错误。
| ctx
:= context.Background() // blank context
ctx, cancel = context.WithTimeout(ctx, 5*time.Second)
defer cancel( )
grpc.CallServiveX(ctx, arg1) |
上述这段代码，发起方设置了大约5s的等待时间，只要远端的调用在5s内没有返回，发起方就会报错。
除了能加入超时时间，context还能加入其他内容，下文我们还会见到context的另一个妙用。
2. 使用TLS实现访问权限控制
gRPC集成了TLS证书功能，为我们提供了很完善的权限控制方案。在实践中，假设我们的系统中存在服务Ａ，由于它负责操作用户的敏感内容，因此需要保证Ａ不被系统内的其他服务滥用。
为了避免滥用，我们设计了一套自签名的二级证书系统，服务Ａ掌握了自签名的根证书，同时为每个调用Ａ的服务颁发一个二级证书。这样，所有调用Ａ的服务必须经过Ａ的授权，Ａ也可以鉴别每个请求的调用方，这样可以很方便的做一些记录日志、流量控制等操作。
3. 使用Trace在线追踪请求
gRPC内置了一套追踪请求的trace系统，既可以追踪最近 10个请求的详细日志信息，也可以记录所有请求的统计信息。
当我们为请求加入了trace日志后，trace系统会为我们记录下最近10个请求的日志,下图中所示的例子就是在Trace日志中加入了对业务数据的追踪。
在宏观上，trace系统为我们记录下请求的统计信息，比如请求数目、按照不同请求时间统计的分布等。
需要说明的是，这套系统暴露了一个http服务，我们可以通过debug开关在运行时按需打开或者关闭，以减少资源消耗。
监控
1. 确定监控指标
在接到为整个系统搭建监控系统这个任务时，我们面对的第一个问题是要监控什么内容。针对这个问题，Google
SRE这本书提供了很详细的回答，我们可以监控四大黄金指标，分别是延时、流量、错误和饱和度。
延时衡量了请求花费的时间。需要注意的是，考虑到长尾效应，使用平均延时作为延时方面的单一指标是远远不够的。相应的，我们需要延时的中位数90%、95%、99%值来帮助我们了解延时的分布，有一种更好的办法是使用直方图来统计延时分布。
流量衡量了服务面临的请求压力。针对每个API的流量统计能让我们知道系统的热点路径，帮助优化。
错误监控是指对错误的请求结果的统计。同样的，每个请求有不同的错误码，我们需要针对不同的错误码进行统计。配合上告警系统，这类监控能让我们尽早感知错误，进行干预。
饱和度主要指对系统CPU和内存的负载监控。这类监控能为我们的扩容决策提供依据。
2. 监控选型
选择监控方案时，我们面临的选择主要有两个，一是公司自建的监控系统，二是使用开源Prometheus系统搭建。这两个系统的区别列在下表中。
考虑到我们的整个系统大约有100个容器分布在30台虚拟机上，Prometheus的单机存储对我们并不是瓶颈。我们不需要完整保留历史数据，自建系统的最大优势也不足以吸引我们使用。相反，由于希望能够统计四大黄金指标延生出的诸多指标，Prometheus方便的DSL能够很大程度上简化我们的指标设计。
最终，我们选择了Prometheus搭建监控系统。整个监控系统的框架如下图所示。
各服务将自己的地址注册到Consul中，Prometheus会自动从Consul中拉取需要监控的目标地址，然后从这些服务中拉取监控数据，存放到本地存储中。在Prometheus自带的Web
UI中可以快捷的使用PromQL查询语句获取统计信息，同时，还可以将查询语句输入Grafana，固定监控指标用于监控。
此外，配合插件AlertManager,我们能够编写告警规则，当系统出现异常时，将告警发送到手机／邮件／信箱。
日志
1. 日志格式
一个经常被忽略的问题是如何选择日志记录的格式。良好的日志格式有利于后续工具对日志内容的切割，便于日志存储的索引。我们使用logrus来打印日志到文件，logrus工具支持的日志格式包裹以空格分隔的单行文本格式、json格式等等。
文本格式
| time="2015-03-26T01:27:38-04:00"
level=debug g="Started
observing beach"
animal=walrus number=8
time="2015-03-26T01:27:38-04:00" level=info
msg="A group
of walrus emerges
from the ocean" animal=walrus size=10 |
Json格式
| {"animal":"walrus","level":"info","msg":"A
group of
walrus emerges from
theocean","size":10,"time"
:"2014-03-10
19:57:38.562264131 -0400 EDT"}
{"level":"warning","msg":"The
group's number increased tremendously!","number":122,"omg":true,"time":
"2014-03-10
19:57:38.562471297 -0400 EDT"} |
2. 端到端链路上的调用日志收集
在微服务架构中，一个业务请求会经历多个服务，收集端到端链路上的日志能够帮助我们判断错误发生的具体位置。在这个系统中，我们在请求入口处，生成了全局ID，通过gRPC中的context将ID在链路中传递。将不同服务的日志收集到graylog中，查询时就能通过一个ID，将整个链路上的日志查询出来。
上图中，使用session-id来作为整个调用链的ID可以进行全链路检索。
小结
微服务构建的系统中，在部署、调度、服务发现、一致性等其他方面都有挑战，Go技术栈在这些方面都有最佳实践（Docker、Kubernetes、Consul、etcd等等）。具体内容在网上已经有很完善的教程，在此不用班门弄斧，有需要的可以自行查阅。 |
