由阿里云智能集团高级技术专家赵建强和阿里云智能集团技术专家曹佩杰介绍相关API稳定安全最佳实践。

在快速发展的信息和AI时代， API已成为各行各业数字化转型的关键。无论是电商领域，医疗，科技等行业， API链接着不同的系统，使得单个应用能够和其服务快速的做互通。

稳定即服务在关键能否满足客户的需求，安全性指保护资源和数据免受潜在的威胁。

主要介绍四部分。

第一部分是通过云上案例来阐述企业在不同的阶段，在稳定安全方面面临的问题和挑战。第二部分针对上述问题和挑战，阿里云由何种最佳实践和工具来去做支撑和保障。最后，集成开发了共担模型，如何协助一起构建更稳定更安全的服务给业务保驾护航。阿里云和用户各自应该遵循与提供什么。

 

一、业务上云真实案例

业务在起步阶段存在许多问题。如开发者目标是快速的集成阿里云，把业务快速的跑通支撑业务。通过API文档就开始接入的会遇到如签名报错，签名的算法复杂，公共参数繁杂。通过前面的方式去调试，无法成功，经过耗费了大量的时间和精力去做的调试，背后是缺少语言的示例，以及排查整个错误比较困难，终于调通达到自己的目标，但在代码工程里边遗留下了，如异常处理的不严谨，永久密钥硬编码，单一地域的部署，没有灾备的情况，把东西带到了线上的生产环境。

虽然跑通，但给未来的整个的安全和稳定性留下了隐患。随着业务的增长，业务规模与用户的流量增长，整个线上服务器的流量随之增长。开发小王发现线上收到监控，有很多的流控的报错，导致服务的不可用，运维同学也收到告警，共同上线协助一起去尽快解决问题。因为业务到了一定的规模，对业务影响大。

当发现大量的报错的日志，把磁盘打爆了，导致宕机的情况，发现情况越来越恶化，第一反应通过快速的扩容去解决问题，去尽快的去恢复，但去扩容的发现遇到了新的问题，报错，报的错误创建了实例并超过了能创建的最大实例。整个线上的处理杂乱，业务的时间被拉长的，可以看到业务随着时间的推移在成熟的阶段，所有的业务量也达到了比较大的规模，易遭受黑客入侵。安全小刘发现数据被泄露，经过排查发现是依赖了非官方的第三方包，里面存这些缺陷存安全漏洞，被黑客利用到带了安全的问题，运维小张也发现随着因为公司比较成熟，云的流动是相对比较正常，发现经过排查下来，是发现是离职同学带走了永久的AK，是还是在初创阶段留下的坑，也发现存在止损，不合理的从事导致重复创建云上的资源给公司带来的损失。

 

二、案例要点解析

在不同的阶段如开发小王遇到了挑战，可以在对于要点做解析和归类，主要是分为三个节点，开发调试，生产集成以及运维监控。

1.开发调试

在开发调试阶段，如签名的困难，异常处理的不严谨，永久密钥硬编码状况以及单一地域部署。

2. 生产集成

服务不可用线上，机器宕机，创建ess遇到了的限制，导致扩容无法成功

3.运维监控

遇到流控到到运维监控，发现数据的泄露， AK的泄露以及止损等问题。

4.小王集成API的请求流程

想象帮小王去解决问题和挑战，先了解小王作为去集成阿里云，整个完整的流程以及如何缓解。看屏幕可知首先经过客户端，签名算法以及请求报文以及返回解析的的传输，包括选址异常，打印日志，经过网络传输层以后会到达阿里云的网关层。

网络层有健全的服务，有访问控制，还有流量的管控，经过网关层在到达真正的产品层，如像存储，计算网络，背后会有对资源操作的审计，以及对于资源配额的管理，账单管理等。在整个流程可以看到效率方面要光顾小王，在开发阶段能够提升效率，快速去对接阿里云，能够快速的去集成，在安全保证数据和资金整个传输的安全。对稳定阶段运行如何保证服务的高可用资源和资金的稳定性。小王在每个业务不同的阶段面临的挑战不同，是否在每个阶段有最佳实践，或者平台工具能够去规避安全和稳定性的风险。

 

三、集成开发最佳实践

由曹佩杰先生讲解集成开发最佳实践。

阿里云的API调用是非常复杂的过程，维护的调用的安全性及稳定性，是否为了安全性和稳定性，牺牲整个的开发效率。

1.SDK是集成阿里云的重要途径

