SAP|SAP Commerce Cloud 架构概述

SAP Commerce Cloud Architecture
尽管我们在“SAP Commerce Cloud 入门”一文中介绍了 SAP Commerce Cloud 的一些高级架构,但在此我们将重点介绍在您的项目期间需要做出的一些实际架构决策。 使用 SAP Commerce Cloud 时,您可能会发现存在一些在 On-Premises 项目中不存在的限制。 然而,事实并非如此。这只是以不同方式设计您的解决方案的问题。
High-Level Software Architecture SAP Commerce Cloud 包含可用于创建定制商务解决方案的强制性和可选软件包的组合。 这些包括:
云自动化

  • Microsoft Azure - 公共云基础架构提供商
  • SAP 业务技术平台 - 用于托管 SAP Commerce Cloud Portal、SAP ntegration Suite 和 SAP Extension Suite 等应用程序/服务的业务平台
  • Kubernetes - 用于编排运行商业解决方案所需的 docker 节点
可定制的软件
  • SAP Commerce - 在 Cloud Portal 构建过程中与您的自定义代码结合的核心平台
  • Accelerator - 基于 SAP Commerce 中提供的模板的定制店面。
  • Spartacus JavaScript 店面 - 一个解耦的开源店面,它使用全方位商务连接 (OCC) API 与您的 SAP Commerce Cloud 环境进行通信。 有关更多详细信息,请参阅为您的 SAP Commerce Cloud 解决方案选择要使用的店面。
  • 行业加速器(文档) - 行业特定店面模板
  • 数据中心(文档)- 用于为每个 SAP Commerce Cloud 环境导入/导出主数据的选项。 有关更多详细信息,请参阅 SAP Commerce Cloud 的集成选项。
  • SAP 扩展套件 - 基于开源项目“Kyma”的微服务扩展层。 有关更多详细信息,请参阅 SAP Commerce Cloud 的集成选项。
SAP|SAP Commerce Cloud 架构概述
文章图片

Additional Server Hosting & Third-Party Software Applications 【SAP|SAP Commerce Cloud 架构概述】通常,您需要 SAP Commerce Cloud 解决方案与第三方应用程序进行交互。 如果您的第三方应用程序需要访问服务器或无法通过固定的构建和部署过程实现(即需要的不仅仅是通过“ant all”目标可以完成的工作),那么它就不能成为您的 SAP Commerce 的一部分 云代码,需要托管在其他地方。 本节更详细地记录了一些常见示例,但其他选项可能包括第三方 CMS 或为二进制包设置私有存储库。
在规划您的应用程序时,请仔细考虑哪些应用程序、二进制文件或基础架构组件(超出 Commerce 应用程序和数据库)构成您的目标架构的一部分。 本节中的示例不排除更多样化的目标架构,但确实需要一种架构设计,以促进生产性 SAP Commerce Cloud 订阅与单个项目所依赖的其他组件(不由 SAP 提供)之间的关注点分离 商务云)。
Continuous Integration / Continuous Delivery (CI/CD) 如果您正在寻找复杂的自动化管道或每次提交构建,您将需要设置自己的 CI/CD 实例。 这将为您提供灵活性和控制力,以确保在构建/部署到共享 SAP Commerce Cloud 环境之一之前构建和测试您的代码。 您可以使用 Commerce Cloud API 远程执行构建/部署。 您的 CI/CD 实例应该能够连接到 SAP Commerce Cloud 使用的同一个 Git 存储库。 CI/CD 应用程序的位置并不重要,因为它不会直接影响 SAP Commerce Cloud 解决方案的性能。 如果您发现从 Git 存储库中提取代码的延迟太长,您可以考虑更换您的 CI/CD 应用程序的托管位置。 有关为 SAP Commerce Cloud 解决方案设置 CI/CD 的更多信息,请参阅使用 SAP Commerce Cloud 实施持续交付。
Image Resizing 图像大小调整通常在 Commerce 中通过扩展完成,该扩展通常依赖于安装在 Commerce 服务器上的第三方软件 (ImageMagick)。 在 Cloud Automation 1912 版本中,SAP Commerce Cloud 中提供了图像转换服务,并且可以在清单文件中包含 cloudmediaconversion 扩展时启用。
Third Party Application 如果您的 SAP Commerce Cloud 解决方案需要尚未由第三方托管的应用程序,您应该考虑在何处托管它。 建议尝试通过在与 Commerce Cloud 订阅相同的 Azure 日期中心运行它来尽量减少延迟。 如果您不知道正在使用哪个数据中心,您可以通过云可用性中心找到此信息。 如果您不想使用 Azure,您可以在同一地区寻找等效的公共云提供商,尽管当呼叫转到外部数据中心时可能会有额外的延迟。 如果它是一个异步调用或一个不经常发生的调用,那么这种额外的延迟可能不是您的解决方案的关键。
SAP|SAP Commerce Cloud 架构概述
文章图片

