混合应用设计注意事项
Microsoft Azure 是唯一一致的混合云。 它允许重复使用开发投资，并启用可跨全球 Azure、主权 Azure 云和 Azure Stack 的应用，后者是数据中心内 Azure 的扩展。 跨云的应用也称为 混合应用。
Azure 应用程序体系结构指南 介绍了用于设计可缩放、可复原且高度可用的应用的结构化方法。 Azure 应用程序体系结构指南中所述的注意事项 同样适用于为单个云和跨云的应用设计的应用。
本文扩充了
混合方案因可用于开发的资源而有很大差异，并跨越地理、安全、Internet 访问和其他注意事项等注意事项。 虽然本指南无法枚举具体的注意事项，但它可以提供一些关键准则和最佳做法供你遵循。 成功设计、配置、部署和维护混合应用体系结构涉及许多设计注意事项，这些注意事项可能本身就未知。
本文档旨在聚合实现混合应用时可能出现的问题，并提供使用它们时的注意事项（这些支柱）和最佳做法。 通过在设计阶段解决这些问题，可以避免在生产过程中导致的问题。
从本质上讲，在创建混合应用之前，需要考虑这些问题。 若要开始，需要执行以下操作：
- 识别和评估应用组件。
- 根据支柱评估应用组件。
评估应用组件
应用的每个组件在较大的应用中都有自己的特定角色，应查看所有设计注意事项。 每个组件的要求和功能都应映射到这些注意事项，以帮助确定应用体系结构。
通过研究应用的体系结构并确定其包含的内容，将应用分解为其组件。 组件还可以包含应用与之交互的其他应用。 确定组件时，请通过提出以下问题，根据预期混合操作的特征评估预期混合操作：
- 组件的用途是什么？
- 组件之间的相互依赖关系是什么？
例如，应用可以具有定义为两个组件的前端和后端。 在混合方案中，前端位于一个云中，后端位于另一个云中。 应用在前端和用户之间以及前端和后端之间提供通信通道。
应用组件由许多窗体和方案定义。 最重要的任务是识别它们及其云或本地位置。
清单中包含的常见应用组件列在表 1 中。
表 1. 常见应用组件
| 组件 | 混合应用指南 |
|---|---|
| 客户端连接 | 你的应用（在任何设备上）可以通过各种方式从单一入口点访问用户，包括以下方法： - 客户端服务器模型，要求用户安装客户端才能使用应用。 从浏览器访问的基于服务器的应用。 - 客户端连接可以在连接中断时包括通知，或者在漫游费用可能适用时发出警报。 |
| 认证 | 用户连接到应用或从一个连接到另一个组件的组件，可能需要身份验证。 |
| 蜜蜂属 | 你可以通过 API 集和类库为开发人员提供对应用的编程访问，并基于 Internet 标准提供连接接口。 还可以使用 API 将应用分解为独立操作的逻辑单元。 |
| 服务业 | 可以使用简洁的服务为应用提供功能。 服务可以是应用运行的引擎。 |
| 队列 | 可以使用队列来组织应用的组件的生命周期和状态。 这些队列可以为订阅方提供消息传送、通知和缓冲功能。 |
| 数据存储 | 应用可以是无状态或有状态的。 有状态应用需要可通过多种格式和卷满足的数据存储。 |
| 数据缓存 | 设计中的数据缓存组件可以战略性地解决延迟问题，并在触发云突发方面发挥作用。 |
| 数据引入 | 可以通过多种方式将数据提交到应用，从 Web 表单中的用户提交值到持续大量的数据流。 |
| 数据处理 | 数据处理任务（例如报表、分析、批处理导出和数据转换）可以在源处进行处理，也可以使用数据副本卸载在单独的组件上。 |
评估支柱的应用组件
对于每个组件，评估每个支柱的特征。 当你使用所有支柱评估每个组件时，你可能没有考虑的问题可能会让你知道，这些问题会影响混合应用的设计。 根据这些注意事项进行操作可能会增加优化应用的价值。 表 2 提供了与混合应用相关的每个支柱的说明。
表 2. 支柱
| 支柱 | 说明 |
|---|---|
| 放置 | 混合应用中组件的战略定位。 |
| 可伸缩性 | 系统处理增加的负载的能力。 |
| 可用性 | 混合应用正常运行的时间比例。 |
| 弹性 | 混合应用恢复的功能。 |
| 可管理性 | 使系统在生产环境中运行的操作进程。 |
| 安全 | 保护混合应用和数据免受威胁。 |
放置
混合应用本质上具有放置注意事项，例如数据中心。
放置是定位组件的重要任务，以便它们可以最好地为混合应用提供服务。 根据定义，混合应用跨越位置，例如从本地到云以及不同云。 可以通过两种方式将应用的组件放置在云上：
垂直混合应用
应用组件分布在各个位置。 每个单个组件只能有多个实例位于单个位置。水平混合应用
应用组件分布在各个位置。 每个单个组件可以有多个跨多个位置的实例。某些组件可以了解其位置，而其他人则不知道其位置和位置。 这种良性性可以通过抽象层实现。 此层具有现代应用框架（如微服务）可以定义应用如何通过跨云节点上运行的应用组件来提供服务。
放置清单
验证所需的位置。 确保应用或其任何组件都需要在特定云中运行或需要认证。 这可以包括贵公司的主权要求，也可以由法律决定。 此外，确定特定位置或区域设置是否需要任何本地操作。
确定连接依赖关系。 所需的位置和其他因素可以决定组件之间的连接依赖关系。 放置组件时，确定它们之间通信的最佳连接和安全性。 选择包括 VPN、ExpressRoute、 和 混合连接。
评估平台功能。 对于每个应用组件，请参阅应用组件所需的资源提供程序是否在云中可用，以及带宽是否可以满足预期的吞吐量和延迟要求。
规划可移植性。 使用新式应用框架（如容器或微服务）来规划移动操作并防止服务依赖项。
确定数据主权要求。 混合应用旨在容纳数据隔离，例如在本地数据中心。 查看资源的位置，以优化成功以适应此要求。
规划延迟。 云间操作可以在应用组件之间引入物理距离。 确定满足任何延迟的要求。
控制流量流。 在公有云中前端访问时，处理峰值使用情况以及个人身份信息数据的相应安全通信。
可伸缩性
可伸缩性是系统处理应用负载增加的能力，这在一段时间内可能会有所不同，因为其他因素和强制影响受众大小，以及应用的大小和范围。
有关此支柱的核心讨论，请参阅体系结构卓越五大支柱中的 可伸缩性。
混合应用的水平缩放方法允许添加更多实例以满足需求，然后在更安静的时间段内禁用它们。
在混合方案中，在组件分散到云中时，横向扩展各个组件需要进一步考虑。 缩放应用的一部分可能需要缩放另一部分。 例如，如果客户端连接数增加，但应用的 Web 服务未适当横向扩展，则数据库上的负载可能会使应用饱和。
某些应用组件可以线性横向扩展，而另一些组件则具有缩放依赖项，并且可能仅限于它们能够缩放的程度。 例如，为应用组件位置提供混合连接的 VPN 隧道对可缩放到的带宽和延迟有限制。 如何缩放应用的组件以确保满足这些要求？
可伸缩性清单
确定缩放阈值。 若要处理应用中的各种依赖项，请确定不同云中的应用组件可以相互独立缩放的程度，同时仍满足运行应用的要求。 混合应用通常需要缩放应用中的特定区域，以在功能交互并影响应用的其余部分时处理该功能。 例如，超过许多前端实例可能需要缩放后端。
定义缩放计划。 大多数应用都有繁忙时段，因此需要将其高峰时间聚合到计划中，以协调最佳缩放。
使用集中式监视系统。 平台监视功能可以提供自动缩放，但混合应用需要聚合系统运行状况和负载的集中式监视系统。 集中式监视系统可以启动在一个位置缩放资源，并根据另一个位置的资源进行缩放。 此外，中央监视系统还可以跟踪哪些云自动缩放资源和哪些云没有。
利用自动缩放功能（如可用）。 如果自动缩放功能是体系结构的一部分，则可以通过设置阈值来实现自动缩放，这些阈值定义何时需要纵向扩展、横向扩展、缩减或缩减应用组件。 自动缩放的一个示例是一个客户端连接，该连接在一个云中自动缩放以处理增加的容量，但会导致应用的其他依赖项（分布在不同的云中）也会进行缩放。 必须确定这些依赖组件的自动缩放功能。
如果自动缩放不可用，请考虑实现脚本和其他资源以适应手动缩放，这由集中式监视系统中的阈值触发。
按位置确定预期的负载。 处理客户端请求的混合应用可能主要依赖于单个位置。 当客户端请求的负载超过阈值时，可以在其他位置添加其他资源，以分配入站请求的负载。 确保客户端连接可以处理增加的负载，并确定客户端连接处理负载的任何自动化过程。
可用性
可用性是系统正常运行的时间。 可用性按运行时间百分比进行度量。 应用错误、基础结构问题和系统负载都可以降低可用性。
有关此支柱的核心讨论，请参阅体系结构卓越五大支柱中的 可用性。
可用性清单
为连接提供冗余。 混合应用需要在应用分散的云之间建立连接。 可以选择混合连接技术，因此，除了主要技术选择之外，如果主要技术发生故障，请使用另一种技术来提供具有自动故障转移功能的冗余。
对容错域进行分类。 容错应用需要多个容错域。 容错域有助于隔离故障点，例如，如果单个硬盘在本地发生故障、机架顶部交换机出现故障，或者整个数据中心不可用。 在混合应用中，可将位置分类为容错域。 随着可用性要求增加，需要评估单个容错域的分类方式越多。
对升级域进行分类。 升级域用于确保应用组件的实例可用，而同一组件的其他实例则通过更新或功能升级提供服务。 与容错域一样，升级域可以按其跨位置的位置进行分类。 在将应用组件升级到另一个位置之前，必须确定应用组件是否可以容纳在一个位置升级，或者是否需要其他域配置。 单个位置本身可以有多个升级域。
跟踪实例和可用性。 高度可用的应用组件可以通过负载均衡和同步数据复制获得。 在服务中断之前，必须确定可以脱机的实例数。
实现自我修复。 如果问题导致应用可用性中断，监视系统的检测可能会启动对应用的自我修复活动，例如清空失败的实例并重新部署它。 很可能这需要一个中央监视解决方案，与混合持续集成和持续交付（CI/CD）管道集成。 该应用与监视系统集成，用于识别可能需要重新部署应用组件的问题。 监视系统还可以触发混合 CI/CD 来重新部署应用组件，以及可能位于相同或其他位置的任何其他依赖组件。
维护服务级别协议（SLA）。 可用性对于任何协议都至关重要，用于维护与客户提供的服务和应用的连接。 混合应用依赖的每个位置都有其自己的 SLA。 这些不同的 SLA 可能会影响混合应用的整体 SLA。
弹性
复原能力是混合应用和系统能够从故障中恢复并继续正常运行。 复原的目标是在发生故障后将应用返回到完全正常运行的状态。 复原策略包括备份、复制和灾难恢复等解决方案。
有关此支柱的核心讨论，请参阅体系结构卓越五大支柱中的 复原能力。
复原能力清单
发现灾难恢复依赖项。 一个云中的灾难恢复可能需要更改另一个云中的应用组件。 如果从一个云中的一个或多个组件故障转移到另一个位置（位于同一云中或另一个云中），则需要了解这些更改。 这还包括连接依赖项。 复原需要针对每个云的完全测试的应用恢复计划。
建立恢复流。 有效的恢复流设计评估了应用组件，使其能够容纳缓冲区、重试、重试失败的数据传输，并在必要时回退到其他服务或工作流。 必须确定要使用的备份机制、其还原过程涉及什么，以及它测试的频率。 还应确定增量备份和完整备份的频率。
测试部分恢复。 部分应用的部分恢复可以向用户保证所有内容都不可用。 计划的这一部分应确保部分还原没有任何副作用，例如与应用交互的备份和还原服务，以在进行备份之前正常关闭它。
确定灾难恢复煽动者和分配责任。 除了可以备份和还原哪些操作之外，恢复计划还应描述谁以及哪些角色可以启动备份和恢复操作。
将自我修复阈值与灾难恢复进行比较。 确定应用的自动恢复启动的自我修复功能，以及应用自我修复被视为失败或成功所需的时间。 确定每个云的阈值。
验证复原功能的可用性。 确定每个位置的复原特性和功能的可用性。 如果某个位置不提供所需的功能，请考虑将该位置集成到提供复原功能的集中式服务中。
确定停机时间。 确定由于整个应用和应用组件维护而导致的预期停机时间。
记录故障排除过程。 定义用于重新部署资源和应用组件的故障排除过程。
可管理性
管理混合应用的注意事项对于设计体系结构至关重要。 托管良好的混合应用提供基础结构即代码，用于在通用开发管道中集成一致的应用代码。 通过对基础结构进行一致的系统范围和单个更改测试，可以确保在更改通过测试时进行集成部署，从而允许将它们合并到源代码中。
有关此支柱的核心讨论，请参阅 DevOps 体系结构卓越五大支柱。
可管理性清单
实现监视。 使用分散在云中的应用组件的集中式监视系统来提供其运行状况和性能的聚合视图。 此系统包括监视应用组件和相关平台功能。
确定需要监视的应用部分。
协调策略。 混合应用跨越的每个位置都可以有自己的策略，这些策略涵盖允许的资源类型、命名约定、标记和其他条件。
定义和使用角色。 作为数据库管理员，需要确定需要访问应用资源的不同角色（例如应用所有者、数据库管理员和最终用户）所需的权限。 需要在资源和应用内部配置这些权限。 基于角色的访问控制 （RBAC） 系统允许对应用资源设置这些权限。 当所有资源部署在单个云中时，这些访问权限具有挑战性，但当资源分散在云中时，需要更多关注。 一个云中设置的资源的权限不适用于另一个云中设置的资源。
使用 CI/CD 管道。 持续集成和持续开发（CI/CD）管道可以提供一致的流程，用于创作和部署跨云的应用，并为其基础结构和应用提供质量保证。 此管道使基础结构和应用能够在一个云上进行测试，并部署在另一个云上。 管道甚至允许将混合应用的某些组件部署到一个云，并将其他组件部署到另一个云，这实质上构成了混合应用部署的基础。 CI/CD 系统对于在安装过程中处理应用组件彼此具有的依赖项至关重要，例如需要数据库连接字符串的 Web 应用。
管理生命周期。 由于混合应用的资源可以跨越位置，因此需要将每个位置的生命周期管理功能聚合到单个生命周期管理单元中。 请考虑如何创建、更新和删除它们。
检查故障排除策略。 对混合应用进行故障排除涉及的应用组件多于在单个云中运行的相同应用。 除了云之间的连接外，应用在两个平台上运行，而不是一个平台。 排查混合应用问题时，一项重要任务是检查应用组件的聚合运行状况和性能监视。
安全
安全性是任何云应用的主要注意事项之一，对于混合云应用而言，安全性变得更加重要。
有关此支柱的核心讨论，请参阅体系结构卓越五大支柱中的 安全。
安全清单
假设存在违规。 如果应用的一部分遭到入侵，请确保有一些解决方案可以最大程度地减少违规的传播，不仅在同一位置，而且跨位置。
监视允许的网络访问。 确定应用的网络访问策略，例如仅从特定子网访问应用，并且仅允许应用正常运行所需的组件之间的最小端口和协议。
采用可靠的身份验证。 可靠的身份验证方案对于应用的安全性至关重要。 请考虑使用提供单一登录功能的联合标识提供者，并采用以下一个或多个方案：用户名和密码登录、公钥和私钥、双因素或多重身份验证以及受信任的安全组。 确定用于存储敏感数据和其他机密的适当资源，以用于应用身份验证，以及证书类型及其要求。
使用加密。 确定应用使用加密的区域，例如数据存储或客户端通信和访问。
使用安全通道。 跨云的安全通道对于跨云提供安全和身份验证检查、实时保护、隔离和其他服务至关重要。
定义和使用角色。 实现跨云的资源配置和单标识访问的角色。 确定应用及其平台资源的基于角色的访问控制（RBAC）要求。
审核系统。 系统监视可以记录和聚合来自应用组件和相关云平台操作的数据。
总结
本文提供了在创作和设计混合应用期间必须考虑的项清单。 在部署应用之前查看这些支柱可防止在生产中断中遇到这些问题，并可能需要重新访问设计。
它似乎是一个耗时的任务，但如果你根据这些支柱设计应用，你很容易获得投资回报。
后续步骤
有关详细信息，请参阅以下资源：