可扩展和弹性伸缩系统设计

可扩展架构基础

可扩展架构的背景

软件系统是可以随着需求变化或者技术变化而不断扩展和迭代的，我们常见的各种软件系统比如操作系统、各种知名开源软件系统都是如此。而在这个过程中，我们如何通过较小的代价去扩展我们的系统，是我们要重点考虑的。

可扩展的基本思想：拆分（流程、服务、功能）

可扩展性架构的设计方法虽然很多，但是最核心的思想就是拆分。将大系统拆分为小系统、小模块，然后针对其中的子系统或者模块来进行扩展，这样可以通过较小的改动去实现整个系统的扩展能力，可以同时满足扩展需求和改动的风险。

拆分的方式包括流程、服务、功能三部分，理解这三种思路的关键就在于如何理解“流程”“服务”“功能”三者的联系和区别。从范围上来看，从大到小依次为：流程 > 服务 > 功能。以 TCP/IP 协议栈为例，来说明“流程”“服务”“功能”的区别和联系：

【资料图】

流程对应 TCP/IP 四层模型，因为 TCP/IP 网络通信流程是：应用层 → 传输层 → 网络层 → 物理 + 数据链路层，不管最上层的应用层是什么，这个流程都不会变。服务对应应用层的 HTTP、FTP、SMTP 等服务，HTTP 提供 Web 服务，FTP 提供文件服务，SMTP 提供邮件服务，以此类推。功能每个服务都会提供相应的功能。例如，HTTP 服务提供 GET、POST 功能，FTP 提供上传下载功能，SMTP 提供邮件发送和收取功能。

可扩展架构模式

根据拆分的思想，典型的可扩展系统架构有：

面向流程拆分（分层架构）。由于系统做了合理的分层，因此扩展的时候，可能只需要修改其中一层就可以进行功能扩展。一个典型的分层架构系统的扩展就是对数据层的扩展，比如之前只支持 MySQL，现在需要同时支持 MySQL 和 Elasticserach，那么只需要在数据层进行修改扩展即可不太常见的 2 层架构（C/S 架构、B/S 架构）。通过用户交互维度来划分，和用户交互的是一层、支持交互的后端系统是一层。常见的是 3 层架构（MVC、MVP 架构）。一般通过业务功能职责来划分。还有一些 2 层架构（C/S 架构、B/S 架构）。通过用户交互维度来划分，和用户交互的是一层、支持交互的后端系统是一层。常见的逻辑分层架构。比如操作系统的逻辑分层架构、比如一般我们后台业务系统里面的分层架构。面向服务拆分（SOA、微服务）。这个是现在最常见的架构设计，因为都是微服务形态，那么扩展的时候，只需要针对每个独立运行的微服务进行扩展，其他服务无感知，这样修改的粒度很小，扩展会比较容易。面向功能拆分（微内核架构）。这个是我最近才了解到的一种架构设计，针对这种架构，对某个功能扩展，或者要增加新的功能时，只需要扩展相关功能即可，无须修改所有的服务。

响应时间和可伸缩性的关系

可扩展性（Scalability）与性能是不能混为一谈的，性能 != 可扩展。性能是指系统提供一定响应时间的能力；可扩展性是指我们可以很容易的通过扩容集群、扩容数据库、扩容实例等简单的方式来提供整体的并发能力，这样的话，只要请求访问量增加，我们就可以通过扩展机器的方式来适应请求量的增加。系统可以是高性能的，但可能是不可扩展的。

性能（performance）-> 响应时间：接口请求的响应时间可伸缩性（Scalability）：包括横向扩展（Scaling Out）和纵向扩展（Scaling Up ）横向扩展（水平扩展）：增加实例、增加机器纵向扩展（垂直扩展）：增加硬件配置如 CPU 核数；使用更高性能的 CPU、网卡等；增加内存容量；

但是这里需要注意的是响应时间和可伸缩性可能不是同步的或者是线性的，也就是说当请求量增加，并且进行各种扩容后，虽然抗住了请求量，但是响应时间不见得会变短，可能会变长，因为请求量的增加导致底层的各种系统资源消耗较多或者下游的依赖压力较大从而导致响应时间变长。

系统资源和水平扩展的关系

请求量增加的时候，要进行扩容，扩容最容易和最常见的方式是水平扩展服务，也就是扩容无状态实例。但是，针对一些系统资源或者依赖资源，比如数据库（MySQL）、缓存（Redis）等，这些有状态的不能无限扩容，因此就一定考虑他们的性能，他们的性能才是底线，如果 redis 、ES 等扛不住，那么扩容再多无状态实例也是白费。这里需要特别注意这些底层依赖资源的性能以及无状态服务和他们连接的一些连接池、并发数等。