大客户和中小企业都会用到sdk来去集成，有4组数据，首先每天有上百万的用户，有几百亿的调用，其中大客户的占比是高达30%的。使用官方sdk的占比是超过了90%的，SDK只是提供了签名算法，就让愿意去用sdk，SDK提供从本地开发至线上维护到业务迭代一整套的结合业务生命周期的一套流程。

2.阿里云SDK的生命周期

本地开发提供签名算法。签名算法不仅仅只方便去对接签名算法，对接事情先耗效率，但能够完成。签名算法还在不断的在升级，根据业界的流程，会直接享受到最新的业界的签名算法。第二个签名工具，为提供了很多健全能力，IQ模型和ISP模型，是出参入参的序列化的封装，通过序列化的封装，只需要关心自己语言本身和字段类型即可，提供方便开发提升效率以及规范流程的工具，比如异步调用，异步调用语言会为提供异步调用的能力，能极大的降低it可以降低线上的服务的延迟。

翻译器：翻译的流程除了page形式还有游标的形式，常规流程需要进行翻阅与阅读，而通过此不需这种流程。Waiter是接触过一组的API，API a是去做任务，但花的时间会很长，也同时需要API b去调用结果。如果自己去开发，首先要去调用apia，有个循环等待，去拉结果过程。waiter的能力可以直接等待结果。

中间件是一种开发模式，可以在请求和返回之前去做自己的逻辑，如打日志，也能规范开发的流程。

调试阶段，调试过程是占据整个开发里面大量的开发成本，工具中增加tracing，对整个开发的关键路径，整个代码的关键路径中间去做打印，通过信息不仅可以去调试错误，且可以发现潜在的风险的存在。除了本地的工具以外，除了错误诊断，门户的筹码，诊断，跟网关有所结合，整个报错信息里面带了关于这次报错的筹码方案的解决问题，点开链接就可看到。

调试完成以后，SDK通信的阶段，通信工具会为选择语言里面最成熟且最稳定的工具，通过工具，可以去屏蔽掉很多漏洞。第二个是安全工具，即HTBS。HTBS里面涉及到 tls版本以及自签证书的问题。问题也是工作中常见的用户会问到的问题，SDK就会为把事情给封装给最佳时间，保证在传输过程有安全性。

介绍荀子工具，通过把所有产品的antpoint封装成了向CN杭州CN北京的短字符串的一种形式，只需要通过日银ID，SDK就为自动提供请求。

遭遇“黑天鹅”事件：部署失败，或线上服务出问题，事情有去排查就会发现可能是，如没有测试的包发布上来，依赖上了，或者说是有非兼容性的包围，依赖上了，导致了整个部署失败，SDK会提供全场景的测试，覆盖所有ATI和是兼容性的检查。

还会对包里面的安全性进行检查，如果有安全漏洞，会第一时间修复，到了线上业务阶段首先是日志分级，日志分级就会意味着可以通过自己的业务的运行情况，去对整个日志进行打印，如果是新业务，对还需要去看更多的信息，可以达到应付非常的助力，可以根据环境变量去定制某台机器，可以达到的级别，如这台机器可能经历了问题，可以通过改变这台机器的环境变量，让打印到更多的信息去。线上的问题，从事和推理这是sdk能为做到的线上的最后一道保险，通过从事机制，对非密等的 API，不会从事，退避也会解决掉无脑从事的问题。

通过解决无脑从事，也可以降低整个日志和CPU的性能的消耗。业务迭代，因为所有的API，所有的，能为提供重要一点，首先是风格统一，风格统一可以保证说所有的API的编写代码是一致的，就不用去关注，说别人的代码有没有，可能会看不懂。提供参考指南或者都有的东西会为提供所有API的文档和参数的文档，可以直接通过ID就能看到。还有发报告即SDK的白皮书，认为每版本的sdk都打白皮书，里面包含了整个场景化测试的内容，兼容性，测试的内容以及依赖包测试内容。可以通过发布报告去选择。Codesample提供适合云的API提供sdk。

场景化选择方面，首先会提供常用的场景，每个产品都会提供，通过场景，可以直接拷贝下来去简化自己的开发流程，除此之外，相信功能也能启发去开发适合自己业务场景的。通过demo的整个 sdk的对接的便捷性，先看三个数据，sdk的首次成功率，根据平时的调研，2~3个小时，之前前面在3~5天，3~5天是保守的数据，遇到过超过一周的情况。

