写点什么

SOA 与 API 的分裂和统一

2014 年 11 月 11 日

虽然 API 和 SOA 有着相似的商业和技术目标,许多 API 的支持者却坚持表示 API 与 SOA 几乎没什么关联,认为它们属于截然不同的方法。他们经常宣扬务实的 REST API 和 SOA 之间有着巨大的差异。分工限制了 SOA 服务和 RESTful API 无法干净利索地集成到一个统一的架构中。

团队必须在 SOA 和 API 的观点之间建起一座桥梁,构建一个实际的规划去融合 API 和 SOA。

“做 REST”和“创建 API”的团队通常的关注点是,以增量的外部扩展、具体的演示和不涉及复杂技术的核心业务用例来克服技术和业务的障碍。而 SOA 团队通常关注的是,获得扩展效率、达到商业标准、建立决策中心和满足复杂的非功能性需求。

通过结合 API 和 SOA 的观点,当遵循商业策略和扩展需求时团队就能够迅速地交付业务解决方案了。

务实的 REST API 关注点

REST 是一种系统开发的架构风格,它强制实行一系列服务交互的约束。正规的 REST 约束包括客户端 - 服务端和无状态的交互、可缓存的响应、不变的契约、分层的系统设计和按需编码。这些约束有利于特性的显现,也就是简单性、可扩展性、可变性、可靠性、可见性、性能和可移植性。满足 REST 约束的系统称为 RESTful。RESTful 设计方法能够增加许多的收益:

  • 使数据和服务更易于访问
  • 降低入门门槛
  • 尽最大可能扩展受众数量
  • 使 API 或服务被大量的用户代理消费
  • 使数据和服务逐步演进
  • 在运行期扩展系统
  • 对资源的修改不会影响到客户
  • 动态指导客户行为
  • 使系统可扩展、可靠和高性能
  • 简单
  • 可缓存
  • 原子性

虽然 RESTful 设计有益于支撑 SOA 的目标,但务实的 REST 的战略关注点与许多 SOA 的举措不同。务实的 REST API 设计团队专注于自下而上的应用场景、友好的协议或格式(比如 HTTP、JSON、DNS)、宽容的接口定义和简单的交互模型(比如在保证送达之上的重试)。

务实的 SOA 关注点

务实的 SOA 专注于面向服务的模式,该模式着重于增加软件资产的价值。基本的面向服务的模式是:

  • 共享和重用资产
  • 将冗余的功能固定到稳定的部件中
  • 使项目遵守公共标准和最佳实践

应用这三种模式将减少 IT 环境的复杂度,带来更大的灵活性,比如,能够更加快速地构建应用、更加快速地修改以处理需求的变更。面向服务的模式推动开发团队去评估软件资产满足商业干系人需求的能力。

务实的 SOA 最佳实践

务实的 SOA 团队不强行推进公共(而且复杂)的标准。务实的 SOA 团队提供有价值的商业能力、降低应用的阻力并交付独特的服务价值。

务实的 SOA 团队不鼓吹难以操作的最佳实践。他们依靠团队间的传帮带和自动化的治理以简化最佳实践的应用,这使团队可以更轻松地做正确的事情。

务实的 SOA 团队会留意技能差异和应用的障碍。他们提供加速器包(比如架构、工具、框架和 API 或服务构建块)减少培训、增加自助服务的应用,以及加快项目的交付速度。

务实的 SOA 团队会平衡企业治理与项目的自主权。而不是竖立开发和注册门槛,成功的团队引入若干机制去改进服务、间接的交互、硬性服务水平并促进自助服务的应用,通过引入这些机制使团队促进服务的开发、服务的共享和服务的应用。你可以把这些机制当成现有 API 管理的核心。

务实的调和

REST 与 SOA 是不同的,虽然它们并非格格不入。服务可以成为 RESTful,RESTful 资源也可以成为服务。像 SOA 一样,REST 是由一组设计原则定义的架构规程,REST 还强制施行一组架构约束。REST 使用以资源为中心的模型,这与以对象为中心的模型截然相反(比如,通过资源来封装行为)。在 REST 中,你感兴趣的每件事物都是资源。当进行 RESTful 服务(也叫作 API)的建模时,以一组资源来封装和暴露服务的能力。

因为 SOA 所呈现的架构目标状态通常与目前遗留的 IT 资产是有一定差异的,所以 SOA 是一个漫长的架构之旅,而不是一种短期实现。因为 API 使组织内外的业务能力相互连通,所以 API 能够为商业干系人提供一个平台,使他们可以在其上发起企业 IT 革新以及实行务实的业务。

