毛剑：Bilibili 的 Go 服务实践（下篇）

本文是 Blibli 技术总监毛剑在GopherChina 2017大会上所做分享的下篇，包含 B 站的中间件、持续集成和交付，以及运维体系搭建。微服务的演进过程和高可用实践见上篇。

中间件

到一定的时间以后，发现我们的服务稍微稳定了，但是业务越来越大，然后业务也越来越发展，我们发现还是需要很多中间件来辅助我们跟各个对接的业务方，或者是其他的一些平台去对接.所以我们就做了一些事情——做了一个队列（这里叫databus），也做一个 canal ，然后做了一些数据刷新、同步，又基于 twitter的 twemproxy 改了一个多线程的版本，然后还做了一个对象存储，此外还做了一个配置中心，最后是基于 Google 的 dapper 做了一个 APM 的链路追踪。

接下来我来讲一下各个中间件都是什么场景使用的。

Databus

如图10所示。Databus基于 Kafka 。当时我们用 Kafka 做了一些简单的业务，但是 SDK 很多 bug，而且各个语言实现也不一样。后来我们想了一个办法，做了一个 redis 的协议，用的时候相当于我先批量存一批过去，用一个长轮询的方式，然后如果它 30 秒没有返回数据，那么下次再来重拉一次。还有就是像 Kafka 不太好做健全，我们又做了一个健全，就是把 Kafka 整个地址网段都屏蔽掉，然后我们的 Databus 再对外。此外会加一些简单的授权，避免一些核心的数据泄露。

我们早期用 Databus 和 Canal 回放数据库的 binlog，然后把 Databus 跟 Canal 打通。我们可以把稿件的核心数据或者一些技术，同步给我们的搜索、大数据，甚至一些微服务的，包括我们有一些业务，db 跟 cache 要保持强一致的话，我们都是通过 binlog 来回放的。所以我们大量使用 Databus 和 Canal 的这么一个组合。

图10

图11所示场景就是我们用 Databus 来加上刚刚那两个 rpc 来支持广播，来做我们服务的 logic cache 的清理。我们有一些业务可能有多个副本，L1、L2这种， cache 可能不太好清，而且我们后续上了 docker ，发现这个IP也是变的，server 非常多，cache 清除更加困难，所以就用这样一个 Job 加一个广播再加 da tabus 订阅的方式来清理，保证整个 cache 的一致。

图11

配置中心

后来我们又做了配置中心，如图12。早期也是通过配置文件，后来实在太痛苦了。我们参考了很多家，360、淘宝，后来用最了简单的方法，把配置文件存到 mysql 里面，我们认为 mysql 足够可靠而且可以做主从。然后