关于 ABAP Netweaver 的一些基础知识

在Jerry之前的图片推送中，我提到了SAP社区上这样一篇博客：

Proof of Concept: Deploying ABAP in Kubernetes
https://blogs.sap.com/2020/02/06/proof-of-concept-deploying-abap-in-kubernetes

里面介绍了SAP Linux实验室的工程师们将ABAP应用服务器各组件进行容器化并部署到Kubernetes上的尝试。

读完这篇博客后，我很想把其大意译成中文分享给大家，但是看到作者在博客里分享的这张架构图后，我觉得还是先有必要单独用一篇文章回顾一下ABAP Netweaver服务器的组成部分，作为探讨ABAP容器化的预备知识储备，因此就有了这篇文章。

本文简单回顾ABAP Netweaver应用服务器的主要组件。虽然即使不了解这些知识，也不影响ABAP开发人员完成日常工作，但是很多ABAP编程的最佳实践都和这些知识有着千丝万缕的联系，知其然知其所以然，能帮助大家写出更健壮更高效的ABAP应用。

什么是ABAP Netweaver应用服务器？

SAP Netweaver应用服务器是SAP ABAP应用开发和运行平台，ABAP开发人员在上面可以专注于具体业务逻辑的开发，凡涉及到更底层的基础设施相关任务，比如请求的负载均衡，进程的派生，同步和调度，内存管理，服务器多实例间缓存同步等等，统统交由Netweaver平台本身处理。如此一来，一个ABAP开发人员，即使不具备精深的计算机组成原理，操作系统，计算机网络等领域知识，也能胜任SAP应用的开发工作。

ABAP Netweaver应用服务器和SAP解决方案的关系？

本文讨论的SAP解决方案，仅限于那些基于ABAP技术栈的SAP产品。

Google里根据关键字"SAP ABAP three layer"搜索，能找到很多基于ABAP技术的SAP解决方案的三层经典架构图：

随便点开一张查看：

SAP客户位于图中最上面的展现层(Presentation Layer)，通过SAP GUI这个客户端软件或者浏览器访问SAP系统；

SAP系统的软件，安装在ABAP Netweaver服务器上，响应用户请求，完成对应的业务逻辑。ABAP Netweaver服务器位于上图中间的应用层。

最底层是数据库层，很多SAP产品都支持不同类型的数据库，比如SAP HANA，Oracle数据库，SQL Server等。

部分ABAP开发人员觉得，我们既然能够直接在ABAP Netweaver里用OPEN SQL对数据库表进行读写操作，那么Netweaver应用服务器本身就包含了数据库层。这样理解其实不正确。我们在Netweaver SE38里编写的OPEN SQL代码，会通过Netweaver内部的数据库接口，转换成数据库提供商相关的原生SQL语句在数据库里执行，并且从最底层的数据库层，到应用层里的ABAP程序之间的数据传输，也是通过数据库接口完成的。

本文讨论的ABAP Netweaver服务器的组成部分，位于三层架构中的应用层。

ABAP Netweaver服务器实例

运行在物理机器上的ABAP应用服务器，按照其用途的不同，又可分为两种实例：应用服务器实例和ABAP SAP中央服务实例(ABAP SAP Central Services instances, 缩写为ASCS instances), 也就是下图两个灰色矩形框代表的实例。

一个典型的SAP系统一般由一到多个应用服务器实例和一个ASCS实例组成。

从上图左边的矩形框里，能观察到ABAP应用服务器实例包含的主要组件有：

(1) Internet Communication Manager (ICM)

(2) ABAP dispatcher

(3) 工作进程

(4) RFC Gateway

(5) Start Service

下面是对这些组件的简要介绍。

Internet Communication Manager (ICM)

ICM是Netweaver服务器里一个单独的进程，由ABAP Dispatcher启动并监控，负责SAP系统和外部的网络通信。基于收到请求URL的解析，ICM会将请求分发给具体的handler进行处理。

ICM常用的与Internet交互的协议有HTTP，HTTPS，SMTP等。

下图是ICM的架构图。

Thread Control：该线程负责接收外界请求，从ICM线程池中取出空闲的工作线程，将请求的上下文交给工作线程。

工作线程：负责请求的具体处理，包含一个I/O处理器，可以用来进行网络的输入和输出操作。对于不同协议类型的请求，Thread Control会调度包含了对应协议插件的工作线程。

Watchdog：如果一个工作线程在任务处理时出现了等待某个响应直至超时的情况，Watchdog会将该工作线程释放，避免其无限期的等待，这样该工作线程可以服务于其他请求。而Watchdog会继续等待尚未到来的响应。其后如果响应到达，Watchdog会通知Thread control, 后者会继续调用新的工作线程来处理。

Signal Handler：处理来自操作系统或者其他进程的信号。

Connection Info: 这张表维护了每个连接的状态信息，包括内存管道等。

Memory Pipes：内存管道是基于内存的通讯数据结构，用于将ICM接收到的外部请求包含的数据转交给工作线程。

Internet Server Cache：服务器端的缓存，对于重复的请求可以加快响应速度。

ABAP Dispatcher和工作进程

二者的关系在下图体现得很清晰，ABAP应用服务器上运行着许多工作进程(Work Process)，这些进程类型各异，负责处理各种类型不同的请求。

