您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

架构样式Architecture styles

架构样式是具有某些共同特征的一系列样式。An architecture style is a family of architectures that share certain characteristics. 例如,N 层就是一个常见的架构样式。For example, N-tier is a common architecture style. 最近以来,微服务架构开始受到青睐。More recently, microservice architectures have started to gain favor. 架构风格不需要使用特定的技术,但某些技术非常适合某些架构。Architecture styles don't require the use of particular technologies, but some technologies are well-suited for certain architectures. 例如,容器原生就能适应微服务。For example, containers are a natural fit for microservices.

我们已经识别了云应用程序中常用的一组架构样式。We have identified a set of architecture styles that are commonly found in cloud applications. 有关每个样式的文章包括:The article for each style includes:

  • 该样式的说明和逻辑关系图。A description and logical diagram of the style.
  • 有关何时选择该样式的建议。Recommendations for when to choose this style.
  • 优点、难题和最佳做法。Benefits, challenges, and best practices.
  • 使用相关 Azure 服务的建议部署。A recommended deployment using relevant Azure services.

样式概览A quick tour of the styles

本部分提供我们已识别的架构样式的概览,以及有关其用法的概要性注意事项。This section gives a quick tour of the architecture styles that we've identified, along with some high-level considerations for their use. 请在链接的主题中阅读更多详细信息。Read more details in the linked topics.

N 层N-tier

N 层 是适用于企业应用程序的传统架构。N-tier is a traditional architecture for enterprise applications. 可通过将应用程序划分成执行逻辑函数的层(例如呈现、业务逻辑和数据访问)来管理依赖项。Dependencies are managed by dividing the application into layers that perform logical functions, such as presentation, business logic, and data access. 一个层只能调用位于其下面的层。A layer can only call into layers that sit below it. 但是,这种水平分层方式可能带来麻烦。However, this horizontal layering can be a liability. 在不改动应用程序的其他部分的情况下,可能很难在应用程序的一个部分中引入更改。It can be hard to introduce changes in one part of the application without touching the rest of the application. 这使得频繁的更新成为一个难题,限制了添加新功能的速度。That makes frequent updates a challenge, limiting how quickly new features can be added.

N 层原生就很适合用于迁移已使用分层架构的现有应用程序。N-tier is a natural fit for migrating existing applications that already use a layered architecture. 因此,N 层往往出现在基础结构即服务 (IaaS) 解决方案中,或混合使用 IaaS 和托管服务的应用程序中。For that reason, N-tier is most often seen in infrastructure as a service (IaaS) solutions, or application that use a mix of IaaS and managed services.


对于单纯的 PaaS 解决方案,可以考虑 Web-队列-辅助角色 架构。For a purely PaaS solution, consider a Web-Queue-Worker architecture. 在此风格中,应用程序有一个处理 HTTP 请求的 Web 前端,以及一个执行 CPU 密集型任务或长时间运行的操作的后端辅助角色。In this style, the application has a web front end that handles HTTP requests and a back-end worker that performs CPU-intensive tasks or long-running operations. 前端通过异步消息队列来与辅助角色通信。The front end communicates to the worker through an asynchronous message queue.

Web-队列-辅助角色架构适合用于包含一些资源密集型任务的相对简单域。Web-queue-worker is suitable for relatively simple domains with some resource-intensive tasks. 与 N 层一样,该架构也很易于理解。Like N-tier, the architecture is easy to understand. 托管服务的使用简化了部署和操作。The use of managed services simplifies deployment and operations. 但对于复杂的域,可能很难管理依赖项。But with a complex domains, it can be hard to manage dependencies. 前端和辅助角可能很容易变成难以维护和更新的大型单体组件。The front end and the worker can easily become large, monolithic components that are hard to maintain and update. 与 N 层一样,这可能会降低更新频率并限制创新。As with N-tier, this can reduce the frequency of updates and limit innovation.


如果应用程序包含更复杂的域,可考虑转移到 微服务 架构。If your application has a more complex domain, consider moving to a Microservices architecture. 微服务应用程序由许多小型独立服务构成。A microservices application is composed of many small, independent services. 每个服务实现单个业务功能。Each service implements a single business capability. 服务松散耦合,通过 API 协定通信。Services are loosely coupled, communicating through API contracts.

每个服务可由小规模的专业开发团队生成。Each service can be built by a small, focused development team. 无需在团队之间进行过多的协调即可部署单个服务,因此有利于频繁更新。Individual services can be deployed without a lot of coordination between teams, which encourages frequent updates. 与 N 层或 Web-队列-辅助角色相比,微服务架构的生成和管理更复杂。A microservice architecture is more complex to build and manage than either N-tier or web-queue-worker. 它需要成熟的开发和 DevOps 文化。It requires a mature development and DevOps culture. 但如果实施得当,此样式可以加快发布速度,加速创新,提高体系结构的复原能力。But done right, this style can lead to higher release velocity, faster innovation, and a more resilient architecture.

事件驱动的架构Event-driven architecture

事件驱动的架构 使用发布-订阅 (pub-sub) 模型,其中,生成者发布事件,使用者订阅事件。Event-Driven Architectures use a publish-subscribe (pub-sub) model, where producers publish events, and consumers subscribe to them. 生成者独立于使用者,使用者互相独立。The producers are independent from the consumers, and consumers are independent from each other.

可考虑对以极低延迟引入和处理大量数据的应用程序(例如 IoT 解决方案)使用事件驱动的架构。Consider an event-driven architecture for applications that ingest and process a large volume of data with very low latency, such as IoT solutions. 当不同的子系统必须对相同的事件数据执行不同类型的处理时,该样式也很有用。The style is also useful when different subsystems must perform different types of processing on the same event data.

