一．微服务化带来的挑战

上图是我们 B 站全链路追踪的一个截图，这只是其中一个拓扑图的调用链路，就已经非常复杂了。可以想象一下，如果是整个公司所有的调用链路，会有多么复杂。而这就带来了微服务治理的复杂性问题：如何保证注册和发现；如何保证多机房高可用；如何保证低延迟等等。

其次，微服务化以后，服务拆分的比较多，调用链也比较长，调用链很容易受到一个坏节点的影响，导致用户端出现超时的现象。另外，负载不均衡会导致热点问题，并影响资源调度；单个节点不可用，如果限流或者熔断手段做的不好可能有雪崩效应；微服务代理的分布式事务问题和分布式一致性问题，以及编排、日志、链路追踪等问题。

二．Go 语言在 B 站开源服务发现框架–Discovery 的实践历程

2015 年到 2017 年，B 站的微服务也是基于 Zookeeper，Zookeeper 是一个 CP 系统，可以保证一致性，在网络分区的情况下保证可用性。但是我们 CP 系统有一个问题，就是难以支持跨机房。如果机房 1 和机房 2 由于某些不稳定的原因发生网络断开，provider B 去往 ZK Follower 的注册是无法实现的。因为 ZK Follower 所有的请求是强一致，都有同步到 ZK Leader，这时机房 2 就无法注册了，但其实 Consumer B 和 Provider B 之间的网络是正常的。

Zookeeper 有一个性能瓶颈，因为强一致系统一般都会缓存全量日志，而 ZK Leader 是单节点的，所有的写请求都会到 ZK Leader 上，因此，写是无法水平扩展的。

另外，基于 TCP 的健康检查也不是最优的。

2018 年，我们开始自研了服务发现框架，目前该框架已经在 B 站大规模使用了。这是一个 AP 的系统，Service Provider 注册以后，所有的注册、健康检测、取消注册都会通过 Discovery Server 异步同步到其它 Discovery Server，然后来保证最终一致。

Discovery Server 一定要满足网络分区时的自我保护，保证健康的服务节点可用。

客户端与 Discovery Server 是通过 HTTP Long Polling 来连接的。这种方式开发比较简单，且拥有推拉结合的好处，既能及时感知到节点变更，又方便并发编程的维护。

上图中下方的表格是与开源 Eureka 的对比图，基本上 Eureka 可以做到的，Discovery 也可以做到，Eureka 不能做到的，Discovery 还可以做到。（具体可参考表格）

机房的流量调度是怎么做的呢？

点击“了解更多” 查看全文