什么时候去创建服务或者去创建 API

当正要创建一个同时包含 SOA 和 REST 的统一架构策略时,下一个合乎逻辑的问题是:什么时候去创建服务或者去创建 API 呢?从消息传递的观点来看,服务和 API 有相似的属性。它们都是可访问的的网络终端,通过访问交付数据或触发事务。从架构的观点来看,服务和 API 都提供了分离关注点、创建松耦合解决方案的机会。许多架构师和开发人员都想要随着 API 一起扩展他们面向服务的架构(SOA),但并不清楚什么时候去创建服务或者去创建 API。

什么时候创建服务?

作为一个可访问的网络终端,一项服务是一项已经发布的业务或者数据。当团队要网络域或运行期应用共享业务能力或业务数据时,创建服务。

服务应当实现一个适当自动化的业务任务,不应该设计成与其他组件交互的精细化组件。当服务暴露了业务流程中的一项独立任务时,开发人员和业务分析师更喜欢去获悉服务的目标。以业务任务的粒度去设计服务,减少服务的交互复杂度,简化应用的维护工作。举一些适合于面向服务的方法的业务任务的示例,它们包括“提交订单”、“检索客户记录”以及“缴费”。

接口与实现分离

服务封装了特定的实现,服务终端通常在服务与后端业务逻辑之间有一个一对一的关联关系。服务应该通过多种接口风格(比如面向资源的、发布 / 订阅的、方法调用的)暴露业务能力或数据。为了最大化有效性和范围,服务实现应该通过多种消息协议(比如 HTTP、JMS、MQ)和消息格式(比如 JSON、XML、CSV)去发布可访问的接口。

RESTful是一种接口风格。这种网络非常适用于移动应用、瘦 JavaScript 客户端应用以及跨网络和所有域的 bash 脚本访问函数。

理想情况下,接口风格不仅是详细的解决方案,还是重要的管理特性(比如安全性、服务层的强制实施、用法跟踪等),在所有接口风格(比如面向资源的、发布 / 订阅的、方法调用的)中这些特性都是有效的。图 1 展示了外观模式,连接了一个单一的服务实现和多个消费者:

图 1:API 外观模式

内在表征与外部契约和外部协议的分离,肯定会影响随着时间去演变服务实现的能力。当从已有的实现中清晰地分离出接口时,开发人员就可以修改其实现而不会影响到使用该服务的应用调用了。

然而,从共享的应用平台消除消费者和提供者的耦合,以及从实现中消除接口耦合都会增加额外的关注点。例如,如果试图使操作语义(比如身份、服务层、授权)跨不同的平台和分布式环境无缝地流转,那么难度就增大了。团队依靠中间件基础设施去桥接跨所有参与者和组件的语义。

因为从实现中分离接口引入了复杂度和额外的工作量,许多团队把接口紧紧地绑定在实现上。通过下述的架构最佳实践,并引入 API 外观或代理终端(使用自动化开发),团队可以增强解决方案的可维护性和适应性。

什么时候创建 RESTful API?

RESTful API 是一种与服务实现互补的接口风格。可在以下时机创建 RESTful API,当要共享控制领域(比如业务单元、组织)之外的服务时,当以扩大影响范围和消费群体为目标时,当要提供跨本地 web 基础架构的服务时,或者对服务端、接口和实现的不对称演进极其感兴趣时。

如果开发团队发布已有服务前的 API 外观,他们要从服务的实现中分离出服务的接口。API 端点是实施安全、监控使用和流量整形的轻量级代理。代理使消费者接口合约和后端服务的实现可以清晰地分离。

当应用服务器、企业服务总线节点或者数据服务主机可以发布 API 端点的时候,API 网关是由 API 传送机制优先管理的。托管的 API 是:

  • 可主动发布和订阅
  • 与相关已经发布的服务级协议(SLA)一起有效
  • 安全的、已认证的、已授权的且受保护的
  • 通过分析可监控和可货币化

服务接口或 RESTful API 接口

RESTful API 与服务是不一样的,虽然它们并非格格不入。服务可以成为 RESTful,RESTful 资源也可以成为服务。像 SOA 一样,REST 是由一组设计原则定义的架构规程,REST 还强制施行一组架构约束。

