站在巨人肩膀上的牛頓：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程式設計環境：
如今(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叢集的種子。
除了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或者雲應用進行擴充套件。
當您在閱讀很多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的關係從概念上有一個瞭解，感謝閱讀。
更多閱讀
-
SAP Cloud Platform Kubernetes Environment：
https://cloudplatform.sap.com/enterprise-paas/kubernetes.html
要獲取更多Jerry的原創文章，請關注公眾號"汪子熙":
