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