从抖音关闭评论，看服务治理的重要性

Posted 2021-04-25 芋道源码

4月10日，某日头条下的低俗试听产品「XX段子」被勒令永久关停。

该消息传出后，该APP大量用户涌入抖音，以统一头像以及统一的评论迅速占领抖音热门视频评论区。

而就在该某段子APP被封当晚 23 点 40 左右，抖音关闭了评论的所有功能。虽然页面显示有几千条评论，但是当点开评论的时候却发现没有评论内容。

作为技术人员，我不禁在想：从用户刷屏到最后关闭整个评论功能，今日头条在技术上如何能够如此快速地关闭所有评论功能？

我们可以猜想，以抖音这种数量级的用户，抖音后台早已实现了各个功能模块的服务化拆分，并且进行了服务治理。而从今日头条对外的技术分享来看，今日头条确实是这么做的。

我们使用 Go 语言研发了内部的微服务框架 kite，协议上完全兼容 Thrift。以五元组为基础单元，我们在 kite 框架上集成了服务注册和发现，分布式负载均衡，超时和熔断管理，服务降级，Method 级别的指标监控，分布式调用链追踪等功能。目前统一使用 kite 框架开发内部 Go 语言的服务，整体架构支持无限制水平扩展。

从上面的技术分享片段，我们可以知道今日头条内部使用了 Go 语言开发的 Kite 微服务框架，并且实现了服务监控、服务熔断、服务降级、服务指标监控等功能。

所以我们可以猜想：当 4 月 10 日，广电总局宣布勒令关闭XX段子，大量用户涌入抖音评论区的时候，抖音评论接口调用数暴增，相应的服务监控报警，相关的技术人员收到信息进行紧急处理。此时技术人员便会排查评论接口调用暴增的原因，并且商量对应的对策。

到了 4 月 10 日 23 点 40 分左右，或许因为担心事态进一步发酵，所以抖音选择将评论接口进行服务熔断。所有请求评论列表的请求，全部返回空的评论数据。

其实所谓的「服务熔断」指的就是当某个指标达到一定程度时，服务接口自动熔断，对所有请求该接口的消费者都返回一个默认值。例如抖音一定时间内评论接口调用数达到100万次，自动返回空的评论数据。当然了，服务熔断也可以手动触发。

现在回头想一想，抖音之所以能快速地处理好这件事情，很大一部分是服务治理的功劳。试想一下，如果没有服务监控，那么技术人员就无法第一时间获取异常信息。那用户就会在抖音评论区一直刷屏，这时时态很可能得不到平息，反而会越演越烈，抖音很可能会成为下一个XX段子，这对今日头条的打击将是巨大的。

正是因为服务治理对于突发情况的处理效果出众，所以当一个公司产品达到一定数量级之后，服务治理一定是绕不过的一个话题。

而服务治理不仅仅在处理突发事件效果出众，对于线上问题处理，服务监控也能发挥很大的作用。笔者之前的公司有一个完善的服务监控系统，它能统计各个接口的异常率，并且能针对每个异常请求显示出完整的分布式调用链，这对于开发人员排查线上问题非常有用。

服务监控、服务熔断其实只是服务治理很小的一部分，本文也只是简略地提了一下。希望这篇文章，能让更多的技术人了解到热点背后的技术，提炼出对于技术更深刻的理解。

---

欢迎加入我的知识星球，一起交流、探讨源码：