自动化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，出现这个报错时，开发者需要排查对应与业务之间相关联的逻辑问题，并且最终修正请求成功。
可以通过官方的诊断平台寻求更加详细的解决方案，有关于诊断平台的内容，其实在前两期也有提到。在错误的处理有一点需要强调，异常处理不应该被直接忽略，设计代码也只是打印出来，为了简单的演示异常信息的获取方式。在实际的项目工程过程当中，开发者需要采取更为合理的措施来处理异常，比如可以传播异常、记录日志、尝试恢复等等，以确保系统的健壮性和稳定性。对于错误的处理，假如不够得当，很可能会导致在某一个时间点异常情况的发生。所以工程师们对于异常错误处理一定要更加全面、更加严谨的有方案上的设计和处理机制。
