例如，容器原生就能适应微服务。
样式概览
请在链接的主题中阅读更多详细信息。
N 层
这使得频繁的更新成为一项难题，限制添加新功能的速度。
因此，N 层往往出现在基础结构即服务 (IaaS) 解决方案中，或混合使用 IaaS 和托管服务的应用程序中。
Web-队列-辅助角色
前端通过异步消息队列来与辅助角色通信。
与 N 层一样，这可能会降低更新频率并限制创新。
微服务
服务松散耦合，通过 API 协定通信。
但如果实施得当，此样式可以加快发布速度，加速创新，提高体系结构的复原能力。
事件驱动的架构
生成者独立于使用者，使用者互相独立。
当不同的子系统必须对相同的事件数据执行不同类型的处理时，该样式也很有用。
大数据、大计算
应用领域包含仿真、建模和 3D 渲染。
架构样式即约束
当某个体系结构符合特定样式的约束时，就会显现某些所需属性。
例如，微服务中的约束包括：
- 服务代表单一责任。
- 每项服务都独立于其他服务。
- 服务不共享数据。
如果遵守这些约束，则会显现一个可在其中独立部署服务、隔离故障、频繁更新且很容易将新技术引入应用程序的系统。
有时，最好是放宽约束，而不是坚持体系结构的纯度。
下表总结了每个样式如何管理依赖项，以及最适合每个样式的域类型。
| 架构样式 | 依赖项管理 | 域类型 |
|---|---|---|
| N 层 | 按子网划分的水平层 | 更新频率较低。 |
| Web-队列-辅助角色 | 通过异步消息传送分离的前端和后端作业。 | 包含一些资源密集型任务的相对简单域。 |
| 微服务 | 通过 API 相互调用的垂直（功能）分解服务。 | 频繁更新。 |
| 事件驱动的架构。 | 为每个子系统提供独立视图。 | IoT 和实时系统 |
| 大数据 | 针对本地数据集执行并行处理。 | 使用机器学习进行预测分析。 |
| 大计算 | 将数据分配到数千个核心。 | 仿真等计算密集型域。 |
考虑难题和优势
该体系结构样式在该子域和界定的上下文中是否利大于弊？
下面是在选择体系结构样式时要考虑的一些挑战类型：
-
在这种情况下，风险是最终只设计出一个大泥球，因为该体系结构无助于利落地管理依赖项。
-
但是，这也会在处理最终一致性方面带来挑战，并可能会导致出现重复消息。
-
将应用程序分解为独立的服务时，风险是服务之间的通信会导致不可接受的延迟，或造成网络拥塞（例如，在微服务体系结构中）。
-
管理应用程序、监视、部署更新以及其他操作的难度有多大？