第二自签名nonce，整个短时间内，所有的人都不能重复的。该情况下，很多字签名不会考虑到说别人的会跟自己碰撞的问题，可以看到整个字签名的碰撞率是阿里云sdk的100倍，且是占比只占了不到10%的情况下，还能高出100倍。问题是很影响线上业务的稳定性的。最后为SDK示例。

示例内容：首先去通过门户去搜索创建ecs实例的接口，参数已经填了，可以看到参数加载完成后，实例会生成，生产代码直接复制了，首先要去做依赖保单，可以直接通过插件来个，但走老流程直接通过复制的方式把复制到的泡沫文件里面。，把安装上。安装完成以后，把代码直接复制过来调用了。可以看到代码已经复制过来，提醒，不可以用其，需要用环境变量去获取，现场通过ess已经创建成功，接下来通过参考指南，演示怎么去迭代开发，去查询已创建的ECS。

这边点开参考指南，因为风格统一，所有的request response，包括调用方法，只需要把改成对应的API名字即可。看参数，只用到ring ID，也可以根据自己的需求去填不同的参数，把所有的层次进行改变。为演示全程是怎么改的。改完后已经成功了，把刚才创建的这台ecs给查询出来了。所以从实例可以看到，整个创建ecs的过程可能就一分钟左右，改动的过程可能还不到一分钟，效率是非常高的，自己可以尝试。不能用英文AK，用的环境变量，但环境变量用的就一定安全吗，不一定因为只要用到了固定的长久的AK，就有泄露的可能性，泄露就会带来很大麻烦，SDK的安全方面，为提供无AK方案。

阿里云Credentials提供无AK方案的最佳实践，提供多方式配置，覆盖所有使用场景。如刚才的环境变量，在ECS里面的危机方案让肉以及在容器里面的危机方案adc，第二个自动刷新的能力，无AK处是不会泄露AK，但坏处就说需要自己去维护生命周期，即会遇到token过期线上业务宕机情况，理论上自动刷新不超过刷新时间即可，但实际在具体业务的过程中，不是非常简单的事情，经常会犯错误。第三个能力，容灾能力，阿里云是为提供了长达5小时的容灾能力，因为是面对问题去设计，面对灾难去设计的，灾难不仅是考虑到自己系统的灾难，甚至考虑到阿里云假设自身的服务出现问题情况，能够高达5小时容灾。

3.阿里云Credentials自动刷新

介绍阿里云自动刷新。提前刷新是通过异步方式去刷新，所以有叫最佳的叫提现刷新时间，perfect time.之间设计的是上文刷新的一小时以后加抖动时间，使用 one callerblocks是现成进行刷新，用cas可以保证说获取到的刷新句柄也不会跟其人重复，也不会说造成多次刷新造成token过期。第二个定期刷新，定期刷新，每用异步线程可以去每分钟检查下发是否有误或者过期的情况。

也是面对灾难的设计，因为也不能说保证说sts服务给下发的token一定是有效的，或者说一定是不会过期的，定期刷新能够保证及时修复。第三为兜底刷新。15分钟，到了最后都很快要过期，前15分钟才刷新已经是最差的情况了，一般遇到情况就说明之前的所有的提前刷新或者都出现问题了，该情况已经是非常危险的情况了，但如果真的这次刷新真失败，有重试和退避策略来保证token刷新的一致性和有效性，也提过高可用，刚才已经提到通过锁的方式去保证只有一个验证线程获取到距离，确保刷新的一致性有效性，不会出现有两个同时刷新了以后其中拿到了就过期了。

第二个后台异步检测能力，会考虑客户端的性能，只存在一百个刷新线程，多于会skip并等待下一轮刷新并log.warning可通过日志分级进行忽略。Token刷新抖动时间刚开始如果自己去做开发，因为的服务是有限的，不会考虑到相关问题，但因为阿里云去做服务，要考虑到有很多客户，服务有可能会很多，假如说在同时启动东西，就有可能会造成资源耗尽或者网络拥塞以及服务端限流，抖动时间里可以保证说可以是分步去刷新token。

下面就通过demo， ecs如何实现方案。首先流程图，首先开发者可以创建RAM角色，授信给ecs服务，通过配置角色到ecs实例上，客户的用户程序在ecs上直接通过无ak的方式就能获取api。

