容器，Docker, Kubernetes和Kyma，以及Kyma对SAP的意义

大家好，今天非常高兴能给大家做一个关于Kyma的技术分享。这个session的audience主要是针对使用咱们成都研究院使用Java和nodejs等技术栈做微服务开发的同事们。对于在ABAP netweaver上做SAP传统开发的同事们来说，这个session可以让大家开阔一下眼界。

这是今天session的agenda：

•Why Containers?

•Relationship between Containers and Dockers?

•Why Kubernetes？

•Relationship between Kyma and Kubernetes

•A real example: Commerce cloud extension via Kyma

之所以要在Kyma真正开始前做容器，Docker，Kubernetes的铺垫，是因为Kyma基于Kubernetes，而Kubernetes又是容器编排框架，Docker又是一种流行的容器运行时实现技术，如果不提Kubernetes，Docker和容器，没有接触过这些概念的同事一定会觉得一头雾水。

我们先来看容器。

我们说任何技术都有其使用场景和解决的痛点。那么为什么这些年来容器技术非常火呢？

得益于近些年微服务架构的火热，很多企业包括SAP自己也在开发基于微服务架构的新应用，比如在坐很多同事所在团队正在做的事情。而基于微服务架构的SaaS软件开发，业界有一套标准，或者说是最佳实践，那就是著名的twelve-factor标准：

https://12factor.net/zh_cn/

而容器，就是一种有助于开发人员以更小的代价去开发一个满足这12个准则的基于微服务架构的云原生应用的技术。比如这个准则里提到的，微服务应用的build，release和运行阶段应该严格区分，应用通过一个或多个无状态的进程进行执行，彼此隔离，通过进程模型进行水平扩展，等等，这些通过容器技术都可轻易实现，不需要开发人员付出额外代价。

因此，我们需要记住一个结论，容器的使用场景，永远是和微服务架构，SaaS，云原生应用这些紧密相连的。

那么容器具体来说到底是一个什么东西呢？字面意思，用来装东西的集装箱。

装什么东西？除了应用程序本身之外，还包括这个应用要能正常运行所需的运行环境和库文件等外部依赖。

我们想象一下现实世界中的集装箱。一辆汽车从码头上被装到集装箱里，然后被货船载到另一个码头里。

这里的汽车就好比我们的应用，集装箱就是容器，汽车在不同的码头上装入集装箱就好比应用的部署。

这就是slide里第一条，Convenient package to ship things的概念。

Open specification：

要注意，容器 != Docker。Docker只是容器技术的一种商业化实现方案。

在2015年，由Google，Docker、CoreOS、IBM、微软、Redhat等厂商联合起来，成立了一个OCI（Open Container Initiative）组织，并于推出了第一个开放容器标准，旨在避免容器技术的碎片化。该标准主要分为运行时标准和容器镜像标准。

Isolated：容器隔离。这个很好理解，容器里运行的应用彼此之间是隔离的，一个应用出故障不会影响到其他容器。可以独立分别进行水平扩展。

Portable：既然容器封装了所有运行应用程序所必需的相关的细节，比如应用依赖以及操作系统，这就使得镜像从一个环境移植到另外一个环境更加灵活。比如，同一个镜像可以在Windows或Linux，开发、测试或生产环境中运行。基于容器的应用，既能运行在开发者的笔记本电脑上，也能运行在云服务提供商的数据中心上。真正做到一次构建，到处运行。

LightWeight：轻量级。虚拟机和容器的目的类似，都致力于对应用程序及其关联性进行隔离，从而构建起一套能够不依赖于具体环境而运行的应用单元。虚拟机是在物理服务器的上层用软件来模拟特定的硬件系统。Hypervisor位于硬件和系统之间，是创建虚拟机必须的一个部分。虚拟机软件必须使用Hypervisor作为一个中间层，是虚拟机技术的核心，当宿主操作系统启动虚拟机时，会通过hypervisor给虚拟机分配内存，CPU，网络和磁盘等资源，并加载虚拟的操作系统，因而需要消耗宿主机大量的物理资源。

