站在巨人肩膀上的牛頓：Kubernetes和SAP Kyma

這周Jerry在SAP上海研究院參加了一個為期4天的Kubernetes教育訓練，度過了忙碌而又充實的4天。Jason，Benny和Peng三位大神的教育訓練幹貨滿滿，借此機會，Jerry和過去的兩位老上司Patrick和Evan叙了叙舊，也拜見了上海SAP圈子裡的幾位大佬。以前在網絡上久聞大名，這次終于見到了大佬們本人，了卻我一樁心願。

​

為什麼SAP内部也在開展Kubernetes的教育訓練呢？誕生于2015年7月的Kubernetes，是Google内部多年使用的容器叢集管理系統Borg的開源版本。由于凝聚了Google在容器編排領域多年的深厚功力，釋出之後很快就一飛沖天，如今已經成為事實上的容器叢集管理領域的标準和霸主。

我們知道Docker的logo“萌萌哒”，一頭馱着軟體鏡像的集裝箱在IT世界的汪洋裡自由遨遊的鲸魚。

而Kubernetes的logo，則展現了Google這家老牌IT企業的睿智和大氣。Kubernetes源自古希臘語，意為“舵手”，Google的用意昭然若揭：Kubernentes(舵手)就是Google在雲時代裡，引領整個IT世界在容器編排管理這個領域裡傲遊的舵手和上司者地位的展現。

再回到SAP，作為一家向雲轉型的軟體公司，據Jerry所知目前SAP内部很多開發團隊的持續內建/持續傳遞的流程和系統已經遷移到Kubernetes上，受益于Kubernetes高度的自動化和高可用性，SAP基于微服務架構的産品開發團隊的傳遞流程大大簡化，同時運維人員的工作量也大大減輕。伴随着SAP内部對Kubernetes的使用，也誕生了一位位像**Jason Gu，Benny Gu和Peng Wang(排名不分先後)**這樣的Kubernetes技術專家。

Kubernetes隻用于SAP内部麼？當然不是。Jerry之前的文章曾經介紹過SAP雲平台上的Neo和CloudFoundry程式設計環境：

使用Java+SAP雲平台Neo環境+SAP Cloud Connector調用ABAP On-Premise系統裡的函數

在SAP雲平台的CloudFoundry環境下消費ABAP On-Premise OData服務

