本文是笔者作为 SAP 2020 全球技术大会(SAP TechEd)，“客户自主”时代的极致体验分论坛内容之一的演讲者,给 SAP 从业者做的一个分享。

本文的分享主要分为以下四个方面来介绍 Spartacus.

首先，通过 Spartacus 四大特性的介绍，让大家对作为 SAP Commerce Cloud 新一代 Storefront 这个电商前台店铺应用有一个直观的了解。Spartacus 的首页如下图所示，其 logo 是一个印有闪电的购物袋，象征着 Spartacus 能为用户带来流畅快捷的在线购物体验。

其次，通过和 Commerce Cloud 原有的基于 Accelerator 技术的 Storefront 相比较，让大家了解 SAP 推出 Spartacus 的原因是什么。

紧接着，是 Spartacus 技术架构的简要介绍。

最后，可能是 SAP Commerce 从业者比较关心的一个话题，即 Spartacus 的发布方式和更新频率，因为这个话题也和广大 Commerce 从业者是否决定选择 Spartacus 密切相关。

SAP Commerce Cloud 是 SAP 一款电商解决方案，而 Storefront 这个术语，指的是该解决方案的前台店铺界面。一句话概括 Spartacus，它是基于现代 Web 开发技术和框架打造而成的一款新的 SAP Commerce Cloud Storefront.

那何谓现代呢？Spartacus 1.0 版发布于 2019 年 7 月，因此相比前一代基于 Accelerator 技术的 Storefront 来说，Spartacus 具有得天独厚的优势，能够采取比较成熟和现代的前端技术来开发。

Spartacus 特性之一：单页面应用 Single Page Application

这也是 Spartacus 命名的由来。所谓单页面应用，是由一个称为外壳(shell)的 html 页面和多个包含具体业务逻辑的页面片段组成。

Commerce 传统的 Storefront，基于 JSP 实现，JSP 是一种服务器端渲染技术，页面代码在 Commerce 服务器端生成。而单页面应用是一种富客户端技术，页面片段的渲染以及页面路由，放在客户端完成，这样减轻了 Commerce 服务器的负载。当单页面应用的界面内容发生变化时，不需要重新加载整个外壳 html 页面，而仅仅需要更新相关的发生变化的页面片段，这样较多页面应用相比，页面之间的切换更加流畅，用户体验更好。

Spartacus 特性之二：响应式设计和自适应设计

这是 web 应用的用户体验领域两个容易混淆的概念，因为二者都是为了解决网页在不同屏幕尺寸的设备上展示的问题。从编程角度讲，响应式设计通过各种前端技术，为页面元素赋予了根据屏幕分辨率的变化而自动调整显示行为，以达到最佳显示效果的能力。

例如 Spartacus 里的列表控件，随着屏幕宽度的减小，显示的列表栏的数目也随之减少。而自适应设计，为不同类别的设备分别实现不同的页面，检测到设备分辨率后调用对应的网页。Spartacus 的页面设计绝大部分是响应式布局，但也支持自适应布局的特性。

Commerce 的 CMS 模块将 Storefront UI 按照功能上的逻辑相关性,划分成不同的区域，而 Spartacus 可以允许使用者根据不同的屏幕尺寸，配置在该尺寸下，不同的区域内应该显示哪一些 UI 组件。

Spartacus 特性之三：100% API 驱动

Commerce Cloud 提供了一组称为 Omni Commerce Connect(简称 OCC)的 Restful API.

Spartacus 通过标准的 HTTP 协议调用这组 API，实现同 Commerce Cloud 交互的目的。从编程层面来说，100%的 API 驱动确保了 Spartacus 的前后端分离，使得 Spartacus 的二次开发人员不需要去了解 Commerce 平台 Java 层的实现细节，而过去基于 Commerce Accelerator 技术的 Storefront 二次开发，需要的是会使用 JSP 和 Java 的全栈开发者。

从更深层次来说，100% API 驱动使 Spartacus 同 Commerce 平台也解除了紧耦合关系，从而极大提升了 Spartacus 的可升级性。这一点在接下来 Accelerator 同 Spartacus 的对比中我们会进一步说明。

Spartacus 特性之四：开源，免费

