maven 引入sdk sdk里面引入的包没有被编译_多语言SDK开发终极解决方案——阿里云Darabonba...

作者丨普冬 开放平台高级开发工程师

前言：如今 OpenAPI 已经成为完成系统之间集成的重要桥梁，OpenAPI 的可用性以及客户在使用时的体验就变得越来越重要，阿里云前架构师曾说过：“阿里云的本质是一家卖 API 的公司。API 有没有做好，是关乎生死的大事"。但是从日常来自客户的反馈中我们总结了以下比较通用的几点OpenAPI体验问题 ：

• 云产品 OpenAPI 没有提供 SDK 或者 SDK 语言不全；

• 部分云产品的 SDK 使用风格差异过大，导致使用成本增加；

• API 文档缺失或者不够清晰，不具备指导意义；

• 没有场景化 Code Sample 或提供 CodeSample 无法运行。

那么阿里云又该如何解决以上问题呢？本文就将通过客户调用阿里云 OpenAPI 服务所遇到的重点问题来介绍开源技术 Darabonba(原名TeaDSL)是如何逐步解决的。

如何为任意风格的 OpenAPI 生成SDK

说起生成多语言 SDK，大家第一时间想起的一定是当前业界内生成多语言 SDK 的通用方案——Swagger，开发者通过 Swagger 定义的 OpenAPI 标准并配合模板的方式来生成多语言 SDK。不过问题并没有因此而得到完美的解决，首先模版的生成方式相对生硬，虽然实现起来容易，但维护起来却不那么灵活；其次，大量 OpenAPI 并不是 RESTful 风格的，这就导致很多的产品现存的 OpenAPI 在文档、SDK等场景下，无法使用上 Swagger 这样强大的生态工具链；例如，阿里云就有很多 OpenAPI 网关，不同的网关有不同的风格，不同的签名算法，不同的序列化格式，且都不是 RESTful 风格的 OpenAPI，所以导致了 SDK 风格差异大，也很难为所有的 OpenAPI 都提供 SDK 生成服务。如果还沿用 Swagger 的模板生成的方式去生成如此之多网关的 SDK 生成器，先不说这些生成器后面是否还能维护，就算可以其工作量也是我们一个小团队所无法承担的。所以如何能够兼容所有网关生成风格统一的 SDK 就成了最主要的问题。

Darabonba 的解决之道

正所谓穷则变，变则通。为了能够完成这个艰巨的挑战就不能沿用以前规范元数据的方法来解决，我们就需要对我们的工作重新进行抽象。在笔者看来，之所以没有一套元数据可以适用于所有的网关主要还是因为每个网关所对应的后端情况不同，就像机器语言或者汇编语言会因为架构的不同而有所不同，但是其本质还是描述如何通过操作寄存器、内存里的数据来完成一个程序。而对于 OpenAPI 来说也是同样的道理，所以我们通过重新定义一门 DSL 语言 Darabonba 来描述各种各样的 OpenAPI。

基于 OpenAPI 的设计理念

通过我们的研究发现，无论 OpenAPI 的参数是如何组成的，传输是 JSON，还是