如今(2018年11月），打開SAP雲平台官網，會發現這樣一條新聞：

https://cloudplatform.sap.com/enterprise-paas/kubernetes.html

按照網頁上提供的資訊，Kubernetes在未來也會成為SAP雲平台支援的運作環境之一。SAP Partners們以前部署并運作在Kubernetes容器叢集上的應用，通過另一個開源工具，Gardener，可以容易地遷移到SAP雲平台的Kubernetes環境下。

Gardener的首頁也很有意思，口号是“The Kubernetes Botanist”，Jerry用過Gardener提供的一站式服務建立用于試用目的的Kubernetes叢集，覺得确實非常友善，其簡捷的步驟為應用軟體開發人員屏蔽了Kubernetes叢集底層搭建和配置細節，能夠在短短幾分鐘内得到一個可用的Kubernetes叢集：

這種Kubernetes-As-A-Service的特點，正和其口号裡的"Botanist"相吻合，Gardener就像一位辛勤的園丁，在全球的Kubernetes初學者的laptop上播下了一顆顆Kubernetes叢集的種子。

https://gardener.cloud/

除了SAP内部産品産品的持續內建和持續傳遞已經在使用Kubernetes，SAP雲平台将會添加對Kubernetes的支援之外，據Jerry所知，至少還有一個SAP釋出的産品是基于Kubernetes的，那就是Kyma。

小的時候，Jerry聽過牛頓這樣謙虛的一句話：“如果說我看得比别人更遠些，那是因為我站在巨人的肩膀上。（If I have seen further, it is by standing on the shoulders of giants.）”。當時聽了也就聽了。今年上半年，我是在對Kubernetes一無所知的前提下接觸了Kyma，當時覺得一頭霧水。等聽了SAP上海研究院三位老師的Kubernetes教育訓練課程之後，再回過頭來看Kyma，忽然有點領悟到牛頓當年這句話的含義。

Kyma是什麼? 又雙叒叕一個SAP開源的項目，源自希臘語，意思是wave(水波，波濤，注意下圖Kyma官網的水波logo吧，囧)，Jerry個人揣測，這意味着SAP希望憑借Kyma，在本就風起雲湧的雲原生開發世界裡再掀波瀾？

根據Kyma官網的描述，Kyma是一個基于Kubernetes的企業軟體擴充平台，能以Serverless/微服務架構的方式對On-premise或者雲應用進行擴充。

https://kyma-project.io/

當您在閱讀很多SAP C/4HANA的宣傳資料時，比如下圖對SAP C/4HANA五朵雲的介紹，會看到另一個名詞，SAP Cloud Platform Extension Factory(SAP雲平台擴充工廠)。Kyma和SAP Cloud Platform Extension Factory的關系，恰如Open UI5和Fiori的關系。Open UI5是SAP推出的一個開源UI開發架構和UI控件庫，而Fiori是SAP 基于Open UI5這個技術架構開發出來的商業化産品（當然現在Fiori也代表SAP推薦的一種UI風格）。類似的，SAP Cloud Platform Extension Factory是SAP基于Kyma這個開源項目，再針對企業應用所必須滿足的一些标準(比如SAP産品标準，區域特殊需求）而添加進額外的附加功能和實作的商用産品。

Jerry目前工作的團隊隸屬于SAP客戶體驗(Customer Experience)部門，這個部門的CTO Moritz Zimmermann, 在他的linkedin上發表過一篇部落格，裡面也提到了Kyma:

https://www.linkedin.com/pulse/yaas-turns-sap-cp-extension-factory-bringing-digital-level-moritz/

也正是在這篇部落格裡，Mortiz給出了一個重要的訓示：Kyma(SAP Cloud Platform Extension Factory)将來會成為SAP C/4HANA套件裡所有基于微服務架構産品的統一擴充工具。

Kyma到底有什麼強大之處，能夠同時滿足SAP C/4HANA裡五朵雲的擴充需求？我們來看看Kyma的官方網站是怎麼說的：

作為一個開發人員，上面這段Kyma的介紹文字，最吸引我的莫過于Jerry高亮的“Kyma能夠允許開發人員使用任何技術棧去擴充應用，這些技術棧可以和被擴充的原始應用沒有任何關系”。

那麼Kyma的工作原理到底是怎樣的？我們用一個具體例子來說明。

由于到目前為止出現了很多新名詞：容器，Kubernetes，Gardener，Kyma等等，在Netweaver上做二次開發的partner們可能覺得很陌生，是以這裡我們選擇一個熟悉的場景作為例子。

假設有這樣一個資料同步的需求：每當SAP Cloud for Customer(C4C)裡有銷售訂單建立或者修改時，把該訂單同步到S/4HANA去。

對于這種多個SAP産品間的資料同步需求，SAP推薦的解決方案是使用SAP PI或者SAP HANA Cloud Integration作為資料同步的中間件。

因為本文是談Kyma，是以Jerry介紹第三種解決方案。

C4C系統提供一個所謂OData事件通知機制：

下圖配置頁面含義是為銷售訂單這個Business Object的Create和Update兩個事件定義釋出機制：一旦有新的銷售訂單生成或者已經存在的銷售訂單被修改，C4C會通過我定義的OData服務zjerrysalesorder自動向這兩個事件的監聽者釋出事件。

事件的監聽者，或者說消費者，在下面的界面注冊。我在S/4HANA系統，A6P/213開發了一個Restful API，負責接收C4C系統釋出的銷售訂單事件，根據C4C Odata提供的資料在S/4HANA建立銷售訂單。這是另一種輕量級的資料同步解決方案。

這種解決方案的核心就是釋出者/訂閱者模式。其實這也正是Kyma的擴充原理。

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

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

通過這種方式，實作了進行二次開發的Kyma微服務同SAP标準産品的解耦。我們可以同ABAP Netweaver裡傳統的流程擴充手段**Business Addin(****BAdI)**進行比較，後者也能實作增強邏輯和标準産品的解耦，隻不過BAdI增強和SAP标準邏輯是運作在同一台實體機的同一個ABAP session内的。而Kyma這種增強方式，标準産品通過HTTP調用去消費部署在Kyma上的包含增強邏輯的微服務，雖然增加了網絡調用的開銷，但是能享受到Kyma底層的Kubernetes帶來的Servless特性，不用花費額外的工作量就能確定擴充的高可用性，節點處理能力的高擴充性和高伸縮性。

3. 為了確定應用開發人員能真正專注于增強邏輯的開發，Kyma還引入了Lambda函數的概念。使用過JavaScript ES6的箭頭函數和Java 8的Lambda表達式，函數接口的朋友們對這個概念一定不會陌生。

使用Kyma Lambda函數，應用開發人員不需要從頭實作一個微服務，Kyma會自動将SAP标準産品釋出的事件和上下文通過輸入參數注入到Lambda函數中，所有的增強邏輯均是現在Lambda函數内。

下圖上半部分是Kyma内的一個Lambda函數，基于nodejs實作，下半部分是完全等價的ABAP SICF服務實作, Kyma中的event.extensions.request和response分别對應ABAP裡的server->request和server->response。

Lambda函數調用好之後，可以直接作為消費者綁定到某個事件上，被Kyma的Event Bus子產品觸發來實作對SAP産品的增強。當然，因為Kyma是基于Kubernetes，我們也可以直接用kubectl create -f 建立service，然後綁定到某個事件上，或者可以借助Service Broker導入第三方的service進行消費。

希望本文能讓大家對Kubernetes和SAP Kyma的關系從概念上有一個了解，感謝閱讀。