站在巨人肩膀上的牛顿：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的关系从概念上有一个了解，感谢阅读。
更多阅读
-
SAP Cloud Platform Kubernetes Environment：
https://cloudplatform.sap.com/enterprise-paas/kubernetes.html
-
使用Java程序消费SAP Leonardo的机器学习API
-
使用Java+SAP云平台+SAP Cloud Connector调用ABAP On-Premise系统里的函数
-
使用JDBC操作SAP云平台上的HANA数据库
-
用JavaScript访问SAP云平台上的服务遇到跨域问题该怎么办
-
在SAP云平台的CloudFoundry环境下消费ABAP On-Premise OData服务
-
SAP数据中心概述
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
