什么是 Kyma？其官网的定义是，Kyma 是一个开源的云原生应用开发平台和运行时，底层基于 Kubernetes，借助一系列包括 Istio, NATS, Serverless 和 Prometheus 在内的其他优秀开源项目和组件，能够开发、运行和操作云原生应用程序，支持对传统的 On-Premises(本地部署)应用程序和云原生应用基于事件驱动模式的松耦合扩展。
本文分为两部分，分别给大家介绍使用 Kyma 对本地部署的传统应用和企业级云原生应用进行扩展的案例。
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 官网的客户成功案例中，赫然有 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 数据的工作量。
这个增强最关键的一步，就是打通 SAP 销售云与 Kyma 的连接，让 Kyma 能够接收到 SAP 销售云运行业务流程时抛出的事件。
进入 SAP 销售云 Administration 工作中心 的 Event Notification 配置页面：
新建一个销售云 OData 事件的消费者，即 Kyma 实例。
Consumer 创建页面需要维护远端 Kyma Application Connector url：
这个 url 可以通过登录 Kyma 控制台，点击 Connect Application 按钮生成：
回到销售云配置页面，指定将 Account 和 Opportunity 这两个 Business Object 的创建和更新事件，发送给 Kyma.
这些 Business Object 的事件发布行为，通过销售云的 Subscription 来描述：
保存配置后，到 Kyma 控制台，此时就能观察到 SAP 销售云(Sales Cloud) 注册的事件了。
点击 SAP Sales Cloud，能够查阅注册事件的技术明细，比如事件负载(Payload) 格式，包含的字段名和数据类型等。
剩下的就是和之前扩展 WordPress 以及 SAP 电商云一样的操作，在 Kyma 中基于 SAP 销售云注册的事件，创建 Lambda Function，解析事件参数并进行相应处理。出于文章篇幅限制，在 Lambda Function 里仅仅简单将销售云传入的事件对象的内容打印出来。
在 SAP 销售云里新建一个 Opportunity 并保存。
到 Kyma Lambda Function 日志控制台里，观察到了函数体里使用 console.log 打印出的来自 SAP 销售云的 Opportunity 创建事件包含的字段：
本文首先简要介绍了 Kyma 这个底层基于 Kubernetes 的开源云原生应用开发平台和运行时，接着分成两大部分，分别分享了使用 Kyma 对传统的 On-Premises 应用(WordPress) 和企业级云原生应用(SAP 电商云和 SAP 销售云)进行扩展的案例。
这些扩展案例均来自笔者实际工作中的项目经历，希望能起到抛砖引玉的作用，感谢阅读。