本文探讨如下几个问题：

• 架构模式和架构风格有区别吗？
• 什么是架构模式？
• 什么是架构风格？
• 架构模式和架构风格的区别是什么？
• 有哪些架构模式？
• 有哪些架构风格？

架构模式=架构风格？

如果你搜索「架构模式和架构风格的区别」，你会发现答案千差万别：

• 有的观点认为架构模式和架构风格是一个东西，只是叫法不同
• 有的观点认为架构风格是架构模式的外在表现
• 有的观点认为架构模式和架构风格是不同的两个概念（具体有什么不同，又有不同的观点）
  • 有的观点认为架构模式解决问题，架构风格不解决问题(例如：建房子有建房子的模式，而无论是建成哥特风还是现代风，都还是房子)
  • 有的观点认为架构风格是高层级的架构模式

我个人的观点是：架构模式是特定问题域下，架构风格的具体应用！

我们来一个个的说！

什么是架构模式？

在说架构模式之前，我们先来看看我们常挂在嘴边的设计模式是怎么定义的！

GOF在《Design Patterns》这本书的「What is a Design Pattern?」小节，对设计模式下了一个明确的定义：

The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.
设计模式描述了一组类和对象的关系，用以解决特定上下文内的某个常见的设计问题！

那我们可以这么定义架构模式：架构模式描述了一组组件之间的关系，用以解决特定上下文内的某个常见的架构问题！

Wiki上也给架构模式做了类似的定义：

An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context
架构模式是一个通用的、可重用的解决方案，用以解决特定上下文内的某个常见的架构问题！

什么是架构风格?

Roy Thomas Fielding博士，在他的REST论文中，对架构风格做出了定义：

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.
一种架构风格是一组协作的架构约束，这些约束限制了架构元素的角色和功能，以及在任何一个遵循该风格的架构中允许存在的元素之间的关系。

Martin Flower在微服务文章中的说明，也间接支持了此定义。文中首先明确「微服务」是一种架构风格，然后给出了微服务所具有的特征（就是约束），具有这些约束的系统就可以说是使用了微服务架构风格！

微软的Azure文档也给出了类似的定义：架构风格即约束！

架构模式和架构风格的区别

上面我们分别给「架构模式」和「架构风格」下了定义！那么「架构模式」和「架构风格」到底有什么区别呢？

我们来看架构模式的定义，可以抽出几个关键词：

• 模式：描述的是一种关系（类与类的关系、组件与组件的关系）！并且这种关系是可复用的！
• 特定上下文：说明这种关系的适用场景是有限制的，只能在特定场景下才能适用！
• 常见问题：说明这种关系是解决某个问题或某类问题的解决方案，是有针对性的！

我们再看架构风格的定义，它仅仅就是约束！约束了组件之间的关系！

所以「架构模式」和「架构风格」的区别就在这里：

• 架构模式是针对某个特定上下文的某类问题的解决方案
• 架构风格是一个解决方案

举个例子

如果你仔细看看Wiki中列出的架构风格和架构模式，你就能看出点端倪了！