自动化AutoTalk第十期:应知必会的自动化工具-阿里云SDK
内容介绍:
一、阿里云 SDK 概述
二、快速生成 SDK 示例
本期我们带来的是应知必会的自动化工具之阿里云SDK的特性介绍。
今天的分享分为三个部分
总体分为阿里云SDK的概述;如何快速生成的SDK示例;SDK的一些进阶特性介绍。
一、阿里云 SDK 概述
如何更高效和安全地使用阿里云SDK。
首先是阿里云SDK的基本概况,阿里云SDK为开发者提供了全方位的云端资源操作能力,并支持了超过300多款云产品的服务接口,同时覆盖了两万多个OpenAPI以及多达8门语言的SDK,支持包括Python,Java,go等在内的主流语言,以更好地应对不同的技术栈和技术深度的开发者,能够保证开发者用到最新的API和自身的SDK特性。
SDK包都在每天地进行更新,SDK功能和特性就是今天分享的重要内容,将重点展开其中一部分的功能和特性。
SDK是开发工具包,但它不简简单单是接口包、接口的工具包,更多是一系列开发者可以无需过多关注的功能和特性,例如签名算法,签名算法有本身字段排序、字段拼接、字段编译等等。假如今天一个开发者从0到1来自主地实现签名算法,这可能需要花每一位开发者两到三天的时间,这个是非常没有必要的。所以在SDK这个环节,不简简单单是调用接口,也支持了更多自身的一些特性,来降低开发者、简化开发者对于云资源OpenAPI的调用,例如签名算法Endpoint配置、异常的处理翻页器以及最新的SSE流失的接口协议等等。
关于SDK的版本和带隙,阿里云SDK目前一共提供的是两代SDK版本,分别为V1.0和V2.0版本,目前更加推荐使用V2.0版本,它提供了更为丰富和完善的特性。
在生成的机制上,阿里云SDKV2.0版本的生成、更新、发布的效率也得到了最大的提升。这意味着V2.0版本支持更多的OpenAPI和产品,此外SDK版本号也遵循语义化版本的控制规范,包含了Major ,Minor和Patch 3个层级,方便开发者理解版本的变动和适配。对于Major版本一般代表的是非兼容性API变更,开发者对于Major版本的升级需要更加的谨慎。
对于Minor和Patch,阿里云SDK产生的是一些向下的兼容性的功能性变更,对于这部分的变更和升级,开发者往往可以更加的低成本的、高效率的进行。
二、快速生成 SDK 示例
以V2 SDK的Java语言为例。
首先向大家介绍一下如何快速的生成SDK工程,这个功能在前期的OpenAPI调试功能介绍上有提到。通过OpenAPI门户,开发者可以选择所需要的语言,并输入相关的参数,一键快速生成SDK工程,并且下载到本地,这是提供给不同语言、不同技术深度的开发者最快捷的功能之一,也是OpenAPI领域最高频使用的功能之一。
下载到本地之后再正确配置,例如调用凭证,就是所谓的鉴权凭证、本地的环境等等一些前置条件之后,开发者就可以通过本地的id、本地的编译直接执行SDK示例,发起API的调用。
开发者和工程师们需要重点避免在代码中硬编码明文的AKSK,这种做法非常容易导致凭证的泄露。例如在工程师之间的代码的传输、仓库的一个公开等等,在这种情况下非常容易危及到账号下所有资源的安全,并且直接对于线上的数据,对于用户的财产安全造成不可预估的风险。
代码示例也明确展示了环境变量的方式,有关于更多凭证的最佳时间。可以参考更加详细的官方文档。
1、Endpoint配置
接下来是关于Endpoint的配置
阿里云SDK支持两种配置方式,一种是用户自定义,直接指定请求地址,在初始化阶段setEndpoint的方法内,可以直接配置对应的最终Endpoint的域名。另一种是通过Endpoint的数据文件寻址,通过setRegionID直接配置RegionID,例如CN-杭、CN-北京等等,最终通过数据文件寻址。如果遇到未知的RegionID,会需要通过通用的规则进行拼接。Endpoint有一定的通用规则,假如通过以上两种方式,最终都没有一个准确的endpoint,此时可能发生一个报错,开发者可以通过OpenAPI门户来查看每个产品的Endpoint列表。
2、代理配置
也提供了代理配置的选项。
开发者可以在初始化课程阶段通过config设置请求的代理,比如需要配置临时代理情况,也可以通过运行时的参数RuntimeOptions来配置当前请求的代理,这种情况也是为了特殊网络环境的应用提供了便利性。
3、HTTPS请求配置
HTTPS请求配置非常重要,通过config在初始化Client阶段,可以配置对应的请求协议,开发者应该始终使用HTTPS的协议,强烈推荐使用HTTPS来保证通信的安全。
也是在当今的计算机通信领域的一个共识,当然也是最新的一个安全版本。同时需要重点注意,在生产环境当中,不要忽略证书的校验,并且需要正确的配置证书的环境,否则即使使用了HTTPS,最重要的安全性依然是无法得到保障的。
4、超时机制
在超时机制方面,开发者依然是通过初始化Client阶段配置超时的参数。
连接超时默认的设置为5000毫秒,读取超时的默认设置为10000毫秒,是根据实际的业务系统需要,合理的配置这些超时时间的参数,避免资源被不合理的占用和挂起。实际上开发者也应该根据实际的应用,通过配置文件来灵活的调整,而不应该是简单的hard code到代码里。应对不同环境的不同配置,也就是测试环境、线上环境以及不同的区域之间各种各样情况。
5、异常种类处理的机制
最后开发者对于理解异常处理的机制也是至关重要的,那么OpenAPI领域其实对于两端之间的通信交互,对于错误的高效处理,其实直接决定了整个业务系统的健壮性和稳定性。
SDK将不同类型的异常进行了细化分类,以便开发者能够更加精准的处理错误情况,主要区分了以下3种异常,这几个异常也都是符合开发者习惯和心智的标准命名。
首先,第一个validateException,这类异常一般发生用户没有正确填写必填参数的情况,这是一个基础的校验或提供数参数的这个类型,数据的类型不符合要求,不符合原数据的定义规范。在请求OpenAPI时,有一些参数是必填,有些参数是选填的,这是一层校验。另外是参数类型,有String、Bulling、Integration等等的参数类型。本地的校验机制显然是为了做一些最基础的校验,降低一些非常低级的错误,直接请求到后端,请求服务端,开发者可以查看这个异常信息当中的message,找到具体的错误点并进行修正。
其次TeaUnretryableException,这是一种通常由于网络问题引起的异常,在SDK达到最大重试次数后,假如依然无法执行成功,这时可能就会抛出这个异常,开发者也是可以通过getLastRequest信息,了解到错误发生时的具体的请求细节并进行修正。之后最为常见的是TeaException,这个异常主要在执行请求时业务的错误相关。所谓的业务错误相关是当具体出现这个报错,一般代表这个请求已经到达了云服务端,这个报错在TeaException默认会提供三个关键的参数,在示例代码里也是默认的这样三个参数,例如错误码code、错误信息Message和服务端返回的相对更详细的Data,出现这个报错时,开发者需要排查对应与业务之间相关联的逻辑问题,并且最终修正请求成功。
可以通过官方的诊断平台寻求更加详细的解决方案,有关于诊断平台的内容,其实在前两期也有提到。在错误的处理有一点需要强调,异常处理不应该被直接忽略,设计代码也只是打印出来,为了简单的演示异常信息的获取方式。在实际的项目工程过程当中,开发者需要采取更为合理的措施来处理异常,比如可以传播异常、记录日志、尝试恢复等等,以确保系统的健壮性和稳定性。对于错误的处理,假如不够得当,很可能会导致在某一个时间点异常情况的发生。所以工程师们对于异常错误处理一定要更加全面、更加严谨的有方案上的设计和处理机制。