支撑百度搜索引擎99.995%可靠名字服务架构设计

https://v.qq.com/x/page/l0530rnydcc.html

搜索引擎的挑战

机器数量多，服务数量大：我们有数万台服务器，数十万个服务，分布在多个IDC。

服务变更多，变更数据大：每天几十万次变更，每周10P量级的文件更新，千余人并行开发上百个模块。

检索流量大，稳定性要高：每秒数万次请求，满足99.995%的可用性，极短时间的故障都可能引发大量的拒绝。

服务发现的原理

什么是服务发现

服务上游如何找到下游；服务上游如何负载均衡；下游挂了上游如何感知。

客户端服务发现

所有服务下游自行向服务注册表中进行注册，同时服务上游集成注册表的客户端，查询注册表以获取服务下游列表。服务上游集成负载均衡器，实施负载均衡。

服务端服务发现

服务端服务发现和客户端服务发现的区别就在于，服务端服务发现所有服务上游的请求都是通过网关去查询。

服务发现组件

服务发现主要由服务注册表、注册表客户端和负载均衡组成。

服务注册表是分布式的存储，持久化服务地址和自定义属性，服务名字全局唯一。

注册表客户端支持对注册表的增删改查，支持高并发高吞吐，对延迟的要求不太高，读多写少。

负载均衡对于整个服务系统来说是一个不可或缺的组件。它根据负载选择某个服务，剔除和探活故障服务。

关键技术与实践难点

Eden架构蓝图

Eden是百度网页搜索部自行研发的基于百度matrix集群操作系统的PaaS平台。它主要负责服务的部署、扩缩容、故障恢复等一系列服务治理的相关工作。底层是基础设施层，包括监控、故障检测以及matrix集群操作系统。

Eden由三部分组成，第一部分是总控服务，分为InstanceMgr和NamingService。底层有多个agent来执行总控下发的命令。所有的源数据保存在zookeeper上，并提供了命令行、web之类的接口来使用。还有一个机器维修仲裁的组件，根据故障类型、服务状态来决策机器的维修，同时提供了日志的收集分析，和一个仿真的测试平台。

在这之上是job engine层，提供了封装日常服务变更的操作，包括升级、数据的变更、服务扩容、故障实例的迁移等，在这层上做了抽象。

最上面是一些托管的服务，有网页图片搜索服务、度秘服务、和信息流。

服务发现组件

对于一个IDC来说，我们会部署一套NamingService，agent复用的是Eden的agent。

服务发现不可避免的是要支持跨机房的服务发现机制，必须要有跨机房查询的功能，我们就做了一套远程的跨机房查询，上层提供了SDK接口把这些过程封装起来。

为了支持跨机房一定要APP的ID或者名字必须要全局唯一。

技术难点

我觉得一个真正能够在线上稳定运行的服务发现系统必须要解决以下六个问题：

调用时机：谁来向服务注册表注册和注销服务？

健康检查：上游如何感知下游的健康情况？

无损升级：如何无损的进行服务升级？

变更分级：连接关系变更如何分级？

感知变化：上游服务如何感知下游服务列表的变化？

避免单点：如何避免服务注册表局部故障？

调用时机

第一种方式是服务自己，在启动或停止的时候注册或注销自己。这种方式服务的启停对注册表有很强的依赖，服务需要植入SDK，会产生植入成本，容易干扰运维的可预期性，影响过载保护策略。

第二种方式就是采用第三方组件，有一个代理模块去实施服务的注册和注销。我们使用这种方法的时候是利用agent通过SDK去操作。它的优点就是只需在服务添加删除时修改注册表，不用植入SDK，对注册表的依赖很弱，更容易进行运维效果监控，降低注册表的负载。

健康检查

健康检查有服务端健康检查和客户端健康检查两种做法。

服务端健康检查是服务自己做健康检查，把健康结果反馈给服务注册表。但这种方式对注册表的依赖性很强，而且它自己的健康不一定是上游看到的健康，所以结果未必准确，感知周期也很长。

客户端健康检查则是客户端和服务端建立心跳和探活机制。它的优点是对注册表的依赖性弱，感知周期短，准确性更高了。

无损升级

升级就意味着同时重启的数量要比平时更多。对于上游来说，不可访问的服务也比日常要多，这就意味着失败概率会变大。

重试虽然可以在一定程度上解决问题，但重试的副作用大，通常重试的次数会被严格限制。

而健康检查虽然可以探测到不可用的下游服务，但是健康检测存在周期性。

后来我们又有了一个更好的做法:：我们采取的方法是下游服务退出过程中，先不会关闭服务读写端口，而仅仅关闭心跳端口，使服务处于"跛脚鸭"状态，等上游检测到下游心跳异常之后，将流量调度到其他服务实例，然后下游服务实例再关闭读写端口退出，从而实现完全可控的无损服务升级。

变更分级

基于分布式锁的个数，控制上游变更的服务，但上游分级方式具有随机性，出错情况损失偏大。

给下游实例打tag，标记是否被上游可见。

其实这种分级方式并不是很好，因为变更连接关系高危变更，一旦错误，损失很大。更好的方法是通过权重来控制下游服务的流量比例。

感知变化

我们在实践中发现zookeeper的通知机制不可靠，对注册表依赖过重，发生局部故障，影响服务可用性。

而轮询是一种比较可靠的机制。由agent周期性轮询服务注册表，引入版本节点，只有版本变化时，才获取全量数据，增强了运维的可预期性。

避免单点

对于IDC来说，它不希望由于服务发现系统局部故障而影响服务。

历史上我们发生过多次zookeeper的局部故障，比如网络抖动导致大量session超时所引起的通知机制。

把这些“不可靠”作为设计思路，我们把上游持久化缓存下游服务列表，作为容灾手段。采用的是轮询机制。

健康检查是通过上游服务探测下游服务健康状态。

应用范围

目前的服务发现系统应用到了万级的服务数量，支持了十万级的服务实例数量，覆盖了百度搜索引擎规模最大的indexer服务，数千个实例扩缩容的索引分布调整，分钟级完成连接变更。

应用案例

相关对策

原有方案无论是ssdb、proxy还是master，都大量应用了对于zk通知的机制，同时还依赖zk的session机制做探活。

这个方案在实际应用中很容易出现网络抖动session超时的故障，zk通知机制也容易丢消息，zk故障会导致服务整体不可用，平均1~2个月就会发生故障。

所以我们把它迁移到了NamingService，以解决上述问题。

总结和思考

总结

使用第三方组件进行注册和注销；

上游探测下游服务健康状态；

通过服务分组实现无损升级；

连接关系变更一定要有分级机制；

使用轮询而不使用通知；

以服务注册不可靠作为假设条件。

思考

我们打算引入类似k8s的endpoint机制；通过控制流量比例更好的实现分级；提升易用性，成为通用的中间件。

标签：架构设计,99.995%,服务,健康检查,搜索引擎,故障,注册表,上游,下游
来源： https://blog.51cto.com/u_15127602/2757767