应用架构演进

• 概述
• 架构演进
  • 单体应用架构
  • 垂直应用架构
  • 分层服务架构
  • 面向服务架构
  • 微服务架构
• 总结

概述

在学习软件架构设计的过程中，总是能听到单体架构、分布式架构、SOA架构、微服务架构 等各种架构方法论，而这么多架构方法都有什么区别和联系呢？它们是一起涌现的还是依次出现的？为什么会出现这种情况呢？

另外，大家应该都听前辈说过 “架构是设计出来的，也是演进出来的”。一个运行中的应用，肯定存在一个架构，而这个架构是由研发人员设计出来的，它能满足当前的质量属性约束，为业务运行带来价值。但是，随着业务需求的变更、应用系统的迭代和业务量的增长，之前的应用架构还能满足质量属性约束吗？如果不能，该怎么办呢？很显然，需要做应用架构调整，来解决当下碰到的问题，如此便有了架构演进的诉求。那么是否存在一个银弹，可以一劳永逸的解决所有架构问题呢？很显然，答案是否定的，因为应用架构的方法论也一直在发展中。

因此，我们有必要审视一下应用架构方法论的演进，除了回答上面提到的问题，看看能否从中领会到一些有用的东西。那么，带着问题，我们开始吧。

架构演进

随着互联网的普及，Web应用成了软件开发的主流，而Web应用的架构方法自然也就成了焦点。下面我们一起研究一下它的演进路径。

单体应用架构

特点：

1. 所有应用功能都部署在一起。

2. 应用可通过水平复制或数据分区的扩展方式提升系统吞吐和可用性。

3. 架构设计的重点是对应用做分层设计，先后经历了MVC架构、分层架构、DDD架构、六边形架构等模式。

• MVC架构（二层架构）将视图和模型分离，多个视图可以共享一个模型，解决视图和模型耦合的问题。

• 分层架构（三层架构）进一步对模型进行分层，采用面向接口编程，各层之间采用接口相互访问，解决了业务逻辑可测试性的问题。

• 六边形架构以业务逻辑层为中心组织逻辑视图。业务逻辑层通过暴露的出入站端口（port）与适配器层的出入站适配器（adapter）交互，完成系统之间的调用。

优点：

1. 架构简单，前期开发成本低，小型项目的首选。

2. 开发效率高，模块之间交互采用本地方法调用。

3. 容易部署，运维成本小。打包为一个完整的包即可运行。

4. 容易测试，在本地就可以启动完整的应用，集成测试方便。

缺点：

1. 应用的可测试性、可扩展性和可维护性影响软件交付速度。全部功能集成在一个工程中，对于大型、复杂项目不易测试、扩展及维护。

2. 版本迭代速度逐渐变慢。修改一个地方就要将整个应用全部编译、打包、部署、启动，开发及测试周期过长。

3. 无法按需伸缩。通过集群的方式扩展，无法针对某业务功能按需伸缩。

垂直应用架构

特点：

1. 通常按用户角色使用场景划分多个互相独立的单体应用。

2. 应用之间的公共业务逻辑，通过数据复制集成或通过共享代码集成。

优点：

1. 每个单体应用采用分层架构，可独立部署、演进和扩展。

2. 每个单体应用可按需伸缩。不同业务单体的架构约束不一样，可区别对待。

3. 每个单体应用可采用不同的技术栈。

缺点：

1. 单体应用之间存在数据冗余、功能冗余，耦合性高。

2. 数据模型变更会影响整个应用的稳定，变更风险高。

分层服务架构

特点：

1. 将垂直应用中的公用核心业务逻辑抽取出来，作为独立的服务。

2. 应用和服务之间通过定义良好的接口交互。此时，分布式服务框架（RPC）是关键。

优点：

1. 提高了业务的复用，使得应用能快速的响应需求。服务可独立部署、演进和扩展。

2. 垂直单体应用可按需伸缩。不同业务单体的架构约束不一样，可区别对待。

3. 垂直单体应用和公共服务可采用不同的技术栈。

缺点：

1. 本地事务变成分布式事务。分布式架构带来的事务问题。

2. 本地调用变成远程调用。分布式架构带来的稳定性问题。

面向服务架构

特点：

1. 基于分布式架构思想，将重复的功能拆分成多个服务。

2. 系统与服务之间采用 Web Service、 RPC 等方式通信。

3. ESB（企业服务总线）作为系统与服务之间通信的桥梁。

优点：

1. 将重复的功能抽取为服务，提高了开发效率，提升了系统的复用性、可维护性。

2. 可以针对不同服务的特点按需伸缩。

3. ESB降低了系统中的接口耦合。

缺点：

1. 系统与服务的界限模糊，会导致抽取的服务的粒度过大，系统与服务之间耦合性高。

2. ESB是系统稳定的关键，所有服务调用都经过它。

3. ESB的服务接口协议种类繁多，不利于系统维护。

微服务架构

特点：

1. 业务功能按领域拆分为一组服务。

2. 每一个服务都是由一组专注的、高内聚的功能职责组成。

3. 服务之间采用RESTful、 RPC等轻量级协议传输。

4. 通常采用前后端分离架构。

优点：

1. 灵活性：由于每个服务都是独立的，因此可以快速地开发和部署新的服务，也可以快速地修改和升级现有的服务。这使得微服务架构更加灵活，可以快速地适应不同的需求和变化。

2. 可扩展性：每个服务都可以独立地进行扩展，而不必扩展整个系统。这使得微服务架构更加可靠、高效和可扩展，可以满足大流量和高并发的需求。

3. 可靠性：由于每个服务都是独立的，因此一个服务的故障不会影响整个系统的运行。这使得微服务架构更加可靠，能够更好地处理系统中的故障和问题。

4. 技术多样性：每个服务都可以使用不同的编程语言、框架和技术，这使得微服务架构更加灵活，可以使用最适合每个服务的技术。

5. 易于管理：由于每个服务都是独立的，因此可以更好地管理和监控每个服务的状态和性能，这使得微服务架构更加易于管理和维护。

缺点：

1. 服务的拆分和定义是一项挑战。服务拆分和定义更像是一门艺术。

2. 分布式系统带来的各种复杂性，使得开发、测试和部署变得困难。

3. 当部署跨越多个服务的功能时，需要谨慎协调更多开发团队。

4. 开发者需要考虑到底应该在应用的什么阶段使用微服务架构。

总结

1. 架构方法的演进是基于务实的解决问题的思想发展而来，当然更多的是向外思考追求解决方案的结果。虽然在解决核心问题的过程中引入了新的问题，但是本质上还是促进了大型复杂系统的设计。

2. 通过对各种架构风格的介绍，也能够看清各自的特性、优缺点和技术要求，所以需要根据业务的不同阶段，团队的规模大小、技术能力，选择适合自己的架构风格才是硬道理。