大家好，今天非常高興能給大家做一個關於Kyma的技術分享。這個session的audience主要是針對使用咱們成都研究院使用Java和nodejs等技術棧做微服務開發的同事們。對於在ABAP netweaver上做SAP傳統開發的同事們來說，這個session可以讓大家開闊一下眼界。

這是今天session的agenda：

•Why Containers?

•Relationship between Containers and Dockers?

•Why Kubernetes？

•Relationship between Kyma and Kubernetes

•A real example: Commerce cloud extension via Kyma

之所以要在Kyma真正開始前做容器，Docker，Kubernetes的鋪墊，是因為Kyma基於Kubernetes，而Kubernetes又是容器編排框架，Docker又是一種流行的容器執行時實現技術，如果不提Kubernetes，Docker和容器，沒有接觸過這些概念的同事一定會覺得一頭霧水。

我們先來看容器。

我們說任何技術都有其使用場景和解決的痛點。那麼為什麼這些年來容器技術非常火呢？

得益於近些年微服務架構的火熱，很多企業包括SAP自己也在開發基於微服務架構的新應用，比如在坐很多同事所在團隊正在做的事情。而基於微服務架構的SaaS軟體開發，業界有一套標準，或者說是最佳實踐，那就是著名的twelve-factor標準：

https://12factor.net/zh_cn/

而容器，就是一種有助於開發人員以更小的代價去開發一個滿足這12個準則的基於微服務架構的雲原生應用的技術。比如這個準則裡提到的，微服務應用的build，release和執行階段應該嚴格區分，應用通過一個或多個無狀態的程序進行執行，彼此隔離，通過程序模型進行水平擴充套件，等等，這些通過容器技術都可輕易實現，不需要開發人員付出額外代價。

因此，我們需要記住一個結論，容器的使用場景，永遠是和微服務架構，SaaS，雲原生應用這些緊密相連的。

那麼容器具體來說到底是一個什麼東西呢？字面意思，用來裝東西的集裝箱。

裝什麼東西？除了應用程式本身之外，還包括這個應用要能正常執行所需的執行環境和庫檔案等外部依賴。

我們想象一下現實世界中的集裝箱。一輛汽車從碼頭上被裝到集裝箱裡，然後被貨船載到另一個碼頭裡。

這裡的汽車就好比我們的應用，集裝箱就是容器，汽車在不同的碼頭上裝入集裝箱就好比應用的部署。

這就是slide裡第一條，Convenient package to ship things的概念。

Open specification：

要注意，容器 != Docker。Docker只是容器技術的一種商業化實現方案。

在2015年，由Google，Docker、CoreOS、IBM、微軟、Redhat等廠商聯合起來，成立了一個OCI（Open Container Initiative）組織，並於推出了第一個開放容器標準，旨在避免容器技術的碎片化。該標準主要分為執行時標準和容器映象標準。

Isolated：容器隔離。這個很好理解，容器裡執行的應用彼此之間是隔離的，一個應用出故障不會影響到其他容器。可以獨立分別進行水平擴充套件。

Portable：既然容器封裝了所有執行應用程式所必需的相關的細節，比如應用依賴以及作業系統，這就使得映象從一個環境移植到另外一個環境更加靈活。比如，同一個映象可以在Windows或Linux，開發、測試或生產環境中執行。基於容器的應用，既能執行在開發者的膝上型電腦上，也能執行在雲服務提供商的資料中心上。真正做到一次構建，到處執行。

LightWeight：輕量級。虛擬機器和容器的目的類似，都致力於對應用程式及其關聯性進行隔離，從而構建起一套能夠不依賴於具體環境而執行的應用單元。虛擬機器是在物理伺服器的上層用軟體來模擬特定的硬體系統。Hypervisor位於硬體和系統之間，是建立虛擬機器必須的一個部分。虛擬機器軟體必須使用Hypervisor作為一箇中間層，是虛擬機器技術的核心，當宿主作業系統啟動虛擬機器時，會通過hypervisor給虛擬機器分配記憶體，CPU，網路和磁碟等資源，並載入虛擬的作業系統，因而需要消耗宿主機大量的物理資源。

