可伸缩Web架构的4个问题：瓶颈，CPU，数据库，IO

 在这篇文章中我将谈到关于大规模网站架构扩展和性能方面的一些问题。

首先让我们先来了解一些术语。稍后我将对Web应用扩展过程中所遇到的不同问题进行讲解，例如：

 架构瓶颈

 数据库扩展

 CPU消耗型应用

 IO消耗型应用

性能

Web系统的性能受多方面因素的影响，但大多数开发人员主要关心的是响应时间和可扩展性这两方面。

响应时间

响应时间是指Web应用从收到请求到返回响应结果所花费的时间。而应用系统应该在可接受的时间范围内返回响应结果，否则就不能算是一个性能良好的应用系统。

可扩展性

如果Web应用通过增加更多硬件可以使处理的请求数呈线性增长，那么该应用是可扩展的。

扩展的方式可以分为以下两种：

1) 纵向扩展（垂直扩展）：为单台机器增加CPU或者提高单台机器CPU性能。

2) 横向扩展（水平扩展）：增加服务器数量

垂直扩展 VS 水平扩展

一般情况下水平扩展比垂直扩展更重要，主要是因为普通硬件商品远比需要特殊配置的硬件便宜（比如大型机）；但是增强单个应用在一个硬件商品上处理的请求数同样也是比较重要的。同时，一个应用系统在不降低响应时间的前提下，如果通过添加更多的资源能够处理更多的请求，那么这个系统表现良好。

响应时间 VS 可扩展性

在同一个应用中，响应时间和可扩展性并不总是能够同时达到最好的效果。要么应用程序有可接受的响应时间但是不能处理超过一定数量的请求；要么应用程序可以处理大量请求，但是响应时间却不尽如人意，甚至非常糟糕。因此，通常情况下我们需要在这两个要素中寻求平衡点使我们的应用系统性能达到最佳状态。

容量规划

容量规划需要我们根据产品期望的负载量来预估所需要的硬件数量。除了整体的预估外，这通常还包括使用更少硬件时系统的性能表现情况以及单台机器下的性能的测试及评估。

架构扩展

如果Web应用的每一层在多层架构体系中都是可扩展的，那么该应用也具有可扩展性（横向扩展）。例如，如下图所示，我们就可以通过增加额外的资源来实现应用层和数据库层的线性扩展。

负载均衡器扩展

可以通过将DNS指向多个IP以及使用DNS轮循查找IP地址的方式来实现负载均衡器的横向扩展。或者可以使用多级负载均衡，使上一级负载均衡器来分发至下一级负载均衡器，但使用多个负载均衡器的情况比较少，主要是由于Web容器一般可以处理几千并发请求，而使用nginx或者HAProxy的单个负载均衡器可以处理超过20000的并发请求，因此单个负载均衡器完全可以代理多个web应用。

数据库功能扩展

数据库功能扩展是非常常用的方式，但是扩展数据库功能（比如创建存储过程或自定义函数）都会给数据层带来额外开销以及增加数据层的复杂性。

关系型数据库

关系型数据库可以通过主从同步的模式实现扩展，主库以写入数据为主，从库只做读操作。但是，如果业务量比较大时主从同步模式所提供的扩展能力非常有限，此外，开发人员还需要通过数据库拆分技术来进一步满足业务需求。

NoSQL

CAP定理（译者注：不熟悉的读者可通过谷歌查阅）告诉我们一个应用不可能同时满足一致性、可用性、分区容错性三个要求。而NoSQL一般则是通过牺牲一定的一致性来获得更高可用性以及更好的分区容错性。

数据库拆分

数据库拆分可以垂直拆分和水平拆分：

 垂直拆分（Partitioning）：根据领域模型概念的基础可以将数据库拆分为几个松耦合的子库。例如，拆分为消费者数据库、产品数据库。另一种垂直拆分数据库的方式是将一个实体的一部分字段拆分出来作为一个新数据库，另一部分字段作为另一个数据库。例如，将消费者数据拆分为消费者联系信息和订单数据两部分。

 水平拆分（Sharding）：可以根据数据的离散属性将数据进行水平分割。例如，消费者可以根据地域不同拆分为美国消费者数据库和欧洲消费者数据库。

将数据库从单个数据库使用分区或者sharding拆分为多个数据库是一项非常有挑战性的任务。

架构瓶颈

可扩展系统出现性能瓶颈的原因主要在于以下两方面：

 中心化组件 应用中一个不可扩展的组件直接影响整个系统或者请求处理通道所能处理请求数的上限。

 高延迟组件 一个高延迟的组件会影响整个系统响应时间的下限，使整个系统响应时间更长。通常解决这个问题的办法是使高延迟的组件作为后台任务线程或者使用异步队列来解决。

CPU消耗型应用

如果一个应用的吞吐量受CPU的限制，那么该应用就是CPU消耗型应用。此类引用通过增加CPU计算速度即可减少响应时间。

以下这些应用场景可能属于CPU消耗性：

 需要计算或者处理数据而不需要做IO操作的应用（财务或者交易类系统）

 非常依赖缓存而且不做任何IO操作的应用

 异步（非阻塞）模型而且不需要等待外部资源的应用（被动应用或者使用NoJs的应用）

在以上使用场景中已经正常运行的应用，如果在一些应用场景中写了糟糕的或者效率低下的代码来对每次请求做大量额外的计算或者循环，那么这些应用的CPU占用率将非常高。但是通过分析应用可以很容易发现并修改效率低的问题。

IO消耗型应用

如果一个应用的吞吐量受IO或者网络操作影响而且提升CPU计算速度并不能减少响应时间，那么该应用即为IO消耗型应用。大多数应用是IO消耗型应用主要是由于要做增、删、改、查操作。而性能调优和对iO消耗型应用进行扩展也由于这些系统依赖于其他系统的下行流量变得非常困难。

以下这些应用场景可能是IO消耗性：

 依赖数据库并进行增、删、改、查操作的应用

 需要下行流量来完成本身操作的应用

译者注：本文只是简单提到可伸缩应用的主要问题以及所用到的技术，其中每一项展开来谈都不是一两篇文章可以讲的完的。archleaner今后也将持续为大家提供优质的技术文章。

 

1.本文由程序员学架构翻译，由mathew同学校审；仅用于交流学习使用。

2.本文译自Venkatesh CM在Architecture Issues Scaling Web Applications的博客。

3. 更多文章请关注公众号：程序员学架构(微信号：archleaner )

4.更多文章请扫码：