评估云原生和 REST

在本单元中，我们将深入了解 ABAP 云开发模型 (ABAP Cloud)，即可在 ABAP 上构建和运行云原生应用程序的模型。但是，由于 ABAP Cloud 的部分灵感来自云计算和云原生范例，因此有必要对这两个主题进行简短的讨论。

正如课程 S4CP01：探索 SAP ERP 云所讨论的，在当今的业务环境下，企业需要快速调整业务流程，以响应不断变化的业务环境和不断变化的客户需求。这种调整需求需要可扩展、坚固且非常灵活的应用程序。云计算环境是满足这一需求的一种方式。另一个是云原生。

云计算仍在计算中，但云计算的设计方式与传统上 IT 人员使用的典型企业预置数据中心基础架构不同。使用企业预置基础架构（通常称为企业预置数据中心），客户负责安装和维护物理元素，例如服务器和网络设备。通过云计算，这些基础架构组件由外部云提供商提供。

一般来说，云提供商提供以下组件：

• 网络
• 服务器（提供计算和内存容量）
• 存储
• 操作系统和虚拟化

这些组件的初始设置及其正在进行的操作、维护和升级由云提供商处理。

使用以下原则向客户提供这些组件：

• 弹性

  大多数组织都会遇到资源使用的高峰和山谷。例如，工资核算每月运行两次，在这些时间内，需要额外的网络和服务器容量。作为产品的一部分，云提供商通常具有面向客户的弹性功能。这样，由于需要更多资源，因此可以分配这些资源，并且可以在所需级别维护单个和整体应用程序性能。

• 定价

  云计算组件在商定的定价和消耗工厂提供给客户。这可能因提供者而异。例如，SAP 在提供 SAP BTP 的平台即服务 (PaaS) 中提供了各种运行时和服务，不仅基于订阅的计划，还提供两种不同类型的基于使用量的采购计划。

• 可用性

  返回上述工资核算示例，云计算资源的可用性为每半月（假设每月运行两次工资核算）。对于其他类型的业务流程（例如，供应链管理流程），可用性因相关流程类型和公司选择运营的方式而异。对于大型企业而言，合理地说，每周 7 天、每天 24 小时，至少有一个流程需要资源才能执行。这就是可用性发挥作用的地方。作为产品的一部分，云提供商可以透明地向客户传达其组件的预期可用性。同样，虽然技术上不需要，但几乎所有提供商都提供 24x7 可用性选项，如果某些操作需要持续执行或以不可预测的间隔执行，则为客户提供最大的灵活性。

• 服务级别协议 (SLA)

  与可用性密切相关的是服务级别协议 (SLA)。可用性通常表示为数字 (24x7)，而 SLA 以时间维度添加（即，24x7 表示当月的 99.99%）。使用此示例，如果一个月有 30 天，则转换为 43,200 分钟（30 天乘以每天 24 小时，每小时 60 分钟）。根据 99.99% 的 SLA，系统在大约 4 分钟半（ 0.0001 乘以 43200）内将无法使用（在该月内）。

虽然一开始可能会想到"除了提供商之外，云计算与客户提供的数据中心之间似乎没有实际差异"，但情况并非如此。云提供商提供计算基础架构的后果意味着，软件应用程序应设计为独立于基础架构。无论云提供商提供的特定服务器、操作系统或存储系统如何，它们都应该运行相同的 。完全可以想象，云提供商可能会频繁更改其基础架构。此外，客户还可以决定更改云提供者（即，不同的提供者提供卓越的 SLA 性能）。此外，快速调整应用程序的需求意味着不应需要在不同类型的基础架构上测试应用程序以确保兼容性，更不用说开发应用程序不同版本的时间和成本，这样应用程序就可以在不同的基础架构类型上运行，而这种类型同样是不启动的。从开发人员（最终是最终用户）的角度来看，云计算中使用的基础架构组件是一个抽象组件。

为确保这种抽象，需要在云计算中对用于进行应用程序开发和维护的编程模型、工具和技术进行自上而下重新思考。云原生已成为这种重新思考的结果。

云原生是一种方法，首先是在云计算环境中开发、部署和维护软件应用程序的方法，从而实现快速的应用程序适应性和灵活性。虽然云原生的特定定义因源而异，但根据正在使用的定义，有一些组件所有定义通常都一致，并且在了解 ABAP Cloud 开发模型时非常重要：

• 与基础架构无关
• 微服务
• 应用程序编程接口 (API)

如前所述，云提供商提供基础架构组件，其中包括云计算环境（即网络、服务器（提供计算和内存容量）、存储、操作系统和虚拟化）。不同的云提供商使用不同的技术、配置、品牌等提供这些资源。无论这些差异如何，无论云提供者如何，云本机应用程序都运行相同。

许多云原生编程模型遵循三层应用程序开发方法。第一个是用户层（有时称为使用层），负责最终用户与之交互的用户界面的可视渲染。第二个是数据层，应用程序需要的数据永久存储在某些数据源（通常是数据库）中。在这两个层之间是服务层。服务层响应用户层在一端触发的请求，并在此过程中在数据层级别对其数据源中的数据执行操作。这些操作通常分为以下四种类型，通常称为 CRUD 操作：

• 创建
• 读取
• 更新
• 删除

