软件架构模式之第一章：介绍

      在缺乏正式架构的情况下，开发人员开始编写应用程序是一种非常普遍的做法。这种做法通常会导致组件定义不明确，创建出被称为“大泥球”的东西。这些结构通常紧密耦合、脆弱且难以改变，并且缺乏清晰的愿景或方向。在没有定义良好的架构风格时，也很难确定应用程序具有哪些架构特征。该架构是否可伸缩？应用程序性能如何？更改应用程序或添加新功能是否容易？架构响应速度如何？

       架构风格有助于定义应用程序的基本特征和行为。一些架构风格自然地适用于高度可伸缩的系统，而其他架构风格则自然地适用于允许开发人员快速响应变化的应用程序。了解每种架构风格的特点、优势和劣势对于选择满足特定业务需求和目标的架构风格是必要的。自2015年第一版本报告发布以来，软件架构经历了许多变化。微服务和事件驱动架构都变得越来越受欢迎，开发人员和架构师已经探索出设计和实现这些架构风格所需的新技术、工具和方法。此外，领域驱动设计广泛使用也导致了对如何结构化划分架构以及划分如何影响应用程序设计与实现有更深入理解。第二版报告解决了这两个问题，并增加了其他重要增强功能，还提供更多关于架构与数据交集方面信息，并在每章末尾添加扩展分析部分。这些新部分为您提供更好指引，在选择是否使用本报告中介绍的各种架构时给予指导。

       在第二版中，您会注意到一个变化，即本报告所描述的架构被称为“架构风格”而非“架构模式”。这个区别有助于消除一些困惑，例如事件驱动架构——一种架构风格和CQRS（命令查询责任分离）等架构模式之间的差异。

       一个架构风格，例如在本报告中提及的那些，描述了系统的宏观结构。而架构模式则是描述可重用的结构性构建块模式，可用于解决特定问题，在每个架构风格中都可以应用。以广为人知的CQRS模式为例，它描述了对数据库或事件系统进行结构上分离以实现读操作和写操作之间的隔离（例如将读操作和写操作分离成服务和数据库）。这种架构模式适用于本报告所述任何一种架构风格，并能优化数据库查询和更新。

        架构模式与设计模式（如生成器设计模式）有所不同，架构模式主要影响系统的结构方面，而设计模式则主要影响源代码的设计方式。例如，在微服务架构中可以采用生成器设计模式来实现CQRS架构模式，并将CQRS作为其组成部分之一。图1-1展示了这三个术语之间的层次关系以及它们在软件系统构建中的相互关联。   

 Figure 1-1. Architecture styles can be composed of architecture patterns,which in turn can be composed of design patterns

 

          设计模式和架构模式通常结合在一起，形成一个完整的解决方案。同样地，架构风格也以类似的方式工作——当构建软件解决方案时，它们可以相互融合为一个完整的解决方案。在现实世界中，混合使用不同的架构风格非常普遍，因为并非每种架构风格都能够解决所有业务问题。常见的混合架构风格包括基于事件驱动的微服务（通过微服务之间的事件进行通信）、基于空间划分的微服务（将处理单元作为微服务实现）甚至是事件驱动型微内核架构（核心系统与远程插件组件之间通过事件进行交互）。虽然混合使用是一种常见做法，但在将它们结合使用之前，了解各个独立架构风格及其对应优缺点至关重要。这份更新版报告与第一版目标相同：帮助高级开发人员和架构师理解更加常见的架构风格、它们如何工作以及何时适用或不适用。这不仅有助于扩展您对于架构知识的了解，还能够帮助您做出正确选择来设计系统。