构建并维护弹性应用程序和基础架构的7个最佳实践

应用程序和网站不可用时，收入和声誉将遭殃。但是我们对数字系统的日益依赖将弹性的定义扩展到了故障和服务中断之外，还包括性能和应用程序交付——这些同样重要。如今，最终用户要求他们使用的应用程序和服务能迅即响应。连延迟数秒都嫌太久。

希望构建并维护弹性应用程序和基础架构的企业应考虑这七个建议。

基础架构多样化

虽然一些人可能忍不住想“全力”支持某个云或CDN提供商，但如果该提供商宕机或遇到其他性能问题，这种做法会导致代价高昂的停运。使用两家或多家供应商实现基础架构多样化的公司可以使内容和处理更接近用户，从而大幅缩短延迟。如果一家提供商遇到网络拥塞、地理限制、资源可用性或其他问题引起的问题，自动故障切换系统可以确保对用户的影响最小。

考虑实施微服务

微服务和容器等新技术的出现确保了弹性对于应用程序开发者来说最重要。由于企业从物理数据中心中运行的整体式应用程序改为广泛分布的微服务和单个应用程序，它们须尽早解决这些系统彼此如何交互的问题。而冗余性是在微服务的设计阶段内置的。这就是为什么已经在进行数字化转型或竭力升级系统的企业应考虑采用微服务方法。

随着组织发展壮大，它们会看到系统的不同部分更早面临压力。微服务和整体式应用程序使组织能够独立扩展那些特定组件。使用微服务时，由于系统的某些组件，组织可能会看到局部故障，但整体故障很罕见。

将冗余性做入到代码库中

企业可以通过将冗余性做入到代码中，从软件开发的角度做好弹性。一家全球流媒体提供商就使用该方法，如果其中一家云提供商出故障，可以激活自行开发的系统，以保持在线状态。电子商务公司常常采用类似的策略;对这类公司而言，即使停运几分钟，也可能导致利润严重损失。Gremlin的混沌工程专家估计，亚马逊停运10分钟将使这家电子商务巨头损失200万美元的收入。因而，许多电子商务公司常常以这种方式编写代码：应用程序在数据中心中运行，作为备用/冗余策略的一部分。购物车应用程序在这种环境下运行起来可能较慢，但速度慢的购物车总比没有购物车好。

将混沌工程引入实践

混沌工程是指有意引入问题以识别系统故障点的做法，已成为交付高性能弹性企业应用程序的一个重要部分。有意将“混沌”引入到受控的生产环境中可以暴露系统的弱点，并使工程团队能够更好地预测并主动缓解问题，以免造成重大的业务影响。进行计划中的混沌工程试验可以提供企业在系统弹性方面进行战略性投入所需要的信息。

调整流量路由策略

公司可以尽量减小停运和延迟的风险，只需实施流量路由策略，将有关网络情况和资源可用性的实时数据与真实的用户测量数据结合起来。这使IT团队能够部署新的基础架构，管理资源的使用，以规避问题或解决意外的流量高峰。比如说，企业可以结合流量引导功能，确保始终将用户引导到拥有足够容量的附近节点。因而，保护用户免受故障和局部网络事件的影响，否则这些事件会扰乱业务运营。流量引导还可以快速启动新的云实例，在互联网长期速度缓慢或无法预测的战略性地理位置增加容量。另外，团队可以设置控制措施，以便在流量激增期间将流量引到低成本资源，或者在持续大量使用期间以经济有效的方式让资源在工作负载之间得到均衡使用。

定义SLA并持续监测系统性能

企业应监测其应用程序和系统，事先防范性能波动、故障或其他问题。监测应用程序每个部分的运行状况和响应时间是系统弹性的一个关键方面。比如说，衡量应用程序的API调用所花的时间或核心数据库的响应时间，可以早早表明即将发生的情况，并使IT团队可以事先防范这些障碍。该方法还包括为不同的子应用程序和系统创建服务级别协议(SLA)，然后监测那些 SLA，确保合规。

从新的系统和应用程序入手

希望为IT堆栈添加弹性的企业应该在实施对业务影响不大的新应用程序或服务时开始入手。虽然一些企业可能忍不住先为核心服务或应用程序添加弹性，但万一出了岔子，这种做法会导致代价高昂的、破坏性更大的停运。IT员工可以先学习做好新系统的弹性。也许组织在启动一个新的支持门户网站。针对该服务测试确保弹性的新方法风险较低，允许出现一些小问题。以后，IT团队可以将经验运用到其他关键业务系统和服务。