举例：角色刚开始不给任何权限，直接把给复制到 ecs上，复制成功以后，以刚才为例，创建ecs，安装包。把代码复制到ecs上，可看到安装credential的文档。首先安装credential，切换到ECS ram，把之前获取AK的代码替换成获取ECS代码，代码行数为4-5行，即替换成功。由于执行无权限，会报错。把ecs的权限给复制到角色上，复制成功以后，再调用同样api，可观察调用成功，可看到方案里面不仅没有出现任何的问题，token角色也是可以随时对权限进行绑定和解绑的，整个流程安全。

4.阿里云SDK稳定性保障

阿里云SDK有高并发的稳定性，为提供了很多异步能力，异步能力java为例，可以20K的请求，平均rt为2.75毫秒，同步为36毫秒，提升了13倍的性能。关于运维部署稳定性，首先场景化测试覆盖全量api，每个SDK的发布都经过测试。兼容性测试会严格地遵照semver的标准，只有miner版本会出现非兼容变更，可以按照自己的需求去安装对应的版本。最后依赖包版本的检查，不仅仅是会检查兼容性版本，会检查安全漏洞，避免有漏洞的包被攻击的情况。

最后异常的稳定性，重试机制会遵循API的幂的性，避免同时导致资损问题。第二退避机制，比如与网关结合，就实现了对流控错误的退避，流控的退避也会有最大的时间，因为如果流控设计的不合理，客户需要等待限流时间。一般提供一分钟到一分半的最大时间，如果实践从事了后，还被限流，还会经过一段的时间。流控的错误，发生在本地，已经触碰到sdk给的业务的最后一层保险。怎么样才能避免说保险被触及，需要在源头去解决问题，需要在服务端去配置流控和配额的量，避免问题。

回顾小王所遇到的相关问题。如遇到了服务端遇到流控线上导致整个服务挂掉，不可用，影响线上的业务，以及包括做紧急扩容，发现报错，对应对流控配额在sdk侧能去做的退避和重试的配置的优化，优化从客户端无法进行完全解决，服务端也需要平台和最佳实践来去保障。

5.持续关注云约束

介绍配额相关概念。配额本质是云的约束，看右边图，组织下面会有多个的部门，每个部门下面有很多人以及对应的账号，通过账号去调用对应的API，如图里的123，账号对于api的频次有一定的限制，应对的左下角速率配额。继续通过API123，去请求对应的云资源，如a资源，b资源，ecs与网络存储等。背后蓝色部分，指阿里云账号可以使用云状云资源的最大值，如遇到扩容遇到的实例资源超限。

6.通过配额中心统一管理云产品配额

介绍阿里云的配额中心，想象如果没有相关平台，不管是在流控在扩容会遇到资源配额的限制，需要管理很多的产品，很有可能需要去对接很多的产品，对api和控制台做配额的管理。配额中心的统一后，可以看到架构图，底层还是各种产品的数据以及配额，在基础之上做了一层原子能力的封装，主要是有像配额的查询，配额的申请以及配额的模板，还有配偶的告警的能力。在原子能力的基础之上，通向除了向配额中心的API，用户只需要去集成配额中心的一套统一的api或者控制台，就能满足需求，配额中心核心价值，主要是有三个方面，第一方面是在事前，可以通过配额规划，确保资源使用能够符合业务的目标。第二个方面事中，遇到报错之类，能够迎合，动态的去调整以及应对业务的变化，优化分配提升资源利用率。

分享配额中心的几个核心的能力项目，首先阿里云的配额模板，是提供多账号管理配额的最佳实践，可看到整个组织会有很多业务部门，包括每天可能会经常的去创建的成员账号，如果常规的做法要去对于这一块，所有的的账号去做配额管理，而配额管理每产生账号都需要去做配置，做上调，这是常规且低效的。且很有可能新创建账号会承载很重要的业务量，有可能会由于配额的问题会导致的业务中断，带来很多的问题。

目前已有多账号管理配额的最佳实践，账号产生的配额中心会自动帮助成员状况去发起上调。前提是用户需要在这做模板的配置。模板里边可做最核心的配额项目，如实例，或核心的API需要去关注用量等。可能会有限制比较严重影响业务，提升，服务端也会有很多的策略，如自动审批的策略能够保证提额的申请能够快速的去能够去解决，去响应，能够确保不会由于新增账号遇到同样的配额报错导致业务的中断。

