[广告前端] Node服务资源治理

天天都在讲的服务治理，指的是什么？都包含哪些方面呢？为什么要需要服务治理呢？

对于任何一个产品或者功能来说，开发完成仅仅只是开始，后面还会有很长一段时间的维护期。

上图是一个很基础的产品或者功能的生命周期示意图，从图中我们可以看到：

1. 功能开发阶段的成本非常显性，但是功能维护期，包含了产品功能迭代以及后续的维护，隐性成本往往会更高。

2. 功能开发阶段时间虽然有可能很短（相对维护期来讲），但是它是起点，也是源头。

   在功能开发期的“所作所为”，很大程度上决定了后续功能维护代价。

但是，以互联网为载体的产品或者服务往往还会要求 24 小时不间断服务。这就导致了功能开发与维护的边界变得不再那么清晰，尤其是 Web 服务，还不像客户端那样有着固定的发版周期，有时候我们每天都会发布新的版本，以及不定期的 Hot Fix，甚至频繁的 “Hot Featrue”

而服务治理的核心目标，除了软件治理（如何让众多的软件一起融洽相处，感觉好像自己独享着物理的硬件资源）外，更重要的是考虑如何能够真正做到 24 小时不间断的服务。

服务治理这个范畴很宽泛，可以包含以下部分：

1. 发布、升级与版本管理

2. 日志、监控与报警

3. 资源与容量

4. 服务发现

5. 流量调度

6. 过载保护

7. 故障预案、故障排查与根因分析

8. 可支持性

   
   

服务治理的目标，是保障软件提供 24 小时不间断服务。服务治理没有简洁的抽象问题模型，我们需要面对的是现实世界的复杂性。

服务治理它并没有那么简单纯粹，在理想情况下，我们应该尽可能所有故障的恢复，但是故障的可能太多，很多情况是我们无法提前预知的，这也就意味着人工介入并不能比避免。

所以，互联网不只是产生了开发工程师的工种，随着系统变得更加复杂，如何让软件提供 24 小时不间断提供服务呢？

Site Reliability Engineer (网站可靠性工程师)，最先被 Google 引入，后被各类公司所借鉴。区别于传统意义上的运维，SRE 也是一个特殊的工程师群体，和服务端开发一样，他们肩负着自己独特的使命。

我们先来看看故障的类别，以及 SRE 独特的使命又是什么。

可用性时间表

我们系统的可用性可以做到 “三个9”、“三个9一个5”，甚至更高的“四个9”，但是往往不可能做到系统 100% 可用，即没可能，也无必要。

故障类别

故障基本上是难以避免的。可以导致故障的因素又很多，大体上可以按照这么几个层面进行划分：

1.软硬件升级和各类配置的变更。变更是故障的第一问题源头。所以，这是一个研发效率与稳定性之间做平衡的问题（一个可用的思路是引入错误预算，详见：Motivation for Error Budgets）。

2.软硬件环境故障引发的服务异常

• 单机故障：

  硬盘坏、内存坏、网卡坏、系统死机失去响应、重启等

• 机房或者机架故障：

  断网、掉电等

• 区域性故障：

  运营商网络故障、DNS 服务故障、海底光缆损坏等

• 自然灾害：

  地震、火灾、山洪等

3.终端用户的请求

• 秒杀场景，短时间大量用户涌入，系统承受能力超出规划

• 针对性恶意攻击

• 特定类型用户请求占用大量服务端资源

一般来说，SRE 团队要承担以下几类职责：

1. 可用性改进

2. 延迟优化

3. 性能优化

4. 效率优化

5. 变更管理

6. 监控

7. 应急事务处理

8. 容量规划与管理

   
   

在这些复杂的工作中，有包含了大量的“琐事”。那什么是琐事呢？

琐事指的是运维工作中手动性的，重复性的，可以被自动化的，战术性，没有持久价值的工作。而且，琐事与服务呈线性增长。并不是所有琐事都有上面的全部特性，但是，每件琐事都会满足以上述的一个或者全部的属性。

SRE 的一个公开目标就是要保证每个 SRE 的工作时间中运维工作（琐事）的比例低于 50%。SRE至少要花费 50% 的时间在工程项目上，以减少未来的琐事或者增加服务功能。增加服务功能包括提高可靠性、性能，或者利用率，同时也会进一步消除琐事。

1. 职业停滞

2. 士气低落

另外，牺牲工程实践而做琐事会对 SRE 组织的整体发展造成损害，原因如下：

1. 造成误解

2. 进展缓慢

3. 开创先例

4. 促使摩擦产生

5. 违反承诺

   
   

工程工作是一种新颖的、本质上需要主观判断的工作。它是符合长期战略的，会对你的服务进行长久的改善工作。工程工作通常是有创新性和创造性的，着重通过设计会解决问题，解决方案越通用越好。工程工作有助于该团队或者整个 SRE 组织在维持同等人员配备的情况下接手更大或者更多的服务。

典型的 SRE 活动分为以下几类：

1.软件工程：编写或者修改代码，以及所有其他相关的设计和文档工作，例如:

• 编写自动化脚本

• 创造工具或框架

• 增加可拓展性和可靠性的服务功能

• 修改基础设施代码使其更加稳健

2.系统工程：配置生产系统、修改现有配置，或者使用一种通过一次性工作产生持久的改进的方法来书写系统文档。

• 监控的部署和更新

