共计 5295 个字符，预计需要花费 14 分钟才能阅读完成。
大家好，今天非常高兴能给大家做一个关于 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 的原创文章，请关注公众号 ” 汪子熙 ”:
