Jerry在2020 SAP全球技術大會的分享：SAP Spartacus技術介紹的文字版

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

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

https://v.qq.com/x/page/b3212...

這個分享是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的原創文章，盡在："汪子熙":