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

可扩展架构基础

可扩展架构的背景

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

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

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

(资料图)

拆分的方式包括 流程、服务、功能 三部分，理解这三种思路的关键就在于如何理解“流程”“服务”“功能”三者的联系和区别。从范围上来看，从大到小依次为：流程 > 服务 > 功能。以 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）与性能是不能混为一谈的，性能 != 可扩展。性能是指系统提供一定响应时间的能力；可扩展性是指我们可以很容易的通过扩容集群、扩容数据库、扩容实例等简单的方式来提供整体的并发能力，这样的话，只要请求访问量增加，我们就可以通过扩展机器的方式来适应请求量的增加。系统可以是高性能的，但可能是不可扩展的。