不要立即检查刚做过的事情，也不要立即读刚写过的数据。绝对不要为了验证而立即读刚写过的数据。为了近期内的运维需要，可以把数据存储在本地或分布式的缓存中。验证工作相对于不太可能出现的故障来说成本更高。这种活动有悖于有效扩展的需求。...

利用应用的日志文件诊断问题并防止问题出现。落实监控日志文件的流程，强制人们对发现的问题采取措施。利用各种监控工具，如定制的脚本或者Splunk，观察应用的日志，找出错误。导出这些错误，指派人员识别并解决相关的问题。 ...

只有当防火墙能够显著减少风险，并且你能认识到它们会引发扩展性和可用性问题时，才使用防火墙。适用情形:无论何时都适用。只对遵从PI和PCI等法规的重要数据采用防火墙。对价值低的静态数据，不要采用防火墙。防火墙会降低可用性，造成不必要的护展瓶颈。虽然防火墙很有用，但它们通常会被滥用，如果设计或实施不当，可用性和扩展性都会受影响。...

当你需要ACID属性来维护数据间的关系时，可以用关系型数据库。对于其他的数据存储，需要考虑更合适的工具。适用于在系统架构中引入新数据或数据结构时。在选择最合适的存储工具时，要考虑数据量、存储空间响应时间的要求、关系以及其他多种因素。...

有目的地利用云技术应对突发的扩展。临时的、激增的或者间歌性的需求，或者产品响应时间并非关键因素的情况。对于临时需求，如大型的批量作业或者测试阶段所需的QA环境，可以利用第三方的云环境；设计应用，使其能够在需求激增到一定水平时接受来自第三方云设备的请求。...

设计具有三个或更多实时数据中心的系统，以减少整体成本提高可用性以及实现灾难恢复。适用于任何考虑加入一个灾难恢复(冷备份)数据中心的超高速发展的公司。采用“多个实时数据中心”的配置，拆分你的数据，分散到这些数据中心，把事务负载也分散到这些数据中心。利用多余的容量来应对每年的高峰期。...

尽可能米用小的、便宜的系统。在超高速发展阶段，在生产环境中采用该方法。应用方式:在生产环境中不要采用非常大的系统。允许低成本的快速发展。采用经济型硬件构建系统，不要让自己陷入高利润、高端服务器的陷阱。 ...

所谓横向扩展，就是通过复制服务或数据库来分散事务负载，而纵向扩展即购买更大的硬件。前者可以替代后者。适用于任何预计会快速增长的系统、服务和数据库。利用AKF扩展立方确定环境的正确拆分方法。通常，横向拆分(克隆)是最简单的方法。...

通常可以利用客户特有的属性进行拆分，如客户ID、姓名、所在地等。非常大的相似数据集合，如快速增长的大型客户群。标识你所知道的客户属性，如客户ID、姓、所在地或设备，根据这些属性拆分数据和服务。...

有时该原则被称为通过服务或资源进行扩展，重点是扩展数据集合、事务和程序员小组。非常大的数据集合，数据间关系并不重要口大型的复杂系统，需要特别扩展编程资源。...