饿了么在API的实践——构建API Everything框架

简单来说就是后端服务通过API的形式对外暴露，作为前端访问后端的中间层。API Everything会将SOA服务接口适配给外部各端进行访问。

我们在之前的开发中后端没有分层，是直接在Web API层写业务逻辑，甚至直接访问数据库。但是Web API的风格存在差异，不利于团队间的沟通合作。

API文档也容易过时，不能及时反映代码的变更情况。另一个常见的问题就是前后端开发不同步，前端需要等待后端的API 接口开发完成。

我们在构建API Everything框架时所确定的最基本原则是稳定性、性能、高可用以及容错性。另外为了让业务团队能够自行解决使用API Everything时遇到的问题，还将DevOps中心配置到框架中。

其他一些原则，包括自动化、代码即文档、用户体验以及功能需求。这其中的代码即文档可以将代码中的注释给提取出来，使开发者无需另外创建API 文档。用户体验是面向开发人员准备的，让开发过程能够更加方便。

除了对产品原则的考量外，我们还需要考虑整个API的生命周期。API Everything作为SOA与前端之间的中间层，它的生命周期一般由API开发、API管理、API网关、API运维这样的流程构成。上图详细的罗列出了各个生命周期所需要考虑的细节，例如在API开发时就要着手考虑文档以及Mock的问题，API管理阶段考虑访问权限以及限流、灰度问题。

基于对产品原则和生命周期的考虑，我们提出了完善的产品规划。API Portal负责从代码中抽出文档、API Mock、访问权限、限流灰度以及API拼接剪裁，主要是对API的定义。

在定义完成后由Stargate Cluster来实现功能，包括鉴权认证、协议装换、监控告警、部署扩容、API拼接裁剪。MockServer中包含的是针对Mock功能的实现，这里不仅仅是Mock API还有Mock SOA，在SOA没有准备好前，可以事先通过Mock SOA实现出来。最后的API Robot主要是一些测试相关的功能。

前端通过Nginx访问到达圈SOA服务，灰色表示正常访问服务，红色则是先通过query string访问Mock。Stargatecluster会相对API Portal准备好的API定义，去调用SOA服务。API Robot则是消费API定义来进行API测试及回归测试。

• API文档生成自动化：代码注释和标注写完，提交代码，就可以看到API文档。

• API代码自动生成：通过标注将SOA接口自动映射成Http接口，并且生成代码。

• API部署自动化：在SOA服务部署的时候，自动部署对应的Web API。

• API Mock自动生成：根据API Model自动生成Mock数据，支持函数。

• API自动监控告警：每个应用接入，自动进行全链路监控和告警。

Stargate Cluster是运行在docker环境下的。图中右上角的ELESS是饿了么内部的发布环境，当SOA环境发布后会调用Stargate_core，然后进入MaxQ，再由Stargate运营管理服务去消费MaxQ，最后通知Stargatenodes进行分析处理。

图中是Stargate Cluster的具体部署环境，流量先从F5api-xxx.ele.me到达Nginx，再通过upstream抵达Docker环境，最后Docker会将IP注册到Nginx上。

图中是一些部署的log，包括部署消息、是否部署成功以及变更等。

这份文档相对前端比较友好，后端可能更喜欢直观的数据展示。文档中会有一些讨论、版本控制以及变更对比之类的信息。

在API完成提交到git中后，发布系统会创建build。buid完成后就会自动化生成API文档。通过图中的public APIs就可以通知相关人员API完成的消息，接受到消息的人员可以来到API界面进行讨论留言，之后留言将被转发给API开发人员。

图中的ServiceProvider需要依赖后面的服务，而通过Mock Server就可以Mock这些服务。

将相关的依赖放入Mock中后，Mock Server会自动解析依赖或者API对应架包所包含的方法，并且还能自主添加Mock case。

前面我们谈论了StargateCluster、API Portal、Mock Server这些可以独立使用的工具。而在前后端开发分离实践中这些工具将会被很好的结合在一起。上图就是整个开发过程的流程图，能够看到所有的部分都被有机的结合在一起。

我们的前端基本上就是通过API Portal完成Mock相关的部分。后端原本是要写Web controller，以及相应的测试，现在通过Stargate Cluster可以自动化生成Web API。之前开发中经常会出现部分功能留待联调期间进行开发的情况，以至于联调时间变长。而现在前后端是独自进行开发的，联调时间明显减少。

通过API Everything框架看起来是解决了所有的问题，但是其实还存在不足。

我们设想中API Robot会录制线上流量，然后进行回放。录制下来的流量会被回放给到新上线的系统，来测试新系统是否有问题。

而要完成回归测试需要录制很多东西，包括SOA1和SOA2依赖、第三方应用、Redis还有Database。用户端的至下而上请求同样需要根据时间点录制，再进行整合分析抽取出合适的顺序，也就是Case。这整个过程可谓相当复杂。

今天的分享就到这里，谢谢大家！