需要拆分主数据库的扩展项目，就像一个开发功能的项目一样，也需要平衡这四个约束因素。你会把自已大部分的高级工程师从开发功能的项目中抽调出来，从事拆分数据库的项目吗?你会给自己的团队6个月或18个月时间来完成这个项目吗?你会加人内置的功能，从而在必要的时候进一步拆分数据库吗?你会缩短项目，只进行一一次拆分吗?这些都是你在项目过程中需要提出的问题，也是为了平衡项目三角中的速度、成本、质量和范围而提出的问题。
这些约束因素还会间接地影响可扩展性。让我们以AllScale公司的付款功能为例，它的侧重点在于速度。这个功能必须在月底之前发布，这样才能供月底的结算周期使用。错过了这个日期，就会造成需要手工处理付款，这样会引人更多错误，从而导致拒付和收人损失。软件开发团队的VP麦克，索福特从另一个项目上抽调了三位高级工程师，把他们分配到这个付款项目上，以便能够按时完成它。一切都进展得很顺利，在月底之前的那个周末，这个功能就被发布了，这样就能够根据计划处理账单。
6个月后，AllScale公 司的HRM站点存储的内容的增加量超过了100%，而参与月底结算周期的用户数量增加的百分比更大，他们在结算功能上产生的负载总量接近这个功能发布初期的负载总量的150%。迄今为止，它的处理时间仍然控制在12小时之内。但这个月的用户增长使它发生了明显的变化，处理时间一跃达到了38小时。由于这个服务被设计为单一应用的附加功能， 所以不能在多个服务器上运行。直到现在，这个6个月之前所做决策的后果才逐渐显现出来。AllScale公司的运营团队必须给这个应用分配一个更大的服务器才能完成下个月的结算工作，而这个服务器原本是计划用作数据库服务器的。当然，这也会对硬件预算产生不好的影响。运营团队还需要花费大量的时间为这次迁移进行服务器的监控、准备、配置和测试。此外，这个项目可能还会引人软件开发工程师和质量保证工程师，以对变更提出建议，并最后验证该应用能够在新服务器上运行。由于这个置换新硬件的项目对用户而言的高风险，它必须在维护的时间窗内进行，同时它也用去了这一周系统允许的风险的大部分。另外的数据库拆分的项目则必须推迟了，因为需要订购新的硬件才行了，这样增加了数据库过载而造成问题的风险。
从我们的例子中你会发现，最初的网站制作功能开发阶段所做的决策会给整个系统的可扩展性带来许多未知的影响。这是否意味着当初的权衡和决策是错误的呢?不，事实上，即使有后见之明，你仍然会觉得迅速地把这个功能投人到生产环境中，是个正确的决定。对于这个场景，我们大概同意这种看法。从这个例子中我们学到的重要点， 不是个决策是对还是错， 而是对于一个决策会造成长期和短期的后果，你可能不能完全了解。
本文地址：//www.gogoparty.cc//article/3862.html