一台宿主机上运行的多个容器化应用共享这台宿主机操作系统的内核，因而不需要虚拟机技术的hypervisor中间层，因而同虚拟机技术相比，更加轻量化，启动速度更快。

那么容器和docker的关系又是怎样的？

前面已经说到了，Docker只是基于开放容器标准的一种比较受欢迎的实现。Docker之于容器，相当于React，Angular和Vue之于UI开发框架。

既然大多数时候我们在谈到容器时，都会不自觉地想到Docker，那么Docker到底是用什么实现的呢？

著名的计算机科学家王垠，曾经在他的个人博客上撰文，声称Docker和Kubernetes并不是什么了不起的技术。从科学家的角度出发，这个论断不能算错误，因为Docker底层确实就是对Linux里很多原语做了很好的封装，所以从商业化的角度取得了成功。

以下是一些Docker封装的Linux系统原语的一些例子。Jerry是SAP Docker和Kubernetes培训课程的讲师之一，在这个课程上，我们会对Docker如何凭借这些原语实现开放容器标准做深入的讨论。

接下来，我们引入Kubernetes。为什么有了Docker后，还需要Kubernetes？

我们知道从结果上看，Docker和虚拟机都可以做到让应用在隔离的环境下运行，区别在于Docker运行环境仍然能够和宿主机共享操作系统内核，而虚拟机则通过付出更多宿主机系统资源的代价，构造出一个完全虚拟的操作系统，让应用在里面运行。

然而Docker容器和虚拟机还是有一些问题没有解决，就是容器在大型分布式集群上的部署，微服务应用中的容器管理和协同，自动地水平扩展，自动修复和弹性伸缩等等。

这也是Kubernetes大显身手的地方。诞生于2015年7月的Kubernetes，是Google内部多年使用的容器集群管理系统Borg的开源版本。由于凝聚了Google在容器编排领域多年的深厚功力，发布之后很快就一飞冲天，如今已经成为事实上的容器集群管理领域的标准和霸主。

Kubernetes源自古希腊语，意为“舵手”。有人调侃说，Google选择Kubernetes这个单词，暗示了自己想在容器编排管理这个领域里扮演舵手和领导者的角色。

Kubernetes和Docker容器的关系？下面这张图片是SAP Kubernetes培训课程slide里的一张，用来说明Kubernetes和docker容器的关系，我觉得很形象。

运行了各种微服务应用的容器就好比图中使用各种乐器演奏的音乐家，而站在中间的指挥家，和使用乐器演奏的音乐家站立的台阶，就相当于Kubernetes。

如果更准确的说，Kubernetes管理的不是容器，而是pod。Pod是一个或者多个容器组成的集合。

至此，我们终于完成了了解Kyma必须的前置知识的介绍。

什么是Kyma？去年6月份，SAP C/4HANA正式announce时，这张图在大家的朋友圈中都刷屏似的存在。

大家可以看到，Slide里的描述，SAP云平台扩展工厂是一个基于云端原生微服务的通用创新和敏捷平台。

那么云平台扩展工厂和括号里的Kyma关系又如何？

