规则二 方案中包括扩展
内容:提供及时可扩展性的DID方法
场景:所有项目通用,是保证可扩展性的最经济有效的方法(资源和时间)
- Design(D)设计20倍的容量[这里的容量是指:压力容量等]
- Implement(I)实施3倍的容量
- Deploy(D)部署1.5倍的容量
原因:DID为产品扩展提供了经济、有效、及时的方法
要点:在早期考虑可扩展性可以帮助团队节省时间和金钱。在需求发生大约一个月前实施(写代码),在客户蜂拥而至的几天前部署
这个规则是最不清晰的一个规则，但是，他的意思很明确：要在设计，实施，部署的时候，都要提供可扩展的部分，每个阶段的部分有所不同！在设计的时候，就要考虑到，要对需求有20倍的容量的扩展！也就是设计上是可以允许有这么大的扩展空间的，在实施上，是要实施需求的3倍的容量的【实施了3倍，并不代表以后不会在扩展，以后还可以继续实施的】
我们的每个设计都应该是基于一套定义和指导设计的架构原则和标准
设计(D, Design)
讨论和设计很明显要比我们在代码中具体实现该设计成本更低，鉴于成本相对低,我们可以未雨绸缪讨论和草拟好如何扩展平台的设计。
例如,我们显然不想部署比现在的生产环境需要高10倍、20倍甚至100倍的容量。但是,讨论和决定如何扩展到这些维度的成本相对来说比较低，因为设计是智力活动，我们完全有可能在设计的时候，就将其设计成可以扩展的！
然后,在DID方法的D(设计)阶段聚焦在扩展到20倍和无限大之间。因为聘请“思想家”来思考“大问题”,所以我们的智力成本很高，然而,由于我们不编写代码或部署昂贵的系统,所以技术和资产成本较低。
通过召集可扩展性大会,把领导者和工程师团队聚集在一起,共同有讨论产品的扩展瓶颈,这是在DID设计阶段发现和确定需要扩展部分的一个好办法
实施(I,Implement)
随着时间的推移,我们逐步接近对未来扩展预想的需求，于是开始编写软件实现设计。
我们把规模需求的范围缩小到更接近现实,例如当前规模的3~20倍。“规模”在这里指被视为扩展最瓶颈的系统组件,这部分最需要亟待解决以实现业务目标。
可能有些情况下,把当前的规模扩大100倍或更多倍的成本与扩大2倍没有区别。假设如此,也许我们可以一次完成所需要的改变非反复折腾。
但是，有些成本确实是跟数据量的大小有关的话，我们就必须要悠着来，不要一次实现过大的容量，因为，那样会带来很多的技术成本和人力资源！
我们在每个阶段，只需要20倍的容量实现就好了，这样的话，足以应对意外情况，也不会有太高的技术成本和经济损失！
部署(D, Deploy)
DID的最后阶段是部署(D)。
当你的程序可以实现扩展的时候，你一点要在部署的时候，悠着来！
该阶段的总成本往往是最高的,部署相当于现有规模100倍的系统容量将会使许多公司破产
记住,扩展具有弹性,它既可以扩张也可以收缩,我们的解决方案应该认识到这两个方面因此,灵
活性是关键,因为你需要响应客户的请求,随着规模的收缩张,在系统之间调整容量
这个阶段是真金白银的阶段，最好的部署就是：刚刚够用！最好的部署就是：可以灵活扩展，应对压力
你需要响应客户的请求,随着规模的收缩张,在系统之间调整容量。
在基础设施即服务(IaS)的环境下,我们没有必要在需求到来前购买容量,在系统接近所需和接近实时的情况下,可以在部署阶段很容易地把计算资产“旋转”起来，自动扩容即可，这就是虚拟硬件，云资源的好处，大大的降低了成本，提高了灵活度
对可扩展性的设计和思考的成本相对低,因此应该经常进行。理想情况下,这些活动会产生某些书面文件,可以作为基础文档在需要时快速参考。架构或设计解决方案的整体成本更高,可以留在日后处理,而且实际上也没必要在生产中实现
