为更好的应对业务快速变化带来的挑战，许多系统正在从“关联系统”角色向着“服务”角色转变。这样的转变对系统各方面质量特别是运行时质量提出了不一样的要求。如何管理并始终满足这些要求，打造弹性、容错、可管理的服务，是我们需要重点考虑的问题。

作为“风险驱动的架构设计”的实践者，我们以系统运行过程各个阶段可能遇到的风险为线索，整理我们可能采取的保障措施。——

• 设计时
• 业务接入时
• 日常趋势
• 事故时

性能和容量

设计时

需要根据业务目标确定适当性能理想值。比如：

• 响应时间
• 吞吐量

业务接入时

新的业务接入，不论是新的系统接入还是旧有接入系统业务量发生变化。

• 新系统接入时应该声明业务量和变化趋势。
• 接入系统业务量（即将）发生显著变化时应该声明。
• 需要知晓当前系统可以承受的业务量。

日常趋势

系统运行中，几个方面的风险需要持续防范：

• 性能表现恶化
• 业务量异常变化
• 资源消耗异常变化

为此，我们需要：

• 性能指标的周期性监控记录。
• 业务总量的周期性监控记录。
• 各接入系统业务量周期性监控记录。
• 资源消耗量周期性监控记录。

事故时

性能事故指的是性能表现发生急剧恶化，用户受到明显影响。性能事故的原因可以分两种情况分析——

• 业务量发生变化
  • 各接入系统业务量及调用量。
  • 隔离、特别是热隔离。
  • 扩展性，特别是横向扩展。
• 业务量没有明显变化
  • 受依赖系统拖累
    • 依赖系统调用记录。
    • 替代方案或后备方案。
  • 某（些）节点性能异常
    • 各节点的性能数据。
    • 节点可（热）拔插。
  • 变更 - 环境、代码
    • 诊断用现场数据

为及时发现性能事故和区分两种情况，我们需要：

• 性能数据，实时监控和阙值报警。
• 总业务量，包括时间和功能分布。

小结

综上，为持续保障系统性能表现，需要采取的措施有：

• 根据业务目标有适当的性能和容量的理想值。影响因素变化后或者周期性地需要review。
• 明确当前系统最大承受业务量。影响因素变化后或者周期性地需要review。
• 确保新系统接入或接入系统业务量变化时声明业务量和变化趋势。建立机制，包括事后回朔机制。
• 系统性能指标的阙值报警。
• 系统性能指标的持续监控记录和分析。
• 业务总量的持续监控和分析。
• 各接入系统业务量持续监控和分析。
• 资源消耗量持续监控和分析。
• 各接入系统业务量及调用量实时数据。
• 有能力实时隔离接入系统。
• 容量可扩展性，特别是横向扩展。
• 依赖系统调用记录的实时数据。包括调用量和性能。
• 依赖系统替代方案或后备方案。至少有业务层面后备方案。
• 各节点的性能指标的实时数据。
• 各节点可（热）拔插。拔出后性能和容量可接受。
• 诊断用现场实时数据。各节点都需要此类数据，比如线程dump。