這是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的公開課.
感謝閱讀。