SAP ABAP Netweaver 容器化的一些前沿性研究工作分享

笔者之前的文章一个15年ABAP老兵的建议：了解这些基础知识，对ABAP开发有百利而无一害, 回顾了 ABAP Netweaver 服务器主要的组件。本文咱们就来聊聊 ABAP Netweaver 容器化这个话题。

笔者假定阅读本文的朋友，都听说过虚拟机和容器的概念， 并且对虚拟机和容器的区别有所了解。

容器与虚拟机的出发点很类似：对应用程序及其依赖进行隔离，生成一套能够随处运行的自容纳单元；二者都能够使应用运行在一个虚拟出的抽象层里，摆脱对传统物理硬件的依赖，使得计算资源的利用更加高效，能源效率与成本效益得以提升。容器在虚拟化程度上比虚拟机技术更进一步，摆脱了前者对 Hypervisor 层的依赖，直接利用宿主机的内核，抽象层比虚拟机更少，更加轻量化，同虚拟机技术相比能达到更高的物理资源利用率，因此更受当今云服务提供商的青睐。

Docker 是一个开源的应用容器引擎，是当今最流行的容器技术之一。

那么 SAP ABAP Netweaver，能否利用 Docker 引擎，让它运行在容器里呢？

SAP 官方的 note 1122387 - Linux: SAP Support in virtualized environments 给出了答案：截至 2020 年 1 月 17 日，答案是不支持。SAP 官方不支持将 ABAP 应用服务器运行在容器或者容器编排环境内。比如目前业界流行的 Docker 和 LXC，以及运行在 Google Cloud Platform, Microsoft Azure, AWS 上的 Kubernetes Cluster，都不是 SAP 官方支持的能够将 ABAP Netweaver 服务器以容器的方式运行的平台。

SAP 社区曾经有一篇博客：Installing SAP NW ABAP into Docker

这又是怎么一回事呢？我们可以通过阅读博客了解作者是怎么做到的。

首先，我们从 SAP 官网上能免费下载 Netweaver 的开发者试用版，ABAP 版本号为 7.52 SP04：

下载到本地，得到一个 rar 文件，解压之后执行里面的安装文件即可把 ABAP Netweaver 安装到本地。

因此 SAP 社区上的一群 ABAP 爱好者们，想到了一个点子：如果把下载的 Netweaver 安装文件，解压之后，将其内容构建成一个 Docker 镜像文件，在这个 Docker 镜像内完成 Netweaver 的安装和启动工作。如此一来，岂不是达到了在容器里运行 ABAP Netweaver 的目的？

我们可以在这位 ABAP 爱好者的 github 仓库 上找到用来制作 Docker 镜像的 Dockerfile 文件，从中了解到该容器镜像的制作过程：

这个 Dockerfile 构建的镜像选择了 openSUSE Leap 作为母镜像，该镜像提供了 ABAP Netweaver 运行的 Linux 操作系统。

Dockerfile 的第一行用 FROM 关键字指定了这个基准镜像的名称：

第 16 行用 COPY 将事先从 SAP 官网下载好的存储在宿主机 NW752 文件夹下的 Netweaver 开发者版本安装文件，拷贝到容器镜像里，然后第 22 行用 RUN 关键字运行安装脚本。

安装完毕后，执行 47 行的启动脚本 run.sh, 这样就能在容器里启动 Netweaver 服务器了。这个容器镜像制作好之后，只需要简单地使用 docker run 命令行，就能启动一个新的容器运行实例了。从 SAP 官网下载的 Netweaver 开发者版本，就运行在这个新启动的容器实例里。

我们回顾这种做法，发现 Docker 技术较之虚拟机的优点并没有体现出来，按照博客作者提供的信息，通过这种方式制作出的镜像文件的大小超过了 100GB，如此巨型的镜像文件几乎无法通过 Docker Hub 分发给其他人，无法用于生产用途。

另一方面，通过这种容器化方式，Netweaver 服务器的诸多组件，被放置到同一个容器内，无法通过简单地增加容器实例的方式，实现 Netweaver 处理能力的水平扩展。

正是因为意识到将 Netweaver 所有组件放置于同一容器镜像内这种措施无法发挥容器技术的优势，SAP Linux 实验室的工程师们采取了另一种思路，即这篇 SAP 社区博客里给出的架构图所体现的，将 Netweaver 组件进行拆分，分别放置于不同的容器编排逻辑单元中。

Proof of Concept: Deploying ABAP in Kubernetes

