软件系统的可扩展性设计

一、可扩展性的设计关注点

通常网站的可扩展性架构设计，能够在对现有系统影响最小的情况下，同时能保持可持续扩展和稳定提升的能力。
按照可扩展性的定义，一个具备良好可扩展性的架构设计应当符合开闭原则：对扩展开发，对修改关闭。
衡量一个软件系统具备良好可扩展性主要表现但不限于：

• 软件内部方面：在软件系统实现新增业务时，对现有系统功能影响较少，即不需要对先用功能做任何改动或很少改动。
• 软件外部方面：软件系统本身与其他存在协同关系的外部系统之间存在松耦合关系，软件系统的变化对其他软件系统无影响，其他软件系统和功能不需要进行改动。反之，则是一个扩展性不好的软件系统。

开闭原则明确的告诉我们：软件实现应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化的。

1.可扩展性设计的优势

其表现为基础设置不需要经常变更，应用之间较少依赖或耦合，可以对需求变更快速响应。

它对扩展开放，对修改关闭。架构设计会考虑到未来功能的可扩展性，所以当系统增加新功能时，不需要对现有系统的结构和代码进行修改。
度量一个开发框架、设计模式或者编程语言优劣的一个重要尺度就是他是否能够让软件开发过程和软件产品更加低耦合。
因为低耦合的系统更容易扩展，也更容易被复用，而且也会让开发过程和维护变得更加容易。但如何分解系统的各个模块、如何定义各个模块的接口，如何复用、组合不同模块构造一个完整的系统，这是软件设计中最具挑战性的部分。
架构设计的最大价值，就在于把一个大系统分解为多个低耦合的子模块的能力，这些子模块包含横向的业务模块和纵向的基础技术模块。这种能力来源于专业能力与经验、业务场景的理解、对人性的把握以及对世界认知。
构建可扩展的网站架构的核心思想是模块化，并在此基础上，降低模块之间的耦合，提高模块的复用性。
可以利用分层与分割的方式，把软件分割为若干个低耦合、独立的组件模块，然后这些组件模块之间以消息传递或依赖调用的方式聚合在一起合成一个完整的系统。这些模块可以通过分布式部署的方式，部署在独立的服务器上。这种从物理上分离模块之间的耦合关系，可以进一步降低耦合性。

2.可扩展性设计的目的

可扩展性设计的目的在于为了处理更大规模的业务。
在项目初期，硬件的成本会非常高，但随着时间的推移，软件成本变得昂贵得多。因此，构建应用程序时，应该想法让他不需要或者很少需要软件就能扩展；买更多的硬件，使用更多硬件来扩展要好一些。为了处理更大规模的业务，同时保证性能提升，还要搞清楚如何向外扩展。垂直扩展和水平扩展是其中两个重要的方法。

3.可扩展性设计的两种方法

• “垂直扩展”：
  在同一个逻辑单位添加资源以增加容量。开始的设置非常基础，可能就是一台web服务器和一台数据库服务器。当机器性能不足时，用更大的机器替换它。新机器能力不足时，用另外一台机器替换它。这台机器能力也不足时，就买一台更加强大的机器。如此反复。
• “水平扩展”
  水平扩展内在原则上和垂直扩展相似，不断添加更多的硬件。不同于垂直扩展的地方在于，增长时不需要超级强劲的机器，而只需要很多常规的机器。从一台常规的机器开始，其能力不足后添加第二台。然后第三台，第四台等。增加多个逻辑单元资源并且使他们作为一个整体在工作。大多数的集群解决方案，比如分布式文件系统，负载均衡都是通过横向扩展技术来进行的。

二、扩展方式

设计具备良好可扩展性的系统，有两个思考角度：从业务维度，对业务深入理解，对可预计的业务变化进行预测；从技术维度，利用扩展性好的技术，实现对变化的封装。

• 在业务维度

对业务深入理解，对业务的发展方向进行预判，也就是不能完全不考虑可扩展性；但是变化无处不在，对业务看得远一点的同时，需要注意的是，要警惕过度设计；不能每个设计点都考虑可扩展性；所有的预测都存在不正确的可能。

• 在技术维度

预测变化是一回事，采取什么方案来应对变化，优势另外一个复杂的事情。及时预测很准确，如果方案不合适，则系统扩展性很麻烦。第一种应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。

1.分层架构

三层架构通常意义上的三层架构就是将整个业务应用划分为：界面层、业务逻辑层、数据访问层。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。
在早期的单体应用中，通过系统分层，每层可以独立的变化，降低的系统内部的耦合程度。分层的思想也是模块化的体现。

2.消息队列

如果模块之间不存在直接调用关系，那么新增或修改对其他部分的影响最小，这样的扩展性自然更好。通过在低耦合的模块之间传输事件消息，保持模块之间的松散耦合。不同系统之间，通过消息传递的方式，实现了系统之间的解耦。采用消息的方式，通常还是异步操作的，能够提升系统的性能。

