当我们谈论应用程序及其在生产中的部署时，我们经常将可靠性视为非功能性需求。当我们说“可靠”时，我们真正想要的应用程序及其部署是什么？

通常，我们的意思是我们希望应用程序执行预期的操作并在没有故障和中断的情况下运行。对于许多人来说，这意味着它必须是稳定的（对代码的要求）和可用的（部署要求）。因此，您可以进行大量测试和QA以获得稳定的“无错误”应用程序。然后，您可以从具有高SLA的云或其他基础架构提供商那里获得服务器，例如“五个9”。但是应用程序现在真的可靠吗？实际上可靠吗？这是在2015年构建和部署高度复杂和可扩展的应用程序的正确方法吗？

 

 

也许......如果不是墨菲定律（“如果有什么事情可以出错，它会”）。一方面，只要我们受到共同的时间和预算限制，我们就有一个很难“无bug”的应用程序。总有一些你没有预见到的东西，你没有测试过。现在常见的分布式系统和基于技术的创新必须快速发展，这一点变得更加糟糕。另一方面，我们有服务器（硬件和软件加网络和存储），永远无法保证100％的可用性。当然，我们可以尝试在问题上投入更多资金，但我们永远不会达到100％，那么为什么不采取不同的路线呢？为什么不构建弹性部署的弹性应用程序？

弹性定义

首先，什么是弹性？根据您的要求以及使用的背景，有几种定义。让我们来看看它们中的一些并了解它对我们意味着什么：

弹性（elasticity）

弯曲，压缩或拉伸后返回原始形状，位置等的能力或能力;。

韧性 （toughness）

（http://dictionary.reference.com/browse/resilience）从困难中迅速恢复的能力;。

（https://www.google.de/webhp?q=resilience%20definition）[系统]应对变化的能力。 （http://en.wikipedia.org/wiki/Resilience）

第一个定义告诉我们这个术语的一般背景。以下文学描述非常合适：

“橡树在风中挣扎而且被打破了，柳树在它必须的时候弯曲并幸免于难。” - 罗伯特乔丹

因此，弹性系统应该能够弹性地应对问题并且不能防止失效，这在某些程度上是不够的并且导致破裂。

第二个是更明确地说明系统（或者如果在心理环境中使用的人）的快速恢复。如上所述，您可以随时减少故障，但永远不会100％无故障。因此，你需要在从失败中恢复过程中尽可能好，这与我们的第一个定义中的弹性图像相辅相成。

第三个定义来自供应链背景，更多的是关于保持系统运行。适应更一般的背景，系统应该能够应对变化以及轻微或重大的中断。

应用程序开发和部署的弹性

现在让我们将这些概念带入应用程序开发和部署领域，看看哪些模式和工具可以帮助我们实现目标。 （注意：我们不会在安全上下文中使用弹性软件，这本身就是一个完全不同的主题）。回顾我们的背景，一方面我们有一个复杂的应用程序，必须根据市场的动态变化进行迭代和调整。为了保持竞争力，必须通过测试和快速投入生产 - 最好甚至连续。另一方面，我们已经部署了所述应用程序，其中必须将其部署到生产环境（以及之前的测试/暂存）环境，通过动态的用户/使用量大量增加和扩展，并保持高可用性在众多场景中。

使用微服务进行弹性应用程序开发

在应用程序方面，工程师和组织正在寻求微服务架构更灵活，并构建更好的应用程序。在微服务架构中，应用程序分为高度分离的，简单的分布式服务，这些服务通过轻量级通信机制（如消息队列和HTTP API）相互通信。

微服务是高度分离的，并且是为失败而构建的（注意：这并不意味着您不应该进行备份），因此它们能够应对故障和中断。这种简单的小型服务的隔离使它们彼此独立，因此当一个失败时，其他人不会停止工作。它们是明确构建的，以期望失败（在服务本身以及其他服务中的失败）。

通过这种分离，我们实际上可以在我们的应用程序中获得很大的弹性。他们有能力应对变化和破坏。所有这一切，同时保持开发过程中的敏捷性和速度。然而，弹性和恢复部分的弹性仍然需要不仅仅是移动到开发中的微服务架构来实现。

在群集基础结构上使用容器进行弹性部署

弹性和恢复虽然部分必须内置到服务中，但更多的是部署，管理和扩展所述微服务系统的工作 - 并且不要忘记保持高可用性。这就是容器和集群基础架构发挥作用的地方。

通过容器化，我们获得了一种简单的技术，可将我们的微服务打包成持久可部署的单元。由于这些容器可以在各种环境中运行，因此开发人员不必处理开发，升级和生产方面的差异。

但是，现在遇到了困难的部分：这些容器需要在生产中进行部署，管理和扩展。请记住，我们希望具有弹性，即弹性和恢复能力。理想情况下，我们不希望出现任何单点故障。理想情况下，我们希望在集群基础架构上运行，从而抽象出底层硬件并为我们带来冗余。此外，我们必须在服务之间使用负载平衡器和断路器，以使我们能够水平地上下弹性扩展。

扩展和冗余有助于我们在发生故障时不会完全中断。但是，要真正具有弹性，我们需要能够应对故障并恢复到应用程序的预期/原始状态。此外，当应用程序的某些部分出现故障时，它们必须再次出现。但是，其余服务必须知道如何才能达到新服务。这可以通过从容器中取出配置并仅在运行时注入它来解决。此过程导致容器被配置服务（理想情况下也在容器中运行）包围，这有助于它们在相应的环境中运行并找到它们的对等体。当这些容器连在一起使得它们没有完全断裂，而是下降并且优雅地一起上升时，我们得到一种弹性意义上的弹性部署。它确保服务从外部返回到看起来像原始状态的状态（即使例如底层服务器已更改）。

现实生活中的复原力很难

获得应用程序的弹性是可能的，像Netflix，Twitter，Facebook和其他公司正在展示自己的方式。他们与公众共享的一些发展，其中一些甚至专门针对工程弹性。他们用例如工具严格测试他们自己的系统。 Simian军甚至可以关闭整个数据中心以测试弹性。然而，即使这些具有高级弹性架构的公司也无法完全防止停机。

即使拥有所有这些工具，如果您是一家开发人员少于100人的公司，也不容易构建弹性系统。两者，开始使用微服务架构以及所述微服务的弹性部署都很困难。在Giant Swarm，我们尝试用两者来帮助我们的用户。首先，我们尝试为他们提供构建他们自己的微服务架构所需的工具，同时确保如果他们想要使用他们认为更好的其他工具，我们给他们自由使用他们喜欢的任何东西。其次，我们为用户提供微服务基础架构，使其易于部署和管理应用程序。到底

弹性就是能够克服意外情况。可持续性就是生存。恢复力的目标是茁壮成长。 -  Jamais Cascio

弹性应用程序为您提供的不仅仅是可靠性，它们可以帮助您构建持续的创新流程，从而快速实现目标并保持领先地位。它们可以帮助你茁壮成长。