2.2.2　弹性原则

弹性原则是指系统部署规模可以随着业务量变化自动调整大小，而无须根据事先的容量规划准备固定的硬件和软件资源。优秀的弹性能力不仅能够改变企业的IT成本模式，使得企业不用再考虑额外的软硬件资源成本支出（闲置成本），也能更好地支持业务规模的爆发式扩张，不再因为软硬件资源储备不足而留下遗憾。

在云原生时代，企业构建IT系统的门槛大幅降低，这极大地提升了企业将业务规划落地为产品与服务的效率。这一点在移动互联网和游戏行业中显得尤为突出。一款应用成为爆款后，其用户数量呈现指数级增长的案例不在少数。而业务呈指数级增长会对企业IT系统的性能带来巨大考验。面对这样的挑战，在传统架构中，通常是开发人员、运维人员疲于调优系统性能，但是，即使他们使出浑身解数，也未必能够完全解决系统的瓶颈问题，最终因系统无法应对不断涌入的海量用户而造成应用瘫痪。

除了面临业务呈指数级增长的考验之外，业务的峰值特征将是另一个重要的挑战。比如，电影票订票系统下午时段的流量远超凌晨时段，而周末的流量相比工作日甚至会翻好几倍；还有外卖订餐系统，在午餐和晚餐前后往往会出现订单峰值时段。在传统架构中，为了应对这类具有明显峰值特征的场景，企业需要为峰值时段的流量提前准备大量的计算、存储及网络资源并为这些资源付费，而这些资源在大部分时间内却处于闲置状态。

因此，在云原生时代，企业在构建IT系统时，应该尽早考虑让应用架构具备弹性能力，以便在快速发展的业务规模面前灵活应对各种场景需求，充分利用云原生技术及成本优势。

要想构建弹性的系统架构，需要遵循如下四个基本原则。

（1）按功能切割应用

一个大型的复杂系统可能由成百上千个服务组成，架构师在设计架构时，需要遵循的原则是：将相关的逻辑放到一起，不相关的逻辑拆解到独立的服务中，各服务之间通过标准的服务发现（Service Discovery）找到对方，并使用标准的接口进行通信。各服务之间松耦合，这使得每一个服务能够各自独立地完成弹性伸缩，从而避免服务上下游关联故障的发生。

（2）支持水平切分

按功能切割应用并没有完全解决弹性的问题。一个应用被拆解为众多服务后，随着用户流量的增长，单个服务最终也会遇到系统瓶颈。因此在设计上，每个服务都需要具备可水平切分的能力，以便将服务切分为不同的逻辑单元，由每个单元处理一部分用户流量，从而使服务自身具备良好的扩展能力。这其中最大的挑战在于数据库系统，因为数据库系统自身是有状态的，所以合理地切分数据并提供正确的事务机制将是一个非常复杂的工程。不过，在云原生时代，云平台所提供的云原生数据库服务可以解决大部分复杂的分布式系统问题，因此，如果企业是通过云平台提供的能力来构建弹性系统，自然就会拥有数据库系统的弹性能力。

（3）自动化部署

系统突发流量通常无法预计，因此常用的解决方案是，通过人工扩容系统的方式，使系统具备支持更大规模用户访问的能力。在完成架构拆分之后，弹性系统还需要具备自动化部署能力，以便根据既定的规则或者外部流量突发信号触发系统的自动化扩容功能，满足系统对于缩短突发流量影响时长的及时性要求，同时在峰值时段结束后自动缩容系统，降低系统运行的资源占用成本。

（4）支持服务降级

弹性系统需要提前设计异常应对方案，比如，对服务进行分级治理，在弹性机制失效、弹性资源不足或者流量峰值超出预期等异常情况下，系统架构需要具备服务降级的能力，通过降低部分非关键服务的质量，或者关闭部分增强功能来让出资源，并扩容重要功能对应的服务容量，以确保产品的主要功能不受影响。

国内外已有很多成功构建大规模弹性系统的实践案例，其中最具代表性的是阿里巴巴一年一度的“双11”大促活动。为了应对相较于平时上百倍的流量峰值，阿里巴巴每年从阿里云采买弹性资源部署自己的应用，并在“双11”活动之后释放这一批资源，按需付费，从而大幅降低大促活动的资源成本。另一个例子是新浪微博的弹性架构，在社会热点事件发生时，新浪微博通过弹性系统将应用容器扩容到阿里云，以应对热点事件导致的大量搜索和转发请求。系统通过分钟级的按需扩容响应能力，大幅降低了热搜所产生的资源成本。

随着云原生技术的发展，FaaS、Serverless等技术生态逐步成熟，构建大规模弹性系统的难度逐步降低。当企业以FaaS、Serverless等技术理念作为系统架构的设计原则时，系统就具备了弹性伸缩的能力，企业也就无须额外为“维护弹性系统自身”付出成本。