㊗️ ☝🏼 📴 云架构应用指南 📱 📈 👆🏼

本指南为可伸缩，弹性和高度可访问的云应用程序设计了结构准则。无论您使用哪种云平台，它都旨在帮助您做出有关体系结构的决策。

该手册按一系列步骤进行组织-选择架构→选择用于计算和存储数据的技术→设计Azure应用程序→选择模板→检查架构。对于它们每个人，都有一些建议可以帮助您开发应用程序体系结构。

今天，我们出版本书第一章的一部分。您可以在此处免费下载完整版本。

架构选择

设计云应用程序时，您需要做出的第一个决定是选择架构。架构的选择取决于应用程序的复杂性，范围，其类型（IaaS或PaaS）以及其预期的任务。考虑开发团队和项目经理的技能以及应用程序的现成体系结构的可用性也很重要。

体系结构的选择对应用程序的结构施加了某些限制，从而限制了技术和应用程序其他元素的选择。这些局限性与所选体系结构的优点和缺点有关。

本节中的信息将帮助您在实现特定体系结构时在两者之间找到平衡。本节列出了要记住的十个设计原则。遵循这些原则将帮助您创建更具可伸缩性，弹性和可管理性的应用程序。

我们已经确定了一组在云应用程序中常用的体系结构选项。每个部分专用的部分包含：

架构的描述和逻辑；
有关此体系结构范围的建议；
优点，缺点和使用建议；
使用适当的Azure服务的推荐部署选项。

架构概述

本节简要概述了我们已经确定的体系结构选项，以及使用它们的一般建议。您可以通过链接在相关章节中找到更多详细信息。

N级

N层体系结构最常用于企业应用程序。为了管理依赖关系，将应用程序分为几层，每一层负责某种逻辑功能，例如，负责数据的表示，业务逻辑或对数据的访问。一层可以调用下面的其他层。然而，这种划分为水平层会引起额外的困难。例如，在不影响应用程序其他部分的情况下，可能很难对其进行更改。因此，更新这样的应用程序通常并不容易，并且开发人员将不必频繁添加新功能。

当传输已使用的基于分层体系结构的应用程序时，N层体系结构是自然选择。因此，此架构最常用于IaaS（基础架构即服务）解决方案或将IaaS与托管服务结合在一起的应用程序中。

Web界面-队列-辅助角色

对于PaaS解决方案，Web界面队列工作角色体系结构是合适的。通过这种体系结构，该应用程序具有处理HTTP请求的Web界面以及负责长时间或需要计算资源的操作的服务器工作角色。异步消息队列用于在接口和服务器工作角色之间进行通信。

“ Web界面-队列-工作角色”架构适用于需要计算资源的相对简单的任务。与N层架构一样，此模型也易于理解。使用托管服务可简化部署和操作。但是，当为复杂的主题领域创建应用程序时，可能很难控制依赖关系。 Web界面和工作角色可以轻松扩展到难以维护和更新的大型整体组件。与N层架构一样，此模型的特点是更新率较低且改进机会有限。

微服务

如果该应用程序旨在解决更复杂的问题，请尝试在微服务体系结构的基础上实现它。这样的应用程序由许多小型独立服务组成。每个服务负责一个单独的业务功能。服务是松散耦合的，并使用API合同进行交互。

一小组开发人员可以创建单独的服务。无需在开发人员之间进行复杂的协调就可以部署服务，从而可以轻松地定期更新服务。与前两种方法相比，微服务架构更难以实现和管理。这需要成熟的发展管理文化。但是，如果一切组织得当，这种方法将有助于增加发布新版本的频率，加快创新的实施速度，并使体系结构更加容错。

Cqrs

CQRS的体系结构（命令和查询职责隔离，团队和查询之间的职责分配）使您可以在各个模型之间分离读写操作。结果，负责更改数据的系统部分与负责读取数据的系统部分是隔离的。此外，可以在物化视图中执行读取操作，该物化视图与要写入的数据库在物理上是分开的。这使您可以独立地缩放读写过程，并优化物化表示以执行查询。

