大规模服务设计部署经验谈(4) | 依赖管理

4               依赖管理

在大规模服务中，依赖管理这个话题通常得不到应有的关注。一般的准则是，对于小型组件和服务的依赖关系，对于判断管理它们的复杂性来说，并不足以节约成本。在以下情况中，依赖关系存在重要意义：

1. 被依赖的组件在大小和复杂度上有重要价值；

2. 被依赖的服务在作为单一的中央实例时存在价值。

第一类的例子有存储和一致性算法（consensus algorithm）的实现。

第二类的例子包括身份和群组管理系统。这些系统的整体价值在于它们是一个单一且共享的实力，因此使用多实例来避免依赖关系就不是可选方案。假定要根据上面的标准判断依赖关系，那么用来管理它们的最佳实践有：

4.1               为延迟做好准备。

为延迟做好准备。对外部组件的调用可能需要很长时间才能完成。不要让一个组件或者服务中的延迟在完全不相关的领域中引发延迟；确保所有的交互都存在长度合适的超时时长，避免资源阻塞更长的时间。运营等幂性允许请求在超时后重启，即便这些请求可能已经部分或完全完成。确保所有的重启操作都得到报告，并给重启操作设定界限，从而避免反复故障的请求消耗更多的系统资源。

4.2               隔离故障。

网站的架构必须能防止层叠的故障，要总是“快速失败（fail fast）”。当依赖服务出现故障时，把这些服务标注为停机，并停止使用这些服务，以避免线程因等待故障组件而阻塞。

4.3               使用已经交付的历经考验的组件。

使用已经交付的历经考验的组件。历经考验的技术通常总是要比大胆前卫地走在潮流尖端运行要好很多。稳定的软件要优于新版本的早期，不管新特性如何有价值。这条原则也适用于硬件。批量生产的稳定硬件，往往要比从早期发布的硬件所获得的些许性能提升要有价值得多。

4.4               实现跨服务的监控和警报。

实现跨服务的监控和警报。如果服务中有一个附属服务过载，那么被依赖的服务就必须了解这个情况，并且如果服务无法自动备份，那么必须发送警报。如果运营部门无法快速地解决这个问题，那么服务就得设计得能容易迅速地联系到两个团队的工程师。所有相关的团队都应当在附属团队中安排工程联络人。

4.5               附属服务需要同一个设计点。

附属服务需要同一个设计点。附属的服务和附属组件的生产者至少必须遵循与所属服务相同的SLA（服务水平协议）。

4.6               对组件解耦。

对组件解耦。在所有可能的地方保证在其他组件故障时，组件可以继续运行，可能在一个降级的模式中。例如，比起在每一个连接上重新验证，维护一个Session键值，并且无论连接状况如何，每过N小时就刷新这个键值会更好些。在重新建立连接时，只使用现有的Session 键值。这样的话在验证服务器上的负载就会更加一致，而且也不会在临时网络故障和相关事件之后的重新连接过程中出现登录高峰期的情况。