云服务OpenAPI的7大挑战，架构师如何应对？
|
实践中，如果不做好问题a的处理，可能会造成系统异常情况下大批资源被重复创建，有可能造成用户或云服务商资损;问题b-e没有处理好，可能会让用户陷入盲目等待或者盲目重试，使用体验和效率极差;而f-g关系到自动化处理工具如何做到效率最大化，也关系到被集成的效率。
一个异步重试的状态机 当出现异常的时候，API一般是要靠错误码来告知用户有什么问题。HTTP协议本身对错误码做出了详尽的规定，Restful的API要尽可能地符合标准。除此之外，云服务有必要在此基础上进一步提供业务错误码和错误信息，来描述错误具体的细节。 当前云服务的错误码很多，看起来非常专业，但问题主要集中在以下几个方面： 1.错误类型过多：错误码越多客户端处理起来越方便吗?看一下HTTP的错误码，只有5大类加几十个子类的错误码就涵盖了所有场景，而通常大家耳熟能详的无非是200、400、404、500、502等屈指可数的状态码。有的人考虑错误码越多，客户端可以switch/case一下针对每个错误码做不同的操作，这个就见仁见智了，一般的程序员可能不会写那么多的分支流程，必要性也不大。 2.错误信息表达不够充分：相比于提供大量的错误码，错误信息的明确表达更为重要。如果错误信息不够详细，作为用户不了解细节无法掌控的云服务，几乎是无法明确发生了什么，要么提工单，要么只能被动等待，客户体验很差。 3.业务错误码与HTTP错误码含义不匹配：例如参数错误应该返回4xx系列Code，返回5xx系列就不够专业。即便是RPC风格的API，也要大致符合HTTP规则，否则可能会给一些依赖HTTP Code的系统造成误导。网上有种思路觉得无论后台响应如何，HTTP Code统统返回200，在Body里面的错误信息体现异常信息，这种不利于对接口的监控，因为监控系统很难通过识别消息体来鉴别功能是否正常响应。 4.相同错误不同云产品表达不一致：这会给客户端开发造成困扰，增加开发工作量，不利于自动化集成，用户体验比较差。 5.错误码应该是可枚举集合：一个API能够产生的错误码类型应该是可预期的，即便是业务升级，也应该给客户提供明确的错误码列表，不能随心所欲。因为用户端需要明确知道可能会发生什么，而不是随时可能出现不可预知的错误类型。如果错误类型不确定，就意味着针对错误码分支处理基本是无效的。 要做好服务端容错上述问题，需要从云服务整体层面加强API的容错设计，做好错误码规范，加强对错误信息的管理，来提升用户体验。 挑战5：版本管理 API都是不断迭代的，通常都需要版本管理。云服务API的版本管理尤其重要，主要是以下原因：
针对API各种场景的管理，需要一套成熟的API管理平台，照顾到各种场景的需求，也是一项不小的挑战。 挑战6：API该如何开放 API如何开放看起来是奇怪的问题，难道API做出来不就是开放给别人用的吗?做好就开放就开放啊?但在云服务场景下，情况会更复杂一点! 产品技术都是在不断迭代的，功能始终在增加，新的API层出不穷。从客户视角来看，他们对已开发完毕的API是否开放的需求是什么?假设一个云产品有100个功能特性，20个只能保留在内部，官网上总共提供了80个特性，而公开API只开放了50个，这是用户期望的状态吗?理想状态应该是什么? 围绕云服务有一个庞大的生态，除了普通的开发者，还有许多第三方服务商、企业客户、开源工具。当我们考虑所有这些生态成员的需求时会发现：云服务自身拥有的功能集合与客户能使用的功能集合之间的差异比较能体现产品的开放程度。这里的差异强调的是云服务已经拥有的，不包括云服务自身没有的服务。客户能使用的功能与云服务能提供的功能之间的差距越大，说明云产品的开放程度越低，因为很多功能都作为保留节目被雪藏了，导致客户和第三方服务商无法享受与云厂商接近的服务，最终生态无法拓展。理想状况是，云服务商自身能通过API使用的功能，客户都能通过OpenAPI使用，内外看到的是一致的。 但具体到某个API应不应该开放，实践中会做如下考虑：
（编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
