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

2021 年 12 月 26 日
本文字数：3706 字
阅读完需：约 12 分钟

诞生于 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 集群的种子。

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 <yaml file>创建 service，然后绑定到某个事件上，或者可以借助 Service Broker 导入第三方的 service 进行消费。

希望本文能让大家对 Kubernetes 和 SAP Kyma 的关系从概念上有一个了解，感谢阅读。

更多阅读