一個13年ABAP老兵的建議：了解這些基礎知識，對ABAP開發有百利而無一害

在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實驗室的工程師們，是如何将這些元件容器化的。

感謝閱讀。

本文來自雲栖社群合作夥伴“汪子熙”，了解相關資訊可以關注微信公衆号"汪子熙"。