大数据、大计算Big Data, Big Compute

大数据大计算 是专业化的架构样式,适用于符合某些特定要求的工作负荷。Big Data and Big Compute are specialized architecture styles for workloads that fit certain specific profiles. 大数据将庞大的数据集划分为区块,针对要分析和报告的整个数据集执行并行处理。Big data divides a very large dataset into chunks, performing paralleling processing across the entire set, for analysis and reporting. 大计算也称为高性能计算 (HPC),它使用大量(数千个)核心执行并行计算。Big compute, also called high-performance computing (HPC), makes parallel computations across a large number (thousands) of cores. 应用领域包含仿真、建模和 3D 渲染。Domains include simulations, modeling, and 3-D rendering.

架构样式即约束Architecture styles as constraints

架构样式对设计施加约束,包括可显示的元素集,以及这些元素之间允许的关系。An architecture style places constraints on the design, including the set of elements that can appear and the allowed relationships between those elements. 约束通过限制所选的范围来引导架构的“形状”。 Constraints guide the "shape" of an architecture by restricting the universe of choices. 当某个架构符合特定风格的约束时,就会显现某些所需属性。When an architecture conforms to the constraints of a particular style, certain desirable properties emerge.

例如,微服务中的约束包括:For example, the constraints in microservices include:

  • 服务代表单个责任。A service represents a single responsibility.
  • 服务相互独立。Every service is independent of the others.
  • 数据专用于拥有此数据的服务。Data is private to the service that owns it. 服务不共享数据。Services do not share data.

如果遵守这些约束,则会显现一个可在其中独立部署服务、隔离故障、进行频繁更新且很容易将新技术引入应用程序的系统。By adhering to these constraints, what emerges is a system where services can be deployed independently, faults are isolated, frequent updates are possible, and it's easy to introduce new technologies into the application.

在选择某个架构样式之前,请确保了解该样式的基础原则和约束。Before choosing an architecture style, make sure that you understand the underlying principles and constraints of that style. 否则,最终可能会得到一个表面上符合该样式,但不能完全发挥该样式的潜力的设计。Otherwise, you can end up with a design that conforms to the style at a superficial level, but does not achieve the full potential of that style. 讲求实用也很重要。It's also important to be pragmatic. 有时,最好是放宽约束,而不是坚持架构的纯度。Sometimes it's better to relax a constraint, rather than insist on architectural purity.

下表总结了每个样式如何管理依赖项,以及最适合每个样式的域类型。The following table summarizes how each style manages dependencies, and the types of domain that are best suited for each.

架构样式Architecture style 依赖项管理Dependency management 域类型Domain type
N 层N-tier 按子网划分的水平层Horizontal tiers divided by subnet 传统的业务域。Traditional business domain. 更新频率较低。Frequency of updates is low.
Web-队列-辅助角色Web-Queue-Worker 通过异步消息传送分离的前端和后端作业。Front and backend jobs, decoupled by async messaging. 包含一些资源密集型任务的相对简单域。Relatively simple domain with some resource intensive tasks.
微服务Microservices 通过 API 相互调用的垂直(功能)分解服务。Vertically (functionally) decomposed services that call each other through APIs. 复杂域。Complicated domain. 频繁更新。Frequent updates.
事件驱动的架构。Event-driven architecture. 生成者/使用者。Producer/consumer. 为每个子系统提供独立视图。Independent view per sub-system. IoT 和实时系统IoT and real-time systems
大数据Big data 将巨型数据集划分为小区块。Divide a huge dataset into small chunks. 针对本地数据集执行并行处理。Parallel processing on local datasets. 批处理和实时数据分析。Batch and real-time data analysis. 使用机器学习进行预测分析。Predictive analysis using ML.
大计算Big compute 将数据分配到数千个核心。Data allocation to thousands of cores. 仿真等计算密集型域。Compute intensive domains such as simulation.

考虑难题和优势Consider challenges and benefits

约束也会带来难题,因此,在采用其中的任何样式时,必须了解各自的利弊。Constraints also create challenges, so it's important to understand the trade-offs when adopting any of these styles. 该体系结构样式在该子域和界定的上下文中是否利大于弊?Do the benefits of the architecture style outweigh the challenges, for this subdomain and bounded context.

下面是在选择体系结构样式时要考虑的一些挑战类型:Here are some of the types of challenges to consider when selecting an architecture style:

  • 复杂性Complexity. 该体系结构的复杂性对于域而言是否合理?Is the complexity of the architecture justified for your domain? 反过来,该样式对于域而言是否过于简单?Conversely, is the style too simplistic for your domain? 在这种情况下,风险是最终只设计出一个大泥球,因为该架构无助于利落地管理依赖关系。In that case, you risk ending up with a "big ball of mud", because the architecture does not help you to manage dependencies cleanly.

  • 异步消息传送和最终一致性Asynchronous messaging and eventual consistency. 异步消息传送可用于分离服务,并提高可靠性(因为消息可以重试)和可伸缩性。Asynchronous messaging can be used to decouple services, and increase reliability (because messages can be retried) and scalability. 但是,这也带来了“永远/一次”语义和最终一致性等方面的难题。However, this also creates challenges such as always-once semantics and eventual consistency.

  • 服务间通信Inter-service communication. 将应用程序分解为独立的服务时,风险是服务之间的通信会导致不可接受的延迟,或造成网络拥塞(例如,在微服务体系结构中)。As you decompose an application into separate services, there is a risk that communication between services will cause unacceptable latency or create network congestion (for example, in a microservices architecture).

  • 可管理性Manageability. 管理应用程序、监视、部署更新以及其他操作的难度有多大?How hard is it to manage the application, monitor, deploy updates, and so on?