每当我们讨论面向服务架构（SOA）的价值时，总要提出灵活性这个问题。多年来困扰IT行业的头等问题都是围绕如何处理变化莫测的变化的。因此，不难理解，为什么企业架构（EA）都把目光集中到了变化这个问题上——灵活性是其在设计中需要考虑的头等要素。但是，我们在前面的ZapFlash也提到过，依靠对单个服务的关注，很难设计出灵活性。并且，灵活性也是IT复杂系统迫切需要的特性。

　　因此，开发商、基础设计师以及基础设施实施者无法保证操作基本层面灵活性，他们还能保证些什么呢？在复杂的IT系统中，灵活性至关重要，但是，在设计SOA的讨论中有一个概念经常被人们忽略到了。这就是Resilience。

　　什么是Resilience？当一个实体遭遇变化时，这个实体能够从变化中吸取能量，并且能够及时从变化反弹回原有状态。实际上Resilience是一种“自我修复倾向”，当系统遭遇重大变化时，这种倾向可以让系统保持全局结构，而不会长期被变化所影响。如果我们一开始希望启用SOA预期的松耦合变化，那么我们创建的服务，实施的基础设施，塑造的流程，以及启用的系统都会有某种程度的Resilience。

　　Resilience与灵活性有什么联系？

　　从多方面来说，Resilience和灵活性这两个概念都有相似之处。Resilience和灵活性都以各自不同的形式应对IT系统发生的变化，但是二者还是有明显的差别。因此，我们设计师、工程师在设计自己的复杂系统时对二者也要区别对待。要想理解二者的不同之处，一种方法是对比较Resilience和适应性这两个概念进行比较。我们经常用适应性这个词描述灵活性的预期效益。如果一个系统能伸能屈，满足新的需求，一旦事物发生变化我们就不用反复设计了。

　　但是，Resilience和适应性二者是截然不同的。理解它们之间差别的最好方式就是，这两个词的反义词。刚度通常被人们称为“强度”，同时也是适应性的反义词，它暗示意义是，对事物变化的无能为力，抑或是抗拒。但是，Resilience的反义词是脆性，它指的是当实施某种力量时，既定实体会中断乃至崩溃。但是适应性和复原性之间肯定是有联系的。因为适应性强的事物往往对外力的忍耐力也很强，但是适应性强的系统也可能是脆弱的系统。有些事物具有适应性但是并不具有Resilience。许多系统都可以被改变但是永远复发恢复原来的状态。但是，如果情况总是这样的话，最初的意志会被曲解，实际上你需要的是Resilience和灵活性，而不仅仅是适应力和强度。更有甚者，建设强度比建设适应性要更容易些。从整体着眼，我们一般会觉得把系统建得越强大，越坚固越厚重越好，这样就可以适应更多的变化。但是谁愿意又能承受得了无法避免的变化呢？难道你不想利用变化吗？

　　一种观点认为，当系统发生的变化超出了它们的“弹性极限”时，就会变得异常脆弱。从这个观点来看，稳固的系统往往弹性极限都较低，并且非常脆弱。相反，适应性强的系统弹性极限也比较高，并且可以反弹到一个点。反弹性是由可变性来衡量的。因此，在设计之初，可变性这个要素应该给予充分的重视，同时还要思考一个问题，那就是我们预想的变化程度究竟有多大，当变化发生时会有多大的影响。此时你可能会认为在一个不断发生变化的系统中，刚性提供的Resilience既无法提供适应性也不能提供灵活性。从这一点来说，我们可以把系统中所计划的Resilience看作是可变性，把非计划的Resilience看作是灵活性。

　　通过设计可变性而达到测量适应性的目的，对于大家来说，这一点可能并不陌生。我们在介绍灵活性模型这个概念时，曾经讨论过这个话题。灵活性模型为设计师提供了三个重要的方法：在充分考虑到它们的可变性时，为其提供设计服务和流程的方法，业务用户可以通过此种方式表达他们的需求，同时也为测量开发系统和服务提供了一种方法。可变性提供了适应性，同时也提供了测量Resilience的一种方式，并且也提供了灵活性，这种重要的系统特征。特别是，设计灵活性需要你从长远出发，透过某个服务设计的具体层面，充分考虑服务的可变性。那么未来会发生哪些变化呢？设计这样的可变性成本收益究竟如何呢，而不是只考虑其不可适应性。

　　在现实生活中，Resilience要更加复杂。设计师可以通过一种或者是两种方式通过Resilience：一种是创建一个足够坚固的系统来抵抗变化，一种是创建一个灵活性极强的系统来减弱变化的影响，不必长期改变系统。我们经常通过一些重要的机制来解决Resilience问题：冗余度、分布、故障切换以及负荷平衡，分组以及一个强制的非单一故障点。如果将这一点铭记于心，即便有时一个服务发生故障，也不会影响到其适应性。我们不能指望系统为我们提供这样的Resilience。通过一个单一的故障点、系统管理软件、ESBs以及其它的基础设施会导致整个系统更为脆弱。如果服务本身运转情况良好，而SOA管理系统停止运转，这时该怎么办呢？我们不能依靠基础设施解决架构Resilience问题。应该在架构中设计Resilience，而不必考虑目前使用中的技术。