上面的架构图里并没有看到容器的影子，而 Jerry 之前文章介绍的 ASCS(ABAP SAP Central Services instances)和 AS(Application Server，应用服务器)，被放置到了名为 Pod 的逻辑单元里。

Kubernetes 是容器编排和管理的平台，不直接操作容器，而是将一个或多个功能上相关的容器封装到称之为 Pod 的逻辑单元中，我们可以简单的把 Pod 理解成容器的集合。

一个 SAP 系统由一个 ASCS 实例和一个或多个 AS 实例构成，对于 ASCS 里包含的组件，比如之前介绍过的消息服务器，Enqueue 服务器，Dispatcher 等等，每个组件分别构建不同的容器镜像，再将这些镜像封装到一个单独的 ASCS Pod 里。

而 ABAP Netweaver 支持多 AS 实例部署的这种特性，恰巧能让 Kubernetes 原生支持的 Horizontal Pod Autoscaler 机制大显身手。将 AS 单独制作成容器镜像并放入 AS Pod 里，通过 Kubernetes 的 Deployment Unit 管理这些 Pod，从理论上说，可以使用 Kubernetes 命令行进行 ABAP 应用服务器的水平扩展。

这种思路将 ABAP Netweaver 的组件分别进行容器化，大大缩小了每个组件对应的容器镜像文件的尺寸，使得应用服务器实例能够根据实际计算能力的需求变化，进行动态伸缩。如果想将这种方法应用到生产场景中，面临的一些挑战有：

(1) Kubernetes 对待 Pod 的方式是官网里所谓的 Cattle-like treatment，即 Kubernetes 就是 Pod 的上帝，可以根据实际需要，随时创建新的 Pod 或销毁已有的 Pod，而运行在 Pod 内的应用消费者，完全感知不到 Pod 的这些变化。另一方面，我们知道，运行在 ABAP Netweaver 上的很多应用都是有状态的事务，比如编辑一个订单之前，用户先点击编辑按钮，此时应用会往 Enqueue 服务器发起一个申请锁的请求，成功获取锁之后继续编辑操作。如果此时运行该事务的 AS 实例所在的 Pod 正好被 Kubernetes 销毁了，那该用户尚未结束的编辑操作该如何处理？再比如某个 Pod 内的 AS 实例正在运行很多后台作业，那么这种 Pod 可以被 Kubernetes 销毁么？

这种挑战简单概括起来，就是如何调和 Kubernetes Pod 的水平伸缩机制和 ABAP Netweaver 的有状态事务处理(会话一致性)的需求。

(2) 在 ABAP Netweaver 容器化以前，大部分组件是在同一物理网络下彼此通信。容器化之后，组件与组件之间的通信会多经过一层 Kubernetes 的网络层，这使得整个系统的复杂度增加。

(3) 我们知道 ABAP Netweaver 有很多种同第三方系统集成的途径：RFC，Web Service，OData，IDOC 等等。将 ABAP 容器化之后，以前这些技术是否仍然可以在不需要调整 Netweaver 核心实现的前提下继续工作，需要进行实际的验证。

所谓 No pain，no gain，付出总会有收获。如果 ABAP 成功容器化之后，理论上我们会享受到哪些容器技术带来的便利呢？

(1) ABAP 的安装和部署过程将会大大简化。假设出现了官方的 ABAP 容器镜像和 Kubernetes Deployment 文件，我们可以仅仅用几行简单的命令行，在任何支持容器和 Kubernetes 的平台上，轻松完成 ABAP 的安装和部署。

(上图来自博客：https://www.itsfullofstars.de/2017/09/dockerfile-for-sap-netweaver-abap-7-5x-developer-edition/)

(2) 假设前文介绍的 ABAP 会话一致性的挑战已经成功解决，那么 ABAP 应用服务器实例的弹性伸缩，仅仅通过 Kubernetes 几条简单的命令行就可轻松实现。在 ABAP 传统部署场景下，增添新的应用服务器实例需要 ABAP Basis 人员进行繁琐配置的局面将不复存在。

除了在 Kubernetes 里通过人工敲命令行的方式调整 Kubernetes 的计算资源以外，Kubernetes 原生就具有根据 CPU 或者内存的使用率，进行全自动伸缩的调整能力。这种完全无需人工界入的资源调整功能，如果能够运用到 ABAP Netweaver 上，无疑给我们留下了太多美好的想象空间。

SAP 技术在不断向前演化，ABAP 也从未停止前进的脚步，让我们活到老，学到老。感谢阅读。