云服务OpenAPI的7大挑战，架构师如何应对？
|
另外，云服务并非单个服务的简单排列，它是多个体系的横向整合，总体对外呈现出有机连接。随着云计算的发展，企业客户对对云服务的要求不断提高。最典型的就是当企业客户大规模开始上云后，对虚拟化的云产品提出了各种管理需求，例如鉴权、编排、弹性伸缩等。
企业客户对云服务的管理需求 以最常用的鉴权功能为例，客户创建了一组云服务器来跑业务，运维人员需要有重启服务器的权限，其他角色人员则不需要此类权限，针对RestartServer这么一个API就需要进行权限控制了。权限在云平台中一般是中心式管理的，单独的云产品不需要分别管理。如果统一处理鉴权，就需要知道当前API正在操作什么资源，与此相关的资源有哪些(例如与服务器有关的资源包括磁盘、网卡、网络等关联资源)，然后针对所有相关资源逐一鉴权才能确认API操作是否可行。 上面提到的资源有两个关键点，一是要有统一的资源模型，便于云产品对特定的API进行鉴权，二是要明确资源关系，当出现资源依赖的时候，需要关联鉴权。在Google的API Guide中就明确提到需要资源关系，可以看出资源关系不仅仅是用来做API设计建模的，它对于平台功能的实现也有至关重要的作用。不了解资源关系，有可能把多个资源封装到一个API中，使用和变更都很痛苦，即便后期发现了问题再补救拆开，由于很多用户已经在使用了，要付出的开发成本和沟通成本也是极大的，甚至成为不可能。所以清晰的资源模型有利于梳理清楚API体系。
定义清晰的实体关系图有助于设计出更为完整的API 而且，明确的资源模型对于构建云上运维管理基础设施至关重要，例如可以通过对资源打Tag来对资源进行分类管理(参考阿里云资源Tag)，分组授权(参考阿里云资源组)，资源审计(参考阿里云CloudConfig)，类似开源软件Terraform这样的编排工具，由于有资源模型会更容易接入和使用。 所以，统一的资源模型对云服务的帮助是巨大的：
既然有这么多好处，那么众多的云产品在实际设计API的时候能否坚持以资源为中心，充分考虑到上下游的需求就变成一个很大的挑战了。 挑战3：API设计风格 确定了设计模式和资源模型后，是时候进入到API设计细节了。诸如API名称、参数名、属性名称、数据格式、错误码之类的信息，看起来根本不是问题。单个产品问题还不大，只要保证内部风格一致即可，如果考虑到云服务多产品对外的整体体验，就有必要考虑以下问题：
上述问题都是实际研发过程中要注意的，要全部罗列的话远不止这些。API的用词描述是云服务展现给外部用户的第一印象，绝非随意写就。对人员有一定规模，内部有多条产品线的组织来说，如何协调组织的各个部分对外具有统一的体验是个很大挑战。 回顾下HTTP协议，最广为认知的是对HTTP Mehod的约定，使用9个单词就完成了对基本动作的规范，为开发者提供了清晰的思维模型：
Http Method 类型 图片来源：https://tools.ietf.org/html/rfc7231 同样，在HTTP Header里面也对浏览器信息、语言、网络连接属性等做了详细的规定，这样开发者在使用HTTP服务的时候都有一个大致的约定，在关键信息上面不会有偏差，保障了异构系统的接口一致性。 因此云服务在管理API时应该考虑一些具体的规范，对命名规则、标准词汇、最佳实践模式、错误码等信息都有明确的规定，同时用系统化、平台化的手段来管理API，确保不走偏。设计风格不是云服务API设计中致命的问题，但是它关乎云服务外表形象，不可不察。 挑战4：服务端容错处理 （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