可扩展和弹性伸缩的关系

可扩展性是指系统适应更大的负载的能力，只需通过增加资源，使硬件更强大（扩展）或增加额外的节点（扩展）。

弹性伸缩是指动态地适应应对负载所需的资源的能力，通常与扩展性有关。因此，当负载增加时，你通过添加更多的资源来扩大规模，而当需求减弱时，你就缩减并删除不需要的资源。弹性伸缩在云环境中非常重要，一方面你要按使用量付费，不想为你目前不需要的资源付费，另一方面要在需要时满足不断增长的需求。

可扩展架构设计（Scalability）

可扩展架构设计的最佳实践

一些最佳实践可以参考（翻译） OpenShift 的 Best Practices for Scaling Out 这篇文章，这里在此基础上做进一步的整理和总结：

微服务化设计，尽量让我们的系统模块化、组件化，从而实现高内聚，低耦合的思想，提高复用性，扩展性。这样每个微服务可以独立进行扩展，而且一个服务挂掉并不会导致整个服务不可用；这个也同样适用于数据库的拆分逻辑。分层设计，可扩展架构设计的基本要求就是我们服务要先进行分层，然后每一层都要能够单独扩展，并且需要用到负载均衡技术。消息队列：模块化的系统通过消息队列进行交互，使模块之间的依赖解耦。队列的引入可以缓解流量突峰，也可以流程异步化，提高性能、稳定性。高并发、大流量下，同步机制会使得整体响应非常慢，因此当前一般的高并发系统都是异步处理的，一般我们可以通过消息队列实现异步。分布式服务：公用模块服务化，提供其他系统使用，提高可重用性，扩展性。联系紧密的服务尽量部署到同一个集群，避免跨集群访问带来的延迟、带宽增加等应用程序应该尽量采用无状态服务，而不是采用有状态服务；将需要存储的状态统一用分布式存储、分布式缓存来存储。善用分布式缓存；访问缓存比访问数据库或者文件系统性能高很多，避免直接操作数据库，可以极大提高性能设计模式：应用面向对象思想，原则，使用设计模式，进行代码层面的设计。网关入口要使用负载均衡层，常见的是 Nginx 和 HAProxy，当做 7 层代理集群，然后后面再接入应用服务。使用代理层是可扩展架构的必要前提。不要过度设计，根据情况考虑是否最初就设计为可扩展架构，不必从一开始就构建可伸缩的体系结构，扩展的关键是先于用户发现瓶颈。不要强迫将自己熟知的技术运用到不恰当的领域来解决特定领域的问题；所用来解决问题的技术方案应该是某个技术所擅长的领域尽可能的自动化所有事情，好的监控统计系统非常重要，可以帮助我们了解系统的运行状态、回溯问题、分析问题；及时告警，这个不仅仅是针对扩展架构，所有服务架构都是一样的。

可扩展代码的一些最佳实践

参考（翻译）Rackspace Writing Code that Scales 的写出高扩展和高性能代码的工程原则：

首先就要编写压力测试计划。比如支持 10w 个并发连接、响应设计小于 200ms。这个就是我们的预期目标，我们接下来的设计、规划都要围绕这个目标以及超过目标来进行善于缓存。包括分布式缓存、本地缓存。少量频繁访问的可以本地缓存大部分情况下都能够使用分布式缓存解决我们的数据缓存问题。（Redis）需要外网进行网络传输的数据，能够压缩的尽量压缩后传输。客户端和服务端之间的数据交互，尽可能的压缩。数据压缩后的传输可以大大减少外网传输时间，并提高了单位时间的连接处理能力。压缩的传输一定会比未压缩后传输的效率高，相比网络传输的时间，CPU 用来压缩和解压缩的时间是可以忽略的。关于磁盘 IO 如果有大量的数据需要存储到磁盘上，然后需要读写，那么要进行压缩后存储，虽然存储便宜，但是 IO 消耗却很大，压缩后可以有效的提高 IO 吞吐量尽可能将随机 IO 模式替换为顺序 IO 模式降低每个连接的开销。一般而言，每个连接都需要一定的内存，比如一个最基本的 TCP 连接可能需要 2k 的内存；减少每个连接的开销可以支持更多的连接处理更多的事情。入口流量设计准入控制，需要有限流设计、队列设计。后端服务虽然可以自动扩缩容，但是它们的承受能力可能会有一个极限值，因此在极限值的时候就需要有限流措施，可以允许有一定的队列任务堆积，但是不能无限制的增长队列，当请求量超过一定的极限后，这个时候不能继续等待，而应该快速失败。如果持续等待，不加以限流措施，那么很可能会导致让整个系统变得更慢，从而压垮整个系统。关于通信协议，如果应用程序的组件通过外网相互通信，或者在客户端和服务器之间进行了大量通信，尽可能将文本分析协议的使用降至最低，也即是减少 xml、json 协议，而应该使用二进制协议如 pb，

