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

时间 2019-11-19

标签站在巨人肩膀牛顿 kubernetes sap kyma 繁體版

原文原文链接

这周Jerry在SAP上海研究院参加了一个为期4天的Kubernetes培训，度过了忙碌而又充实的4天。Jason，Benny和Peng三位大神的培训干货满满，借此机会，Jerry和过去的两位老领导Patrick和Evan叙了叙旧，也拜见了上海SAP圈子里的几位大佬。之前在网络上久闻大名，此次终于见到了大佬们本人，了却我一桩心愿。html

为何SAP内部也在开展Kubernetes的培训呢？诞生于2015年7月的Kubernetes，是Google内部多年使用的容器集群管理系统Borg的开源版本。因为凝聚了Google在容器编排领域多年的深厚功力，发布以后很快就一飞冲天，现在已经成为事实上的容器集群管理领域的标准和霸主。node

咱们知道Docker的logo“萌萌哒”，一头驮着软件镜像的集装箱在IT世界的汪洋里自由遨游的鲸鱼。git

而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的关系从概念上有一个了解，感谢阅读。

更多阅读

要获取更多Jerry的原创文章，请关注公众号"汪子熙":