最近，我在公司里遇到了一些批量处理方面的问题。因为需要处理的数据量在不断增长，结果出现了内存耗尽的问题使批量处理工作无法顺利地完成。研发工程师因此要求SRE的工程师扩大内存增加资源。这样的做法是否合理？实际上这是一个普遍存在的架构设计原则问题，具体描述就是随着客户和业务的快速发展和增长，对系统资源要求越来越多的时候，我们到底应该怎么办？
在理想的情况下，我们可以分析各种可能的选项，不是购买更大的服务器，就是投入研发资源使产品可以在多台服务器上运行。能够在所有的层级上，让产品运行在多个不同的服务器上的做法叫做向外扩展。不断地在更大的硬件上运行任何层级的系统，我们称之为向上扩展。在不同方案的分析过程中，我们可能会根据投资回报率（ROI）来决定去购买更大的服务器，而不是投入研发资源来修改应用，因为这么做的成本相对比较低，而且实现起来相对简单，特别是在今天云服务的现状下。虽然我们会认为决策分析的方法得到的决策比较好，但是，对于在动态的市场中快速增长的公司和产品来说，这样的决策有很大的缺失。以我们的经验，即便是对温和增长的公司，这样的决策也同样存在着问题。
在这样的决策分析中，最为常见的错误是未能分析底层硬件和基础设施的更新换代周期。把一台64位服务器的处理器从两个八核升级到四个八核，从成本比例上看与所获得到的计算资源提升一致。当我们继续购买更大的拥有更多处理器内核的服务器时，问题就会出现。因为成本与计算处理能力的曲线并非线性，较大服务器所带来的处理能力的增加与成本的增加并不成正比例。假设公司在不断地取得成功和成长，那么我们将继续沿着曲线购买更大的系统。虽然我们可能预测到技术更新的时间，但是最终将被迫在一个令人难以置信的高价位购买系统。相反，如果有水平扩展的架构，那么就可以通过购买相对便宜的系统来解决问题。最后，总体资本的支出会明显地增加。通过投入技术资源解决这个问题的成本，当然会随着代码规模和系统复杂度的增加而增加，但是这个成本应该是线性的。因此分析的结论应该是立即花时间修改代码以保障系统能随着业务的发展向外扩展。
通过某个大型服务器供应商所提供的在线定价和配置程序，我们用下图显示了七台服务器的成本，除了处理器及其内核越来越多外，服务器的其他配置（内存、磁盘等）都尽可能相近。不可否认，从计算资源的角度来看，虽然成本比较接近，但是两个四核处理器不完全等同于一个八核处理器。请注意图线呈指数而非线形的趋势。
根据我们多年的实践经验，这种决策分析的结论几乎总是修改代码或数据库，实现向外而非向上扩展。多种计算机技术的更新周期，要求企业对大型服务器反复不断地投入资本，从而使这个问题变得更加严重。这就是为什么向上扩展就是向上失败。向上扩展最终必然会停在某个点，要么是设备的成本太高无法负担，要么是没有更大的硬件可以供你购买。曾经有一个公司，他们有能力将其用户分散到不同的系统里，但是事实上却继续向上扩展其数据库硬件，结果他们最终止步于硬件供应商所提供的六个最大的服务器上。这些服务器系统的单价已经超过了300万美元，全部六台服务器的硬件总成本接近2000万美元。随着客户需求的增加，该客户在挣扎着继续向上扩展架构策略的同时，开展了一个数据库水平扩展的项目。他们采购了四台单价35万美元的较小服务器来替换那些大型服务器，结果不仅成功地向外扩展继续为客户服务，而且因此节省了近1000万美元的成本。该公司继续使用旧系统，直到最终过期报废，然后以成本较低的较小的系统完成替换。
大多数应用要么从一开始就可以在多个服务器上运行，要么可以很容易地修改以适应多服务器的情况。大多数的SaaS应用可以通过简单地复制代码，部署到多个应用服务器，然后把它们配置在负载均衡器的后面来实现这一目的。应用服务器彼此之间不必互相耦合通讯，从负载均衡器发来的请求可以由任何一个服务器来处理。如果应用必须要跟踪状态的变化，一个可能的解决方案是让负载均衡器允许使用会话cookie，以保持客户的浏览器和特定的应用服务器之间的对应关系。一旦客户提交了某个初始请求，相应的服务器将会持续服务该客户直到应用会话完全结束。
对数据库进行扩展往往需要更多的架构设计和代码实施工作，正如我们在文章开头部分所解释的那样，这需要耗费研发工程师的精力。应用或数据库扩展的方法共有三种，分别是复制或克隆，功能拆分，以及数据或者用户拆分。大家可以参考《架构即未来》，更详细地理解XYZ三轴扩展的架构思想。
“英特尔的联合创始人戈登·摩尔在1965年预测，放置在集成电路上的晶体管数量将每两年增加一倍。” 虽然摩尔定律已经惊人地保持了超过50年而屹立不倒，但是正如戈登·摩尔在2005年接受采访时所承认的那样，这条定律不可能永远成立。如果计算机的计算能力无法每年提高一倍，你要怎么办？另外，如果你的公司是真正的超级增长型，客户或交易的增长速度超过每年翻一番，那么依靠摩尔定律来扩展你的系统，无论是应用还是数据库，最终都会走向失败。
如果你想对技术架构有更多的了解，可阅读《架构即未来》和《架构真经》。
