摘要：該標(biāo)準(zhǔn)主要分為運(yùn)行時(shí)標(biāo)準(zhǔn)和容器鏡像標(biāo)準(zhǔn)。事件注冊(cè)好之后，使用微服務(wù)架構(gòu)實(shí)現(xiàn)事件的監(jiān)聽(tīng)者消費(fèi)者。

大家好，今天非常高興能給大家做一個(gè)關(guān)于Kyma的技術(shù)分享。這個(gè)session的audience主要是針對(duì)使用咱們成都研究院使用Java和nodejs等技術(shù)棧做微服務(wù)開(kāi)發(fā)的同事們。對(duì)于在ABAP netweaver上做SAP傳統(tǒng)開(kāi)發(fā)的同事們來(lái)說(shuō)，這個(gè)session可以讓大家開(kāi)闊一下眼界。

這是今天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真正開(kāi)始前做容器，Docker，Kubernetes的鋪墊，是因?yàn)镵yma基于Kubernetes，而Kubernetes又是容器編排框架，Docker又是一種流行的容器運(yùn)行時(shí)實(shí)現(xiàn)技術(shù)，如果不提Kubernetes，Docker和容器，沒(méi)有接觸過(guò)這些概念的同事一定會(huì)覺(jué)得一頭霧水。

我們先來(lái)看容器。

我們說(shuō)任何技術(shù)都有其使用場(chǎng)景和解決的痛點(diǎn)。那么為什么這些年來(lái)容器技術(shù)非常火呢？

得益于近些年微服務(wù)架構(gòu)的火熱，很多企業(yè)包括SAP自己也在開(kāi)發(fā)基于微服務(wù)架構(gòu)的新應(yīng)用，比如在坐很多同事所在團(tuán)隊(duì)正在做的事情。而基于微服務(wù)架構(gòu)的SaaS軟件開(kāi)發(fā)，業(yè)界有一套標(biāo)準(zhǔn)，或者說(shuō)是最佳實(shí)踐，那就是著名的twelve-factor標(biāo)準(zhǔn)：

https://12factor.net/zh_cn/

而容器，就是一種有助于開(kāi)發(fā)人員以更小的代價(jià)去開(kāi)發(fā)一個(gè)滿足這12個(gè)準(zhǔn)則的基于微服務(wù)架構(gòu)的云原生應(yīng)用的技術(shù)。比如這個(gè)準(zhǔn)則里提到的，微服務(wù)應(yīng)用的build，release和運(yùn)行階段應(yīng)該嚴(yán)格區(qū)分，應(yīng)用通過(guò)一個(gè)或多個(gè)無(wú)狀態(tài)的進(jìn)程進(jìn)行執(zhí)行，彼此隔離，通過(guò)進(jìn)程模型進(jìn)行水平擴(kuò)展，等等，這些通過(guò)容器技術(shù)都可輕易實(shí)現(xiàn)，不需要開(kāi)發(fā)人員付出額外代價(jià)。

因此，我們需要記住一個(gè)結(jié)論，容器的使用場(chǎng)景，永遠(yuǎn)是和微服務(wù)架構(gòu)，SaaS，云原生應(yīng)用這些緊密相連的。

那么容器具體來(lái)說(shuō)到底是一個(gè)什么東西呢？字面意思，用來(lái)裝東西的集裝箱。

裝什么東西？除了應(yīng)用程序本身之外，還包括這個(gè)應(yīng)用要能正常運(yùn)行所需的運(yùn)行環(huán)境和庫(kù)文件等外部依賴(lài)。

我們想象一下現(xiàn)實(shí)世界中的集裝箱。一輛汽車(chē)從碼頭上被裝到集裝箱里，然后被貨船載到另一個(gè)碼頭里。

這里的汽車(chē)就好比我們的應(yīng)用，集裝箱就是容器，汽車(chē)在不同的碼頭上裝入集裝箱就好比應(yīng)用的部署。

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

