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

大家好，今天非常高興能給大家做一個關(guān)于Kyma的技術(shù)分享。這個session的audience主要是針對使用咱們成都研究院使用Java和nodejs等技術(shù)棧做微服務(wù)開發(fā)的同事們。對于在ABAP netweaver上做SAP傳統(tǒng)開發(fā)的同事們來說，這個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又是一種流行的容器運行時實現(xiàn)技術(shù)，如果不提Kubernetes，Docker和容器，沒有接觸過這些概念的同事一定會覺得一頭霧水。

我們先來看容器。

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

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

https://12factor.net/zh_cn/

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

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

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

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

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

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

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

Open specification：

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

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

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

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

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

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

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

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

既然大多數(shù)時候我們在談到容器時，都會不自覺地想到Docker，那么Docker到底是用什么實現(xiàn)的呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

新建一個Lambda function，取名fraudcheck2：

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

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

Lambda函數(shù)具體的實現(xiàn)，做過nodejs開發(fā)的朋友們一定不會覺得陌生。

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

注意第43行和46行的代碼我暫時注釋掉，稍后才會啟用。

現(xiàn)在我們來測試一下。在Commerce里下一個單，記下訂單ID。

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

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

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

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

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

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

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

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

接下來的步驟和我們在SAP云平臺上消費一個服務(wù)類似，首先創(chuàng)建一個服務(wù)實例：

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

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

再下一個單：

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

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

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

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

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

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