一臺宿主機上執行的多個容器化應用共享這臺宿主機作業系統的核心，因而不需要虛擬機器技術的hypervisor中間層，因而同虛擬機器技術相比，更加輕量化，啟動速度更快。

那麼容器和docker的關係又是怎樣的？

前面已經說到了，Docker只是基於開放容器標準的一種比較受歡迎的實現。Docker之於容器，相當於React，Angular和Vue之於UI開發框架。

既然大多數時候我們在談到容器時，都會不自覺地想到Docker，那麼Docker到底是用什麼實現的呢？

著名的電腦科學家王垠，曾經在他的個人部落格上撰文，聲稱Docker和Kubernetes並不是什麼了不起的技術。從科學家的角度出發，這個論斷不能算錯誤，因為Docker底層確實就是對Linux裡很多原語做了很好的封裝，所以從商業化的角度取得了成功。

以下是一些Docker封裝的Linux系統原語的一些例子。Jerry是SAP Docker和Kubernetes培訓課程的講師之一，在這個課程上，我們會對Docker如何憑藉這些原語實現開放容器標準做深入的討論。

接下來，我們引入Kubernetes。為什麼有了Docker後，還需要Kubernetes？

我們知道從結果上看，Docker和虛擬機器都可以做到讓應用在隔離的環境下執行，區別在於Docker執行環境仍然能夠和宿主機共享作業系統核心，而虛擬機器則通過付出更多宿主機系統資源的代價，構造出一個完全虛擬的作業系統，讓應用在裡面執行。

然而Docker容器和虛擬機器還是有一些問題沒有解決，就是容器在大型分散式叢集上的部署，微服務應用中的容器管理和協同，自動地水平擴充套件，自動修復和彈性伸縮等等。

這也是Kubernetes大顯身手的地方。誕生於2015年7月的Kubernetes，是Google內部多年使用的容器叢集管理系統Borg的開源版本。由於凝聚了Google在容器編排領域多年的深厚功力，釋出之後很快就一飛沖天，如今已經成為事實上的容器叢集管理領域的標準和霸主。

Kubernetes源自古希臘語，意為“舵手”。有人調侃說，Google選擇Kubernetes這個單詞，暗示了自己想在容器編排管理這個領域裡扮演舵手和領導者的角色。

Kubernetes和Docker容器的關係？下面這張圖片是SAP Kubernetes培訓課程slide裡的一張，用來說明Kubernetes和docker容器的關係，我覺得很形象。

運行了各種微服務應用的容器就好比圖中使用各種樂器演奏的音樂家，而站在中間的指揮家，和使用樂器演奏的音樂家站立的臺階，就相當於Kubernetes。

如果更準確的說，Kubernetes管理的不是容器，而是pod。Pod是一個或者多個容器組成的集合。

至此，我們終於完成了瞭解Kyma必須的前置知識的介紹。

什麼是Kyma？去年6月份，SAP C/4HANA正式announce時，這張圖在大家的朋友圈中都刷屏似的存在。

大家可以看到，Slide裡的描述，SAP雲平臺擴充套件工廠是一個基於雲端原生微服務的通用創新和敏捷平臺。

那麼雲平臺擴充套件工廠和括號裡的Kyma關係又如何？