Open specification：

要注意，容器 != Docker。Docker只是容器技術(shù)的一種商業(yè)化實(shí)現(xiàn)方案。

在2015年，由Google，Docker、CoreOS、IBM、微軟、Redhat等廠商聯(lián)合起來(lái)，成立了一個(gè)OCI（Open Container Initiative）組織，并于推出了第一個(gè)開(kāi)放容器標(biāo)準(zhǔn)，旨在避免容器技術(shù)的碎片化。該標(biāo)準(zhǔn)主要分為運(yùn)行時(shí)標(biāo)準(zhǔn)和容器鏡像標(biāo)準(zhǔn)。

Isolated：容器隔離。這個(gè)很好理解，容器里運(yùn)行的應(yīng)用彼此之間是隔離的，一個(gè)應(yīng)用出故障不會(huì)影響到其他容器。可以獨(dú)立分別進(jìn)行水平擴(kuò)展。

Portable：既然容器封裝了所有運(yùn)行應(yīng)用程序所必需的相關(guān)的細(xì)節(jié)，比如應(yīng)用依賴(lài)以及操作系統(tǒng)，這就使得鏡像從一個(gè)環(huán)境移植到另外一個(gè)環(huán)境更加靈活。比如，同一個(gè)鏡像可以在Windows或Linux，開(kāi)發(fā)、測(cè)試或生產(chǎn)環(huán)境中運(yùn)行。基于容器的應(yīng)用，既能運(yùn)行在開(kāi)發(fā)者的筆記本電腦上，也能運(yùn)行在云服務(wù)提供商的數(shù)據(jù)中心上。真正做到一次構(gòu)建，到處運(yùn)行。

LightWeight：輕量級(jí)。虛擬機(jī)和容器的目的類(lèi)似，都致力于對(duì)應(yīng)用程序及其關(guān)聯(lián)性進(jìn)行隔離，從而構(gòu)建起一套能夠不依賴(lài)于具體環(huán)境而運(yùn)行的應(yīng)用單元。虛擬機(jī)是在物理服務(wù)器的上層用軟件來(lái)模擬特定的硬件系統(tǒng)。Hypervisor位于硬件和系統(tǒng)之間，是創(chuàng)建虛擬機(jī)必須的一個(gè)部分。虛擬機(jī)軟件必須使用Hypervisor作為一個(gè)中間層，是虛擬機(jī)技術(shù)的核心，當(dāng)宿主操作系統(tǒng)啟動(dòng)虛擬機(jī)時(shí)，會(huì)通過(guò)hypervisor給虛擬機(jī)分配內(nèi)存，CPU，網(wǎng)絡(luò)和磁盤(pán)等資源，并加載虛擬的操作系統(tǒng)，因而需要消耗宿主機(jī)大量的物理資源。

一臺(tái)宿主機(jī)上運(yùn)行的多個(gè)容器化應(yīng)用共享這臺(tái)宿主機(jī)操作系統(tǒng)的內(nèi)核，因而不需要虛擬機(jī)技術(shù)的hypervisor中間層，因而同虛擬機(jī)技術(shù)相比，更加輕量化，啟動(dòng)速度更快。

那么容器和docker的關(guān)系又是怎樣的？

前面已經(jīng)說(shuō)到了，Docker只是基于開(kāi)放容器標(biāo)準(zhǔn)的一種比較受歡迎的實(shí)現(xiàn)。Docker之于容器，相當(dāng)于React，Angular和Vue之于UI開(kāi)發(fā)框架。

既然大多數(shù)時(shí)候我們?cè)谡劦饺萜鲿r(shí)，都會(huì)不自覺(jué)地想到Docker，那么Docker到底是用什么實(shí)現(xiàn)的呢？

