今日头条Go建千亿级微服务的实践

在 Go 语言中,Server 的模型是“协程模型”,即一个协程处理一个请求.如果当前请求处理过程因为依赖服务响应慢阻塞,那么很容易会在短时间内堆积起大量的协程.每个协程都会因为处理逻辑的不同而占用不同大小的内存,当协程数据激增,服务进程很快就会消耗大量的内存.

协程暴涨和内存使用激增会加剧 Go 调度器和运行时 GC 的负担,进而再次影响服务的处理能力,这种恶性循环会导致整个服务不可用.在使用 Go 开发微服务的过程中,曾多次出现过类似的问题,我们称之为协程暴涨.

有没有好的办法来解决这个问题呢?通常出现这种问题的原因是网络调用阻塞过长.即使在我们合理设置网络超时之后,偶尔还是会出现超时限制不住的情况,对 Go 语言中如何使用超时控制进行分析,首先我们来看下一次网络调用的过程.

第一步,建立 TCP 连接,通常会设置一个连接超时时间来保证建立连接的过程不会被无限阻塞.

第二步,把序列化后的 Request 数据写入到 Socket 中,为了确保写数据的过程不会一直阻塞,Go 语言提供了 SetWriteDeadline 的方法,控制数据写入 Socket 的超时时间.根据 Request 的数据量大小,可能需要多次写 Socket 的操作,并且为了提高效率会采用边序列化边写入的方式.因此在 Thrift 库的实现中每次写 Socket 之前都会重新 Reset 超时时间.

第三步,从 Socket 中读取返回的结果,和写入一样,Go 语言也提供了 SetReadDeadline 接口,由于读数据也存在读取多次的情况,因此同样会在每次读取数据之前 Reset 超时时间.

分析上面的过程可以发现影响一次 RPC 耗费的总时间的长短由三部分组成：连接超时,写超时,读超时.而且读和写超时可能存在多次,这就导致超时限制不住情况的发生.为了解决这个问题,在 kite 框架中引入了并发超时控制的概念,并将功能集成到 kite 框架的客户端调用库中.

并发超时控制模型如上图所示,在模型中引入了“Concurrent Ctrl”模块,这个模块属于微服务熔断功能的一部分,用于控制客户端能够发起的最大并发请求数.并发超时控制整体流程是这样的

首先,客户端发起 RPC 请求,经过“Concurrent Ctrl”模块判断是否允许当前请求发起.如果被允许发起 RPC 请求,此时启动一个协程并执行 RPC 调用,同时初始化一个超时定时器.然后在主协程中同时监听 RPC 完成事件信号以及定时器信号.如果 RPC 完成事件先到达,则表示本次 RPC 成功,否则,当定时器事件发生,表明本次 RPC 调用超时.这种模型确保了无论何种情况下,一次 RPC 都不会超过预定义的时间,实现精准控制超时.

Go 语言在1.7版本的标准库引入了“context”,这个库几乎成为了并发控制和超时控制的标准做法,随后1.8版本中在多个旧的标准库中增加对“context”的支持,其中包括“database/sql”包.

性能

Go 相对于传统 Web 服务端编程语言已经具备非常大的性能优势.但是很多时候因为使用方式不对,或者服务对延迟要求很高,不得不使用一些性能分析工具去追查问题以及优化服务性能.在 Go 语言工具链中自带了多种性能分析工具,供开发者分析问题.

• CPU 使用分析
• 内部使用分析
• 查看协程栈
• 查看 GC 日志
• Trace 分析工具

下图是各种分析方法截图

在使用 Go 语言开发的过程中,我们总结了一些写出高性能 Go 服务的方法

1. 注重锁的使用,尽量做到锁变量而不要锁过程
2. 可以使用 CAS,则使用 CAS 操作
3. 针对热点代码要做针对性优化
4. 不要忽略 GC 的影响,尤其是高性能低延迟的服务
5. 合理的对象复用可以取得非常好的优化效果
6. 尽量避免反射,在高性能服务中杜绝反射的使用
7. 有些情况下可以尝试调优“GOGC”参数
8. 新版本稳定的前提下,尽量升级新的 Go 版本,因为旧版本永远不会变得更好

下面描述一个真实的线上服务性能优化例子.

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!