1.2 容量
这里的容量指的是单位时间内系统能吞吐的最大业务量，一个系统的吞吐量通常可以通过QPS（Queries Per Second，每秒查询率，是系统咋规定时间内所处理查询流量多少的衡量标准）和TPS（Transactions Per Second，每秒传输的处理事务个数，即服务器每秒处理的事务数）来衡量。每个系统的容量都有一个相对的极限值。随着业务的快速发展，系统处理的流量和数据量也在上涨，当系统达到容量上限时，系统的吞吐量就上不去了，如果业务流量继续上涨，系统的吞吐量不但不能位置高位，反而会快速下降，原因是超出系统容量后会导致系统超负荷工作，服务器的计算和存储等资源出现瓶颈，导致系统性能下降，业务连续性得不到保障，进而妨碍业务的发展。
容量的保障能力取决于系统架构的可伸缩性。可伸缩性是一种衡量系统处理能力的指标，高可伸缩性的系统在半岁业务不断发展的过程中，能够保持旺盛的生命力，只需要通过很少的改动甚至只是硬件设备的添置，就能实现整个系统容量的线性增长，满足高吞吐量和低延迟、高性能的要求。
横向典型做法有通过选用普通x86服务器，构建出一个系统集群，通过负载均衡将流量分发到不同节点上，可以根据用户量或数据量的增加情况来扩充服务器数量，提升系统集群处理能力。在单个数据中心的物理空间、网络设备、电力供应等基础设施匹配的情况下，系统容量能通过横向增加服务器数量来提升，不存在系统容量瓶颈。由于单个数据中心承载的服务器数量有限，延展开来，从数据中心维度看，需要将系统集群处理节点部署到多个数据中心来提升整体容量，这些数据中心需要能处于不同的地域，这样不会受单一地域在店里、土地等方面的限制。具备横向可伸缩能力的系统在单个服务器节点出现故障时，对系统的整体处理能力影响不大，但是伴随着服务器节点的增加，整体运维复杂度会上升，维护成本增加，特别是当集群节点分布到不同地域的不同机房时，复杂度会进一步上升，对系统架构设计能力提了更高要求。
典型纵向扩展是升级现有服务器的配置，比如升级内存、cpu、硬盘或者用更高规格的硬件配置替换现有的。这种方式由于不增加处理的节点数，系统复杂度更低。缺点是：系统一般部署在一台服务器上往往对其硬件配置要求很高，同时对服务器自身的稳定性要求极高，服务器的价格比普通x86服务器贵得多，兵器单台服务器的处理能力是有限的的，终将触达系统容量的上线。整个系统的处理能力集中在一台服务器上，没法避免单点问题。单台服务器出现故障时，整个系统就无法运转。当系*统集中在一台服务器时，可能在新版本投产和日常维护期间不得不停止对外服务，不能做到7*24小时。
综上所述，可伸缩性架构往往按照横向可伸缩方案设计，在不改变系统软硬件设计的前提下，通过改变系统部署的服务器数量就可以扩大或缩小整体架构的服务处理能力，调整容量大小，通过普通的x86服务器构建系统集群，增加服务器数量就可以获得平滑、线性的容量提升，实现高吞吐量和低延迟、高性能。
系统架构具备高可伸缩性，就代表具备一种弹性扩缩容能力，要实现这种弹性能力，具备灵活的容量管理能力，需要从应用、数据、数据中心多个维度进行考虑。
1.2.1 应用可伸缩
应用伸缩性的好坏往往取决于应用的状态如何管理，要确保应用是无状态（stateless）的，即应用服务器不存储请求上下文信息。应用无状态话后，部署应用的不同服务器节点都是相同的、对等的，涉及状态的信息将存放在缓存、数据库、文件对象等处。应用被设计成无状态后，将部署有相同应用的服务器组成一个集群，任何用户的请求都可以发送到任意一台服务器上去处理，通过负载均衡体制将用户请求按照某种规则分发到集群的不同服务器上，每个用户的请求都可能落在不同的服务器上，任何一台服务器处理的结果都是相同的。
1.2.2 数据可伸缩
除了读写分离，通过将数据进行垂直和水平拆分能获得更大的伸缩能力，一般先垂直拆分，再水平拆分，每个分库中的分表只存储部分分片的数据。
1.2.3 数据中心可伸缩
数据中心从设计到投产并交付后，数据中心的包间、电力、机架、服务器、网络带宽（跨机房）等资源容量基本就固化了。
传统的“两地三中心”架构中的两地往往间隔上百千米，近几年发展起来的“三地五中心”的两地间隔最长可达上千千米，通过实现数据中心的可伸缩性可以接触整体容量瓶颈，系统处理能力将可伴随数据中心的增加得到线性增长，最终实现高吞吐量，满足业务发展需要。