事务码SM50里能看到当前应用服务器上的工作进程明细，比如下图显示用于处理用户普通事务请求的对话(Dialog)进程有30个，其中29个空闲；Update进程负责执行数据库的更新操作；Background进程处理后台作业，Spool负责打印任务。而ABAP里数据库更新的操作有V1和V2两种级别(平时大家用的默认都是V1级别），分别由下图的Update和Update Task2两种类型的工作进程完成。

Gateway

这里的Gateway和SAP Fiori里的Gateway系统是两码事，后者指代安装了SAP_GWFND这个Software Component的ABAP应用服务器，而我们现在即将讨论的Gateway，是ABAP应用服务器里的一个组件。

SAP系统之间，以及SAP系统与外部系统间通过基于TCP/IP的RFC(Remote Function Call，远程系统调用)进行通信，而Gateway作为RFC调用分发的入口，如下图所示：

值得一提的是，我们能够在SAP标准程序里看到CALL FUNCTION ‘XXX’ DESTINATION 'NONE’的写法，这种写法使得函数XXX仍然在调用它的应用服务器实例内部执行，而非在其他服务器上远程执行。那么这种写法不是多此一举吗？

SAP官网对这种用法的解释：Destination “NONE” has the effect that the function module is started on the same application server as the calling program, however through the RFC interface and in its own RFC context.

也就是说，通过这种方式调用的函数，即便是和调用者同处一个应用服务器实例内，也会像远程调用执行时一样，到RFC接口即Gateway组件里去走一遭。

付出这种在额外协议栈上执行开销的代价，有什么收益？那得从ABAP Netweaver里不同类型的会话说起。我们每用SAP GUI登录一次系统，会在服务器上生成一个用户会话(User Session). 每个User Session里通过命令行输入/o可以生成新的ABAP会话，每个ABAP会话内的程序调用生成新的内部会话(Internal Session).

如果直接调用函数CALL FUNCTION ‘XXX’, 在发起该函数调用的同一ABAP会话内，会派生一个新的内部会话去执行函数体的逻辑。如果用CALL FUNCTION ‘XXX’ DESTINATION ‘NONE’, 则会派生一个全新的用户会话，此时这个全新的用户会话，和发起函数调用的原始用户会话是完全隔离的，不共享任何数据，参数传递也是通过RFC标准的参数传递方式进行。通过这种方式，能实现被调用函数和原始程序的异步调用效果，同时两个用户会话里的程序执行完全隔离，不会彼此影响。

事务码SM04能看到ABAP应用服务器上所有的用户会话。双击某一用户会话，能看到该用户会话派生的所有ABAP会话。

SAP Start Service

该服务运行在部署了SAP应用服务器实例的服务器上，实现载体是Windows的系统服务(sapstartsrv.exe)和Unix系统的Daemon进程(sapstartsrv).

SAP Start Service实现的功能有：

(1) 启动和终止SAP应用服务器实例，及其运行状态的监控
(2) 应用服务器日志，跟踪和配置文件的读取与管理

ABAP SAP中央服务实例(ABAP SAP Central Services instances, ASCS)

主要包含Enqueue服务器和消息服务器。

Enqueue Server

数据库层面的锁由数据库管理，而ABAP应用程序级别的锁，比如锁一个订单，锁一个物料主数据，则通过应用程序提出锁申请，由Enqueue Server完成和管理锁。应用服务器实例上所有用户当前会话持有的锁，都维护在Enqueue服务器的锁信息管理表中，该表维护在Enqueue服务器的内存中，不会进行持久化，因此Enqueue服务器成为了ABAP系统的单点故障源之一：当Enqueue服务器由于各种原因运行时发生故障需要重启时，维护在内存中的锁信息表的数据会丢失。

因此为了确保Enqueue服务器的高可用性，通常将其放到单独的物理主机上部署，甚至引入遵循主从机制的多台Enqueue服务器，将Master Enqueue服务器上的锁信息管理表同步到其他Enqueue服务器上。

事务码SM12查看某个用户持有的应用锁：

SE11里打开任意一个锁对象，点击Lock Modules，进入自动生成的ABAP函数内部，就可以了解锁请求是如何从应用服务器发送到Enqueue服务器的。

SAP Message Server

每个SAP系统只能包含一个消息服务器，该组件负责完成以下任务：

(1) 作为SAP系统内多个应用服务器实例间通讯的中央渠道
(2) 对来自客户端通过SAP GUI和SAP RFC登录请求的负载分发

当一个应用服务器实例启动后，其Dispatcher进程就会联系消息服务器，向其报告自己能够提供的服务类型。

SAP系统的消息服务器地址，可以在SAP GUI里维护该系统登录信息的Message Server字段里查询到。

上图我登录的AG3系统有多个应用服务器实例，我登录的实例编号为54，使用事务码SM53发现这个系统还有另外两个实例，编号为55和56.

忽视SAP系统可以由多个应用服务器实例组成这一点，有时候可能会遇到一些无法按照自己期望工作的场景.比如数据库性能测量工具ST05，如果在实例A上打开跟踪，而业务代码实际执行在实例B上，那么待分析性能的应用执行完毕后，在实例A上关闭跟踪后，当然看不到性能数据。这种情况下，最保险的做法就是，在激活跟踪时，选择“在所有实例上”打开跟踪开关。

希望本文介绍的这些ABAP基础知识对你有用。有了这些预备知识，后续我们就可以去了解SAP Linux实验室的工程师们，是如何将这些组件容器化的。