API接⼝驱动设计和开发（22.1.13）
今天聊⼀下微服务架构下接⼝设计和开发。在单体拆分成微服务之后，我们可以看得到api接⼝越来越重要，微服务和微服务之间需要通过接⼝去做交互，微服务和前端之间也需要通过api做交互。我们在谈微服务开发整个改进过程的时候，⼀个重点就是基于api接⼝驱动，接⼝先⾏这么⼀个模式去做微服务开发。我们在项⽬开发过程中常常遇到这样⼀个问题，前端和后端之间衔接时，前端长时间处于等待状态，等着后端接⼝出来我才能够开始做前端的事情。还有⼀个情况就是前端边做边像后端要接⼝，做的过程中发现某个地⽅少了⼀个借⼝，赶紧让后端加⼀个。这些问题会导致⼤量的协同交付限制或者是变更，相关的资源没办法做到定型，这些都是我们不太希望发⽣的情况。
更好的⽅式是API接⼝驱动的开发模式。因为现在谈敏捷开发，实际上整个架构设计的过程是逐渐在弱化，但是在整个弱化的过程中我们需要去抓住⼀个点。原来我们是抓数据库设计，现在我们要抓的是接⼝先⾏。API接⼝要提前设计、提前规划。同时经过前后端开发共同评审。
回到敏捷开发，任何⼀个⽤户故事或者说是业务功能点，我们可以看到其实是可以拆分成多个任务。其中包括了后端开发、前端开发以及⾯对测试⼈员的测试⽤例设计。接⼝测试和实际功能界⾯的⿊盒测试，⼀系列的任务。但是这些任务⾥⾯最核⼼的还是API接⼝，如果⼤家有⼀份共同的API接⼝契约。那么所有⼈的⼯作都可以并⾏开始。因为⼤家遵循的是同⼀套接⼝契约，所以最后⼤家⾃然⽽然可以集成在⼀起。也
正是因为这个原因，我们要求任何⼀个变更版本，优先要去考虑相关业务需求或者业务功能点究竟涉及到哪⼀些接⼝。先把API接⼝确定下来，包括接⼝详细的输⼊和输出，接收⽂件格式都确定下来，完成评审后我们再进⾏开发。所以在定接⼝和评审的过程中，实际上进⼀步改进了我们整个的研发管理过程。因为在评审这个接⼝的过程中，我们会发现原来的需求有不够详细不够清楚，间接发现需求中存在的⼀些需要改进的问题。第⼆个点就是定接⼝的过程中我们会发现，原来由于需求模糊，后端在开发接⼝的时候更多是在做数据接⼝，就是⼀些核⼼的数据库的CRUD接⼝。但是在实际评审中，我们会发现很多接⼝应该做进⼀步的组合，形成领域服务能⼒接⼝再对外暴露。⽐如最近做⼀个应急响应启动接⼝开发，简单的接⼝设计就是增加⼀个响应记录。实际上这个过程中还会涉及到任务下发，⽽任务下发之前⼜涉及到⼀系列业务的处理。这些后端的问题前端并不关⼼，我们要努⼒把服务复杂的业务逻辑封装在后端。这个时候我们所提供就是组合服务API或者叫领域服务API，将这些更粗粒度的接⼝给前端去使⽤。这样才真正实现了领域服务应该具备的能⼒，⽽不是造成贫⾎的领域服务层。当我以API驱动⽅式去做设计开发时，这些问题⾃然就会被发现。
前端测试和后端测试的区别在我们定义完成接⼝分解以后，这个时候由于已经有个接⼝设计这个契约⽂件。测试⼈员完全可以开始解析相应接⼝的测试能⼒。同时录制相应的接⼝⾃动化测试脚本。对于前端开发也可以基于接⼝契约开始⼯作，即使后端开发还没有完成，前端可以基于预定义数据进⾏调测。这样我们可以看到整体的⼀个集成过程。后端开发完后，⾸先⾃⼰要做单元测试，⾸先把单元测试跑通。这个时候测试其实需要介⼊
两次。第⼀次测试是对后端提供的接⼝进⾏测试，在接⼝测试通过后告诉前端进⾏对接，前端完成联调之后，测试需要进⼀步进⾏完整的功能性测试和⿊盒测试。所以我们可以看到整个过程是联动的，能并⾏的尽量并⾏掉。这个时引⼊API接⼝驱动很关键的⼀个⽬的。同时也尽量避免实际开发中滥⽤接⼝。微服务和微服务之间究竟应该暴露哪些接⼝，微服务究竟应该暴露哪些接⼝给前端都应该提前确定下来。⽽不是想到哪⾥就增加到哪⾥，这样很可能导致后续整个API接⼝完全失控，整个微服务治理和接⼝监控都会是灾难性的。
借助类似在SpringCloud 框架下采⽤的Swagger⼯具，我们预先做好接⼝定义，把前后端以及测试开发团队联动起来，这是在微服务架构下不管是什么开发模式下都需要重点去考虑的事情，也是持续去改进或优化的关键点。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。