系统架构之可扩展

系统架构之可扩展

扩展性（Extensibility）

指对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则，当系统增加新功能时，不需要对现有系统的结构和代码进行修改

伸缩性（Scalability）

指系统能够通过增加（减少）资源规模的方式增强（减少）自己计算处理事务的能力。如果这种增减是成比例的，就称作线性伸缩性。在网站架构中，通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力

构建可扩展的系统架构

开发低耦合系统是软件设计的终极目标之一，这一目标驱动着软件开发技术的创新与发展

架构最大的价值不在于掌握多少先进的技术，而在于具有将一个大系统切分成 N 个低耦合的子模块的能力，这些子模块包含横向的业务模块，也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验，还有一部分源自架构师对业务场景的理解、对人性的把握、甚至对世界的认知

设计系统可扩展的核心思想是模块化，并在此基础上，降低模块间的耦合性，提高模块的复用性

在大型系统中，这些模块通过分布式部署的方式，独立的模块部署在独立的服务器（集群）上，从物理上分离模块之间的耦合关系，进一步降低耦合性提高复用性

模块分布式部署以后具体聚合方式主要有分布式消息队列和分布式服务

利用分布式消息队列降低系统耦合性

事件驱动架构（Event Driven Architectrue）：通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间合作，典型的 EDA 架构就是操作系统中常见的生产者消费者模式。在大型系统架构中，具体实现手段很多，最常用的是分布式消息队列

发布/订阅模式：对于新增业务，只要对该类消息感兴趣，即可订阅该消息，对原有系统的业务没有任何影响，从而实现系统业务的可扩展设计

消息接受者在对消息进行过滤、处理、包装后、构造成一个新的消息类型，将消息继续发送出去，等待其他消息接受者订阅处理该消息

由于消息发送者不需要等待消息接受者处理数据就可以返回，系统具有更好的响应延迟；同时，在系统访问高峰，消息可以暂时存储在消息队列中等待消息接受者根据自身的负载处理能力控制消息处理速度，减轻数据库等后盾存储的负载压力

分布式消息队列

队列是一种先进先出的数据结构，分布式消息队列可以看作将这种数据结构部署到独立的服务器上，应用程序可以通过远程访问接口使用分布式消息队列，进行消息存取操作，进而实现分布式的异步调用

消息生产者应用程序通过远程访问接口将消息推送给消息队列服务器，消息队列服务器将消息写入本地内存队列后立即返回成功响应给消息生产者。消息队列服务器根据消息订阅列表查找订阅该消息的消费者应用程序，将消息队列中的消息按照先进先出（FIFO）的原则将消息通过远程通信接口发送给消息消费者程序

在伸缩性方面，由于消息队列服务器上的数据可以看作是被及时处理的，因此类似的无状态的服务器，伸缩性设计比较简单。将新服务器加入分布式消息队列集群中，通知生产者服务器更改消息队列服务器列表即可

在可用性方面，为了避免消费者进程处理缓慢，分布式消息队列服务器内存空间不足造成的问题，如果内存队列已满，会将消息写入磁盘，消息推送模块在将内存队列消息处理完以后，将磁盘内容加载到内存队列继续处理

为了避免消息队列服务器宕机造成消息丢失，会将消息成功发送到消息队列的消息存储在消息生产者服务器，等消息真正被消息消费者服务器处理后才删除消息。在消息队列服务器宕机后，生产者服务器会选择分布式消息队列服务器集群中其他的服务器发布消息

利用分布式服务打造可复用的业务平台

使用分布式服务是降低系统耦合性的另一个重要手段。如果说分布式消息队列通过消息对象分解系统耦合性，不同子系统处理同一个消息；那么分布式服务则通过接口分级系统耦合性，不同子系统通过相同的接口描述进行服务调用

巨无霸系统带来的问题：
1.编译、部署困难
2.代码分支管理困难
3.数据库连接耗尽
4.新增业务困难

解决方案：拆分，将模块独立部署，降低系统耦合性。拆分可以分为纵向拆分和横向拆分

纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离，使其成为独立的 Web 应用。而对于横向拆分，不但需要识别可复用的业务，设计服务接口，规范服务以来关系，还需要一个完善的分布式服务管理框架

Web Service 与企业级分布式服务

大型系统分布式服务的需求与特点

负载均衡、失效转移、高效的远程通信、整合异构系统、对应用最少侵入、版本管理、实时监控