「Azure架构风格」Azure云不同的 架构风格

架构风格是一系列具有某些共同特征的架构。例如，n层是一种常见的体系结构样式。最近，微服务体系结构开始受到青睐。架构风格不需要使用特定的技术，但是有些技术非常适合特定的架构。例如，容器自然适合于微服务。

我们已经确定了一组在云应用程序中常见的体系结构样式。每种风格的文章包括:

1. 样式的描述和逻辑关系图。

2. 建议何时选择这种风格。

3. 好处、挑战和最佳实践。

4. 推荐使用相关Azure服务进行部署。

快速浏览一下这些风格

本节将快速介绍我们已经确定的体系结构样式，以及使用它们的一些高级注意事项。阅读相关主题的更多细节。

n层

n层是企业应用程序的传统体系结构。依赖项是通过将应用程序划分为执行逻辑功能(如表示、业务逻辑和数据访问)的层来管理的。一个层只能调用它下面的层。然而，这种水平分层可能是一种不利因素。在不触及应用程序其余部分的情况下，在应用程序的一部分中引入更改是很困难的。这使得频繁的更新成为一个挑战，限制了新功能添加的速度。

N-tier非常适合迁移已经使用分层架构的现有应用程序。由于这个原因，n层最常出现在基础设施即服务(IaaS)解决方案中，或使用IaaS和托管服务组合的应用程序中。

Web-Queue-Worker

对于纯粹的PaaS解决方案，可以考虑web队列工作人员体系结构。在这种风格中，应用程序有一个处理HTTP请求的web前端和一个执行cpu密集型任务或长时间运行操作的后端工作者。前端通过异步消息队列与工作人员通信。

Web-queue-worker适用于一些相对简单的域，这些域具有一些资源密集型任务。与n层一样，体系结构很容易理解。托管服务的使用简化了部署和操作。但是对于复杂的域，可能很难管理依赖关系。前端和工作人员很容易变成大型的、难以维护和更新的单片组件。与N-tier一样，这可以减少更新频率并限制创新。

Microservices

如果您的应用程序具有更复杂的域，则考虑迁移到微服务体系结构。微服务应用程序由许多小型的独立服务组成。每个服务实现单个业务功能。服务是松散耦合的，通过API契约进行通信。

每个服务都可以由一个小型的、专注的开发团队构建。单个服务的部署不需要团队之间的大量协调，这鼓励了频繁的更新。微服务体系结构的构建和管理比n层或web队列工作人员更复杂。它需要成熟的开发和DevOps文化。但是如果处理得当，这种风格可以导致更高的发布速度、更快的创新和更有弹性的架构。

事件驱动架构

事件驱动的体系结构使用发布-订阅(发布-订阅)模型，生产者发布事件，消费者订阅事件。生产者独立于消费者，消费者相互独立。

考虑一个事件驱动的架构，用于以极低延迟摄取和处理大量数据的应用程序，如IoT解决方案。当不同的子系统必须对相同的事件数据执行不同类型的处理时，这种样式也很有用。

大数据，大计算

大数据和大计算是适用于特定配置文件的特定工作负载的特定体系结构样式。大数据将非常大的数据集划分为块，在整个集合上执行并行处理，用于分析和报告。大计算，也称为高性能计算(HPC)，在大量(数千个)核上进行并行计算。领域包括模拟、建模和3-D渲染。

作为约束的体系结构样式

体系结构样式对设计施加约束，包括可以出现的元素集和这些元素之间允许的关系。约束通过限制选择的范围来指导架构的“形状”。当架构符合特定样式的约束时，就会出现某些需要的属性。

例如，微服务的约束包括:

1. 服务代表单一职责。

2. 每一种服务都是相互独立的。

3. 数据对于拥有它的服务是私有的。服务不共享数据。

通过遵守这些约束，出现的是一个可以独立部署服务、隔离故障、可能频繁更新并且很容易将新技术引入应用程序的系统。

