sap技术架构_谈谈我对协议栈设计和架构的理解

查资料看到的，转一下，附上链接：

SAP Business Technology Platform (BTP)的架构理解

长期以来，我在与客户和伙伴的沟通交流中发现大家依然对SAP业务技术平台 – SAP Business Technology Platform (以下简称BTP)纯有各种疑惑，借此机会借助我原来作为SAP内部IT开发的经验和近期一年来在客户前线的经验，简要聊一下我对BTP的架构理解，希望能对读者有所帮助。

一些简单的历史

BTP原来叫SCP – SAP Cloud Platform，甚至更早叫做SAP HANA Cloud Platform，所以从名字的变更中可以发现，SAP的初衷是将其从单纯的内存数据库业务变更到融合各种技术栈的云平台服务，但是SAP并不是一个纯技术公司，其精华在于依托各种生产实际中的业务流程，数据流转和计划预算等，所以最终将名称定为“业务技术平台”，意思就是说首先这是个平台，其次是这个平台上有各种技术，这些技术用以服务企业业务。

最开始的时候SAP自己提供基础算力，所以可以经常听到BTP的历史版本叫做NEO，用以区分现行底层依赖第三方合作伙伴如Azure，AWS，GCP和阿里云的最新版本Cloud Foudry（简称CF），这都在一定程度上体现了在数字云时代的快速变更对SAP的管理运营决策的影响。

迄今为止，BTP已经形成了十份稳定的运营和扩展架构，对于SAP的云转型起到十分重要的前沿阵地和粘合剂作用。其本身作为平台对企业并没有直接价值，而是上边的90多个云服务才是企业花钱订阅和日常使用的精华所在。这里需要指出的是，中国大陆由于种种原因，这90多个服务目前还并不能全部使用，所以有些客户和合作伙伴可能简单的认为BTP=CPI，是因为仅仅订阅了其中一个服务即SAP集成套件。具体有哪些服务可以使用，可以参考SAP Discovery Center，该网站非常清楚地对这90多个服务分类成几大类：应用开发和自动化，数据和分析，集成，基础服务等，点击每一个磁贴都可以看到每个服务的详细信息。

架构解读

上边提到BTP作为平台本身并没有直接价值，那么为什么还需要这个平台呢？我们试想如果不这样做的话，会出现以下这些结果：

1. 这些90多个服务每次从开发到使用都各自独立为战，不仅对SAP开发流程和速度都是极大浪费，另外还对客户的使用造成很大负担，因为很可能每个服务都有自己的激活方法和使用环境，对于用户体验可以说是十分糟糕的体验。
2. 在解决方案的分类上会让SAP的产品十分分散，无法让客户形成分门别类的统一认知比如那一类服务是用来解决数据问题，哪一类是用来解决流程问题，哪一类是用来解决开发问题等。
3. 在底层角色权限认证，到ERP系统的连接共享等都要各自独立开发，这些服务之间也很难直接通信，每次开发新的服务都要从头做起，无法利用现有资源。

而BTP的架构就是用以解决上述问题。

如果是第一次接触BTP，大概率是从邮件中拿账号和激活密码然后登陆BTP的主控室（cockpit）开始，说的直白点就是总的操作台，点击左侧这些菜单按钮，会在右侧展示详情，看起来十分简单对吧？

但是实际上后边有很多让初学者迷惑的概念，比如什么是Entitlement（官方中文翻译叫做”权利”，意思就是说我作为客户有哪些服务购买了或者免费使用），如何添加新的用户Role，如何配置到S4本地系统的连接，为什么存在全局账户，子账户，甚至子账户下边还有空间（Space）账户？诸如此类问题，很容易迷失在各种手册和配置中无法自拔，那么下面我就试着从全局层面解释下为什么会有这些设计。

首先看这张图，这是我基于自己的理解绘制的一张简单架构图，我们按照顺序解释。

1. Identity Authentication Tenant

这是个免费服务，如果没有的话可以通过开SAP Ticket申请，有时候也经常简称为IAS – Identity Authentication Service。该服务严格意义上并不属于BTP上的服务，而是SAP为了自家的云产品能更好的互联，单独开发的一个进行身份认证的服务。你可以将常见的微软认证数据接入IAS，利用现有用户数据和权限，实现SAP云产品的无缝登陆，你也可以在上边进行从0到1的用户创建填充，重度依赖IAS实现SAP云产品的用户管理。

但是对于很多中国大陆的客户来说，由于他们只订阅了其中一个服务比如SAP集成套件，并没有其他SAP解决方案比如SAP人力资源或者采购报销等云产品，往往直接忽略这一部分，而使用BTP自带的default默认SAP IAS来增减管理用户，这相当于用户数据是在SAP这边而不是在用户自创建的IAS Tenant上。当然，这里需要指出的是，由于中国大陆的特殊性，数据并不是保留在SAP而是保留在SAP在中国大陆的运营代理公司中，而这也是很多客户在注册以及增加其他BTP用户的时候发现会在这种地址，https://awmtxn6rh.accounts.sapcloud.cn/，这个地址就是BTP在中国大陆的统一IAS默认地址。

从上边的架构图中可以看到，IAS在用户通过浏览器登陆BTP上的服务的时候起到非常关键的鉴权作用，只有该用户有足够权限才能访问BTP上的指定服务，要么在BTP上进行开发工作，要么本身就是终端用户使用BTP上暴露的服务。结合方法也不困难，SAP社区论坛有不少资料，其最直接的反应就是在上边BTP主控室的截图左侧可以看到Trust Configuration中多了一个自创建的IAS而不仅仅是default的了。