Spartacus 的代码是完全开源的，托管在 Github 上。如果大家细心察看 Github 仓库上的代码提交者列表，就会发现，这些代码贡献者有的是像 Jerry 这样的 SAP 职员，有的来自 partner 公司，还有 freelancer 即自由职业者。SAP 选择将 Spartacus 开源，希望构建出一个繁荣的生态圈，和开源社区里其他贡献者共同在 Commerce Storefront 领域进行持续创新。

那么，SAP 为什么要推出 Spartacus 呢？这得从 Spartacus 诞生之前，SAP Commerce 传统的 Storefront 实现技术即 Accelerator 说起。

Accelerator 是 Spartacus 发布之前，SAP Commerce Cloud 使用的 Storefront 实现技术。

Accelerator 是一个开箱即用的 web 实现模板，是 Commerce 平台的一部分，以源代码的方式交付给客户。客户通过一个叫做 module generator 的工具，基于 Accelerator 模板代码生成自己的 Storefront 实现，然后基于这些生成的代码继续二次开发。这种源代码生成方式确实能加快客户的 Storefront 二次开发速度，这也是 Accelerator 命名的由来。

然而，Accelerator 这种同 Commerce 平台的紧耦合关系，以及基于源代码级别的二次开发方式，给 Commerce 项目实施的可升级性带来很大的挑战。例如，当客户发现新版本的 Accelerator 能满足自己新的业务需求时，希望升级 Accelerator. 然而由于 Accelerator 是 Commerce 平台的一部分，所以必须先升级整个 Commerce 系统，再使用 module generator 基于高版本的 Accelerator 代码，重新生成自定义实现，再把基于低版本 Accelerator 模板而进行的二次开发内容，逐一手动地迁移到高版本 Accelerator 生成的自定义实现中去。

当 Commerce 的二次开发达到一定规模量的时候，这种手动升级的方式很挑战。

Accelerator 具有的这些缺陷，在 Spartacus 问世之后都迎刃而解。

Accelerator 通过源代码的方式提供了一个 Storefront 的开发模板，而 Spartacus 则以库的方式，提供了一个轻型的 Storefront 开发框架。我们新建一个 Angular 应用，导入对 Spartacus 库的依赖，当我们需要升级 Spartacus 时，只需要更新 Angular 应用的 package.json 文件里 Spartacus 库文件的版本号即可，因此 Spartacus 从可升级性上来说是一个巨大的飞跃。

Spartacus 采用 API 的方式同 Commerce 交互，这使得 Spartacus 可以同 Commerce 分开部署，分别进行升级，比如目前已经发布的 Spartacus 3.0，支持从 Commerce 1905 开始及其之后的所有版本。Spartacus 采用 Angular 开发，编译之后生成 JavaScript 代码，作为其运行时语言。这样一来，使用 Spartacus 的二次开发人员，不再需要像过去开发 Accelerator 那样，不再需要掌握前端 JSP 和后端 Java 的全栈开发技术栈。

Accelerator 的可扩展性，是通过牺牲可升级性为代价换来的。同 Accelerator 只有源代码级别的修改这一单一的扩展方式相比，Spartacus 实现扩展性的手段更加多元化。

(1) Spartacus 的模块之一，ConfigModule，将业务逻辑和页面布局以及样式，通过配置的方式暴露出来。二次开发人员通过调整配置，可以更改 Spartacus 默认的行为和页面布局以及样式。

(2) Spartacus 的页面布局由不同的 Angular 组件组成，这些 Angular 组件同 Commerce 的 CMS 组件具有一一对应关系。Spartacus 允许二次开发人员增强甚至开发新的 Angular 组件，去替换 Spartacus 发布时使用的默认组件，以此来实现客户的页面定制化需求。

(3) 借助 Angular 强大的依赖注入机制，Spartacus 允许开发人员像 Commerce 后台开发人员使用 Java Spring 框架那样，开发自己的 service 实现。通过 Angular 的 Dependency Injection 机制，注入自开发的 service，从而达到定制化 Spartacus 的运行流程和逻辑的目的。

下面我们来简要了解 Spartacus 使用到的一些技术栈和 Spartacus 同 Commerce 交互的基本原理。

