基於 Kyma 的企業級雲原生應用的擴充套件案例分享

什麼是 Kyma？其官網的定義是，Kyma 是一個開源的雲原生應用開發平臺和執行時，底層基於 Kubernetes，藉助一系列包括 Istio, NATS, Serverless 和 Prometheus 在內的其他優秀開源專案和元件，能夠開發、執行和操作雲原生應用程式，支援對傳統的 On-Premises(本地部署)應用程式和雲原生應用基於事件驅動模式的松耦合擴充套件。

本文分為兩部分，分別給大家介紹使用 Kyma 對本地部署的傳統應用和企業級雲原生應用進行擴充套件的案例。

使用 Kyma 擴充套件本地部署的 WordPress 應用

WordPress 是一個基於 PHP 的開源內容管理系統，很多朋友喜歡使用 WordPress 搭建自己的個人部落格網站。

設想這樣一個場景：某程式設計師是一個社交媒體達人，喜歡將自己的見聞經歷，同步到 Twitter，Facebook，Youtube，微信等多個社交媒體上。手動登入一個個媒體平臺然後逐一更新狀態，無疑是一件費時費力的事情。

還好我們是程式設計師，可以充分發揮自己的動手能力。

假設我們自己的 WordPress 網站可以同 Kyma 連線，每當 WordPress 有新的動態(比如一篇部落格)釋出時，會給 Kyma 傳送一個 post.published 事件。Kyma 接收到該事件後，觸發註冊在該事件上的監聽函式，逐一呼叫社交媒體平臺的 API，建立對應的動態即可。

我們本地部署的 WordPress，扮演的就是下圖左邊 Business Solution 代表的角色。

安裝 Kyma for WordPress 的外掛之後，我們能夠在 WordPress Settings 標籤頁裡，看到一個新的 Kyma Connector Settings 頁面，維護 Kyma 例項的 url，登入使用者名稱和密碼等資訊。

在上圖 Kyma Connection 欄位裡維護的 url，會被 Kyma Application Connector 解析，並在 WordPress 和 Kyma 間建立互相信任的連線。

在 Kyma 控制檯建立一個新應用，點選 Connection Application 按鈕，把彈出的 url 維護到 WordPress Kyma Connection 欄位。

如果把該 url 直接貼上到瀏覽器裡，可以看到以下內容：

csrUrl(Certificate Signing Request) 和 certificate：用來生成在 WordPress 和 Kyma 之間建立 SSL 連線所必需的數字證書
api：Kyma Service Catalog 註冊的 endpoint

我們透過單步調式 WordPress 的方式，來深入瞭解 WordPress 與 Kyma 建立安全連線的技術細節。

WordPress 向傳入的 url 發起 HTTP GET 請求(下圖第 22 行程式碼的 wp_remote_get)，獲取到 CSR Certificate 和 API end point，儲存在第 32 行的變數 $body_json 內。

