如何应对云服务端容错处理？
极客时间编辑部
讲述：丁婵大小：2.48M时长：05:25
对于云服务商来说，制定 API 规范有助于云服务对内提高产品间互通的效率，对外提供一致的使用体验，有助于云服务更好地被集成。但是要做好云服务的规范会碰到各种各样的挑战，服务端容错处理就是其中之一。此前，阿里高级技术专家虚明在阿里技术发文阐述了应对服务端容错处理的方法，具体如下。
API 是后端服务的外部表达，是服务就有可能出现问题，无论这个问题是可预期的还是不可预期的。如果只考虑功能本身的特性，而忽视对异常情况的设计，当问题出现时，业务本身可能无法感知造成的服务异常，更重要的是站在客户角度去看，不能有效获取错误原因是非常痛苦的，很多时候只能束手无策，降低云服务提供商的整体口碑，甚至损害营收。
假设有个创建资源的 API，每调用一次都会创建新的资源，考虑以下情况：
同样的请求多次提交，是否会重复创建资源？
请求处理时间过长，客户端是长时间等待，还是先异步返回一个任务 ID？
如果需要等待，Timeout 最大值是多少？
如果 Timeout 最大值达到，客户端的策略是重试还是放弃？
如果最终处理还是失败了，具体是哪个环节的问题？如何给出准确的错误信息？
如果异步方式、异步处理完成后是主动查询还是另有通知？
第三方工具和集成商到哪里去获取这些信息？能不能有标准化的处理？
实践中，如果不做好问题 1 的处理，可能会造成系统异常情况下大批资源被重复创建，有可能造成用户或云服务商资损；问题 2~5 没有处理好，可能会让用户陷入盲目等待或者盲目重试，使用体验和效率极差；而问题 6 和问题 7 关系到自动化处理工具如何做到效率最大化，也关系到被集成的效率。
当出现异常的时候，API 一般是要靠错误码来告知用户有什么问题。HTTP 协议本身对错误码做出了详尽的规定，Restful 的 API 要尽可能地符合标准。除此之外，云服务有必要在此基础上进一步提供业务错误码和错误信息，来描述错误具体的细节。
当前云服务的错误码很多，看起来非常专业，但问题主要集中在以下 5 个方面。
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 的容错设计，做好错误码规范，加强对错误信息的管理，来提升用户体验。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论