• 负载均衡的配置

• 服务器配置

• 操作系统的参数调整和负载均衡器的部署

• 与研发团队进行架构、设计和生产环境方面的咨询工作

3.琐事：与运维服务相关的重复性的，手动的劳动

4.流程负担：与运维服务不直接相关的行政工作

• 招聘

• 人力资源书面工作

• 团队 / 公司会议

• 任务系统的定期清理工作

• 工作总结

• 同行评价和自我评价

• 培训课程等

  
  

在 12 月 24 日晚上 7 点到 9 点间，Google 由于云端运算服务容量分配出现问题，导致账号服务不可用，进而影响全系 Google 服务的使用。

期间，出现了类似“VPN 团队因为无法连接 VPN，而导致 VPN 问题无法被及时修复”的问题。

本次宕机是本年 Google 第三次宕机事件，有些工程师已经其宣称信仰已经崩溃。

从我们目前的服务类型和业务现状来讲的话，目前我们负责的的服务主要会运行在 TCE 、ByteFaaS 这些云计算平台上。

随着业务的发展，目前我们前端团队已经逐渐开始承接 BFF（Backend For FrontEnd）服务开发的工作，主要涉及后端 RPC 接口的数据聚合、裁剪等内容，还会承接一部分和前端 UI 关系比较紧密的业务逻辑。在这种场景下，我们不需要直接连接数据库。对内服务中，Node 已经承担起了相当一部分业务系统的后端开发，Node 在我们团队中发挥着越来越重要的作用。

资源视角一般比较关注的是我们服务在与基础资源进行交互的时候，是否会有稳定性风险，资源滥用等问题。帮助我们的服务能够正确使用资源，降低风险，提高系统稳定性。

资源治理仅仅只是服务治理中的一小部分，从目前我们的实践中，作为前端 BFF 服务主要需要关注到以下部分：

在上面服务治理简要介绍部分我们提到过，服务治理的目标就是让我们的服务 7* 24 小时运行，那么这就对我们的实例数量有着一定的要求。

我们推荐根据服务的状态留有一定的余量，如 N+1 或者 N+2，或者其他业务上规划好的值。这部分就涉及到了容量预估，比较复杂，同样有着很多需要考虑的点，有着“现实世界的复杂性”。目前业界已经有公司在用 AI 帮助业务进行容量的规划与预测。

在上面我们提到过，故障类型大体分为三种：

1. 软硬件升级以及各类配置变更

2. 软硬件环境的故障

3. 终端用户的请求

“过载”就是一种典型的由“终端用户请求”导致的故障。那么，它的原因是什么？

过载原因

所谓过载，最直白的理解就是当消耗超过了资源的承载能力，导致资源耗尽，进而出现了系统的过载。所以过载从本质上讲，可以归为容量规划问题。资源消耗光了，通常的原因有以下几种：

1. 用户增长过快（自然 && 活动引流），资源规划的预期没跟上

2. 部分资源故障，导致线上可用资源不足。

   比如双机房容灾场景

3. 系统关键资源负载变低。

   随着时间的推移，数据库中的数据越来越多，达到了某个临界点后，数据库的整体延迟增加，支持的并发度也下降了

4. 不合理的重试逻辑

• 比如一个 API 失败了后重试 3 次，然后 API 内部依赖了一个下游服务提供的 API，同样可能会重试 3 次，那么可能的额外重试次数就是 3～9 次，如果依赖链路够长的话，重试次数会指数级别上升。

过载后果

通常过载的表现是“资源耗尽”。而且通常也会有“连锁反应”，定位比较困难。更可怕的事情长期过载产生的正反馈效应。比如线上一共 10 个实例，过载导致其中 2 个实例宕机。然后剩下的 8 个实例压力会更大。这种由于正反馈循环导致恶化的情况，在短时间内就快速形成了雪崩效应，击垮系统。

当宕机实例重启后，又会被迅速打垮，形成一种“在棺材里做仰卧起坐”的现象，直到整个服务全部挂掉。

如何应对？

1. 降低过载发生概率

2. 即使发生过载，杜绝雪崩效应

   
   

服务端处理方式

1. 应该在过载情况下主动拒绝请求，保护自己不进入过载崩溃状态。

   及早将请求标记为失败，尽快返回。

2. 伴随性能测试进行容量规划，确定服务容量。

   可根据服务实际的重要冗余部分资源

3. 服务优雅降级。优雅降级不应该被频频触发，否则就是容量规划上的失误。

   
   

客户端的处理方式

1.重试

• 限制每个请求重试次数

• 使用随机化、指数递增的重试周期

• 考虑使用全局重试预算。例如每个进程每分钟只允许重试 60 次。如果重试预算耗尽，那么就直接把请求标记为失败，不要发送给服务端。

2.请求重要性级别，例如“可丢弃”、“一般”、“重要”、“非常重要”，当发生服务端过载后，根据请求级别抛弃一定的请求，直到系统负荷正常

3.请求延迟和截止时间。结构性的超长时间请求有可能拖垮系统，并引起服务的雪崩效应。如果请求处理分为多阶段，则每阶段前都检查下截止时间，发现超时及早返回。

4.客户端节流。当客户端在发现最近请求错误中有大部分是由于“配额不足”错误导致的话，那么就自行限制请求速率，自行限制请求生成数量，抛弃过多的请求（直接在本地回复失败）