1.可扩展架构基础

可扩展架构的背景

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

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

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

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

● • 流程

○ • 对应 TCP/IP 四层模型，因为 TCP/IP 网络通信流程是：应用层 → 传输层 → 网络层 → 物理 + 数据链路层，不管最上层的应用层是什么，这个流程都不会变。

● • 服务

○ • 对应应用层的 HTTP、FTP、SMTP 等服务，HTTP 提供 Web 服务，FTP 提供文件服务，SMTP 提供邮件服务，以此类推。

● • 功能

○ • 每个服务都会提供相应的功能。例如，HTTP 服务提供 GET、POST 功能，FTP 提供上传下载功能，SMTP 提供邮件发送和收取功能。

可扩展和弹性伸缩的关系

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

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

2. 可扩展架构设计

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

● • 微服务化设计，尽量让我们的系统模块化、组件化，从而实现高内聚，低耦合的思想，提高复用性，扩展性。这样每个微服务可以独立进行扩展，而且一个服务挂掉并不会导致整个服务不可用；这个也同样适用于数据库的拆分逻辑。

● • 分层设计，可扩展架构设计的基本要求就是我们服务要先进行分层，然后每一层都要能够单独扩展，并且需要用到负载均衡技术。

● • 消息队列：模块化的系统通过消息队列进行交互，使模块之间的依赖解耦。队列的引入可以缓解流量突峰，也可以流程异步化，提高性能、稳定性。高并发、大流量下，同步机制会使得整体响应非常慢，因此当前一般的高并发系统都是异步处理的，一般我们可以通过消息队列实现异步。

● • 分布式服务：公用模块服务化，提供其他系统使用，提高可重用性，扩展性。联系紧密的服务尽量部署到同一个集群，避免跨集群访问带来的延迟、带宽增加等

● • 应用程序应该尽量采用无状态服务，而不是采用有状态服务；将需要存储的状态统一用分布式存储、分布式缓存来存储。

● • 善用分布式缓存；访问缓存比访问数据库或者文件系统性能高很多，避免直接操作数据库，可以极大提高性能

● • 设计模式：应用面向对象思想，原则，使用设计模式，进行代码层面的设计。

● • 网关入口要使用负载均衡层，常见的是 Nginx 和 HAProxy，当做 7 层代理集群，然后后面再接入应用服务。使用代理层是可扩展架构的必要前提。

● • 不要过度设计，根据情况考虑是否最初就设计为可扩展架构，不必从一开始就构建可伸缩的体系结构，扩展的关键是先于用户发现瓶颈。

● • 不要强迫将自己熟知的技术运用到不恰当的领域来解决特定领域的问题；所用来解决问题的技术方案应该是某个技术所擅长的领域

● • 尽可能的自动化所有事情，好的监控统计系统非常重要，可以帮助我们了解系统的运行状态、回溯问题、分析问题；及时告警，这个不仅仅是针对扩展架构，所有服务架构都是一样的。

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

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

● • 首先就要编写压力测试计划。比如支持 10w 个并发连接、响应设计小于 200ms。这个就是我们的预期目标，我们接下来的设计、规划都要围绕这个目标以及超过目标来进行

● • 善于缓存。包括分布式缓存、本地缓存。

○ • 少量频繁访问的可以本地缓存

○ • 大部分情况下都能够使用分布式缓存解决我们的数据缓存问题。（Redis）

● • 需要外网进行网络传输的数据，能够压缩的尽量压缩后传输。

○ • 客户端和服务端之间的数据交互，尽可能的压缩。

○ • 数据压缩后的传输可以大大减少外网传输时间，并提高了单位时间的连接处理能力。压缩的传输一定会比未压缩后传输的效率高，相比网络传输的时间，CPU 用来压缩和解压缩的时间是可以忽略的。

● • 关于磁盘 IO

○ • 如果有大量的数据需要存储到磁盘上，然后需要读写，那么要进行压缩后存储，虽然存储便宜，但是 IO 消耗却很大，压缩后可以有效的提高 IO 吞吐量

○ • 尽可能将随机 IO 模式替换为顺序 IO 模式

● • 降低每个连接的开销。一般而言，每个连接都需要一定的内存，比如一个最基本的 TCP 连接可能需要 2k 的内存；减少每个连接的开销可以支持更多的连接处理更多的事情。

● • 入口流量设计准入控制，需要有限流设计、队列设计。后端服务虽然可以自动扩缩容，但是它们的承受能力可能会有一个极限值，因此在极限值的时候就需要有限流措施，可以允许有一定的队列任务堆积，但是不能无限制的增长队列，当请求量超过一定的极限后，这个时候不能继续等待，而应该快速失败。如果持续等待，不加以限流措施，那么很可能会导致让整个系统变得更慢，从而压垮整个系统。

● • 关于通信协议，如果应用程序的组件通过外网相互通信，或者在客户端和服务器之间进行了大量通信，尽可能将文本分析协议的使用降至最低，也即是减少 xml、json 协议，而应该使用二进制协议如 pb，

可扩展架构设计