API First
API First,简言之就是接口先行,但是其背后具体的含义与价值也需要着重探讨一下。
微服务架构下API接口驱动设计与开发
当传统的单体应用被拆分为一个个微服务后,微服务之间的交互、后台与前端的交互基本上都通过接口进行。
但是,传统的开发模式下会暴露出一个老生常谈的问题:很多工作没有办法并行进开展。
比如,前端开发停摆,必须等待后端完成接口开发才能进行下一步的工作;或者前端一边开发一边向后端所要具体需求的相关接口等等。
这些现象都是我们不希望看到的,因为会极大影响整体的开发效能。
针对这一问题,目前最理想的解决方案就是基于API接口驱动的设计与开发。
简单来说,就是API接口需要基于特性与用户需求提前设计、提前规划,同时应当经过相应的评审。
具体落实
对于一个业务功能点而言,都可以拆分为很多内容:
- 后端开发
- 前端开发
- 测试
- 测试设计
- 接口测试
- 界面测试
当所有人都拥有一份共同的API接口契约,那么所有人的工作都可以并行开展,最终的工作也可以集成在一起。
因此,在具体落实上,我们在对用户需求做分解时,就应当将该需求所涉及的接口就详细的确定下来,包括接口的输入、输出、认证策略等内容。这一部分工作通常由产品经理与架构师共同完成:
- 产品经理通过对用户需求的分析来确定服务应当提供哪些接口
- 架构师应当从服务架构、功能实现的维度出发,来对接口做具体的设计。如果接口涉及到对外开放的OpenAPI,则还需要更高层级的API TMG做进一步的接口评审工作。
通过这样对需求的分析与接口的提前设计,能够方便服务发现需求与对应功能点之间的模糊之处,从而将需求细化为清晰明了可实现的接口维度。
同时,这种基于用户需求分析而设计出的接口,本质上是领域服务能力接口,并非是单纯的CRUD、而是各个接口功能的汇总与组合。这样的接口将业务的总体逻辑封装成为单独的粗粒度接口对外呈现,将复杂的处理逻辑留给后端、前端只需要关注独立的用户行为即可。
当我们拥有了接口契约文件(这里一般是一份Yaml接口文档)后,整个开发与测试团队就可以同时运转起来了:
- 对于后端,可以根据接口文档按部就班地完成接口功能开发、单元测试等工作;
- 对于前端,可以不需要等待后端提供具体接口、直接开展相应开发工作,在后端接口尚未完备的情况下,通过Mock的方式来进行前端接口功能的验证;
- 对于测试,可以利用这份接口yaml去生成测试AW、编写自动化测试脚本;
最后,契约的概念也非常重要:微服务之间相互之间的调用接口、后端与前端的调用接口本身就应当确定并规范下来,不允许随意修改、删除接口;同时也不能允许服务想到哪里就将接口加到哪里,这样会造成后期的服务接口治理与监控完全失控。