系统可扩展性：原理、成本与权衡

### 系统可扩展性：原理、成本与权衡 #### 1. 互联网发展对商业系统的影响 20世纪90年代，互联网用户的激增为企业带来了新的在线盈利机会。企业纷纷通过网页浏览器向用户开放销售、服务等业务功能，这促使我们对系统构建的思考方式发生了深刻变化。 以一家零售银行为例，在提供在线服务之前，银行能够准确预测其业务系统的负载情况。因为可以明确银行内部使用系统的员工数量、连接到银行网络的终端/个人电脑数量、需要支持的自动取款机数量，以及与其他金融机构的连接数量和性质。基于这些信息，能够构建出最多支持3000个并发用户的系统，并且确信不会超出这个数量。而且业务增长相对缓慢，多数时间（如非营业时间）的负载远低于峰值，这使得软件设计决策和硬件配置变得更加容易。 然而，当这家银行决定让所有500万客户都能使用网上银行服务时，情况就变得复杂起来。最大负载会是多少？业务日中负载如何分布？高峰时段是什么时候？如果开展限时促销活动吸引新客户，又会发生什么？原本相对简单且受限的业务系统环境，被基于互联网用户群体带来的更高平均和峰值负载以及不可预测性所打破。 #### 2. 可扩展性的基本设计原则 系统扩展的基本目标是在特定应用维度上增加其容量，常见的维度是提高系统在给定时间内能够处理的请求数量，即系统的吞吐量。可以通过类比的方式来探索扩展系统和提高吞吐量的两个基本原则：复制和优化。 ##### 2.1 复制原则 悉尼海港大桥于1932年建成，如今的交通流量显然比那时高出很多。在20世纪80年代，悉尼意识到需要增加海港通道的容量，于是修建了悉尼海港隧道，它在海港下方基本沿着相同路线，增加了4条车道，使海港通道的容量大约增加了三分之一。在奥克兰，建于1959年、仅有4条车道的海港大桥也存在容量问题，他们通过使用名为“日本夹片”的装置拓宽桥梁两侧，巧妙地将车道数量增加了一倍。 在软件系统中，复制软件处理资源就类似于增加桥梁的车道。通过复制处理资源，可以提供更多的能力来处理请求，从而增加吞吐量。在基于云的软件系统中，只需点击鼠标就能实现复制，能够有效地将处理资源复制数千次。但需要注意的是，要谨慎复制资源以缓解瓶颈，否则会造成不必要的成本，且无法获得可扩展性的好处。 ```mermaid graph LR A[请求] --> B[复制处理资源1] A --> C[复制处理资源2] A --> D[复制处理资源3] B --> E[处理结果] C --> E D --> E ``` ##### 2.2 优化原则 在悉尼，有人注意到早晨有更多车辆从北向南通过大桥，下午则相反。于是采取了一种巧妙的解决方案：早上将更多车道分配给高需求方向，下午再进行切换。这在不增加新资源的情况下，有效地提高了桥梁的通行能力，即对现有资源进行了优化。 在软件中也可以采用类似的方法。例如，使用更高效的算法、在数据库中添加额外索引以加速查询，甚至用更快的编程语言重写服务器代码，都可以在不增加资源的情况下提高系统容量。Facebook曾经创建的HipHop for PHP（现已停用）就是一个典型例子，它通过将PHP代码编译成C++，使Facebook网页生成速度提高了多达6倍。 #### 3. 可扩展性与成本 假设有一个基于Web（如Web服务器和数据库）的系统，能够以1秒的平均响应时间处理100个并发请求。现在有一个业务需求，要将系统扩展到能以相同的响应时间处理1000个并发请求。在不做任何更改的情况下，对该系统进行简单的负载测试，结果如图1 - 2（左）所示，随着请求负载的增加，平均响应时间会稳步增长到10秒，显然当前的部署配置无法满足需求，系统不具备可扩展性。 经过工程努力后，系统的性能如图1 - 2（右）所示，现在能够以指定的响应时间处理1000个并发请求，成功实现了系统扩展。但问题是，实现这种性能需要多少努力和资源呢？ 可能的情况如下： 1. 数据库在每秒处理1000个请求时响应变慢，需要升级到新的机器。 2. Web服务器动态生成大量内容，在负载下会降低响应时间。可以修改代码以更高效地生成内容，从而减少每个请求的处理时间。 3. 请求负载会在数据库中产生热点，当多个请求同时尝试访问和更新相同记录时，需要重新设计数据库架构并重新加载数据，同时修改数据访问层的代码。 4. 所选的Web服务器框架更注重开发便捷性而非可扩展性，其强制的模型使得代码无法扩展以满足请求负载要求，需要完全重写。可以考虑使用其他框架，甚至更换编程语言。 假设升级数据库服务器（选项1）需要15小时的工作和每月额外1000美元的云成本来使用更强大的服务器，这并非高得难以承受。而重写Web应用层（选项4）由于使用新语言（如用Java代替Ruby）可能需要10000小时的开发时间。选项2和3的成本则介于选项1和4之间。10000小时的开发成本非常可观，更糟糕的是，在开发过程中，应用程序可能因无法满足客户请求负载而失去市场份额和收入，这种情况可能导致系统和企业失败。 这表明资源和努力成本与可扩展性有着千丝万缕的联系。如果系统在设计之初没有考虑可扩展性，那么为满足需求而增加其容量的下游成本和资源可能会非常巨大。有些应用（如Healthcare.gov）能够承担超过20亿美元的成本来修改系统以满足业务需求，而对于另一些应用（如俄勒冈州的医疗保健交易所），无法以低成本快速扩展可能会成为高昂的致命一击。 软件系统如果能够在成本线性增长的同时实现指数级扩展，就被称为超大规模系统。超大规模系统在计算和存储能力方面呈现指数级增长，而构建、运营、支持和发展所需的软件和硬件资源成本则呈线性增长。 ### 系统可扩展性：原理、成本与权衡 #### 4. 可扩展性与架构权衡 可扩展性只是软件架构领域众多质量属性（即非功能需求）之一。软件架构的一个长期复杂性在于需要进行质量属性的权衡，因为偏向某一质量属性的设计可能会对其他属性产生积极或消极的影响。可扩展性也不例外，在关注系统的可扩展性时，需要仔细考虑设计对其他理想属性（如性能、可用性、安全性和常被忽视的可管理性）的影响。 ##### 4.1 性能 性能和可扩展性之间的区别可以简单理解为：追求性能时，目标是满足单个请求的某些期望指标，例如平均响应时间小于2秒，或最坏情况下的性能目标（如第99百分位响应时间小于3秒）。 一般来说，提高性能对可扩展性有益。如果提高了单个请求的性能，系统就会有更多的容量，这有助于可扩展性，因为可以利用未使用的容量来处理更多请求。然而，情况并非总是如此简单。有多种方法可以减少响应时间，比如仔细优化代码（如去除不必要的对象复制、使用更快的JSON序列化库，甚至用更快的编程语言重写代码），这些方法在不增加资源使用的情况下优化了性能。 另一种方法是将常用状态保存在内存中，而不是在每个请求时都写入数据库，这样可以消除数据库访问，通常能加快处理速度。但如果系统长时间在内存中维护大量状态，就需要仔细管理系统能够处理的请求数量，这可能会降低可扩展性，因为这种优化单个请求的方法比原始解决方案使用了更多资源（这里是内存），从而减少了系统容量。 这种性能和可扩展性之间的矛盾在后续会不断出现，有时为了利用额外的系统容量，让单个请求稍微变慢也是明智的选择。 ##### 4.2 可用性 可用性和可扩展性通常是高度兼容的。通过复制资源来扩展系统时，会创建多个服务实例，这些实例可以处理任何用户的请求。如果其中一个实例发生故障，其他实例仍然可用，只是系统会因故障的不可用资源而降低容量。对于网络链接、网络路由器、磁盘等计算系统中的几乎任何资源，这种思路同样适用。 然而，当涉及到状态时，可扩展性和可用性就会变得复杂。以数据库为例，如果单个数据库服务器过载，可以复制它并将请求发送到任意一个实例，这也提高了可用性，因为可以容忍一个实例的故障。但如果更新了一个实例，就需要考虑如何以及何时更新其他实例，这就涉及到副本一致性的问题。 ##### 4.3 安全性 安全性是任何面向互联网系统的必要质量属性，构建安全系统的成本无法避免。下面简要探讨一下安全性对性能和可扩展性的影响。 在网络层面，系统通常使用传输层安全（TLS）协议，它运行在TCP/IP之上。TLS使用非对称加密提供加密、认证和完整性，建立安全连接时需要双方生成和交换密钥，这会产生性能成本。TLS连接建立还包括证书交换以验证服务器（可选客户端）的身份，以及选择一种算法来检查数据在传输过程中未被篡改。一旦连接建立，传输中的数据使用对称加密，由于现代CPU设有专门的加密硬件，这种加密的性能损失可以忽略不计。 建立连接通常需要客户端和服务器之间进行两次消息交换，因此相对较慢。尽可能重用连接可以最大程度地减少这些性能开销。 保护静态数据有多种选择，像SQL Server和Oracle等流行的数据库引擎具有透明数据加密（TDE）等功能，可提供高效的文件级加密。在金融等受监管的行业，越来越需要更细粒度的加密机制（直至字段级）。云服务提供商也提供各种功能，确保存储在基于云的数据存储中的数据安全。实现静态数据安全的开销是为实现安全必须承担的成本，研究表明这些开销在5 - 10%的范围内。 从另一个角度看，安全性的CIA三元组代表机密性、完整性和可用性。前两者与上述描述基本一致，可用性指系统在受到对手攻击时可靠运行的能力。例如，对手可能会试图利用系统设计漏洞使系统崩溃，或者发动经典的分布式拒绝服务（DDOS）攻击，控制大量系统和设备并协调大量请求，使系统变得不可用。 一般来说，安全性和可扩展性是相互对立的力量。安全必然会导致性能下降，系统包含的安全层越多，对性能和可扩展性的负担就越大，最终会影响底线——需要更强大、更昂贵的资源来实现系统的性能和可扩展性要求。 ##### 4.4 可管理性 随着构建的系统变得更加分布式和交互复杂，系统的管理和操作变得至关重要。需要确保每个组件都按预期运行，性能持续满足期望。 用于构建系统的平台和技术提供了大量基于标准和专有的监控工具，可用于此目的。监控仪表盘可以检查每个系统组件的持续健康状况和行为，这些仪表盘使用高度可定制和开放的工具（如Grafana）构建，能够显示系统指标，并在各种阈值或事件发生需要操作员注意时发送警报，这种复杂的监控能力被称为可观测性。 工程师可以使用各种API（如Java的MBeans、AWS CloudWatch和Python的AppMetrics）为他们的系统捕获自定义指标，例如请求响应时间。通过这些API，可以定制监控仪表盘，提供实时图表和图形，深入了解系统的行为。这些见解对于确保系统的持续运行以及突出可能需要优化或复制的系统部分非常有价值。 扩展系统必然意味着添加新的系统组件（硬件和软件），随着组件数量的增加，需要监控和管理的活动部件也更多，这并非毫无代价，它增加了系统操作的复杂性以及开发监控代码和发展可观测性平台的成本。 控制扩展时可管理性成本和复杂性的唯一方法是自动化，这就是DevOps领域发挥作用的地方。DevOps是一套将软件开发和系统操作相结合的实践和工具，它缩短了新功能的开发周期，并自动化了系统的持续测试、部署、管理、升级和监控，是任何成功的可扩展系统的重要组成部分。 #### 总结 系统的可扩展性是当代互联网应用中至关重要的因素，它涉及到基本设计原则（复制和优化）、成本考量以及与多个质量属性（性能、可用性、安全性和可管理性）的权衡。在设计和开发系统时，应从一开始就考虑可扩展性，采用促进可扩展性的设计和开发原则，以便更快速、更经济地扩展系统，满足快速增长的需求。同时，要在各个质量属性之间找到平衡，通过合理的架构设计和技术选择，确保系统在可扩展性、性能、可用性、安全性和可管理性等方面都能达到理想的状态。 |质量属性|与可扩展性的关系|应对策略| | ---- | ---- | ---- | |性能|相互影响，有时存在矛盾|仔细权衡优化方式，必要时为利用系统容量让单个请求稍慢| |可用性|通常兼容，涉及状态时变复杂|处理好副本一致性问题| |安全性|相互对立|合理安排安全层，尽量减少对性能和可扩展性的影响| |可管理性|扩展会增加管理成本|采用DevOps实现自动化管理| ```mermaid graph LR A[系统可扩展性] --> B[性能] A --> C[可用性] A --> D[安全性] A --> E[可管理性] B --> F[优化代码] B --> G[内存优化] C --> H[副本一致性] D --> I[TLS协议] D --> J[数据加密] E --> K[监控工具] E --> L[DevOps] ```