CQRS模型最适合用于大型体系结构的子系统。通常，不应将其应用于整个应用程序，因为这不必要地使其架构复杂化。它在协作系统中效果很好，在协作系统中，大量用户同时使用相同的数据。

基于事件的架构

基于事件的体系结构使用发布订阅模型，其中供应商发布事件，而消费者订阅事件。供应商独立于消费者，而消费者彼此独立。

基于事件的体系结构非常适合需要快速接收和处理低延迟的大量数据的应用程序，例如物联网。此外，这种架构在不同子系统必须以不同方式处理相同事件数据的情况下也能很好地工作。

大数据，大计算

大数据和大计算是用于解决特殊问题的特殊体系结构选项。使用大数据体系结构时，将大数据集划分为多个片段，然后对其进行并行处理以进行分析和报告。大计算也称为高性能计算（HPC）。这项技术使您可以在多个（数千个）处理器内核之间分配计算。这些架构可用于仿真，3D渲染和其他类似任务。

架构选项作为限制

架构在设计解决方案时起着约束作用，特别是，它确定可以使用哪些元素以及它们之间可能的连接。约束定义了体系结构的“形式”，并允许您从较窄的选项集中进行选择。如果满足所选体系结构的限制，则解决方案将具有该体系结构的特性。

例如，微服务具有以下限制：

每个服务负责一个单独的功能；
服务彼此独立；
数据仅适用于负责该数据的服务。服务不交换数据。

遵循这些限制，就可以创建一个系统，在该系统中可以彼此独立地部署服务，隔离故障，可以进行频繁更新，并且可以轻松地向应用程序中添加新技术。

选择架构之前，请确保您充分了解基本原理和相关限制。否则，您将获得一个与所选体系结构模型相匹配的解决方案，但是并不能完全揭示该模型的潜力。常识也很重要。有时候，放弃一个或另一个限制比追求干净的体系结构更明智。

下表显示了如何在其每个体系结构中实现依赖关系管理，以及该体系结构或该体系结构最适合的任务。

优缺点分析

局限性带来了更多的困难，因此，重要的是要了解选择一个或另一个体系结构选项时必须付出的代价，并能够回答所选选项的优点是否大于特定任务在特定上下文中的缺点的问题。

下面列出了选择架构时要考虑的一些缺点：

复杂性 使用复杂的体系结构是否适合您的任务？反之亦然，为复杂任务选择的架构是否太简单？在这种情况下，您可能会面临系统结构不清晰的风险，因为所使用的体系结构不允许您正确管理依赖项。
异步消息传递并最终实现一致性。 异步消息传递有助于分离服务，并提高了可靠性（由于具有重新发送消息的能力）和可伸缩性。然而，这带来了一定的困难，例如单次传输的语义以及长期的一致性问题。
服务之间的交互。 如果将应用程序划分为单独的服务，则存在服务之间的数据交换会花费太多时间或导致网络拥塞的风险（例如，使用微服务时）。
可管理性。 管理应用程序，监视其工作，部署更新和执行其他任务将有多困难？

N层架构

在N层体系结构中，应用程序分为逻辑层和物理层。

层是用于分担责任和管理依赖性的机制。每一层都有自己的职责范围。较高层使用较低层的服务，反之亦然。

这些级别在物理上是分开的，并且可以在不同的计算机上工作。一个级别可以直接访问另一个级别，也可以使用异步消息（消息队列）访问。尽管每一层都应放置在自己的水平上，但这不是必需的。您可以在一个级别上放置多个图层。级别的物理隔离不仅使解决方案具有更高的可扩展性和容错性，而且使速度更慢，因为该网络通常用于交互。传统的三层应用程序由表示层，中间层和数据库层组成。中间级别是可选的。更复杂的应用程序可以包含三个以上的级别。上图显示了一个具有两个中间级别的应用程序，它们负责各个功能区域。

N层应用程序可以具有封闭层体系结构或开放层体系结构。

在封闭式体系结构中，任意层只能访问最近的较低层。
在开放式体系结构中，任意层都可以引用任何较低层。

封闭层体系结构限制了层之间的依赖性。但是，如果特定层仅将请求转发到下一层，则其使用可能会大大增加网络流量。

建筑应用

