楔子：“凡事豫则立，不豫则废。言前定则不跲，事前定则不困，行前定则不疚，道前定则不穷。”—出自《礼记.中庸》

   谈信息安全和业务浪涌，我们不得回顾一下信息安全的三个属性CIA：机密性（Confidentiality）、完整性（Integrity）、可用性（Availability）的可用性，业务浪涌则和可用性密切相关。

   我们知道针对A（可用性）的攻击最常见的是DDoS和DoS，然而真实环境中非攻击带来的可用性问题也是非常普遍的现象，有些影响了使用体验，例如：双“十一”电商；有些则影响了民生，例如：春运票务；有些则影响国计，例如：核酸码，自抗疫以来，多地出现过核酸码服务无法满足大量访问需求的现象，给抗疫工作带来了困扰。

   而以上拥塞，都可以用浪涌来解释。

什么是浪涌

   浪涌的概念（electrical surge）出自电学，是指电压或电流瞬间出现超出正常值的现象。可能引起浪涌的原因包括外部因素（感应雷击、直接雷击等）、内部因素（电气启停、故障等）。

   业务浪涌与电学浪涌有着相似之处，为了便于理解我们可以看如下场景映射：

1. （电压浪涌场景映射）单一车辆造成高速拥堵，现实场景中的大型单车故障，尤其以有害化学品单车故障为典型，造成拥堵。

2. （电流浪涌场景映射）车流量巨大，春节高速塞车是典型现象。

业务浪涌的产生

   参考浪涌的概念，我们认为计算机系统中，业务浪涌的产生来自于超出正常值的业务压力。可能是单请求形成的巨大能力（计算力、网络传输力等）消耗，也可能是短时间内爆发的大量请求。而我们前文提到的双“十一”、春运票务和核酸码均属于后者，也是我们接下来重点讨论的场景。

   业务浪涌伴随商业机构的促销活动，可以预见性的进行部署应对措施，云计算通常是他们的选择之一，而其他机构由于特殊原因也会出发，例如：节假日触发的票务。

   既然业务浪涌的场景有存在的合理性，我们应当如何去避免可用性问题的出现呢？

业务浪涌可用性问题分析

   业务浪涌的产生是很难避免的，它具有充分的产生前提，因此我们需要分析业务系统的架构，以寻找可用性问题产生的原因，从而制定解决方案和预防业务浪涌带来的雪崩效应，常用的系统架构的依赖模式通常包括：

• 纵向依赖型

   纵向依赖对单机性能是个挑战，而单机性能的提升到达一定的程度后，性价比开始降低，技术难度也随之增大。在早期计算机系统中纵向扩展比较常见，尤其是UNIX时代。

• 横向依赖型-集群

   为了解决单机性能所带来的性能困扰，集群模式出现了，在关系数据库时代，集群模式给性能扩展带来了极大的便利。然而集群间协调所消耗的资源是集群扩展的技术难题，集群内成员数量受到一定限制，当大数据时代到来，集群数量上限的问题就凸显了出来。

• 横向依赖型-分布式计算

   人们注意到，随着大数据时代来临时， x86/64架构服务器、操作系统、应用软件已经普及，分布式计算开始流行。分布式计算成为了大数据时代的主流解决方案。

• 外部依赖型

   随着云计算的市场侵蚀，企业或机构采用私有云、公有云和混合云作为解决方案，跨云（或跨网）系统就产生了。由此也产生了外部依赖，例如身份验证服务：

   某系统建设在云A上，其身份验证由于商业或其他原因需要建设在云B上的www.XXX.com（XXX为代指）来完成，瞬间产生的大量的系统访问需要跨云，于是外部依赖产生了，云B的服务能力、云间带宽和延迟等因素对外部依赖都产生影响。

   基于现代应用系统以分布式计算和云作为基础架构的解决方案为主，我们的解决思路主要从基于分布式计算的横向依赖和外部依赖这两点出发。

解决思路

   大型系统的设计，宜自顶向下设计，采用架构设计的逻辑展开。笔者推荐结合企业架构（Enterprise Architecture）方法论进行设计。

• 架构设计

   架构设计，需要结合系统的依赖性，分析各环节的性能可扩展性。业务浪涌对全业务流程的输出能力都是挑战，尤其是外部依赖不能被忽略。

   架构设计，在分布式计算形态下，主要是系统架构各层的横向扩展能力设计。包括应用系统、中间件、数据库，以及硬件资源。

   架构设计良好的系统，其硬件资源往往在业务浪涌中成为资源瓶颈。

• 资源设计

   云计算产生的初期是基于单机计算、存储等能力的富余，为了复用资源，降低成本，虚拟化技术（资源分割）是早期云计算的主流技术。然而，业务浪涌则是逆虚拟化（资源统合）的过程，对算力、存储、网络的消费有着巨大的需求，因此对云内可用资源提出了挑战，冗余资源配置和调度是决绝业务浪涌的关键点。

   考虑到企业运营的费效比指标，冗余资源宜结合服务设计同步实施。

• 服务设计

   服务设计的要点在于QoS（服务质量）设计， 主流的分类包括以下三类：Best-Effort service（尽力而为服务模型），Integrated service（综合服务模型，简称Int-Serv），Differentiated service（区分服务模型，简称Diff-Serv）。QoS和费用相结合，则可以以SLA进行呈现。

   而基于SLA，在资源受限的情况下，就有了资源调配的经济价值基础。

• 技术设计

   瞬间流量巨大的业务系统，其技术要求也提高了，基于架构、资源和服务设计的理念，可以从以下角度出发：

1. 按需上线：采用预测技术，及时上线备用资源；

2. 缓存技术：高速缓存和多级缓存并用；

3. 队列技术：采用队列技术避免拥塞；

4. 异步技术：结合业务流程分析，采用异步方式分流；

5. 无状态：利用无状态连接代替有状态连接，提高处理效率；

6. 读写隔离：降低一致性需求的压力；针对验证性服务，可采用独立的读服务；

7. 降级与限流：在总资源固定时，结合SLA，在流量瞬间爆发时，针对性降级和限流。

小结：

   结合以上分析，业务浪涌可以预测的和预防的。让我们谨记：“凡事豫则立，不豫则废。“

建议继续学习：

1. 信息安全常见误区    (阅读：1565)