摘要：該標準主要分為運行時標準和容器鏡像標準。事件注冊好之后，使用微服務架構實現事件的監聽者消費者。

大家好，今天非常高興能給大家做一個關于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產品的訂單編排做增強就簡單介紹到這里，感謝閱讀。

要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":