著名的計(jì)算機(jī)科學(xué)家王垠，曾經(jīng)在他的個(gè)人博客上撰文，聲稱(chēng)Docker和Kubernetes并不是什么了不起的技術(shù)。從科學(xué)家的角度出發(fā)，這個(gè)論斷不能算錯(cuò)誤，因?yàn)镈ocker底層確實(shí)就是對(duì)Linux里很多原語(yǔ)做了很好的封裝，所以從商業(yè)化的角度取得了成功。

以下是一些Docker封裝的Linux系統(tǒng)原語(yǔ)的一些例子。Jerry是SAP Docker和Kubernetes培訓(xùn)課程的講師之一，在這個(gè)課程上，我們會(huì)對(duì)Docker如何憑借這些原語(yǔ)實(shí)現(xiàn)開(kāi)放容器標(biāo)準(zhǔn)做深入的討論。

接下來(lái)，我們引入Kubernetes。為什么有了Docker后，還需要Kubernetes？

我們知道從結(jié)果上看，Docker和虛擬機(jī)都可以做到讓?xiě)?yīng)用在隔離的環(huán)境下運(yùn)行，區(qū)別在于Docker運(yùn)行環(huán)境仍然能夠和宿主機(jī)共享操作系統(tǒng)內(nèi)核，而虛擬機(jī)則通過(guò)付出更多宿主機(jī)系統(tǒng)資源的代價(jià)，構(gòu)造出一個(gè)完全虛擬的操作系統(tǒng)，讓?xiě)?yīng)用在里面運(yùn)行。

然而Docker容器和虛擬機(jī)還是有一些問(wèn)題沒(méi)有解決，就是容器在大型分布式集群上的部署，微服務(wù)應(yīng)用中的容器管理和協(xié)同，自動(dòng)地水平擴(kuò)展，自動(dòng)修復(fù)和彈性伸縮等等。

這也是Kubernetes大顯身手的地方。誕生于2015年7月的Kubernetes，是Google內(nèi)部多年使用的容器集群管理系統(tǒng)Borg的開(kāi)源版本。由于凝聚了Google在容器編排領(lǐng)域多年的深厚功力，發(fā)布之后很快就一飛沖天，如今已經(jīng)成為事實(shí)上的容器集群管理領(lǐng)域的標(biāo)準(zhǔn)和霸主。

Kubernetes源自古希臘語(yǔ)，意為“舵手”。有人調(diào)侃說(shuō)，Google選擇Kubernetes這個(gè)單詞，暗示了自己想在容器編排管理這個(gè)領(lǐng)域里扮演舵手和領(lǐng)導(dǎo)者的角色。

Kubernetes和Docker容器的關(guān)系？下面這張圖片是SAP Kubernetes培訓(xùn)課程slide里的一張，用來(lái)說(shuō)明Kubernetes和docker容器的關(guān)系，我覺(jué)得很形象。

運(yùn)行了各種微服務(wù)應(yīng)用的容器就好比圖中使用各種樂(lè)器演奏的音樂(lè)家，而站在中間的指揮家，和使用樂(lè)器演奏的音樂(lè)家站立的臺(tái)階，就相當(dāng)于Kubernetes。

如果更準(zhǔn)確的說(shuō)，Kubernetes管理的不是容器，而是pod。Pod是一個(gè)或者多個(gè)容器組成的集合。

至此，我們終于完成了了解Kyma必須的前置知識(shí)的介紹。

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

大家可以看到，Slide里的描述，SAP云平臺(tái)擴(kuò)展工廠是一個(gè)基于云端原生微服務(wù)的通用創(chuàng)新和敏捷平臺(tái)。

那么云平臺(tái)擴(kuò)展工廠和括號(hào)里的Kyma關(guān)系又如何？