弹性伸缩设计

因为可扩展和弹性伸缩是非常紧密的，因此这里也同时看看，要实现弹性伸缩，需要有哪些设计。

目前云上的架构，基本都有自动弹性伸缩功能，服务部署到公有云或者私有云上，应该是都能根据 CPU 使用率等基本指标来自动伸缩的。但是，当我们想要自己设计一个自动伸缩的架构，那么该怎么设计？

无状态服务设计

要能够弹性伸缩，服务一定是要无状态的才能比较好的保证，有状态服务的不太好实现弹性伸缩。

基础镜像轻量、快速启动

实例启动的时间很重要，如果不能快速启动，那么当检测到需要伸缩的时候，如果扩容很久才启动新实例，那么扩容期间是有损的，因此快速启动是必须的。快速启动的一个必要条件就是基础镜像要比较轻量，这样的话，从拉取镜像到启动镜像的过程就会比较快速；这个在容器时代的优势比较明显，通过 Docker 可以比较好的满足我们的诉求。

健康检查

最好要有健康检查模块，能够保证扩容后的实例是可以正常 work 的，要不然扩容了也没用。同时如果服务异常，那么需要及时摘掉。当然，其他基础模块也会对服务做健康检查，这个设计就要根据整体架构做取舍，看是否有更合适的健康检查模块，如果没有，那么健康检查放到哪里更为合适。

如果是在自动伸缩架构中的健康检查，那么需要检测：

业务程序是否部署成功？需要有一个探测接口用来探测业务程序是否正常运行业务服务是否能够对外提供流量操作系统级别是否出现了异常

在 k8s 容器平台下，健康检查一般会有两个地方来保证：

K8s 本身的 kubelet 来保障负载均衡代理层来保障

服务优雅关闭

当我们要自动缩容服务实例的时候，一个非常关键的地方就是，实时运行的服务，如果直接关闭，势必会对流量有损，这样对业务服务、对客户都有一定的影响。作为一个极致的技术人，我们必须要能够保证服务可以优雅关闭、优雅下线。

一般会有如下几个方式：

通知服务退出的时候，服务延迟退出，先摘掉流量，不让新的请求进来，然后预留时间把当前正在处理的任务继续处理完毕之后再退出。这个就要求业务服务和弹性伸缩架构能够配合联动起来，需要设计这么一个机制。K8s 就有这样的机制，当收到 TERMINATED 退出信号之后 Pod 可以不马上退出，而是可以延迟一定的时间后再退出

自定义指标来执行弹性伸缩

一般来说，通过 CPU 、内存的使用率来进行弹性伸缩是最常用的功能，也挺有效果；在此基础之上，我们还可以自定义一些指标，可以更贴合业务，比如 QPS，通过这些个指标来进行弹性伸缩。

比如我们的 K8s 平台，我们就扩展了 QPS 指标，还有一些比如流量带宽之类的，但是 CPU 和 QPS 指标是最常用的弹性伸缩指标。

缩放比例尺设计

使用弹性缩放比例时，删除实例时，应用程序将具有一定的缩放比例。应用程序必须妥善处理要删除的实例。以下是处理 scalein 的一些方法：

最好可以监听关闭（退出）事件，然后优雅关闭。服务的客户/消费者应支持瞬时故障处理和重试。对于长时间运行的任务，应该使用检查点或“ 管道和过滤器”模式来分解工作。将工作项放在队列中，以便另一个实例可以接管工作（如果在处理过程中删除了一个实例）。

卸载资源密集型任务

尽可能将需要大量 CPU 或 I/O 资源的任务移至后台作业，以最大程度地减少处理用户请求的前端负载。

确定整个系统的瓶颈

扩展并不是解决每个性能问题的灵丹妙药，要先确定整个系统中哪个环境是瓶颈，这样才能更好的扩展。