第 73 行從變數 $body_json 的 csrUrl 欄位拿到 Kyma 的 CSR(Certificate Signning Request）url，第 75 行向該 url 傳送一個 POST 請求，拿到響應：

將 HTTP 響應資料另存為WordPress 目錄下的三個本地檔案：

crt.pem
clientCrt.pem
caCrt.pem

接下來 WordPress 同 Kyma 的安全連線，就是基於這些本地數字證書檔案來完成。

建立了安全連線後，下一步需要將 WordPress 指定的事件釋出到 Kyma 上去。

點選上圖 Save Changes 之後，WordPress 的 Kyma 外掛會將使用者維護的待註冊事件，拼裝成對應的 JSON 字串，透過 HTTP POST 請求向 Kyma 傳送：

事件註冊成功後，在 Kyma Application 控制檯，就能看到發起連線請求的 WordPress 例項的對應記錄：

同時在 Kyma Service Catalog 裡，也能看到 WordPress 透過註冊事件暴露出來的可訪問 API 入口：

WordPress 事件釋出成功後，這些事件就會出現在 Kyma 例項控制檯的 Service Catalog(服務目錄)介面裡，如下圖所示。

這種事件序號產生器制，確保了 WordPress 和 Kyma 的松耦合關係：在 Kyma 平臺上編寫事件監聽函式的開發人員，完全不需要了解關於 WordPress 的任何技術細節，這些事件監聽函式在 Kyma 上的載體就是一個個 Lambda Function，開發人員可以用自己喜歡的程式語言來實現函式。

建立一個 Lambda Function，為 WordPress 暴露給 Kyma 的 post.published 事件實現監聽函式的邏輯。

函式實現的技術棧，選擇 Node.js：

Select Function Trigger 即觸發方式選擇，我們選擇 WordPress 暴露給 Kyma 的 post.published 事件。這樣當 WordPress 裡有新的 post 建立時，WordPress 會傳送 post.published 事件，連同 post 的具體內容，傳給 Kyma，後者會自動呼叫建立好的基於 Serverless 的 Lambda Function.

剩下的 Lambda Function 的實現工作就是純粹的 Node.js 程式設計：從事件引數 event 物件裡將 WordPress 傳入的 post 內容解析出來，呼叫 axios 工具庫將此條 post 進行轉發。

Lambda Function 實現裡，我選擇了呼叫微信 Open API，將該條 post 推送給一個用於測試的硬編碼的微信使用者：

以上就是使用 Kyma 將 WordPress 裡釋出的內容自動 "同步" 到其他社交媒體平臺比如微信的步驟。我們簡單回顧一下思路：

(1) 透過 Kyma Application Connector 與 WordPress 建立互相信任的安全連線。

(2) 將 WordPress 暴露出的 post.published 事件，釋出到 Kyma Service Catalog 裡。

(3) 實現 Kyma Lambda Function，監聽 WordPress 所釋出的 post.published 事件，實現對應的內容轉發到社交媒體平臺的功能。如果除了微信之後，還希望轉發到其他社交媒體平臺上，只需再建立一個新的 Lambda Function，然後呼叫其他的社交媒體平臺的釋出 API 即可。

以上步驟同樣適用於透過 Kyma 對其他的雲原生應用進行擴充套件。

按照上述三個步驟，對 WordPress 進行擴充套件之後，釋出一條新的帖子，關於影片《切爾諾貝利》的觀後感：

單步除錯 WordPress 的帖子釋出功能，發現釋出的帖子內容被推送到了 Kyma API Gateway 對應的 url：

回到 Kyma Lambda Function 函式的控制檯，確認 WordPress 傳送的事件內容，已經成功被 Kyma 接收到了：

最後我的微訊號上成功收到了 Kyma Lambda Function 裡呼叫微信 Open API 傳送的訊息：

使用 Kyma 擴充套件企業級雲原生應用

在 Kyma 官網的客戶成功案例中，赫然有 SAP，Netconomy，Accenture，Digital Lights 這些企業使用者。

SAP 在客戶體驗產品線(Customer Experience) 這一領域推出的 C/4HANA 套件，包含市場雲，電商雲，銷售雲，服務雲和客戶資料雲。Kyma 正是 SAP 推薦的對這些企業家雲原生應用進行擴充套件的推薦平臺和工具之一。

下面我們來了解一些具體的擴充套件案例。

SAP 電商雲(Commerce Cloud) 有一套訂單狀態編排模型，從使用者下單到訂單最終處於 Complete 狀態，狀態的遷移透過一系列 Action 進行驅動。

假設我們期望在 SAP 電商雲裡實現這樣一個增強場景：在使用者下單之後，發貨之前，增添一個自定義的檢查步驟 Fraud Check(訂單欺詐檢查)，如下圖流程圖內淺色矩形框所示。

一種比較直接的方式，是在 SAP 電商雲原始碼裡，查詢訂單編排流程裡基於 Spring 框架的 Hook，透過自定義 Java Bean 的方式，實現自定義檢查邏輯。這種方式在開發完成後，需要重新構建 SAP 電商雲的 Java 原始碼。這就是所謂的 In-App extension 方式。

如果選擇 Kyma 以事件驅動的方式對 SAP 電商雲進行增強，則增強邏輯以 Lambda Function 的載體儲存在 Kyma 平臺上，而非對 SAP 電商雲本身的原始碼進行增強。這種方式又稱為 Side-by-Side extension 方式。

主要的開發步驟如下：

(1) 在 SAP 電商雲進行配置，將自定義事件 Fraud Check 釋出給 Kyma.
(2) SAP 電商雲的增強開發人員，登入 Kyma 控制檯，建立 Lambda Function，將 Function Triggers 選擇為步驟一在 SAP 電商雲裡釋出的自定義事件。Lambda Function 的實現內容，即從事件物件裡解析出下單的客戶資訊，然後呼叫 Marketing Cloud 和 SAP 雲平臺提供的 Restful API，對該客戶身份的有效性進行檢查。

執行時，當使用者下單後，SAP 電商雲向 Kyma 丟擲一個事件。Kyma 分別呼叫 SAP Marketing Cloud 和 SAP 雲平臺的 Business Partner API，將檢查結果返回給 SAP 電商雲。

登入 SAP 電商雲 Backoffice 配置頁面，定義一個新的Action，ID 為 EXTERNAL_KYMA_FRAUD_CHECK.

登入 Kyma 控制檯，建立一個新的 Lambda Function，Function Triggers 選擇為 SAP 電商雲 Backoffice 裡維護的自定義事件：

Lambda Function 的具體實現：

程式碼 18～19 行：從輸入的 event 事件物件引數裡，解析出訂單 Code
26 行：消費 SAP 電商雲的 OCC(Omni Commerce Channel) Restul API，獲得訂單明細，從中獲得下單的客戶 ID
30 行：根據客戶 ID 拿到客戶明細
37 行：檢查該客戶的郵箱地址是否有效
40 行：檢查該客戶是否第一次下單
43 行：呼叫 SAP Marketing Cloud API 檢查客戶身份有效性
46 行：呼叫 SAP 雲平臺 Business Partner API 檢查客戶身份有效性

下面對這種基於事件驅動方式所完成的增強實現進行測試。

在 SAP 電商雲裡建立一個新的訂單，記下訂單 ID 2139.

登入 SAP 電商雲 Backoffice 控制檯，檢查自定義 Fraud Check 邏輯是否按照我們期望的流程來執行。

根據 ID EXTERNAL_KYMA_FRAUD_CHECK 進行搜尋，找到了之前新建的 Action 對應的流程日誌記錄：

開啟訂單的 Fraud Reports 皮膚，檢視檢查記錄：

Email 欄位檢查結果：客戶維護的 Email 欄位是一個有效的郵箱地址。

首單檢查(First Time Order Check)返回的分數是 100，根據 SAP 電商雲當前配置，這個結果被判定為首單。

SAP Marketing Cloud API 呼叫返回的結果：

SAP 雲平臺 Business Partner API 呼叫返回的結果：

我們再來看看另一個使用 Kyma 擴充套件 SAP 銷售雲即 SAP Cloud for Customer Sales 模組的例子。

這是一個所謂 Account Address Enrichment 的場景，使用者在 SAP 銷售雲裡建立 Account 主資料時，只需維護基本的地址資訊，點選儲存後，銷售雲傳送事件給 Kyma，後者響應該事件，呼叫 SAP API Hub上的 Address 微服務，把 Enrich 之後的地址詳情，透過銷售雲 Account OData API 進行寫回。這個增強可以減少銷售雲使用者錄入 Account 資料的工作量。