二者的關(guān)系恰如Open UI5和Fiori的關(guān)系。Open UI5是SAP推出的一個(gè)開(kāi)源UI開(kāi)發(fā)框架和UI控件庫(kù)，而Fiori是SAP 基于Open UI5這個(gè)技術(shù)框架開(kāi)發(fā)出來(lái)的商業(yè)化產(chǎn)品（當(dāng)然現(xiàn)在Fiori也代表SAP推薦的一種UI風(fēng)格）。類(lèi)似的，SAP Cloud Platform Extension Factory是SAP基于Kyma這個(gè)開(kāi)源項(xiàng)目，再針對(duì)企業(yè)應(yīng)用所必須滿足的一些標(biāo)準(zhǔn)(比如SAP產(chǎn)品標(biāo)準(zhǔn)，區(qū)域特殊需求）而添加進(jìn)額外的附加功能和實(shí)現(xiàn)的商用產(chǎn)品。

Kyma對(duì)C/4HANA意味著什么？我們CX部門(mén)的CTO Moritz Zimmermann, 在他的linkedin上發(fā)表過(guò)一篇博客，里面也提到了Kyma:

Kyma(SAP Cloud Platform Extension Factory)將來(lái)會(huì)成為SAP C/4HANA套件里所有基于微服務(wù)架構(gòu)產(chǎn)品的統(tǒng)一擴(kuò)展工具。

Kyma是基于Kubernetes的，這也是我們之前花了很多時(shí)間進(jìn)行Docker和Kubernetes介紹的原因。

那么Kyma的工作原理是什么？簡(jiǎn)單的說(shuō)就是一個(gè)觀察者-發(fā)布者模式。

1. 通過(guò)Application Connector，可以使Kyma同SAP C/4HANA的產(chǎn)品建立連接，然后進(jìn)行事件注冊(cè)。

2. 事件注冊(cè)好之后，使用微服務(wù)架構(gòu)實(shí)現(xiàn)事件的監(jiān)聽(tīng)者（消費(fèi)者）。這也是Kyma官網(wǎng)里提到的"開(kāi)發(fā)者可以使用任何技術(shù)棧進(jìn)行擴(kuò)展開(kāi)發(fā)“的含義。舉個(gè)例子，我們?cè)赟AP Commerce Cloud里創(chuàng)建一個(gè)訂單后，客戶(hù)提出了基于該企業(yè)流程的一些特殊校驗(yàn)邏輯。Commerce Cloud發(fā)布一個(gè)"Order Create"的事件，事件payload包含創(chuàng)建訂單的字段。我們開(kāi)發(fā)并部署在Kyma上的微服務(wù)監(jiān)聽(tīng)這個(gè)事件，微服務(wù)內(nèi)部實(shí)現(xiàn)可以采取任何技術(shù)棧，Commerce Cloud通過(guò)HTTP調(diào)用包含了企業(yè)自定義訂單校驗(yàn)邏輯的微服務(wù)，根據(jù)其返回的校驗(yàn)結(jié)果進(jìn)行后續(xù)處理。

我們來(lái)看一個(gè)具體的demo，看看SAP Commerce Cloud里訂單編排功能是如何用Kyma去增強(qiáng)的。

下圖藍(lán)色流程是我們通過(guò)Kyma對(duì)Commerce Cloud的標(biāo)準(zhǔn)流程進(jìn)行的增強(qiáng)，主要是在下單過(guò)程中增加了一些Validation校驗(yàn)。

我們登錄commerce的back office頁(yè)面，定義一個(gè)新的action：

然后進(jìn)到Kyma的console頁(yè)面：

選擇一個(gè)stage進(jìn)去，點(diǎn)擊Lambdas進(jìn)入編輯頁(yè)面：

新建一個(gè)Lambda function，取名fraudcheck2：

這個(gè)function自動(dòng)創(chuàng)建的標(biāo)簽(Labels)，Kubernetes老司機(jī)一定覺(jué)得很親切。這些標(biāo)簽其實(shí)和大家現(xiàn)實(shí)工作中使用云筆記里的標(biāo)簽和圖片管理軟件里的標(biāo)簽作用相同，就是一種鍵值對(duì)(Key Value Pair), 可以允許用戶(hù)把Kubernetes的對(duì)象能靈活的分組，并提供高效的檢索。

Function Trigger里可以指定這些Lambda函數(shù)在哪些事件觸發(fā)后執(zhí)行。選擇第一步定義新的action后對(duì)應(yīng)的event：

Lambda函數(shù)具體的實(shí)現(xiàn)，做過(guò)nodejs開(kāi)發(fā)的朋友們一定不會(huì)覺(jué)得陌生。

首先第18行，19行從event這個(gè)輸入?yún)?shù)對(duì)象里取得發(fā)生事件的訂單Code，然后第26行消費(fèi)OCC(Omni Commerce Channel)Restul API獲得訂單明細(xì)，從明細(xì)里獲得訂單的客戶(hù)ID，再調(diào)用第30行的代碼根據(jù)客戶(hù)ID拿到客戶(hù)明細(xì)，然后使用第37行和第40行的代碼分別檢查該客戶(hù)的郵箱地址是否有效，以及該客戶(hù)是否第一次下單。