第二个能力项为阿里云的配额监控，提前掌控配额用量的最佳实践。阿里云云监控承载了各种业务，各种核心监控指标的监控和告警。配额中心也和云监控做了集成和打通。可以复用整个云监控的能力，用户关注的核心的配额项，可以配置很多的核心业务量，需要去关注，如用量达到60或者是70%以上，要去提前去掌控，要去做相应的策略和应对。有三个步骤，一能够提前去做预警，对用量很关注的配额用量，要提前掌控，做调整，能够规避掉很多稳定性的问题，第二个在长期处于高水位的用量进行配额优化，能够让配额的整个的用量，线上的环境是比较健康的，再进一步，可以去监控资源的利用率，能够去推动资源的利用率的提升，降低用户的成本。

关于能力向有提前前置的动作，如多账号的配额模板，能规避掉账号新产生的带来的配额的报错，监控告警也要去提前掌控用量，去前置规避掉。在用户没有看监控无配置，紧急扩容报错情况，即将用两种demo去演示遇到错用户如何通过配额中心自服务解决这类问题。可以看视频，是回去创建ecs的实例，预设小王去做扩容一样的，应该是报错误的。需要填一系列的参数，有很多的规格图可以去选择。可以看到就遇到问题了，可以通过报错的页面，跳转到配额中心。

跳过了以后，右边有申请的操作，可以通过去申请配额的上调，有几个核心的参数，当前要申请的值是多少，申请的理由，申请的结果能否去实时的去推送给到最终审批。提交完以后，可以看得到，可以通过配额中心的后台，去查到是审批中的状态，也在持续的去努力，如去有更多的复杂的，如自动化的审批的策略来保证申请的效率。

申请通过以后也可以看到对应的状态的变化，再回到返回页面，就已经解决问题，已经创建成功了。遇到配额问题只需要申请一个配额项了。事也是得益于和ecs团队，进行了整个规格组配额的收敛和优化配额，像从原来的十几万已经收敛到2000以内，收敛率是99%，以上直接带来了收益和业务，结果整个配额的拦截率降低，原来需要去配置模板里面有1020配额项，升级完只需要管理12个配额项就能满足所有的业务的需求。

过程当中用户的对于配额管理的成本是大幅下降的，新特性也已经全面发布了，欢迎去使用。第二视频演示，遇到服务端的流控，如何配额自服务能力。在门户里面是已经是报所有停留的流控错误了，可以在诊断里面去找到对应的，如API的信息，再去配额中心去找到对应的和对应的配额项。

与之前资源配额相同，也会有几个核心的参数，需要用户去填，有对应的申请的当前的值是多少，以及对应的的申请理由是，以及对应的的通知结果是不是要实时的去收到。是已经申请成功了。状态是审批中。有两种方式，一种刚刚勾选的是否去主动的去获取到变更的或者是申请的结果，第二个也可以通过后台的申请历史里面去看对应当前的申请的状态。申请成功以后再回到门户页面，能拿到对应的业务数据了，通过自服务方式，把问题给解决。

 

四、集成开发共担模型

小王在不同的阶段遇到问题，有很多问题并不每个阶段一定要去经历，有些可以提前规避。现在最后一块分享集成开发的共担模型，怎么去帮助小王构建更安全更稳定的服务。

可以看到动态模型里面，集成阿里云整个全链路里边，再去看对应的阿里云有哪些最佳实现和平台工具，用户应该遵循何种最佳实践，能够确保自己的服务能够是更稳定，更安全的。可以看到会经过集成SDK，再到经过身份验证以及流量的控制，再到访问控制和资源管理。

集成阶段通过安装文档去进行sdk，并且采用异步的方式通过。如果遇到问题，首先定位问题，并且采用sdk自带的翻页的工具，就能确保集成效率。在身份验证和访问控制阶段，要去遵循跟准审的配置的最佳实践，确保全链路是无aK的，能够规避掉AK泄露，去配置。

流量管控阶段退避和从事去优化流控配额的问题。第二个提前去配置用量报警，能够提前掌控用量，能够去未雨绸缪的去发现问题。第三个真正遇到流控以后，通过刚刚演示的字符的路径去解决流控的问题。再到资源管理层面，如果是多账号体系，会去通过配额模板的最佳实践，能够让去规避掉新增成员账号会带来的业务中断的问题。第二个也是遇到配额，如扩容失败，怎么去自服务去解决。

最佳实践以后能够带来的主要的收益会要会让拥有更安全的服务，更稳定的服务，并且有更高效的运维体验。希望能够在未来的项目当中能够运用到这套模型，减少共进。一起共同努力，用阿里云的SDK为业务保驾护航，确保业务的稳定和安全，推动各自行业的持续发展的创新。

以上为分享全部内容。