前面说到，Spartacus 是基于现代 Web 开发技术打造而成的一个 Storefront 开发框架。因此，涉及到的技术栈都是目前前端开发普遍使用的一些比较成熟的技术。

Angular：由 Google 维护的一款 web 前端开发框架，借鉴了大量有十几二十年历史的成熟的后端开发理念，比如依赖注入、接口、注解等等，这些理念在开发 需要持续迭代和维护的大规模企业级前端应用时，显得特别有优势。Angular 同时也是一款与时俱进的框架，比如对 TypeScript 的支持，跟 RxJS 的深度整合，对 Progressive Web Application 即 渐进式网页应用理念 第一时间的支持等等。

Spartacus 1.0 基于 Angular 9，而目前最新的 Spartacus 3.0, 基于 Angular 10. 上个月 Google 发布了最新的 Angular 11，目前我们团队的架构师，正在评估 Spartacus 支持 Angular 11 的技术可行性。

TypeScript: Angular 的开发语言是 TypeScript，ES5, ES6 是 JavaScript 发展过程中出现的两个版本，而 TypeScript 不仅是 ES6 的超集，而且是一门静态类型编程语言。2018 年有一份前端项目中出现频率最高的十大错误类型统计报告，其中前 7 位都和类型错误有关：

而 TypeScript 的编译器 静态类型检查，可以避免不少的类型错误。通过强类型接口，在服务实现者和服务调用者之间创建了一种契约，这种契约能降低 Spartacus 组件和服务之间的耦合性，帮助像 Spartacus 这种 其开发者来自世界各地的开源项目 进行更有效率地开发。

