发布于: Jul 29, 2022
通过批量 fetch，优化程序逻辑等方法可以缓解延迟造成的性能问题，但为了适配高可用架构来调整应用程序并不是一个好的选择，相反，这将成为在云上获得最佳表现的一个巨大阻碍
在 SAP 企业系统管理软件云上官方架构设计指引中，展示了如何利用其多可用区的技术优势、诸如 Route 53、NLB 等基础设施服务以及 SAP 或操作系统的高可用技术实现端到端的跨可用区高可用方案。
此架构优点是符合 SAP 与亚马逊云科技最佳实践的无单点故障跨可用区高可用方案，而且易于实现，只需要安装部署人员按照官方指引或者使用 Amazon QuickStart/LaunchWizard 就可以实现；但对于追求云上最佳用户体验的客户，其可能需要考虑如下问题：由于同区域内不同可用区之间的延迟必然远远高于同可用区内的延迟，如当可用区 AZ2 上的 SAP 应用实例与可用区 AZ1 上的 HANA 数据库主实例交互时，其运行的程序均会受到延迟的影响形成性能影响；这造成了终端用户或程序将有 50% 的概率获得比较明显的体验差异。
以上 ABAPMeter 的结果来自一套根据 SAP 云上官方架构设计指引设计在亚马逊云科技北京区域搭建的 SAP 系统，其中 saptstapp01 与数据库主节点放在同一可用区内，而 saptstapp02 位于与数据库主节点不同的可用区；可以看到由于跨可用区的网络延迟，saptstapp02 的数据库访问性能（数据列 Acc DB 与 E. Acc DB）比 saptstapp01 慢了近 7 倍，根据 ABAPMeter 的源码，此数值为循环 200 次简单数据库单行查询（SELECT SINGLE）的总时间；除了 SAP 官方推荐此数值应低于 150ms（SAP Note 2879613）之外，值得一提的是不同节点数据库性能表现的差异将是造成终端用户日常体验差异的一个巨大隐患。
更进一步地分析，这种由延迟差异所造成的性能表现差异是由 SAP 应用的数据库访问特点造成的；SAP 作为数据库交互密集型的应用，为其 ABAP 开发人员提供了 OPEN SQL 这样的数据库交互层，而其强大灵活的功能使得程序的数据库开发模式多种多样，具体来说，跨可用区的延迟将对如下几种程序编写模式产生显著影响。
- 使用游标逐行 fetch 大结果集
- 通过 SQL 一次性取出大结果集保存在内表（itab），然后对其进行循环，并在循环中再进行一次或多次数据库查询
- 密集型逐条插入/删除/修改
- 存在大量短小的数据库访问
实际上这些场景并不少见，而且根据上面的 ABAPMeter 测试结果来看，对于上述数据库密集型访问模式，传统高可用方案中不同可用区的 SAP 应用节点的处理性能差异将会接近 7 倍；虽然通过批量 fetch，优化程序逻辑等方法可以缓解延迟造成的性能问题，但我们认为为了适配高可用架构来调整应用程序并不是一个好的选择，相反，这将成为在云上获得最佳表现的一个巨大阻碍。
相关文章