在选择体系结构样式之前，请确保了解该样式的基本原则和约束。否则，您可能最终得到的设计在表面上符合该风格，但并没有实现该风格的全部潜力。务实也很重要。有时候，放松约束比坚持建筑的纯粹性更好。

下表总结了每种样式如何管理依赖项，以及最适合每种样式的域类型。

架构风格	依赖关系管理
N层	按子网划分的水平层	传统的业务领域。更新频率低
Web -Queue- Worker	前端和后端作业，通过 异步消息传递解耦	相对简单的领域与一些资 源密集型任务。
微服务	垂直(功能上)分解的服务通 过api相互调用。	复杂的领域。频繁的更新
事件驱动架构	生产者/消费者。每个子系 统的独立视图	物联网和实时系统
大数据	将一个庞大的数据集分 割成小块。局部数据集 的并行处理。	批量和实时数据分析。 使用ML进行预测分析。
大计算	数据分配给数千个核心.	计算密集领域，如仿真。

考虑挑战和好处

约束也会带来挑战，因此在采用任何一种样式时，理解其中的利弊是很重要的。对于这个子域和有限的上下文，体系结构风格的好处是否大于挑战?

以下是一些选择架构风格时需要考虑的挑战类型:

1. 复杂性。体系结构的复杂性是否适合您的领域?相反，这种风格对您的域来说太简单了吗?在这种情况下，您可能会得到一个“大泥球”，因为体系结构不能帮助您干净地管理依赖项。

2. 异步消息传递和最终的一致性。异步消息传递可以用来解耦服务，提高可靠性(因为消息可以重试)和可伸缩性。然而，这也给处理最终的一致性以及重复消息的可能性带来了挑战。

3. 服务间的通信。在将应用程序分解为单独的服务时，存在这样的风险:服务之间的通信将导致不可接受的延迟或造成网络拥塞(例如，在微服务体系结构中)。

4. 可管理性。管理应用程序、监视、部署更新等有多难?

本文 :https://architect.pub/problem-docker-and-alpines-package-pinning
讨论：知识星球【首席架构师圈】或者加微信小号【ca_cto】或者加QQ群【792862318】
公众号	【jiagoushipro】 【架构师酒馆】 精彩图文详解架构方法论，架构实践，技术原理，技术趋势。 我们在等你，赶快扫描关注吧。
微信小号	【ca_cea】 50000人社区，讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化.
QQ群	【285069459】深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。 加QQ群，有珍贵的报告和干货资料分享。
视频号	【架构师酒馆】 1分钟快速了解架构相关的基本概念，模型，方法，经验。 每天1分钟，架构心中熟。
知识星球	【首席架构师圈】向大咖提问，近距离接触，或者获得私密资料分享。
喜马拉雅	【超级架构师】路上或者车上了解最新黑科技资讯，架构心得。	【智能时刻，架构君和你聊黑科技】
知识星球	认识更多朋友，职场和技术闲聊。	知识星球【职场和技术】
微博	【架构师酒馆】	智能时刻
哔哩哔哩	【架构师酒馆】
抖音	【cea_cio】架构师酒馆
快手	【cea_cio_cto】架构师酒馆
小红书	【cea_csa_cto】架构师酒馆
网站	CIO(首席信息官)	https://cio.ceo
网站	CIO,CTO和CDO	https://cioctocdo.com
网站	架构师实战分享	https://architect.pub
网站	程序员云开发分享	https://pgmr.cloud
官网	行天智能科技咨询公司	https://xingtian.ai
网站	开发者闲谈	https://blog.developer.chat
网站	CPO工作宝典	https://cpo.work
网站	首席安全官	https://cso.pub
网站	CIO酷	https://cio.cool
网站	CDO信息	https://cdo.fyi
网站	CXO信息	https://cxo.pub
网站	首席架构师社区	https://jiagoushi.pro

谢谢大家关注，转发，点赞和点在看。