本文内容来自Architecting solutions on SAP BTP for High Availab… – SAP Community，Distributed Resiliency of SAP CAP applications usi… – SAP Community，目的是帮助您理解架构设计如何为应用提供更高的韧性
如果您对BTP感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容
本文档包含以下部分：
1.前言
2.三种级别的可用性
3.High level实现步骤
1.前言：
SAP BTP 拥有很多能力，但并不具有所有能力，所以在成熟架构中的BTP往往会结合其他技术，例如 PostgreSQL on BTP实际上就利用了IaaS厂商Host的数据库、以及其他服务例如对象存储。
同时，BTP提供了SAP Private Link以从更快速更安全的内部网络从BTP连接到其所在的IaaS数据中心，进而连接到该IaaS厂商的所有数据中心。
本文主题是如何构建支持在 SAP BTP 上运行的关键应用程序实现高可用性（HA）的解决方案。由于 SAP BTP 运行在IaaS之上，它可以受益于IaaS所采用的成熟的AZ机制。
AZ（AZ）是单个地理区域内的单一故障域，是具有独立电力、网络和冷却设施的不同物理位置。一个Region内存在多个AZ，它们通过低延迟网络相互连接。SAP BTP 服务基于底层IaaS的AZ运行，从而实现高可用性。因此，如果其中一个AZ发生故障，服务 / 应用程序将自我修复，并继续由该区域内的其他AZ提供服务。
BTP在不同的 IaaS 提供商上提供遍布全球的 SAP BTP 账户，无论您是开发 Fiori 应用程序作为扩展，还是使用集成套件开发接口，都可以轻松地在不同提供商的 BTP 账户之间移动这些项目。
在下面的解决方案图中包含了开发 / 测试 / 生产环境（位于美国 Azure）和另一个生产环境（位于欧盟 Azure）。所有的开发和测试都在标记为开发 / 测试的子账户中进行，并且通过传输管理服务将更改推送到整个环境中。如您所见，两个地区各有一个生产性子账户。请参考有关应用程序部署最佳实践的文档。传输管理和持续集成 / 持续交付（CI/CD）服务的路线图会不断更新。请检查您要传输的项目是否受支持。
2.三种级别的可用性
要提高应用的可用性，
首先可以做的是在同一BTP子账户下增加实例，用以在同一数据中心中部署多份应用，BTP会自动根据不同实例的可用性来切换服务
其次，我们还可以将应用部署在同一Region的多个AZ
最后，我们还可以将应用部署在不同Region
场景 1：跨AZ故障转移
对于终端客户来说，这是透明的，流量会根据负载和可用性被定向到 Fiori Launchpad。
场景 2：跨Region故障转移与负载分配
假设终端用户分散在欧盟和美国，并且希望对 SAP BTP 上暴露的 Fiori Launchpad进行负载均衡。Fiori 启动台部署在欧盟和美国的 SAP BTP 账户上。两个启动台都配置了相同的自定义域名。为了便于说明，我使用了 Azure 流量管理器，它是一个基于 DNS 的流量负载均衡器。流量管理器的目的是在这两个启动台之间分配流量，并且还支持在其中一个启动台出现故障时（例如，当维护窗口导致服务中断等情况），将流量路由到另一个启动台实例。您可以配置不同的路由规则，为终端用户提供最佳体验。有一份最佳实践文档，解释了一些如何识别故障转移以及使用基于规则的解决方案（如 Akamai ION）的方法。
在SAP官方的参考架构图中也可以找到类似设计: Architecting multi-region resiliency for SAP BTP use cases
3.实现路径：
有多种原则和模式可用于提升应用程序的弹性。然而，要找到最适合自己应用程序的组合并非易事。《在 SAP BTP 上开发弹性应用程序指南》概述了你可采用的各种选项，以及关于你可能运用的特定模式的详细信息。
大多数 SAP BTP 服务支持使用可用区（AZ）来实现高可用性。不过，可用区局限于单个区域，对于关键任务应用程序而言，这是不够的。实施多区域架构，可进一步减少停机时间、降低区域延迟，或者单纯将此架构用作负载均衡器，在不同区域间分散不断增长的流量。
运用多区域架构概念的应用程序的双活（分布式弹性）设置。
解决方案架构
使用 SAP HANA Cloud 的 SAP CAP 应用程序分布式弹性
在这个用法中，SAP CAP 应用程序分布在不同区域，并连接到 SAP HANA Cloud 数据库。传入请求通过 Azure 流量管理器路由到相应区域。
为优化应用程序的响应时间，我们建议将其部署在目标受众和后端系统所在的数据中心。例如，欧洲的用户可选择法兰克福和阿姆斯特丹的数据中心。
注意：如果你希望在不同区域的数据中心部署应用程序，请注意可能存在与合法数据处理限制相关的问题。欲了解更多信息，请参阅《数据保护与隐私》。
High Level的实施步骤
在来自不同区域或超大规模云服务提供商的两个子账户中使用 SAP BTP Cloud Foundry 运行时。自定义域名 URL 作为 SAP CAP 应用程序的单一入口点。使用 SAP BTP 自定义域名服务，配置自定义域名并将其映射到 SAP CAP 应用程序的路由。Azure 流量管理器是一个智能组件，可监控应用程序的运行状况，并在发生故障转移时将用户请求发送到另一个区域。使用 SAP 云传输管理服务，将 SAP CAP 应用程序顺利同步到多个区域。
在实施此架构时，要考虑不同子账户中重复服务的订阅成本，并确保应用程序始终保持同步。还需要配置单点登录（SSO），以实现区域间的无缝切换。
如果你想尝试此场景，我们在SAP发现中心有详细的分步任务说明
关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果需要帮助，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间
本文内容来自Architecting solutions on SAP BTP for High Availab… – SAP Community，Distributed Resiliency of SAP CAP applications usi… – SAP Community，目的是帮助您理解架构设计如何为应用提供更高的韧性 如果您对BTP感兴趣，BTP个人精选内容目录 | SAP Blogs 可能有更多你需要的内容 本文档包含以下部分：1.前言2.三种级别的可用性3.High level实现步骤 1.前言：SAP BTP 拥有很多能力，但并不具有所有能力，所以在成熟架构中的BTP往往会结合其他技术，例如 PostgreSQL on BTP实际上就利用了IaaS厂商Host的数据库、以及其他服务例如对象存储。同时，BTP提供了SAP Private Link以从更快速更安全的内部网络从BTP连接到其所在的IaaS数据中心，进而连接到该IaaS厂商的所有数据中心。 本文主题是如何构建支持在 SAP BTP 上运行的关键应用程序实现高可用性（HA）的解决方案。由于 SAP BTP 运行在IaaS之上，它可以受益于IaaS所采用的成熟的AZ机制。 AZ（AZ）是单个地理区域内的单一故障域，是具有独立电力、网络和冷却设施的不同物理位置。一个Region内存在多个AZ，它们通过低延迟网络相互连接。SAP BTP 服务基于底层IaaS的AZ运行，从而实现高可用性。因此，如果其中一个AZ发生故障，服务 / 应用程序将自我修复，并继续由该区域内的其他AZ提供服务。 BTP在不同的 IaaS 提供商上提供遍布全球的 SAP BTP 账户，无论您是开发 Fiori 应用程序作为扩展，还是使用集成套件开发接口，都可以轻松地在不同提供商的 BTP 账户之间移动这些项目。 在下面的解决方案图中包含了开发 / 测试 / 生产环境（位于美国 Azure）和另一个生产环境（位于欧盟 Azure）。所有的开发和测试都在标记为开发 / 测试的子账户中进行，并且通过传输管理服务将更改推送到整个环境中。如您所见，两个地区各有一个生产性子账户。请参考有关应用程序部署最佳实践的文档。传输管理和持续集成 / 持续交付（CI/CD）服务的路线图会不断更新。请检查您要传输的项目是否受支持。 2.三种级别的可用性要提高应用的可用性，首先可以做的是在同一BTP子账户下增加实例，用以在同一数据中心中部署多份应用，BTP会自动根据不同实例的可用性来切换服务其次，我们还可以将应用部署在同一Region的多个AZ最后，我们还可以将应用部署在不同Region 场景 1：跨AZ故障转移对于终端客户来说，这是透明的，流量会根据负载和可用性被定向到 Fiori Launchpad。 场景 2：跨Region故障转移与负载分配 假设终端用户分散在欧盟和美国，并且希望对 SAP BTP 上暴露的 Fiori Launchpad进行负载均衡。Fiori 启动台部署在欧盟和美国的 SAP BTP 账户上。两个启动台都配置了相同的自定义域名。为了便于说明，我使用了 Azure 流量管理器，它是一个基于 DNS 的流量负载均衡器。流量管理器的目的是在这两个启动台之间分配流量，并且还支持在其中一个启动台出现故障时（例如，当维护窗口导致服务中断等情况），将流量路由到另一个启动台实例。您可以配置不同的路由规则，为终端用户提供最佳体验。有一份最佳实践文档，解释了一些如何识别故障转移以及使用基于规则的解决方案（如 Akamai ION）的方法。在SAP官方的参考架构图中也可以找到类似设计: Architecting multi-region resiliency for SAP BTP use cases 3.实现路径：有多种原则和模式可用于提升应用程序的弹性。然而，要找到最适合自己应用程序的组合并非易事。《在 SAP BTP 上开发弹性应用程序指南》概述了你可采用的各种选项，以及关于你可能运用的特定模式的详细信息。大多数 SAP BTP 服务支持使用可用区（AZ）来实现高可用性。不过，可用区局限于单个区域，对于关键任务应用程序而言，这是不够的。实施多区域架构，可进一步减少停机时间、降低区域延迟，或者单纯将此架构用作负载均衡器，在不同区域间分散不断增长的流量。运用多区域架构概念的应用程序的双活（分布式弹性）设置。解决方案架构 使用 SAP HANA Cloud 的 SAP CAP 应用程序分布式弹性 在这个用法中，SAP CAP 应用程序分布在不同区域，并连接到 SAP HANA Cloud 数据库。传入请求通过 Azure 流量管理器路由到相应区域。 为优化应用程序的响应时间，我们建议将其部署在目标受众和后端系统所在的数据中心。例如，欧洲的用户可选择法兰克福和阿姆斯特丹的数据中心。 注意：如果你希望在不同区域的数据中心部署应用程序，请注意可能存在与合法数据处理限制相关的问题。欲了解更多信息，请参阅《数据保护与隐私》。High Level的实施步骤在来自不同区域或超大规模云服务提供商的两个子账户中使用 SAP BTP Cloud Foundry 运行时。自定义域名 URL 作为 SAP CAP 应用程序的单一入口点。使用 SAP BTP 自定义域名服务，配置自定义域名并将其映射到 SAP CAP 应用程序的路由。Azure 流量管理器是一个智能组件，可监控应用程序的运行状况，并在发生故障转移时将用户请求发送到另一个区域。使用 SAP 云传输管理服务，将 SAP CAP 应用程序顺利同步到多个区域。 在实施此架构时，要考虑不同子账户中重复服务的订阅成本，并确保应用程序始终保持同步。还需要配置单点登录（SSO），以实现区域间的无缝切换。如果你想尝试此场景，我们在SAP发现中心有详细的分步任务说明 关于本文内容有任何问题或见解，欢迎在评论区留下你的想法，如果需要帮助，也可以直接联系到我 arthuryang1996@foxmail.com，感谢你的时间 Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
