由淺入深聊聊SAP Cloud Platform

文 | 袁大兔

Part 2

從Netweaver 到HANA 1.x , 到HANA 2.X 到HCP Neo 到HCP CF

什麼是平台？我們已經在Part 1中大致說明了，軟體公司（中大型）在項目開發初期都會有一個討論就是如何使得後期開發更加簡單。如何分解一個大的項目到可實施的小的模塊，如何更簡單的讓這些小的模塊盡量的相互獨立而方便平行開發。 這些平台在很多項目中有不同稱呼：Platfrom，Core，Framwork等等，但是其目標就是讓開發簡單化，代碼可重複利用。

簡單的例子如同觸摸屏手機，從手指觸摸到定位到觸摸誤判，手勢識別，軟硬體結合。這一系列的邏輯在手機中是一直重複使用的。但是不是每個開發者，開發團隊都有時間和資源去重新開發。而且這一模塊隨著時間和科技發展，會越來越複雜。

如何讓開發者們專註於自己的邏輯功能開發而不去擔心管理這些更新呢？這就是使用平台，模塊化的好處（蘋果Cocoa）。這些模塊在平台中一API 形式提供給開發者，隨著科技更新，這些模塊會自動的加入新的功能而不需要開發者去重新開發自己的軟體（3D 感應，faceID 和 touchID 等等）。

而這一軟體開發行業的邏輯一直在SAP 產品中一直在體現。商業軟體的複雜性就是在於可定製化和靈活， 如何能讓自己的產品被客戶更加靈活甚至於無限靈活的使用又能兼顧安全性是SAP 內部不斷更新的一個課題。

Netweaver就是一個初期的平台，這個平台能夠兼容各種SAP的軟體以及三方開發的軟體並且提供平台的安全性的兼容性。幾乎所有SAP軟體和大多數三方軟體都能在這個平台中進行信息交流完成各種簡單或者複製的商業邏輯。

那為什麼HANA一個資料庫又能拿出來和Netweaver進行對比呢？

我們知道資料庫類似於（My SQL，HANA，NoSQL等等）都只是一個數據儲存和分析的後端。類似於csv或者txt等文件，主要是用於存儲和讀取。當然HANA在開發初期也不例外，初期在戰略上推出HANA遇到一些瓶頸： 很多顧問公司把HANA和ERP一起打包賣給客戶，但是客戶只用ERP而HANA便束之高閣。

隨著這種案例的增加，很多客戶反過來問為什麼他們需要HANA。因為他們所有的需要都能在R3和Netweaver中被解決，報表運行一晚上就能出來和一分鐘就能出來的差別不值得他們去完全重新開發一個6個月的項目。

這種反面的聲音大量出現，以及Netweaver 的大量優勢。HANA在其後很難有大的起色。 當然SAP內部有很多HANA優化案例（比如HANA優化的DSO）但是沒有第三方的投入很難普及。於是乎HANA的路線便從單純的資料庫轉換為一個開發平台，整合了SAP在SQL方面的優勢， nodeJS在後台的簡易性和兼容性開發（XSJS或者稱之為XSC），伺服器的穩定性能host各種小型的網頁服務（HTML5），以及靈活性連接到R，hadoop。 各種套件SDI，SDA，文本處理（TA），預測模型都加入其中。這些服務都極大地利用原生的HANA內存資料庫的優勢並且提供API給開發者去使用。這樣一來一個簡單的網站甚至小型的公司所有需求都能只用一台HANA進行開發。這便是HANA 1.X。

然而在實際開發過程中有更多的複雜度出現：

1. HANA 1中開發的SQL，JS等並不能很好的兼容多個資料庫（MDC），單一資料庫的構架在大型生產運行中相對不便。

2. 上圖中的網路後端以Script邏輯為主（JS，SQL），XSJS中雖然單獨開發了很多資料庫API， 但是有個不可避免的劣勢就是不支持多線程。這個對於大量數據IO，用戶量大的項目是非常致命的缺點。

3. 資源分配問題，因為所有的引擎都在HANA 中運行。如果出現網路資源需求量大時候，資料庫資源就會被減少， 並且無法單獨增加對某一引擎的資源分配。

4. 資料庫地址泄露，因為網路資源或者是API 是直接在HANA上host的，不可避免的會泄露資料庫的IP或者是DNS。如果在內網中的項目這是可以理解的話，在外網中資料庫地址泄露是非常危險的。

針對於 HANA XSC的一些限制， 基於Cloud Foundry的一個項目XSA就成了HANA 2.0的一個契機（XSA在HANA 1.X後期版本中也支持）。

HCP/SCP其開發是在HANA 1.X下開始的，在目前SCP（NEO）還是最高支持1.00.122.14版本。

但是在實際生產中如何去解決以上的問題呢？

由於篇幅原因，SCP的細節在下章中會著重討論，於此僅僅對以上四個問題進行回應。

1. 不能很好的兼容多個資料庫（MDC)

SCP中能夠在一個系統下創立多個資料庫，或者是用同一個資料庫名稱但是建立多個Tenant。

2. 網路後端以Script 邏輯為主（JS，SQL）

提供了Java(Tomcat, web EE)的支持，並且提供了平台上的JDBC 連接到同一平台的資料庫

3.資源分配問題

在SCP 上Java， HTML5 和HANA 都是以容器（Docker）來分配資源，而每個服務都可以單獨監控資源消耗和分配。

4.資料庫地址泄露

因為Java，HTML5，HANA都在不同的docker上，每個單獨服務都有獨立的地址。所以網路服務地址，或者API終端並不是實際的資料庫地址。事實上在服務中使用的地址可以用別名代替，如下圖在Destinations服務中， 進行了別名和真是地址的匹配。 而在所有平台應用中只需要用別名就能解析地址，甚至自動驗證(Authentication)。

在發稿時， SCP CF只是Beta版本，所以SCP CF和HANA 2暫時略過。

關於作者

InweHub用戶名：袁大兔。資深SAP開發者，對HANA，SAP Cloud Platform，Fiori，Blockchain等相關領域有深入理解，現就職於SAP美國公司。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！