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