我们公司的重点是帮助客户实现他们的扩展性需求，也许你可以想到，经常会有客户这样问:“我们应该何时对可扩展性进行投资?”不必经过大脑的答复是应该在需要该解决方案的前一天投资(部署)如果你能够在需要扩展解决方案的前一天部署它，那么就会让投资行为“即时”发生，恰到好处，从而像 Dell/公司那样按需生产。这样做，会使你的公司效益和股东权益最大。
不过我们要面对的问题是，让投资和部署成为即时的是不可能的，即使可能，如果没有选对时机，也会带来很大的风险。退而求其次，部署扩展性方案的最好方法是 AKF Partners的设计一实现一部署(Design-implement-deploy)方法，即D- I -D方法。这三个阶段与我们认识事物的三个阶段一致，即针对问题思考和设计解决方案、构建或编写该解决方案、实际地安装或部署它。这种方法不提倡也不需要瀑布模型。
我们认为敏捷方法正是遵循的这个过程，体现了人的主观能动性。人们不会为还没有注意到的问题开发解决方案，而一个方案，如果还没有开发出来，也不可能被制造或发布出来。无论开发的方法是什么(敏捷模型、瀑布模型、混合模型等)，开发的任何东西都需要基于一套成体系的理论和标准，它们定义并指导着我们该做什么。
1.设计
首先要说的是，讨论和设计什么东西，比真正用代码实现这一设计的投人少得多。考虑到设计的成本较低，那么在实际需要之前，可以讨论并草拟出能够使平台具有高扩展性的设计。但是，显然我们并不想在生产环境中投人比实际需要多10倍、20倍或者100倍的容量，关于如何将容量扩展到这种水平的讨论相对来说成本小得多。那么，在D- I -D扩二展模型的设计(Design)阶段，重点就在于如何将平台的容量扩展到2倍以上，甚至到无穷大。我们的脑力成本是相当高的，因为需要雇佣“大思想家”来考虑“大问题”。但是编程成本和资产成本却是很低的，因为我们并没有编写代码，也没有部署系统。由小组的领导者和程序员参与的讨论扩展性问题的大会，能让人发现在D- I -D方法的设计阶段有哪些地方是必须扩展的。
2.实现
随着时间的流逝，我们所预见的对扩展性的需求就会临近，这日时就需要在软件中实现(Implement)我们的设计了。我们要根据实际需要，把扩展的范围缩小，例如扩展到当前大小的3-20倍。这里使用“大小”这个词，指的就是被认为是系统扩展的最大瓶颈，因此极需要进行可扩展性修改的元素。也许存在这样的情况，即把系统扩展到当前大小的100倍(或更高)所需的成本和扩展到20倍的成本一样，那么我们还不如一次完成这些修改，而不是分成多次来做。在X对用户需求进行模块化，把它们分布(或共享)到多(N)个系统和数据库中时，就可能发生这种情况。我们可以编写一个变量Cust MOD，随着时间变迁，可以把它配置为1(当前)到1000(5年后)。这种修改带来的编程(或实现现)成本不会随着N而变化，所以我们不如选择这种方法。这种修改，带来的是高编程成本、中等的脑力成本(在整个生命周期前期已经讨论过设计了)以及低资产成本，因为如果最初阶段我们只打算部署1倍或者2倍的模块，那么当前就没有必要部署100倍的系统。
3.部署
D-I-D方法的最后阶段是部署(Deployment)。仍然用上面介绍的模块化示例，我们想用即时方法部署系统，没有任何理由让资产闲置从而减少股东的收益。如果我们是一个较高速增长的公司，那么可以在生产环境中投入1.5倍的峰值容量。如果是个超高速增长的公司，则可以在生产环境中投人5倍的峰值容量。我们常常告诉客户，对于爆炸性的容量，要利用“云”，以免备用33%的资产去防范突然的客户活动增长。在部署阶段，需要高资产成本，而其他成本则属中低水平。这类情况的总体成本趋于最高，部署一个相当于需求的容量100倍的系统，会让很多公司倒闭。记住，扩展性是个灵活的概念，它可以是扩张，也可以是收缩，而我们的解决方案需要两方面都考虑到。因此，灵活性至关重要，你可能需要根据客户需求让解决方案中的不同系统进行扩张或者收缩。
虽然D-I-D方法的每个阶段都有不同的脑力、编程和资产成本，但整体成本却是基本一致的。关于扩展性的设计和思考成本相对较低，所以应该经常进行。这些活动最好形成文档，以便当有需求时，程序员就能迅速地根据文档编写代码。将设计好的解决方案编写(开发)成代码可以稍后再进行，开发的成本稍高，但是没必要在生产环境中真正实施它。我们可以像上面的模块化示例中所述的，修改少量代码，而无需再购买一个相当于现有容量100倍的系统。最后，采用这种方法，就可以只在有需求时再购买设备，可能是从主要网站建设的设备供应商那里提前6周购买，或者极其紧急的情况下，让系统管理员去当地的服务器商店采购。
本文地址：//www.xrqsnxx.com//article/3443.html