IAS创建以后是个独立地址，打开以后长这样，上边有各色贴心登陆功能可以探索。

2. Connectivity & Destination

这是BTP上非常重要的组成部份，要理解BTP的架构就一定要知道这个东西，说白了就是个代理，很多服务都要通过该组件进行互联互通。如果你对BTP上的各种服务创建和使用比较熟悉的话，就会感受BTP产品团队的设计理念，就是我只需要在BTP维护这些连接信息，然后各种服务都可以再次复用它们，只要在服务中指定一下就行了，比如在SAP Build Apps里就可以引入对应的连接信息，一次性获取后台系统的各个OData Service。

• 可以看到架构右边是本地onpremise在防火墙后的系统，就要通过SAP云连接器（下边会说）和BTP建立Connection，之后在BTP上的各色服务就可以通过该connection暴露出来的虚拟地址进行数据互通。可以看到下图我已经将BTP连接到两个ABAP系统。

  

• 开发过程中，如果是外部地址，往往会存在跨域访问的限制问题，这时候就要在BTP上通过Destination建立代理，写入外部地址的用户名密码信息等才可以在BTP上开发的应用中进行无缝访问，这样还保证了机要信息存储于Destination中而不是在代码里。如下图就是连往S4系统的一个destination，可以直接在BTP各色服务消费，在代码里也可以任意调用，十分方便。

  

3. Customer Subaccount

客户子账户是客户较大粒度的层级概念，有独立的用户角色分配，独立的计算资源，独立的服务分配，独立的connectivity和destination等，可以说绝大多数服务都存在于客户的某个子账户中。比如你买了2个SAP集成套件的tenant，那么只能将其分配于两个子账户中。但是我们这里主要谈论的还是BTP上的各色服务。

前边讲过通过discovery center可以看到BTP上的服务大致分成了几类，应用开发和自动化，数据和分析，集成，基础服务（公用服务）。其核心思想就是朝着低代码无代码方向进行，我在其上的架构图中拿出了几个非常有代表性也用的比较多的服务。如SAP集成套件就是一种无代码方式进行API的操纵工具，SAP的流程自动化也是通过无代码的方式进行机器人开发和审批流管理，SAP的Build Apps更是当下非常火热的无代码应用开发，可以开发跨平台的端到端应用程序，SAP的Build WorkZone可以用无代码的方法开发企业门户，还有SAP分析云也是可以通过低代码方式进行BI报表开发和分析。当然，传统的专业代码开发工具也依然活跃，比如Business Application Studio和Cloud Foundry运行时环境，由于BTP是基于开源平台，所以在其上部署运行Java，Javascript，Python等各色程序，SAP也有自己开发的后端开发框架如SAP CAP可以较为方便的结合SAP的技术栈和外部开源世界。

除此之外，还有不少零散的服务，比如Feature Toggle可以进行应用程序开关管理，Document Management Service可以进行文档管理，Event Mesh是事件队列服务，Task Center是把各种审批和通知服务融合在一起的服务，Mobile Service可以开发IOS或者Android等等。。。

4. SAP云连接器

简单说就是安装在你本地机器上的反向代理，因为BTP及其上服务是公网概念，通过云连接器可以方便安全快捷的进行资源暴露，这样就不用单独为每个BTP上的服务进行白名单处理或者暴露端口了，出了问题也可以通过云连接器查看日志记录（当然实际使用十分稳定，很少出问题）。所以请记住，SAP云连接器的一端一定是BTP，另一端可以是ERP系统，也可以是你本地开发的Java服务器等。

5. BTP运行时环境

SAP BTP本身作为平台，是基于开源的PAAS Cloud Foundry（就开头提到的CF）建立起来的，所以CF上可以使用的特性比如命令行登陆，管控服务，角色权限，部署Java Python应用程序等等，都可以无缝在BTP上使用，除此之外，很多BTP的服务比如像SAP集成套件，都需要CF作为底层运行环境，这就是为什么这些服务在自助开通的时候，需要强行开启CF环境，作为运行时的“容器”。但是对于使用者来说，除非是做应用开发，部署和运维，否则是不需要关心这些底层的运行环境的，甚至都接触不到命令行，比如SAP集成套件的客户，可能集成套件都已经使用了两三年了，还从来不知道SAP BTP底层有所谓的CF运行时环境。

但是对于SAP BTP上的应用开发，部署和运维，这个概念就要一定知道并且熟练掌握，CF上的环境可以支持常见现代高级语言环境比如Java，Python等，SAP为了支持自家的ABAP语言，也在后期加入了ABAP运行时环境，这样客户不依赖SAP GUI就可以进行ABAP开发了。以及，为了支持更为自由灵活的K8S开发，SAP还提供了Kyma运行时环境，这样客户就可以更大程度的深入底层进行开发和部署了。如果感兴趣的可以在SAP的community直接搜索比如Kyma上如何构建UI5程序进一步了解。

所以一句话概括，目前SAP BTP的运行时环境包括Cloud Foundry（CF），ABAP和Kyma。

总结

以上是本人对BTP的一些认知，由于时间有限也许遗漏一些，会在后续不停更新，也欢迎各位指正，沟通交流，共同创建BTP共享社区

今天的文章
sap技术架构_谈谈我对协议栈设计和架构的理解分享到此就结束了，感谢您的阅读。