Rxjs: Reactive Extension JavaScript，是一种响应式编程实践，Angular 是 RxJS 这个库的重度使用者。Rxjs 的核心是 Observable(可观察对象），Spartacus 的实现，使用 Rxjs 的可观察对象，封装了从 Commerce 读取业务数据的异步操作。通过 Rxjs 提供的施加在可观察对象上的各种操作符，Spartacus 可以灵活地控制 异步读取 Commerce 业务数据的时序，对 Spartacus 和 Commerce 之间的数据流进行聚合或者拆分。

Ngrx: Angular 应用使用的一个能够优雅的管理应用状态的库。Angular 和其他主流的前端框架一样，遵循组件化开发的标准，组件间通信基本都是单向数据流：父组件通过属性绑定把数据传递给子组件，子组件如果想要修改传入的数据，必须通过事件回调同父组件通信。NgRx 作为通信场景里的第三方，能够统一管理组件的状态，降低了 Spartacus 这类复杂前端应用组件间状态管理的复杂度和出错的可能。

SASS：Syntactically Awesome Stylesheets 的缩写，是一种 CSS 的扩展语言，在 CSS 基础上增添了定义变量，支持代码块嵌套，继承，命名空间，父级引用等特性，大大提高了 css 的开发效率。可以说 Spartacus 能够支持从页面整体颜色风格，到控件外观 细粒度的微调，SASS 功不可没。

Jasmine：一个前端单元测试框架。Cypress：一个端到端的自动化测试框架。

我们通过完善的单元测试和端到端自动化测试，保障了 Spartacus 这种开源项目的代码质量。

最后，我们开发出的 Spartacus，经过打包后，以库的形式发布到 npmjs.com 上去。

这是一张 Spartacus 同 Commerce 交互的示意图。我们首先看图的最右边。Spartacus 同 Commerce 系统的通信，通过 HTTP 协议调用 OCC API 完成。Connector 是 HTTP 调用的发起者，维护了静态的配置信息，即 API 的 endpoint.

比如，从 Commerce 系统读取产品主数据，读取的字段列表以 url 参数的形式出现在 API endpoint 里。这些字段列表可以在 Connector 的静态配置点里进行配置。Connector 并不会直接同 Commerce 交互，而是把请求转发给 Adapter，具体通信由 Adapter 完成，Connector 只负责调度 Adapter. Spartacus 发布的 Adapter 默认使用 OCC Module，即 Commerce 标准的 OCC Restful API，但是客户也可以实现自己的 Adapter，连接 Commerce 之外的其他后台系统。

Connector 将 Adapter 取回的数据交给 NgRx 的 store 结构统一管理，后者的复杂度被 Façade 层所隐藏，而 Spartacus UI 组件只会同 Façade 层交互，进行数据绑定和页面展示。这体现了关注点分离的设计原则。最后，因为 UI 组件和 Commerce 后台组件的数据模型存在差异，因此需要 Converter，在数据从 Commerce 取回，准备呈现在 UI 之前，先要通过 Converter 转换成适合 UI 展示的结构；反之，在 Spartacus 提交数据准备写回 Commerce 时，也要先将数据通过 Converter 转换成 OCC API 接受的数据格式。

那么 Spartacus github 仓库里的源代码，通过什么方式发布给客户使用呢？

前面已经提到，Spartacus 打包之后，以库的方式发布到 npmjs.com 上。这是一张 Spartacus 库文件之一，Spartacus Storefront 托管到 npmjs 网站上的截图。这个库的版本号为 2.1.3, 我们稍后会介绍其版本机制。

Spartacus 库主要有三个实体组成：core, storefront 和 styles. 其中 storefront 包含了用户肉眼可见的，组成电商店铺应用外观的 UI 组件，客户可以重用和增强这个库文件里包含的组件。Core 这个库文件则包含了 Spartacus 的控制逻辑。用户可以开发自己的服务类，通过 Angular 依赖注入的机制，把自开发服务类注入到 core 框架之中。Styles 包含了 Spartacus 的界面样式实现，客户可以对这些样式进行定制化，或者用自开发样式来覆盖标准样式。

之前进行 Accelerator 和 Storefront 的可升级性比较时已经提到过，客户基于 Spartacus 库文件进行 Storefront 二次开发，并不会直接修改 Spartacus 发布的源代码。客户的二次开发代码，和 Spartacus 库文件是一种松耦合的依赖关系。客户升级 Spartacus 版本，在绝大多数情况下都不会影响到已有的二次开发代码。那么所谓的“绝大多数情况下”，具体是指什么呢？这就要从 Spartacus 的版本管理机制说起。

同绝大多数流行的开源框架和库一样，Spartacus 的版本管理也采取了所谓语义化版本的机制，版本号由主版本号，次版本号和修订版本号三部分组成，中间由小数点分隔开。

主版本号的升高，用于引入无法向后兼容的变更或颠覆性的更新。无法向后兼容的变更，是指 Spartacus 升级之后，之前基于低版本编写的二次开发代码，需要人工调整后才能继续工作。而颠覆性的更新，一个例子就是 Spartacus 升级到 3.0 版本之后，首次支持 B2B 的电商功能。

次版本号的增加：用于引入新功能，并且版本更新之后，已有的二次开发代码不需任何调整仍然能够继续正常工作。源代码重构，性能优化等不属于 bug 修复的修改，也通过次版本号的增加而引入。修订版本号：主要用于发布 bug 的修复。

Spartacus 的修订版本发布，以周为单位，确保使用过程中发现的 bug 能尽早得到解决。次版本的发布以月为单位，这种更新的频率有助于客户快速地进行持续改进和持续创新。而主版本的更新，可以参考 SAP 官方路线图网站上的声明。

从上面这张截图中 package.json 里定义的依赖，我们能够发现之前讲到的 core, storefront 和 styles 3 个库，再加上主要包含了文档和翻译的 assets 库。

其中版本号 2.1.0 之前的这个符号^，有个术语叫做 hat, 这是语义化版本管理机制里的范围标识符之一，表示这个 Storefront 二次开发工程支持主版本号为 2，且次版本号大于 1 的所有 Spartacus 版本，但是不支持主版本号为 3 的 Spartacus. 换句话说，图中这个二次开发项目，只支持 SAP Commerce B2C 的功能，因为 B2B 的功能是 Spartacus 3.0 版本里才引入的。

最后，让我们用一些关键字来总结今天的分享。SAP Spartacus 诞生于 2019 年 7 月，是一款满足响应式和自适应特性的现代 Storefront 应用和开发框架。同之前的 Accelerator Storefront 相比，Spartacus 在保留了原有的可定制化特性之外，具有更流畅的用户体验和良好的可升级性，并且本身开源，无需购买额外的 license. 如果大家对 Spartacus 有兴趣想深入了解，可以去 open SAP 网站上学习 Spartacus 的公开课.

感谢阅读。