共计 4614 个字符，预计需要花费 12 分钟才能阅读完成。
在笔者之前的文章里，已经提到了 SAP 社区上这样一篇博客：Proof of Concept: Deploying ABAP in Kubernetes
外面介绍了 SAP Linux 实验室的工程师们将 ABAP 应用服务器各组件进行容器化并部署到 Kubernetes 上的尝试。
本文简略回顾 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 服务器的各大组成部分和其职责所在。理解这些底层零碎常识，有助于 ABAP 开发人员写出更强壮的 ABAP 利用，同时工作过程中遇到相干问题，也能更加明确从哪些方向动手进行问题的剖析和定位。