N层体系结构通常用于IaaS应用程序，其中每个层都在一组单独的虚拟机上运行。但是，N层应用程序不必是纯IaaS应用程序。将托管服务用于解决方案的某些组件通常很方便，尤其是对于缓存，消息传递和数据存储。

在以下情况下，建议使用N层体系结构：

简单的Web应用程序；
以最少的重构将本地应用程序移植到Azure
本地和云应用程序的一致部署。

N层体系结构在普通的本地应用程序中很常见，因此非常适合将现有应用程序移植到Azure。

好处

在本地部署和云之间以及云平台之间转移应用程序的能力。
对于大多数开发人员而言，培训较少。
传统应用程序模型的自然扩展。
支持异构环境（Windows / Linux）。

缺点

很容易获得一个应用程序，其中中间层仅在数据库中执行CRUD操作，从而增加了请求的处理时间，并且没有带来任何好处。
单片架构不允许独立的开发团队开发单个组件。
管理IaaS应用程序比托管的仅服务应用程序更耗时。
在大型系统中可能难以管理网络安全性。

N层虚拟机架构

本节提供使用虚拟机构建N层体系结构的准则。

本节提供使用虚拟机构建N层体系结构的准则。每个层由两个或多个虚拟机组成，这些虚拟机托管在可用性集或可扩展的虚拟机集中。使用多个虚拟机可在其中一个虚拟机发生故障的情况下提供容错功能。为了在相同级别的虚拟机之间分配请求，使用了负载平衡子系统。可以水平缩放级别，将新的虚拟机添加到池中。

每个级别还放置在其自己的子网中。这意味着它们的内部IP地址在同一范围内。这样可以轻松地将网络安全组（NSG）规则和路由表应用于各个层。

Web层和业务层的状态不受监视。任何虚拟机都可以处理对这些级别的任何请求。数据层必须包含一个复制的数据库。对于Windows，我们建议将SQL Server与Always On可用性组一起使用以实现高可用性。对于Linux，您应该选择一个支持复制的数据库，例如Apache Cassandra。

对每个级别的访问受到网络安全组（NSG）的限制。例如，仅允许业务层访问数据库层

附加功能

N层体系结构不必由三层组成。更复杂的应用程序倾向于使用更多级别。在这种情况下，请使用通过第7层的路由将请求重定向到特定级别。
级别限制了有关可伸缩性，可靠性和安全性的决策。建议对这些特征有不同要求的服务使用不同级别。
通过可伸缩的虚拟机集使用自动缩放。
查找架构中可以通过托管服务实现而无需进行重大重构的元素。特别要注意缓存，消息传递，存储和数据库。
为了提高安全性，请将应用程序放置在外围网络之后。外围网络包括提供安全性的虚拟网络组件，例如防火墙和数据包检查器。有关更多信息，请参见外围参考网络体系结构。
为了获得高可用性，请将两个或多个虚拟网络组件放入可用性集中，并添加一个负载平衡器以在它们之间分发Internet请求。有关更多信息，请参见为高可用性部署虚拟网络组件。
不允许直接通过RDP和SSH协议访问运行应用程序代码的虚拟机。相反，操作员应进入堡垒节点。这是管理员位于网络上的虚拟机，用于连接到其他虚拟机。在堡垒主机上，NSG规则配置为仅允许从批准的公共IP地址通过RDP和SSH访问。
您可以使用虚拟网络（VPN）类型的网络到网络或Azure ExpressRoute将Azure虚拟网络扩展到本地网络。有关更多信息，请参见混合网络参考体系结构。
如果您的组织使用Active Directory进行身份管理，则可以将Active Directory环境扩展到Azure虚拟网络。有关更多信息，请参见身份管理参考体系结构。
如果要求的可用性级别高于Azure虚拟机服务级别协议要求的可用性级别，请在两个区域之间复制应用程序，并将Azure Traffic Manager配置为进行故障转移。有关更多信息，请参阅在多个区域中启动Windows虚拟机和在多个区域中启动Linux虚拟机。

您可以免费下载本书的完整版本，并在下面的链接中进行研究。

→ 下载

云架构应用指南

目录