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

版权声明:本文为博主汪子熙原创文章,未经博主允许不得转载。 https://jerry.blog.csdn.net/article/details/84240067

这周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编程环境:

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

更多阅读

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券