RESTful API 接口是服务接口中一个有约束的子集。RESTful API 暴露面向资源的接口,理想情况下符合 HATEOS(超媒体作为应用程序状态引擎)。RESTful API 发布资源为中心的模型,它与对象为中心的模型相反(比如,行为是以资源来包装的)。在 REST 中,感兴趣的每样“事物”都是一个资源。当对一个 RESTful 服务(也叫做 API)建模时,服务的能力作为一组资源进行包装和暴露。

去创建一个 RESTful API:

  1. 为所有事物指定“ID”
  2. 将所有事物链接在一起
  3. 使用标准 HTTP 方法
  4. 允许多种消息格式的表述
  5. 减少共享的状态

新兴的 API 设计工具将帮助你把一个服务实现转换成一个 RESTful API。

关于作者

Chris Haddad WSO2 领导平台传道。他居住在 Space Coast Florida,他在那儿观看火箭发射,做冲浪运动,以及编写架构最佳实践。针对云、DevOps 和以API 为中心架构的应用,Chris 汇集了很多以IT 业务为目标的通信战略和战术经验,这些经验都来自于他的亲自实践,极具实用价值。

查看英文原文: SOA and API Schism and Unification

2014 年 11 月 11 日 21:364408

评论

发布
暂无评论
发现更多内容

甲方日常 55

句子

工作 随笔杂谈 日常

MySQL选错索引导致的线上慢查询事故

Zhendong

Java MySQL

DocView 现在支持自定义 Markdown 模版了!

程序员小航

markdown IDEA idea插件 文档生成

探秘RocketMQ源码【1】——Producer视角看事务消息

阿里云金融线TAM SRE专家服务团队

开源 RocketMQ 中间件 开源代码 消息中间件

年轻人你不讲武德,自己偷着学习!spring Security五套「源码级」笔记哪里来的?我也要!

Java架构追梦

Java 源码 架构 面试 spring security

linux开发各种I/O操作简析,以及select、poll、epoll机制的对比

良知犹存

linux开发

Java踩坑记系列之线程池

Java老k

Java 线程池

从资源管理角度认识K8S

LorraineLiu

Kubernetes 云原生 k8s k8s入门

2020年10月公有云性能评测:盛大云-华东蝉联冠军,腾讯云-北京无缘前三

BonreeAPM

云计算 腾讯云 ucloud 公有云 评测

《华为数据之道》读书笔记:序言

方志

数据中台 数字化转型 数据治理

怎么做好一场分享或者培训

fq

聊聊在国企当程序员的这三年,这样的生活真的是你想要的吗?

Java架构师迁哥

基于ELK的日志平台介绍

Rayzh

ELK 日志系统

JVM Metaspace内存溢出排查与总结

Java老k

Java OOM 内存溢出 metaspace

架构师训练营第 1 期第 10 周作业

业哥

区块链商品溯源系统开发,数据上链应用落地方案

WX13823153201

新思科技:ISO/SAE 21434标准即将发布 你准备好了吗?

InfoQ_434670063458

新思科技 汽车软件安全

区块链司法可信存证,版权维护应用落地

t13823115967

区块链司法可信存证 版权维护应用落地

OpenKruise:阿里巴巴 双11 全链路应用的云原生部署基座

阿里巴巴云原生

Kubernetes 运维 云原生 中间件 存储

架构设计:高并发读取,高并发写入,并发设计规划落地方案思考

互联网应用架构

高并发读,高并发写

贞炸了!上线之后,消息收不到了!

楼下小黑哥

Java RocketMQ MQ

训练营第5周学习总结

爱码士

训练营

大整数算法

落曦

anyRTC uni-app 跨平台SDK 发布!总有一款适合你!

anyRTC开发者

uni-app 音视频 WebRTC RTC

前端如何实现一键截图功能?

徐小夕

Java 前端 React 前端训练 前端进阶

《华为数据之道》读书笔记:第1章 数据驱动的企业数字化转型

方志

数据中台 数据湖 数据治理

OAuth 2.0授权框架详解

程序那些事

OAuth 2.0 程序那些事 Oauth 授权框架 安全框架

2021年全球公有云终端用户支出将增长18% ;EMNLP 2020最佳论文:无声语音的数字发声

京东智联云开发者

程序人生

训练营第五周作业

爱码士

训练营

贼好用,冰河开源了这款精准定时任务和延时队列框架!!

冰河

redis 中间件 消息队列 延时队列 Zset

重点人员管控系统开发,情报研判系统搭建

t13823115967

重点人员管控系统开发 情报研判系统搭建

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

SOA与API的分裂和统一-InfoQ