设为首页 - 加入收藏 延边站长网 (http://www.0433zz.com)- 国内知名站长资讯网站,提供最新最全的站长资讯,创业经验,网站建设等!
热搜: mini 系统 为什 为啥
当前位置: 首页 > 综合聚焦 > 移动互联 > 评测 > 正文

云服务OpenAPI的7大挑战,架构师如何应对?

发布时间:2019-10-16 03:13 所属栏目:[评测] 来源:虚明
导读:API 是模块或者子系统之间交互的接口定义。好的系统架构离不开好的 API 设计,而一个设计不够完善的 API 则注定会导致系统的后续发展和维护非常困难。比较好的API设计样板可以参考 github 和 k8s ,它们都是典型的RESTful接口。云服务对外开放的窗口就是Op

云服务OpenAPI的7大挑战,架构师如何应对?

API 是模块或者子系统之间交互的接口定义。好的系统架构离不开好的 API 设计,而一个设计不够完善的 API 则注定会导致系统的后续发展和维护非常困难。比较好的API设计样板可以参考 github 和 k8s ,它们都是典型的RESTful接口。云服务对外开放的窗口就是OpenAPI,今天要讨论的话题是“云服务场景下OpenAPI设计的挑战”。

为什么要有API规范

之所以强调“云服务”的原因在于,小规模独立API的设计与大规模批量生产API面临的问题是不一样的。同样,只专注于自身产品API的可用性与从更高的层次去看云服务整体API体系的健壮性,要建设的体系也是不一样的。

例如,做一个WEB页面使用的API,只需要考虑性能、稳定性、鉴权就好,因为页面与API是一体的,可以一起发布和回滚,只要功能正常,即便API设计有缺陷,用户也可以接受。而云服务要开放API考虑问题就多了:

  • 首先,云服务开放的是基础设施和服务接口,一般是系统级的对接,API一旦开放想要变更就非常困难;
  • 其次,云服务并非单独运行,不同的产品实际场景中是互相组合的,需考虑产品间的一致性和互通便利性;
  • 云服务API数量庞大,为了更方便使用,配套的API查找、编排、自动化生成SDK等需求也比普通服务强烈;
  • 云服务的稳定性非常重要,核心产品的稳定性就是客户的生命线,要求非常高。

所以云服务由于产品线众多,需要统一的API规范来保证云产品间API体验一致,在底层平台层面互相兼容,便于上层应用平台化,同时要兼顾到围绕公有云服务的第三方生态、开源生态、企业生态。

在具体规范层面,业界也在不断尝试,比较知名的是OpenAPI Specfication和 Google API Design Guide。前者针对RESTful API设计在细节层面给出了非常具体的规定,已经成为RESTful API设计领域的事实标准,而后者则主要从云厂商的角度提出许多最佳实践性质的规范与建议,这些原则不仅仅适用于RESTful API,也适合其他类型API设计。对API设计感兴趣的开发者,可以详细研究一下资料。

云服务OpenAPI的7大挑战,架构师如何应对?

2018年Openapi Specification发布了3.0版本

图片来源:https://swagger.io/

因此,对于云服务商来说,在关键环节制定明确的API规范有助于云服务对内提高产品间互通的效率,对外提供一致的使用体验,有助于云服务更好地被集成。那么要做好云服务的横向规范会碰到哪些困难呢?本文就从实践中总结了7大挑战。

挑战1:选择API设计模式

当你在考虑单个产品的API表现形式时,首先会选择一种具体的API风格,常见的有RPC(Remote Procedure Call)和ROA(the Rest-Oriented Architecture)两种模式,然后针对复杂的数据结构你会考虑使用什么样的序列化协议,常见的包括Json/Xml/WSDL/Hessian等,用于封装传输数据。但涉及到不同的产品时,在具体选型时考虑的问题可能就不太一样了。

云服务OpenAPI的7大挑战,架构师如何应对?

gRPC示意图

图片来源:https://www.grpc.io/docs/guides/

虽然RESTful设计风格曝光率很高,但并不是所有云服务商都选择了完全遵循RESTful,例如AWS和阿里云RPC风格反而占了大多数,Google和Azure则RESTful居多。

Restful API的优势是HTTP具备更好的易用性,让异构系统更容易集成,且开发执行效率比较高,面向资源要求也比较高。而RPC API可以使用更广泛的框架和方案,技术层面更底层也更为灵活,设计起来相对简单,掌握起来有一定门槛,架构上更加复杂。

云服务OpenAPI的7大挑战,架构师如何应对?

RESTful与RPC模式对比

不同的团队根据实际情况和业务形态可能选择不同的方案,那云服务作为一个整体应该强制统一好还是随意选择好?如果强制统一风格,有些适合RESTful风格的服务非要使用RPC的话,看起来就会比较丑陋,如果只是一个过程化的服务调用,往RESTful资源化设计方向去靠会比较困难。但如果不强制使用统一风格,会造成针对API的体系化支持会更加复杂,例如为兼容两种风格SDK的自动化支持需要两套代码。

通常RESTful风格对API设计者的要求是比较高的,主要的难点在于面向资源设计要求开发者事先做好规划,将后端数据模型与API服务模型相匹配。所以RESTful API的开发者应该是熟知系统整体实体关系模型的,很难想象一个不懂后台业务的新手能设计出合理的API来。那么是不是RPC风格API就不需要面向资源设计了呢?从实践中来看,并不是!RPC风格的API也需要资源模型来支持,在下一节中会重点分析。

所以,对于云服务商来说,选择API风格时要考虑几个问题:

  • 选择支持哪种风格,才能更好地体现业务特性,让客户操作起来更加方便;
  • 设计API时能否面向资源设计,相应的工程人员是否具备做这种设计的能力;
  • 针对这种风格工具链的支持是否到位,投入产出比如何;
  • 业界流行的趋势如何,是否需要考虑与其他系统体系的互操作。

选定了具体设计模式后,就要努力做到统一,避免多种模式混杂带来管理成本的上升。如果确实有必要两种方式都支持(例如阿里云就同时支持RPC和ROA),就需要在技术上做好充分的准备。

挑战2:面向资源设计API

用户使用API来访问云服务,本质上是想通过对某种云资源执行特定的操作来完成一个业务动作。Restful API需要面向资源设计众所周知,那为什么RPC接口在云服务场景下也需要有资源模型呢?

【免责声明】本站内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。

网友评论
推荐文章