虽然不需要，但这些层通常设计为在不同位置和不同类型的运行时环境中运行。其中一些位置和环境可能是基于云的，而其他位置和环境是基于企业预置的。这种混合方法并不少见，并且供许多客户使用。微服务设计意味着每个层都作为自己的独立部件实施。因此，它可以与其他层分开维护和调整，同时能够在完整应用程序的上下文中与其进行通信和协调。

上一部分中提到的通信和协调通过使用 API 执行。API 是一种技术，通过该技术，两块软件可以相互通信，并使用商定的数据定义和表示（通常称为协议）交换或操纵信息。例如，大多数人使用的应用是银行应用，允许用户执行各种功能，例如检查账户余额或启动资金转账以支付账单。该应用可以使用银行网站通过 Internet 自由访问，也可以安装在手机上。无论哪种方式，应用的设计都是这样，在后台使用一个或多个 API 来执行应用最终用户请求的各种银行功能。每个 API 都旨在执行应用可能需要的一些任务，并且通常可以使用"按需"使用。使用通常基于"调用和响应"流程的某种形式（即应用以某种方式调用 API 和 API）。

此场景中的银行提供 API（因为他们具有银行账户的法律治理），并且他们可自行决定使其可用于第三方使用（例如，设计希望添加银行功能的产品的开发人员），并在自己的应用开发中使用 API 本身。数十年来，API 已经问世，云计算已经过时。但是，API 概念已发展为涵盖云计算和微服务开发的需求。这种演变表现出来的方式之一是采用了目前使用的最常见的 API 体系结构之一：表述性状态转移（REST）。

继续介绍使用 API 的银行应用示例，例如，检查账户余额，我们可以学习重要的 REST 术语。在 REST 下，有一个特殊术语用于指示应用程序可能需要的信息，即"资源"（在本例中为银行账户）。此资源具有"状态"（银行账户始终具有余额），并且此状态可以更改（银行余额向上和向下），但在任何时间点，都会存在此状态。在 REST 术语中，此状态通常称为"资源表示"。可以要求此状态（"告诉我我的余额，请"），甚至可以启动对此状态的更改（"以下是存入我的账户的支票；告诉我我更新的余额"）。最后，应用与 API 之间的所有通信都通过 Internet 进行，这意味着状态必须"来回传输"。这里有：[资源]"表述""状态""转移"。

• 一组体系结构约束
• 开发人员创建 API 时遵循的一组规则
• 由客户端、服务器和资源组成的客户端-服务器体系结构，通过 HTTP 管理请求
• 无状态客户端-服务器通信，意味着请求之间不存储客户端信息，并且每个请求都是单独且未连接的

REST API 基于围绕以下原则的体系结构模式开发：

• 统一资源接口

  资源（在本例中为银行账户）基于一个寻址机制进行唯一标识。例如，http://www.somebankserver.com/Account。

• 客户端服务器

  与微服务设计方法一致，客户端（在本例中为 应用）和服务器（API 所在的位置）是通过 Internet 相互通信的单独层。

• 无状态

  无状态传输程序意味着客户端提出请求（应用发出银行余额检查请求），当服务器托管 API 将余额作为响应传输时，API 将不会存储有关此请求的任何信息。如果稍后进行拆分，应用再次请求对同一账户进行银行余额检查，则 API 会将其作为全新的请求进行处理，而无需使用先前请求中的任何内容（甚至不了解）。

  互联网上最常用的应用程序是万维网 (Web)，它使用 HTTP 协议在不同客户端和服务器之间来回传输信息。由于 HTTP 协议是无状态的，因此它用作 REST 用于传输的协议。

• 可缓存

  为了提高可扩展性和性能，可以为 REST API 实施缓存。某些数据可以以这种方式存储，以便快速访问以更快地响应请求。例如，银行账户余额可以存储在缓存中，而不是从远程数据库中检索。

• 分层系统

  允许中间系统（例如，执行负载平衡或验证）。客户端可能不知道这些中间系统，并且客户端-服务器通信不会受到负面影响或威胁。

• 代码按需

  服务器可以将可执行代码（例如 JavaScript）传输到客户端以扩展客户端功能。这是唯一的可选原则之一。

如前所述，服务层位于用户层和数据层之间，用于实现两者之间的通信。REST API 驻留在服务层上，并在客户端-服务器通信（用户层充当客户端）中作为服务器运行。由于 REST 使用 HTTP 作为其基础传输和通信协议，因此所有 REST API 请求也是 HTTP 请求。客户端使用四种基本 HTTP 方法与 REST API 交互，如下所示：

• HTTP POST，用于对资源执行创建操作
• 用于检索一个特定资源的 HTTP GET
• HTTP PUT，用于对资源执行更新操作
• 用于删除资源的 HTTP DELETE

客户端基于这些方法将 HTTP 请求发送到 REST API，进而对适用资源执行请求的操作，并将 HTTP 响应发送回客户端。

如前所述，REST 已成为作为云原生方法的一部分使用的更流行的 API 体系结构之一。利用微服务设计以及 REST API 的云原生应用程序非常适合现代消费者对在移动应用程序和桌面上运行的应用的期望，并具有流畅的现代用户界面。特别是 SAP 和 ABAP，并不能免去这些期望。因此，ABAP 需要不断发展以拥抱云计算和云原生概念。