上面的示例包含一个在自托管服务器上运行的应用程序,并公开 REST 服务,这些服务可由您的一个或多个 SAP Commerce Cloud 方面调用。
E-mail Service SAP Commerce 使用 Web 内容管理系统 (WCMS) 模块来定义和生成电子邮件,从而利用在电子邮件文本中呈现的 WCMS 组件。 在幕后,Apache Commons 电子邮件库提供了所有必需的软件基础设施,将解决方案与简单邮件传输协议 (SMTP) 联系起来。 SAP Commerce Cloud 充当客户端,但需要 SMTP 服务器/服务。
SAP Commerce Cloud 不提供 SMTP 服务器,这意味着您必须提供备用 SMTP 策略。
SAP|SAP Commerce Cloud 架构概述
文章图片

Cloud Hot Folders (Extended Hot Folders) Hot Folders 已发展成为 SAP Commerce Cloud 的基于文件的集成策略,现在称为 Cloud Hot Folders。
下图概括地显示了该解决方案如何从 SAP 基础架构上的 SAP Commerce Cloud 演变为新的 SAP Commerce Cloud。 主要更新如下:
  • 远程存储支持(Azure 云存储)
  • 支持 ZIP 文件(核心数据、样本数据和原始 ImpEx 文件)
  • 支持 URL 媒体文件
  • 文件排序
  • 改进的监控
SAP|SAP Commerce Cloud 架构概述
文章图片

在 SAP Commerce Cloud 中,Hot Folders 模块已扩展为包括上述改进。 由于 SAP Commerce Cloud 使用临时磁盘存储,不再提供 SSH 文件传输协议 (SFTP) 服务器(用于上传媒体)或数据文件(用于导入)。 相反,您有一个使用 Azure Blob 存储作为文件源的云热文件夹。
SAP|SAP Commerce Cloud 架构概述
文章图片

Caching Content Delivery Network 获取要缓存的端点的 IP(例如,店面、后台)。 要在 Cloud Portal 中执行此操作,请选择环境,然后单击端点的端点链接。 当编辑端点屏幕打开时,找到基本配置部分中的域字段。 端点的 DNS 名称是域地址。 您可以尝试使用 NS 查找来获取 IP.
在您的环境期间,您的端点的 IP 是静态的。 如果您的环境被重新配置,IP 很可能会改变。 因此,您还需要通过 CDN 提供商进行更新。
SAP|SAP Commerce Cloud 架构概述
文章图片

将这些 IP 提供给您的 CDN 提供商。
如果您的端点不可公开访问,请确保您已将 CDN 添加到 IP 过滤器列表中。
Region Cache SAP Commerce Cloud 利用 SAP Commerce 的现有区域缓存。 但是,由于 SAP Commerce Cloud 构建过程控制 Java 堆大小,这可能因环境而异,因此需要以灵活的方式配置缓存区域,而不是在内部设置固定值。
Cronjobs Execution 准备使用 SAP Commerce Cloud 时的一个关键考虑因素是,在处理代表生产的数据集时,确保任何批量处理作业在“backgroundProcessing”方面的固定资源占用范围内可靠运行。 如果您从 SAP 基础架构上的 SAP Commerce Cloud 或本地实例迁移,则尤其如此。 'backgroundProcessing' 方面将运行任何自动触发的 cronjob; 如果您从“后台”方面手动触发作业,它将在触发它的节点上运行。
例如,可以开发加载价格信息的批量处理作业,将整个价格行文件加载到内存中进行处理。 在处理文件导入时,这通常被认为是不好的做法。 原因在于,虽然在使用小数据集进行测试时,这可能在开发环境中可靠地工作,但在生产环境中,实际价格行文件的大小可能有数百兆字节,并且需要显式增加分配给 Java 虚拟机的资源才能将文件可靠地加载到 内存中。 如果这种情况发生在 SAP Commerce Cloud 上,则无法扩展分配给单个“后台处理”节点的资源。
因此,所有批量处理作业都应开发为:
  • 有效利用分配的资源,批量导入并主动释放引用,以在整个导入过程中实现一致的内存配置文件。
  • 避免不必要地将大型数据集加载到内存中。
  • 在“backgroundProcessing” aspect 分发大批量处理任务。
使用现有项目迁移到 SAP Commerce Cloud 的客户应检查其批量处理作业,以验证他们是否遵守了这些准则。
Conclusion 尽管 SAP Commerce Cloud 以一致的架构提供了大部分基础设施,但总会有外部系统需要与您的商务解决方案进行交互。 正确理解 SAP Commerce Cloud 现有架构的特性和优势将有助于您设计新的集成。
更多Jerry的原创文章,尽在:"汪子熙":
SAP|SAP Commerce Cloud 架构概述
文章图片

    推荐阅读