本文是 Blibli 技术总监毛剑在GopherChina 2017大会上所做分享的下篇，包含 B 站的中间件、持续集成和交付，以及运维体系搭建。微服务的演进过程和高可用实践见上篇。
中间件
到一定的时间以后，发现我们的服务稍微稳定了，但是业务越来越大，然后业务也越来越发展，我们发现还是需要很多中间件来辅助我们跟各个对接的业务方，或者是其他的一些平台去对接.所以我们就做了一些事情——做了一个队列（这里叫databus），也做一个 canal ，然后做了一些数据刷新、同步，又基于 twitter的 twemproxy 改了一个多线程的版本，然后还做了一个对象存储，此外还做了一个配置中心，最后是基于 Google 的 dapper 做了一个 APM 的链路追踪。
接下来我来讲一下各个中间件都是什么场景使用的。
Databus
做了一个 redis 的协议，用的时候相当于我先批量存一批过去，用一个长轮询的方式，然后如果它 30 秒没有返回数据，那么下次再来重拉一次。还有就是像 Kafka 不太好做健全，我们又做了一个健全，就是把 Kafka 整个地址网段都屏蔽掉，然后我们的 Databus 再对外。此外会加一些简单的授权，避免一些核心的数据泄露。
回放数据库的 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 足够可靠而且可以做主从。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/129808.html