本文探讨如下几个问题：

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

架构模式=架构风格？

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

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

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

我们来一个个的说！

什么是架构模式？

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

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中列出的架构风格和架构模式，你就能看出点端倪了！

架构模式	架构风格
Three-Tier Multilayered architecture Model-View-Controller(MVC) Domain Driven Design Micro-Kernel Blackboard Pattern Sensor-Controller-Actuator Presentation–Abstraction–Control	CQRS Component-based Monolithic application Layered (or multilayered architecture) Pipes and Filters Database-Centric Blackboard Rule-based Event-driven aka implicit invocation Publish-subscribe Asynchronous Messaging Plug-Ins Microkernel Reflection Domain Specific Languages(DSL) Client-Server (2-tier, 3-tier, n-tier exhibit this style) Shared Nothing Architecture Space-based Architecture Object Request Broker Peer-to-Peer Representational State Transfer (REST) Service-Oriented Cloud Computing Patterns MicroServices

架构模式

架构风格

Three-Tier
Multilayered architecture
Model-View-Controller(MVC)
Domain Driven Design
Micro-Kernel
Blackboard Pattern
Sensor-Controller-Actuator
Presentation–Abstraction–Control

CQRS
Component-based
Monolithic application
Layered (or multilayered architecture)
Pipes and Filters
Database-Centric
Blackboard
Rule-based
Event-driven aka implicit invocation
Publish-subscribe
Asynchronous Messaging
Plug-Ins
Microkernel
Reflection
Domain Specific Languages(DSL)
Client-Server (2-tier, 3-tier, n-tier exhibit this style)
Shared Nothing Architecture
Space-based Architecture
Object Request Broker
Peer-to-Peer
Representational State Transfer (REST)
Service-Oriented
Cloud Computing Patterns
MicroServices

你会发现，架构风格中有「Multilayered」这个架构风格，架构模式里也有「Multilayered」架构模式！好像分层架构既是架构风格，也是架构模式！实际上架构模式中的「分层架构」是架构风格中的「分层架构」的实际应用。

更具有说服力的是CS架构风格，可以看到此架构风格后面有个阐述「2-tier, 3-tier, n-tier exhibit this style」，意思是两层架构、三层架构、n层架构都是CS架构风格的一种表现形式。而可以看到，三层架构是一个架构模式！

你有没有一个疑问？两层架构、三层架构、N层架构为什么不是分层架构风格的表现形式？而是CS架构风格的一种表现形式？
这个问题在后面的CS架构和分层架构中会具体阐述。

再具体一点，我们看看CS架构的约束：

Server组件提供了一组服务,并监听对这些服务的请求。
Client组件通过一个连接器将请求发送到Server,希望执行一个服务。
Server可以拒绝这个请求,也可以执行这个请求并将响应发送回Client

可以看到，这里只是约束了系统分为Client和Server，以及Server和Client之间的行为。

再来看三层架构模式，三层架构一般分为：

Presentation tier 展现层
Logic tier 业务逻辑层
Data access tier 数据访问层

可以看到，三层架构模式比CS架构风格更具体，描述了每一层的作用。
当系统有如下需求时，就可以考虑三层架构：

需要提供用户界面（不论是本地应用这样的富客户端、还是浏览器，亦或手机APP）
需要访问持久层数据
解耦（视图，业务、数据可独立进化）

总结

用Renan Johannsen de Paula Venilton FalvoJr在《Architectural Patterns and Styles》中对架构模式和架构风格的区别来总结一下：

Architecture Pattern: { problem, context } → architecture approach;
Architecture Style: architecture approach.

实际工作中，我们一般会说「架构」，而没有具体到是「架构风格」还是「架构模式」。这么做其实有几点好处：

理解的偏差，不影响讨论和使用：虽然可能每个人对「架构风格」和「架构模式」的理解是有偏差的，但是并不会影响系统的讨论。反而，如果具体到风格还是模式，那可能就变成对「风格」还是「模式」的讨论，而不是对业务的讨论
有些情况下，风格和模式的差异并不大：「架构风格」和「架构模式」的主要区别就是是否是针对某个「问题域」和「上下文」的！当一个「架构风格」应用到了某个「问题域」和「上下文」，且这个「问题域」和「上下文」也比较常见，那么这个「架构风格」在这个「问题域」和「上下文」的应用就是「架构模式」！
可以少说两个字

参考资料

Microsoft Azure文档
《Design Patterns：Elements of Reusable Object-Oriented Software》 GOF
《Architectural Patterns and Styles》Renan Johannsen de Paula Venilton FalvoJr
《Architectural Styles and the Design of Network-based Software Architectures》Roy Thomas Fielding
List of Software Architecture Styles and Patterns
Architectural Pattern

什么是架构模式和架构风格相关推荐

架构模式-微内核架构模式
今天我们来看下微内核架构模式. 微内核架构模式也称为插件式架构模式,是一种天生基于产品应用的架构模式.基于产品应用是将需要发布的程序打包好,并且可能会进行持续迭代升级从而拥有多个版本,提供给用户或三方 ...
架构风格 VS 架构模式
热爱实践而又不讲求科学的人,就好像一个水手进了一只没有舵或罗盘的船,他从来不肯定他往那里走. --达芬奇首先,在维基百科中是这样介绍的,"有些人将架构模式和架构风格视为相同的,有些人将风格 ...
架构模式：MVC与MVVM
本文探讨如下几个问题: 什么是MVC 什么是MVVM MVC与MVVM对架构属性的影响 MVC实例SpringMVC MVVM实例Vue MVC.MVVM与Layer中的Model,Controlle ...
探索从 MVC 到 MVVM + Flux 架构模式的转变
在业务中一般 MVVM 框架一般都会配合上数据状态库(redux, mobx 等)一起使用,本文会通过一个小 demo 来讲述为什么会引人数据状态库. 从 MVC 到 MVVM 模式说起传统 MVC ...
架构业务wait和sleep区别狭义jiavaBean规范，三层架构模式
在写这篇文章之前,xxx已经写过了几篇关于改架构业务主题的文章,想要了解的朋友可以去翻一下之前的文章每日一道理聪明人学习,像搏击长空的雄鹰,仰视一望无际的大地:愚笨的人学习,漫无目标,犹如乱飞乱撞 ...
我理解的软件架构模式，MVC和分层
一.缘起作为程序员,很容易天天被业务追逐着,抽不开时间修炼.有一天突然停了一下,忽地就会有一种怅然的感觉,过去的那些日子我学到了什么? 有人很认真地说自己有10年经验,有人笑说你不过是一年经验用了1 ...
软件架构万字漫谈：业务架构、应用架构与云基础架构
软件架构万字漫谈:业务架构.应用架构与云基础架构本部分节选自<软件架构设计> 软件开发就是把一个复杂的问题分解为一系列简单的问题,再把一系列简单的解决方案组合成一个复杂的解决方案.而软件 ...
K8s, Kafka事件溯源架构模式和用例示例
随着当今快速变化的业务和技术格局,开发人员.数据科学家和IT运营部门正在共同构建具有新技术和动态架构的智能应用程序,因为它们具有灵活性,交付速度和可维护性.本文我将介绍有助于技术架构进化的技术:容器. ...
企业应用架构模式学习笔记
1.概述 2.分层表现逻辑处理用户与软件间的交互.表现层的主要职责是向用户显示信息并把从用户那里获取的信息解释成领域层或数据源层上的各种动作. 数据源逻辑主要关注与其他系统的交互,这些系统将代表应用 ...

什么是架构模式和架构风格