注意第43行和46行的代碼我暫時(shí)注釋掉，稍后才會(huì)啟用。

現(xiàn)在我們來(lái)測(cè)試一下。在Commerce里下一個(gè)單，記下訂單ID。

回到Commerce back office頁(yè)面，查看剛才下的訂單的Business Process：

這里看到了剛才第一步新建的基于Kyma Action對(duì)應(yīng)的流程日志記錄：

我們?cè)偃ゲ榭催@個(gè)訂單的Fraud檢查記錄：

點(diǎn)這個(gè)Fraud Reports查看檢查結(jié)果。這個(gè)標(biāo)簽從左到右依次排開(kāi)的風(fēng)格很像Fiori和ABAP Webdynpro。

可以看見(jiàn)前文介紹的Email和是否是首單的檢查結(jié)果。

Email檢查結(jié)果，客戶(hù)的郵箱地址有效。

現(xiàn)在再回到Kyma的Lambda函數(shù)編輯器里，將之前注釋掉的從Marketing Cloud獲取聯(lián)系人地址的函數(shù)以及調(diào)用SAP云平臺(tái)的Business Partner服務(wù)的函數(shù)重新啟用：

啟用之后，保存，然后進(jìn)入Service Catalog。這個(gè)組件也是Kubernetes提供的標(biāo)準(zhǔn)組件，Kyma基于它做了增強(qiáng)，能夠?qū)⒌谌降姆?wù)導(dǎo)入進(jìn)來(lái)給Kyma的Lambda函數(shù)消費(fèi)。

接下來(lái)的步驟和我們?cè)赟AP云平臺(tái)上消費(fèi)一個(gè)服務(wù)類(lèi)似，首先創(chuàng)建一個(gè)服務(wù)實(shí)例：

然后再基于這個(gè)服務(wù)實(shí)例創(chuàng)建一個(gè)綁定，

綁定類(lèi)型設(shè)置成Function Binding，綁定的目標(biāo)設(shè)置成之前編輯好的Lambda函數(shù)。

再下一個(gè)單：

這一次，這個(gè)第二次下的訂單的Fraud檢查報(bào)告，同第一個(gè)訂單相比就多了兩條記錄：

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

從Marketing Cloud的服務(wù)返回的檢查結(jié)果：

從SAP云平臺(tái)的Business Partner服務(wù)返回的結(jié)果可以看出，下單的這個(gè)客戶(hù)不存在一個(gè)對(duì)應(yīng)的Business Partner。

至此關(guān)于如何使用Kyma對(duì)SAP Commerce產(chǎn)品的訂單編排做增強(qiáng)就簡(jiǎn)單介紹到這里，感謝閱讀。

要獲取更多Jerry的原創(chuàng)文章，請(qǐng)關(guān)注公眾號(hào)"汪子熙":