透过现象看本质企业软件行业中会大量出现流行语。而许多情况下，这些流行语极大地丰富了用于描述如何解决不断涌现的业务问题的词汇库。如果没有这种词汇扩充，许多这些概念将难以普及开来。在不断丰富词汇库、扩展概念的过程中，我们会用到弹性这个术语来描述企业解决方案。
人们经常会陷入这样一个误区，就是经常会使用弹性这个词来描述特定解决方案的设定目标。从最简单的形式来说，弹性的解决方案可允许添加或删除资源，而不会让系统离线。为了创建更高以及更加实用的标准，我希望提出一种更加远大的定义目标。
系统或系统组件中的弹性（我将以软件为例，因为我每天都与 IBM WebSphere eXtreme Scale 打交道）暗示三种特定的自由程度：
现在，在您将这些词汇标榜为空白概念之前，让我来揭示一下它们的实质。
没有限制的伸缩性弹性系统可以随意伸缩，而不会在操作过程中对系统的可用性造成显著影响，这一点不应引起太大的争议。但是，我相信我们还应该期望系统本身不会对合理伸缩场景造成任何限制。我想借此表明，在建立基础设施时应该为系统的持续扩展打下基础，并支持在小开销或无开销下提供新的资源。这意味着线性伸缩的可能。
我们已经解决了 WebSphere eXtreme Scale 中的弹性问题，考虑到了特大网络对产品各个方面的影响。一些示例可以证明：
- 首先，网格成员身份基础架构本身可以转化为较小的可分解的、可包含的伸缩问题。目录服务（处理网格基础架构的管理进程）并未将数以千计的服务器分到一个核心分组中，而是将所有成员归类为 20 个分组。然后，这些单独的分组运行成员身份视图算法（涉及心跳），这包括一个可靠的跟踪记录以及与 IBM WebSphere Application Server 共享功能。选定的分组 “领导者” 将及时更新目录服务中的分组状态，而后只需要与网格中 1/20 的成员保持联系。
- 另一个例子是与网格本身的客户机交互。一个经常出现的问题是单一管理进程的瓶颈，比如目录服务。目录服务可以重复，也可以采用集群方式，但这只会造成冗余。事实是，单一目录服务实际上可以满足几乎任何数量的客户机的需求，因为与目录服务交互的客户机只需要在网格中引导一次。在这种交互过程中，目录服务会返回关于网格的信息，包括完整的路由图（定义所有网格分区的位置）和各自的相关密钥空间。然后，客户机与分区直接交互，并通过普通事务过程中的子通道交互及时更新这个路由表。然后，目录服务可以专注于管理添加和删除资源时网格的平衡性和成员身份。
通过这些方法，我们可以有效地将网格扩展到任意大小。在实验室中，我们实现了一个包含 1500 个容器的网格，而在性能上并没有感受到明显的影响。然后，我们持续长时间运行，但这种伸缩并没有特定或合理的限制。这是在真正考虑弹性解决方案时的一个重要因素。
非常重要的一点是，需要知道这并不意味着每一个弹性的基础架构部署都可以在添加资源时为整个应用程序提供线性伸缩。仍然需要考虑基础架构中构建的逻辑和业务，以及它们是否采用了可伸缩的极限事务处理基础。在这一点上，企业应用程序本身还必须具备弹性的特质。但是，弹性的基础架构应该为有效实现这些目标提供一些途径。
容错性和自我恢复如果您希望部署者相信您的解决方案可以无限伸缩，则还必须能够容忍系统扩展时发生的一些事件，比如由于维护或故障而添加或删除节点、网络故障和变量，等等。由于资源越多越容易造成故障，并且弹性系统必须能够以可预测且有效的方式来克服这些问题，同时可尽可能回到容错的状态。
继续以我们的 WebSphere eXtreme Scale 数据网格为例，将网格扩展到数千计容器进程之后，丢失或维护其中某个进程的几率就越大。通过复制（它是 WebSphere eXtreme Scale 以及类似驻内存数据网格产品的核心竞争力），这些事件将具有容忍性。不仅如此，由于数据的迁移过程完全在 WebSphere eXtreme Scale 客户机 API 的 “黑盒” 中完成，还会自动创建一个新的副本，从而再次确保容错性。
弹性需要具备这种概念上的补充，以便能够在部署扩展过程中真正发挥作用。
管理简单性在考虑弹性基础架构的含义时，对系统管理及维护的专门需求有时会很低。但是，与系统扩展时对容错的需求相类似，您还必须考虑部署者执行常见管理任务的能力。
此处的关键概念在于，各节点的配置和维护应该要么类似，要么将差异降至最低。应该让部署者提供系统运行所需的所有成员机器及进程的列表。根据配置工件的公共集，应该能实现一定程度的自动发现和管理。
就 WebSphere eXtreme Scale 而言，它在这方面的方法相当简单和直观。配置信息专注于网格本身的结构和特性，而不是关于特定成员进程的任何详细信息。举例来说，您可以配置将数据划分到多少个分区中，以及如何复制这些分区。考虑到这方面的信息，WebSphere eXtreme Scale 可以将它们映射到可用网格成员并执行配置中设置的策略。在各网格成员启动时，它们将接收到相同的配置工件，并且关于网格中各成员的详细信息将自动管理和判定。
管理和维护将采用这种原理，并通过交互将物理网格的详细信息与网络结构分开。
我们可以找到更多这方面的例子，比如通过使用 zone 抽象（或者升级实际网格代码层次，而不让网格离线的能力）来解耦复制。关键概念在于，当系统向外扩展时，管理任务应该保持其复杂性不变，或者至少尽可能不变。这样，您可以看到弹性软件和弹性硬件（也就是虚拟化和云部署）可以相辅相成，共同为企业解决方案提供更高层次的自由度。
赞扬流行语可以毫不诲言地说，即使计算领域中最普及的基础技术也是从某种形式的流行语发展起来的。我们只需要在向词汇表添加新概念或目标设定时努力定义其含义和用途就可以了。通过这种方式，我认为非常显而易见的是，当明确的定义和思想发展成逻辑结论之后，企业解决方案中的弹性是一个非常宝贵的概念。我们在讨论 WebSphere eXtreme Scale 作为弹性数据网格的性质时，始终在尝试使用具体的、有用的含义，并且在将这些概念应用于其他旨在创建真正灵活的基础架构的解决方案时将继续采用这种方式。 |
