如何实现弹性架构

为了管理大规模的系统，你必须把系统推向强度极限，但仍然有能力在故障中恢复，并且拥抱失败，Adrian Hornsby 写了两篇博客，分享了自己在大规模系统工作中十多年的经验，以及他发现的有用的模式。

Hornsby是AWS的技术专员，他指出，对于较小的系统，最多几十个实例，完全运行模式通常是正常状态，很少出现故障。在大规模系统中实现这一点几乎是不可能的;相反，部分失败是常态，他指出，对于大多数web应用程序来说，这并不是一个大问题，尽管这当然会影响收入。为了应对这一点，他的建议是在弹性成本和可能的收入损失之间找到一个很好的平衡。

Hornsby描述了几种他认为有助于构建弹性体系结构的模式，但他强调弹性不仅仅与软件有关。基础设施层、网络和应用程序设计以及人员和文化也很重要。

冗余

对于Hornsby来说，在云中部署应用程序时最重要的事就是冗余了，通过部署多个实例(可能在不同的区域或地区)来增加可用性。

自动伸缩

Hornsby的下一步是根据需求自动调整应用程序的容量，这是目前常见的机制。不同的自动缩放技术以不同的速度运作，因此，选择一种适合应用程序需求的非常重要。他还指出，由于容器平台和功能的存在，如今的扩展速度要快得多。

基础设施即代码

在使用基础架构即代码时，可重复性是一个重要的收益点，他比较了使用一个模版针对多套环境手工配置数据中心的工作和多次自动执行模板的工作。

如果，环境遭到某种方式的破坏，甚至被删除时，您可以从备份中恢复所有数据，并使用模板重新构建所有内容。这比手工完成这些工作要快得多，风险也小得多。

Hornsby还将基础架构即代码视为知识共享。团队可以像处理其他代码一样对待这类代码，也可以使用拉请求来验证更改。

不可变的基础设施

不可变的基础设施意味着对于每次部署来说，所有组件都是可替换的，不做任何更新，Hornsby notes提到两条基于不可变服务器模式的规则:

• 不应该在实时系统上进行任何更新。
• 必须始终从供应资源的新实例开始着手。

在处理不可变的基础设施时，Hornsby建议使用金丝雀部署，以减少部署新版本应用程序时出现故障的风险。使用这种技术，您可以在真实的生产环境中进行测试，并在需要时进行非常快速的回滚。

无状态应用程序

为了能够使用自动伸缩和不可变的基础设施，应用程序必须是无状态的。这意味着所有请求都必须独立于先前的请求或会话处理，不能将任何信息存储在本地磁盘或内存中。在自动缩放组中共享状态只能使用内存对象缓存系统，比如Memcached或类似的产品。

避免级联故障

按照Hornby的经验，导致停机的一个常见原因是级联故障，在这种情况下，通过不同类型的依赖关系发生的局部故障有时会导致整个系统崩溃。一个常见的例子是过载，例如当一个集群宕机时，所有的流量都转移到另一个集群。为了避免这些类型的失败，他推荐了一些模式，包括：

• 超时。数据库速度减慢时，如果仍有相同数量的传入流量可能很快使系统失败。超时的速度越快，可能意味着服务的质量下降而不至于崩溃。
• 幂等操作。由于暂时的错误，客户端可能多次发送相同的请求，这可能导致错误。为了避免这种情况，Hornsby倾向于使用幂等请求，使这些请求可被反复处理而不会出现问题。
• 服务降级和回退。在处理高负载时，一种选择是提供要求较低的服务变体。比如说，返回通用的信息列表，而不是个性化的列表。
• 拒绝。自卫的最后一步是开始放弃请求，最好是先放弃不那么重要的请求。

Hornsby最后指出，在处理云中的大规模分布式系统时，间歇性错误是一种常态。可能很难一下子搞清楚如何及时响应这些错误，但他建议可以收集统计数据，并根据这些数据创建处理错误的阈值。最后，他强调了自动化的重要性。要得到弹性和可靠的应用程序，它们经过了充分测试过的部署并具有快速自旋时间，您必须尽可能地自动化。

查看英文原文：How to Achieve a Resilient Architecture