3.远程调用

随着网站功能日益复杂，系统会逐渐发展成为一个巨无霸，里面聚合了大量的应用和服务组件，这样的一个系统会给开发，维护，部署带来巨大的麻烦。所以我们要做拆分，把模块独立部署，降低系统的耦合性。
复用的业务分出来，独立开发部署为分布式服务，新增的业务只需要远程调用这些分布式的服务，就可以快速搭建出一个应用系统，技术模块内的业务逻辑发生变化，只要保持接口一致，就不会影响其他模块。
目前，采用Dubbo，以及SpringCloud可以轻松的完成系统的构建任务。

4.开放平台

放平台是网站内部和外部交互的接口。外部会面对众多的第三方开发者。内部面对的是网站内众多的业务服务。下面是开放平台的常用架构：

• API接口：暴露给开发者的一组API，可以使Restful，RPC等。
  协议转换：把各种API的输入转换为内部服务可识别的形式，并把内部服务的返回封装为API格式。
• 安全：除了身份识别，权限控制等手段之外，还要对访问带宽进行分级限制，保证平台资源被第三方应用合理公平的使用，也能保证网站自身的内部服务不被外部应用拖垮。
• 审计：监控第三方应用的访问情况并计费。
• 路由：把开放平台的各种访问路由映射到具体的内部服务。
• 流程：把一组松散的服务组织成一个上下文相关的新服务，对外提供接口供开发者使用。

三、企业级系统的平台化设计

一个高度平台化的系统，对高扩展性和灵活性是非常关注的，作为企业管理信息系统，最大的挑战是如何满足不同企业通用需求的同事快速满足企业个性化需求，除了企业战略、组织架构、流程体系等紧密相关外，软件的平台化水平，可扩展性和灵活性至关重要。一个高度平台化的系统对高扩展性是非常关注的。

1.分层设计

高可扩展性和灵活性的系统一版是分层架构，这里说的分层是指将客户的需求按照需求的通用性分层。根据自己平台所应用的目标客户群，分析客户的共性需求，将共性部分的需求按需求的通用性分层。根据自己平台所应用的目标客户群，分析客户的共性需求，将共性部分的需求放在平台的最底层实现，所有的客户共用，不要有分支版本，个性的需求放在高层实现。
不同的客户可以完全定制。至于整个架构的层次数量没有绝对的标准，可参考的方法分为4层，

• 公共平台层
• 产品平台层
• 行业扩展层
• 个性扩展层

这里的分层与软件架构中的表示层，中间层，持久层的分发属于不同的维度，是没有冲突的。

2.模块化

高可扩展性的系统一般都是模块化的。
系统最好提供统一的基础组件，通过二次开发的手段提供上层扩展，做项目多了一版都会形成组件库，应该对这些组件进行分类分级管理。一旦有了新的项目，一般从现有的组件库中挑选进行配置，部分不满足要求的可以进行修改后满足，其他个性化很强的完全定制。

3.数据建模

提供图形化的数据建模模块，可以自动生成数据库的表结构，同事将数据的结构也保存为元数据，不依硬编码。

4.流程建模

采用图形化的方式，定义企业的业务流程，依赖业务流程的驱动完成流程的自动化。流程一般需要人的参与，所以与任务管理紧密相关，可能会涉及集成Email，手机短信实现自动通知。

5.状态建模

一般数据对象有多个状态，比如订单就有未发货，已发货，已到货等状态，不同状态下可执行的操作也是不同的，不同的状态下权限也会有差异。一般按照数据类型定义状态图，不同的状态有不同的操作和权限，一般依赖于各个操作或流程改变对象的状态。

6.权限建模

不同的数据类型通常由一些功能的权限项，比如浏览、修改等。应该支持自定义的权限项，不同的类型授权时权限项不同。权限的授予一般也有粒度要求，最小的按单个个体授权，最大的按类型授权。

7.报表系统

不同的角色可以看到不同的报表，最好建立报表的框架，开发一个新的报表后，通过简单的配置，不依赖修改代码，就可以通过系统访问到报表。报表的各种操作，也可以通过配置实现。

8.界面建模

企业中不同角色都希望看到与自己工作相关的功能，这就需要可以按角色自定义菜单和主页，主页的自定义用户可以选择自己需要的部分，添加到主页上。

四、总结

总体来说，可扩展作为软件非功能性设计的一个关注指标，其外在表现是多方面的，包括了分层结构、模块化、数据建模，流程建模等。甚至还包括权限体系的扩展等方面，当然真的要构建高扩展性的系统难度是很大的，也是系统复杂性的重要来源，通常都会遇到诸如性能问题，在各种复杂要求下寻求最好的平衡，大部分问题是可以解决的。