這是Jerry 2020年的第86篇文章，也是汪子熙公眾號總共第268篇原創文章。

這篇文章的視頻版本如下：

https://v.qq.com/x/page/b3212l6kqvg.html

這個分享是SAP 2020全球技術大會(SAP TechEd)，“客戶自主”時代的極致體驗分論壇內容之一：

本文的分享主要分為以下四個方面來介紹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的公開課.

感謝閱讀。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的Jerry在2020 SAP全球技术大会的分享：SAP Spartacus技术介绍的文字版的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。