二者的關係恰如Open UI5和Fiori的關係。Open UI5是SAP推出的一個開源UI開發框架和UI控制元件庫，而Fiori是SAP 基於Open UI5這個技術框架開發出來的商業化產品（當然現在Fiori也代表SAP推薦的一種UI風格）。類似的，SAP Cloud Platform Extension Factory是SAP基於Kyma這個開源專案，再針對企業應用所必須滿足的一些標準(比如SAP產品標準，區域特殊需求）而新增進額外的附加功能和實現的商用產品。

Kyma對C/4HANA意味著什麼？我們CX部門的CTO Moritz Zimmermann, 在他的linkedin上發表過一篇部落格，裡面也提到了Kyma:

Kyma(SAP Cloud Platform Extension Factory)將來會成為SAP C/4HANA套件裡所有基於微服務架構產品的統一擴充套件工具。

Kyma是基於Kubernetes的，這也是我們之前花了很多時間進行Docker和Kubernetes介紹的原因。

那麼Kyma的工作原理是什麼？簡單的說就是一個觀察者-釋出者模式。

1. 通過Application Connector，可以使Kyma同SAP C/4HANA的產品建立連線，然後進行事件註冊。

2. 事件註冊好之後，使用微服務架構實現事件的監聽者（消費者）。這也是Kyma官網裡提到的"開發者可以使用任何技術棧進行擴充套件開發“的含義。舉個例子，我們在SAP Commerce Cloud裡建立一個訂單後，客戶提出了基於該企業流程的一些特殊校驗邏輯。Commerce Cloud釋出一個"Order Create"的事件，事件payload包含建立訂單的欄位。我們開發並部署在Kyma上的微服務監聽這個事件，微服務內部實現可以採取任何技術棧，Commerce Cloud通過HTTP呼叫包含了企業自定義訂單校驗邏輯的微服務，根據其返回的校驗結果進行後續處理。

我們來看一個具體的demo，看看SAP Commerce Cloud裡訂單編排功能是如何用Kyma去增強的。

下圖藍色流程是我們通過Kyma對Commerce Cloud的標準流程進行的增強，主要是在下單過程中增加了一些Validation校驗。

我們登入commerce的back office頁面，定義一個新的action：

然後進到Kyma的console頁面：

選擇一個stage進去，點選Lambdas進入編輯頁面：

新建一個Lambda function，取名fraudcheck2：

這個function自動建立的標籤(Labels)，Kubernetes老司機一定覺得很親切。這些標籤其實和大家現實工作中使用雲筆記裡的標籤和圖片管理軟體裡的標籤作用相同，就是一種鍵值對(Key Value Pair), 可以允許使用者把Kubernetes的物件能靈活的分組，並提供高效的檢索。

Function Trigger裡可以指定這些Lambda函式在哪些事件觸發後執行。選擇第一步定義新的action後對應的event：

Lambda函式具體的實現，做過nodejs開發的朋友們一定不會覺得陌生。

首先第18行，19行從event這個輸入引數物件裡取得發生事件的訂單Code，然後第26行消費OCC(Omni Commerce Channel)Restul API獲得訂單明細，從明細裡獲得訂單的客戶ID，再呼叫第30行的程式碼根據客戶ID拿到客戶明細，然後使用第37行和第40行的程式碼分別檢查該客戶的郵箱地址是否有效，以及該客戶是否第一次下單。

注意第43行和46行的程式碼我暫時註釋掉，稍後才會啟用。

現在我們來測試一下。在Commerce裡下一個單，記下訂單ID。

回到Commerce back office頁面，檢視剛才下的訂單的Business Process：

這裡看到了剛才第一步新建的基於Kyma Action對應的流程日誌記錄：

我們再去檢視這個訂單的Fraud檢查記錄：

點這個Fraud Reports檢視檢查結果。這個標籤從左到右依次排開的風格很像Fiori和ABAP Webdynpro。

可以看見前文介紹的Email和是否是首單的檢查結果。

Email檢查結果，客戶的郵箱地址有效。

現在再回到Kyma的Lambda函式編輯器裡，將之前註釋掉的從Marketing Cloud獲取聯絡人地址的函式以及呼叫SAP雲平臺的Business Partner服務的函式重新啟用：

啟用之後，儲存，然後進入Service Catalog。這個元件也是Kubernetes提供的標準組件，Kyma基於它做了增強，能夠將第三方的服務匯入進來給Kyma的Lambda函式消費。

接下來的步驟和我們在SAP雲平臺上消費一個服務類似，首先建立一個服務例項：

然後再基於這個服務例項建立一個繫結，

繫結型別設定成Function Binding，繫結的目標設定成之前編輯好的Lambda函式。

再下一個單：

這一次，這個第二次下的訂單的Fraud檢查報告，同第一個訂單相比就多了兩條記錄：

首先看第二條首單檢查的記錄，得分為0，和我們期望的結果一致。

從Marketing Cloud的服務返回的檢查結果：

從SAP雲平臺的Business Partner服務返回的結果可以看出，下單的這個客戶不存在一個對應的Business Partner。

至此關於如何使用Kyma對SAP Commerce產品的訂單編排做增強就簡單介紹到這裡，感謝閱讀。