二者的关系恰如Open UI5和Fiori的关系。Open UI5是SAP推出的一个开源UI开发框架和UI控件库，而Fiori是SAP 基于Open UI5这个技术框架开发出来的商业化产品（当然现在Fiori也代表SAP推荐的一种UI风格）。类似的，SAP Cloud Platform Extension Factory是SAP基于Kyma这个开源项目，再针对企业应用所必须满足的一些标准(比如SAP产品标准，区域特殊需求）而添加进额外的附加功能和实现的商用产品。

Kyma对C/4HANA意味着什么？我们CX部门的CTO Moritz Zimmermann, 在他的linkedin上发表过一篇博客，里面也提到了Kyma:

Kyma(SAP Cloud Platform Extension Factory)将来会成为SAP C/4HANA套件里所有基于微服务架构产品的统一扩展工具。

Kyma是基于Kubernetes的，这也是我们之前花了很多时间进行Docker和Kubernetes介绍的原因。

那么Kyma的工作原理是什么？简单的说就是一个观察者-发布者模式。

1. 通过Application Connector，可以使Kyma同SAP C/4HANA的产品建立连接，然后进行事件注册。

2. 事件注册好之后，使用微服务架构实现事件的监听者（消费者）。这也是Kyma官网里提到的"开发者可以使用任何技术栈进行扩展开发“的含义。举个例子，我们在SAP Commerce Cloud里创建一个订单后，客户提出了基于该企业流程的一些特殊校验逻辑。Commerce Cloud发布一个"Order Create"的事件，事件payload包含创建订单的字段。我们开发并部署在Kyma上的微服务监听这个事件，微服务内部实现可以采取任何技术栈，Commerce Cloud通过HTTP调用包含了企业自定义订单校验逻辑的微服务，根据其返回的校验结果进行后续处理。

我们来看一个具体的demo，看看SAP Commerce Cloud里订单编排功能是如何用Kyma去增强的。

下图蓝色流程是我们通过Kyma对Commerce Cloud的标准流程进行的增强，主要是在下单过程中增加了一些Validation校验。

我们登录commerce的back office页面，定义一个新的action：

然后进到Kyma的console页面：

选择一个stage进去，点击Lambdas进入编辑页面：

新建一个Lambda function，取名fraudcheck2：

这个function自动创建的标签(Labels)，Kubernetes老司机一定觉得很亲切。这些标签其实和大家现实工作中使用云笔记里的标签和图片管理软件里的标签作用相同，就是一种键值对(Key Value Pair), 可以允许用户把Kubernetes的对象能灵活的分组，并提供高效的检索。

Function Trigger里可以指定这些Lambda函数在哪些事件触发后执行。选择第一步定义新的action后对应的event：

Lambda函数具体的实现，做过nodejs开发的朋友们一定不会觉得陌生。

首先第18行，19行从event这个输入参数对象里取得发生事件的订单Code，然后第26行消费OCC(Omni Commerce Channel)Restul API获得订单明细，从明细里获得订单的客户ID，再调用第30行的代码根据客户ID拿到客户明细，然后使用第37行和第40行的代码分别检查该客户的邮箱地址是否有效，以及该客户是否第一次下单。

注意第43行和46行的代码我暂时注释掉，稍后才会启用。

现在我们来测试一下。在Commerce里下一个单，记下订单ID。

回到Commerce back office页面，查看刚才下的订单的Business Process：

这里看到了刚才第一步新建的基于Kyma Action对应的流程日志记录：

我们再去查看这个订单的Fraud检查记录：

点这个Fraud Reports查看检查结果。这个标签从左到右依次排开的风格很像Fiori和ABAP Webdynpro。

可以看见前文介绍的Email和是否是首单的检查结果。

Email检查结果，客户的邮箱地址有效。

现在再回到Kyma的Lambda函数编辑器里，将之前注释掉的从Marketing Cloud获取联系人地址的函数以及调用SAP云平台的Business Partner服务的函数重新启用：

启用之后，保存，然后进入Service Catalog。这个组件也是Kubernetes提供的标准组件，Kyma基于它做了增强，能够将第三方的服务导入进来给Kyma的Lambda函数消费。

接下来的步骤和我们在SAP云平台上消费一个服务类似，首先创建一个服务实例：

然后再基于这个服务实例创建一个绑定，

绑定类型设置成Function Binding，绑定的目标设置成之前编辑好的Lambda函数。

再下一个单：

这一次，这个第二次下的订单的Fraud检查报告，同第一个订单相比就多了两条记录：

首先看第二条首单检查的记录，得分为0，和我们期望的结果一致。

从Marketing Cloud的服务返回的检查结果：

从SAP云平台的Business Partner服务返回的结果可以看出，下单的这个客户不存在一个对应的Business Partner。

至此关于如何使用Kyma对SAP Commerce产品的订单编排做增强就简单介绍到这里，感谢阅读。

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