筆者之前的文章[一個15年ABAP老兵的建議：瞭解這些基礎知識，對ABAP開發有百利而無一害](https://xie.infoq.cn/article/86d6f104b86a15dcfe4d143c4), 回顧了ABAP Netweaver伺服器主要的元件。本文我們們就來聊聊ABAP Netweaver容器化這個話題。

筆者假定閱讀本文的朋友，都聽說過虛擬機器和容器的概念， 並且對虛擬機器和容器的區別有所瞭解。

容器與虛擬機器的出發點很類似：對應用程式及其依賴進行隔離，生成一套能夠隨處執行的自容納單元；二者都能夠使應用執行在一個虛擬出的抽象層裡，擺脫對傳統物理硬體的依賴，使得計算資源的利用更加高效，能源效率與成本效益得以提升。
容器在虛擬化程度上比虛擬機器技術更進一步，擺脫了前者對Hypervisor層的依賴，直接利用宿主機的核心，抽象層比虛擬機器更少，更加輕量化，同虛擬機器技術相比能達到更高的物理資源利用率，因此更受當今雲服務提供商的青睞。

![](https://img-blog.csdnimg.cn/img_convert/d727d32b5be1f8a677bb7b75647897cd.png)

Docker是一個開源的應用容器引擎，是當今最流行的容器技術之一。

那麼SAP ABAP Netweaver，能否利用Docker引擎，讓它執行在容器裡呢？

SAP官方的 [note 1122387 - Linux: SAP Support in virtualized environments](https://launchpad.support.sap.com/#/notes/1122387) 給出了答案：截至2020年1月17日，答案是不支援。SAP官方不支援將ABAP應用伺服器執行在容器或者容器編排環境內。比如目前業界流行的Docker和LXC，以及執行在Google Cloud Platform, Microsoft Azure, AWS上的Kubernetes Cluster，都不是SAP官方支援的能夠將ABAP Netweaver伺服器以容器的方式執行的平臺。

![image](https://img-blog.csdnimg.cn/img_convert/b0ae58f719d252f766e769ba3d7ac1be.png)

SAP 社群曾經有一篇部落格：[Installing SAP NW ABAP into Docker](https://blogs.sap.com/2018/05/30/installing-sap-nw-abap-into-docker/)

![](https://img-blog.csdnimg.cn/img_convert/56f7e153239e1c15d1a66e0051a43551.png)

這又是怎麼一回事呢？我們可以透過閱讀部落格瞭解作者是怎麼做到的。

首先，我們從SAP官網上能免費下載Netweaver的[開發者試用版](https://developers.sap.com/trials-downloads.html?search=7.52%20SP04)，ABAP版本號為7.52 SP04：
![](https://img-blog.csdnimg.cn/img_convert/a9e96dc0aaa58651156044564de12b04.png)

下載到本地，得到一個rar檔案，解壓之後執行裡面的安裝檔案即可把ABAP Netweaver安裝到本地。

因此SAP社群上的一群ABAP愛好者們，想到了一個點子：如果把下載的Netweaver安裝檔案，解壓之後，將其內容構建成一個Docker映象檔案，在這個Docker映象內完成Netweaver的安裝和啟動工作。如此一來，豈不是達到了在容器裡執行ABAP Netweaver的目的？

我們可以在這位ABAP愛好者的 [github 倉庫](https://github.com/tobiashofmann/sap-nw-abap-docker/blob/master/Dockerfile) 上找到用來製作Docker映象的Dockerfile檔案，從中瞭解到該容器映象的製作過程：

這個Dockerfile構建的映象選擇了openSUSE Leap作為母映象，該映象提供了ABAP Netweaver執行的Linux作業系統。

![](https://img-blog.csdnimg.cn/img_convert/5fdbae8a6ff146c00fe4b07d8148b633.png)

Dockerfile的第一行用FROM關鍵字指定了這個基準映象的名稱：

![](https://img-blog.csdnimg.cn/img_convert/8d28b971d7196a82d24db8665575ae69.png)

第16行用COPY將事先從SAP官網下載好的儲存在宿主機NW752資料夾下的Netweaver開發者版本安裝檔案，複製到容器映象裡，然後第22行用RUN關鍵字執行安裝指令碼。

![](https://img-blog.csdnimg.cn/img_convert/ee4b80e3c0cd46e5fbb2c5c604bc30b9.png)

安裝完畢後，執行47行的啟動指令碼run.sh, 這樣就能在容器裡啟動Netweaver伺服器了。
這個容器映象製作好之後，只需要簡單地使用docker run命令列，就能啟動一個新的容器執行例項了。從SAP官網下載的Netweaver開發者版本，就執行在這個新啟動的容器例項裡。

![](https://img-blog.csdnimg.cn/img_convert/d4d541015d8d822e5f42b66716914cc0.png)

我們回顧這種做法，發現Docker技術較之虛擬機器的優點並沒有體現出來，按照部落格作者提供的資訊，透過這種方式製作出的映象檔案的大小超過了100GB，如此巨型的映象檔案幾乎無法透過Docker Hub分發給其他人，無法用於生產用途。

![](https://img-blog.csdnimg.cn/img_convert/5f091937bdad6a0dcfaf49508854b9d0.png)

另一方面，透過這種容器化方式，Netweaver伺服器的諸多元件，被放置到同一個容器內，無法透過簡單地增加容器例項的方式，實現Netweaver處理能力的水平擴充套件。

正是因為意識到將Netweaver所有元件放置於同一容器映象內這種措施無法發揮容器技術的優勢，SAP Linux實驗室的工程師們採取了另一種思路，即這篇SAP社群部落格裡給出的架構圖所體現的，將Netweaver元件進行拆分，分別放置於不同的容器編排邏輯單元中。

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

![](https://img-blog.csdnimg.cn/img_convert/da8610d4fd880c77c568d9190c3ead56.png)

上面的架構圖裡並沒有看到容器的影子，而Jerry之前文章介紹的ASCS(ABAP SAP Central Services instances)和AS(Application Server，應用伺服器)，被放置到了名為Pod的邏輯單元裡。

Kubernetes是容器編排和管理的平臺，不直接操作容器，而是將一個或多個功能上相關的容器封裝到稱之為Pod的邏輯單元中，我們可以簡單的把Pod理解成容器的集合。

![](https://img-blog.csdnimg.cn/img_convert/84525b529b2660830d127121b46755a7.png)

一個SAP系統由一個ASCS例項和一個或多個AS例項構成，對於ASCS裡包含的元件，比如之前介紹過的訊息伺服器，Enqueue伺服器，Dispatcher等等，每個元件分別構建不同的容器映象，再將這些映象封裝到一個單獨的ASCS Pod裡。

而ABAP Netweaver支援多AS例項部署的這種特性，恰巧能讓Kubernetes原生支援的Horizontal Pod Autoscaler機制大顯身手。將AS單獨製作成容器映象並放入AS Pod裡，透過Kubernetes的Deployment Unit管理這些Pod，從理論上說，可以使用Kubernetes命令列進行ABAP應用伺服器的水平擴充套件。

![](https://img-blog.csdnimg.cn/img_convert/74884b61426ccbd8a4e7f3c39a7ae703.png)

這種思路將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的有狀態事務處理(會話一致性)的需求。

![](https://img-blog.csdnimg.cn/img_convert/09d41170d704b9c1c1f1365965c92894.png)

(2) 在ABAP Netweaver容器化以前，大部分元件是在同一物理網路下彼此通訊。容器化之後，元件與元件之間的通訊會多經過一層Kubernetes的網路層，這使得整個系統的複雜度增加。

(3) 我們知道ABAP Netweaver有很多種同第三方系統整合的途徑：RFC，Web Service，OData，IDOC等等。將ABAP容器化之後，以前這些技術是否仍然可以在不需要調整Netweaver核心實現的前提下繼續工作，需要進行實際的驗證。

![](https://img-blog.csdnimg.cn/img_convert/1940e5ec8d7407744f97f788df804f9c.png)

所謂No pain，no gain，付出總會有收穫。如果ABAP成功容器化之後，理論上我們會享受到哪些容器技術帶來的便利呢？

(1) ABAP的安裝和部署過程將會大大簡化。假設出現了官方的ABAP容器映象和Kubernetes Deployment檔案，我們可以僅僅用幾行簡單的命令列，在任何支援容器和Kubernetes的平臺上，輕鬆完成ABAP的安裝和部署。

![](https://img-blog.csdnimg.cn/img_convert/a1747db607346df64954798f804a3cb8.png)

(上圖來自部落格：
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上，無疑給我們留下了太多美好的想象空間。

![](https://img-blog.csdnimg.cn/img_convert/19a2360ef799086b5ac345447a0bee93.png)

SAP技術在不斷向前演化，ABAP也從未停止前進的腳步，讓我們活到老，學到老。感謝閱讀。

![](https://img-blog.csdnimg.cn/img_convert/f142190a02b971a6d9b5bddcf6350108.png)

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

相關文章