由浅入深聊聊SAP Cloud Platform (Part II)

文 | 袁大兔

从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美国公司。

查看袁大兔的名片