返回 登录
4

微API设计模式

原文The Micro API Design Pattern
作者:Lukas Rosenstock
翻译:雁惊寒

摘要:本文介绍了微API设计模式的基本概念、组网及其优势。以下是译文

header.png

互联网上的软件部署始于服务器。然后,有了虚拟化。 IaaS(infrastructure-as-a-service, 基础设施即服务)是云计算的第一步,它使得人们可以在一小时内配置好虚拟服务器。 PaaS(platform-as-a-service, 平台即服务)是在物理机器和开发人员的代码之间增加了一个抽象层。最后,构建微服务(而不是单体、集成API和远程托管服务)的趋势导致了当前阶段无服务器平台云计算或FaaS(功能即服务)的出现,在此平台上部署了小单元的代码,以及由托管服务提供商自动管理的整个基础设施。

基于无服务器和FaaS的思想,我在这里要介绍一个我个人称之为微API的概念。我将其定义为描述一段软件的设计模式,这个软件:

  • 向其消费者公开Web API(REST或RPC风格),
  • 在单个文件中实现,具有合理的低LOC(lines of code,代码行),
  • 依赖于一个标准化的框架和一系列的依赖关系
  • 无需关心本地状态。

微API在“执行引擎”中运行,执行引擎提供了标准化的框架和依赖关系。由于自定义逻辑非常小,因此微API可能是按需部署的,这意味着每当需要由特定的微API处理的请求出现时,可以从存储库中下载代码,然后缓存到引擎内并立即执行。执行引擎被设计成多租户的模式。它将自定义代码放在沙箱中,这样,不同的微API之间就不会相互影响。

由于其按需部署和多租户的设计,分布在世界各地服务器上的托管微API执行引擎网络可以像CDN(Content Delivery Network, 内容传送网络)那样工作。如果代码在检索到之后并没有完成缓存,那么就会在距离最近的消费者处接收并执行API请求。有了这样一个边缘服务器网络,服务器端逻辑的分发和扩展可以像分发静态Web内容一样简单!在前期,不需要准备任何资源,这意味着托管一个微API端的成本几乎为零。每秒数千个请求的高可扩展性可以通过水平或垂直的方式扩展执行引擎来实现。另一方面,在部署了引擎服务器之后,微API也可以在单租户环境中使用。引擎服务器可部署在私有和混合云中,甚至部署在网络边缘的设备中。

与其他无服务器环境不同,由于框架和依赖关系的选择,以及执行引擎的影响,微API可能看起来限制很大。这是故意这么设计的,因为这样使得开发人员能够专注于业务逻辑,可以快速启动大量独立的微API,而无需进行架构决策并管理每个微API的依赖关系。另外,还可以针对特定要求设计不同的执行引擎。

微API是完成以下任务的完美选择:

  • 一个API是另一个API的代理或外观,用于桥接不同的身份验证协议或转换数据格式(例如,将XML转换为JSON)。
  • 在调用其他API或Webhook之前修改或检查数据的webhook接收器。(译者注:Webhook是用户通过自定义回调函数的方式来改变Web应用的一种行为)
  • 在通过另一个API或基于云的存储系统在存储数据之前,需要一个简单的数据验证层。
  • 将来自多个API的数据组合成单个响应。
  • 具有静态或半静态响应的模型。
  • 微服务架构中的路由组件。

总而言之,微API就像胶水一样非常有用,它可以通过易于创建和部署的自定义代码来连接任何东西,使它们比可视化集成和聚合服务更具通用性。

在CloudObjects公司,我们正在构建一个基于PHP和Silex 微框架的微API执行引擎,它利用PHPSandbox来提供一个安全的运行时环境。我们给它起了个名字叫phpMAE。phpMAE是围绕着CloudObjects Core和其他即将到来的CloudObjects产品的集成而设计的,它为开发和混合部署以托管服务和完全开源的形式来分发提供。 微API的配置和源代码存储在CloudObjects Core中,并通过CloudObjects Core来部署。

评论