微服务架构下的API接口驱动开发，设计和集成今天谈下在微服务架构下

文章插图
今天谈下在微服务架构下，接口设计和开发方面的思考。
对于微服务架构， SOA和Http Rest API接口设计，在我前面的头条文章中均有专门的说明，因此对于基础方面的解释在本文不再重复。对于今天要写的内容，先总结一句话再展开说明。
在SOA和微服务架构思想下，除了常说的面向对象，领域驱动， SOA等架构思想外。还需要增加基于API接口驱动进行的设计和开发工作。 API接口的识别，定义，设计和开发过程贯彻了整个微服务开发的生命周期。
软件生命周期
文章插图
对于软件开发过程或生命周期，常会说到瀑布模型，增量和迭代模型，敏捷方法论等。即使到了迭代开发，对于全新驱动仍然强调一个关键点，即：
软件开发中应以架构为核心，架构应确保高度的概念一致性和完整性。
也就是说对于全新系统研发，即使要拆分和并行，也需要在架构设计完成后再进行，否则很难真正保证架构一致性和整个领域模型的完整性等。
从模块拆分到前后端分离
文章插图
对于传统业务系统的开发，架构做了一个重要工作，即将大的业务系统拆分为多个子系统或者模块，同时定义清楚各个模块之间的接口。在这个工作完成后，后续各个模块的设计开发工作才能够真正并行起来。也就是说：
只要各个模块是按照预先定义好的接口进行设计开发的，那么最终各个模块就一定能够集成起来。架构师不单是做了分而治之的分解工作，而是通过接口解决了分解后的集成问题。
即使到了现在微服务架构模式下，对于究竟拆分为多少个模块，每个模块应该暴露哪些API接口服务应该是自顶向下方式，由架构师统一进行规划和设计。
微服务架构开发实际上重点解决两个阶段的关键问题

规划设计阶段：通过架构设计来确定微服务拆分，关键接口API定义
实现阶段：选择具体的某个微服务开发框架进行功能的开发实现

其次，在微服务开发中，引入了另外一个关键即前后端分离。
前后端分离实际和SOA思想里面的服务分层思路相对一致，至少SOA跨系统间的服务分层，服务组织思想进入到单个微服务内部的功能实现机制上。
前后端分离实际上当前是包括了技术和团队组织两个方面

在技术上前端和后端完全拆分，都可以独立编译打包
在团队上形成前端和后端角色，不再是一个人前后贯通实现

在分离后开发分工越来越细，各自都可以专注自己的内容做到更加高效，一个前端往往也可以对应多个后端开发。而前端和后端协同的关键就变成了Rest API接口服务调用。
接口先行和驱动的开发

文章插图
那么当前微服务开发，有多少团队是真正将接口定义和设计清楚后，各自基于严格约定的接口契约进行并行开发的？
实际上很多团队并没有严格这样做。
前端说需要一个接口了，后端临时再做一个，或者后端因为另外一个功能实现影响将接口调整了也不通知前方等，这些都是实际经常出现的情况。
即接口本身严肃性不够，导致接口新增和变更都相对随意，也导致了接口很难处于一个稳定的状态。在接口无法稳定的情况下，导致团队各个角色的开发都受到影响。
接口驱动开发的核心思路就是在微服务开发过程中优先定义和设计接口，确定API接口模型和接口契约，然后后端，前端，基于同样的接口标准并行开展工作。
接口定义清楚后，可以生成相应的代码框架或开发框架，前端和后端基于同样的开发框架进行接口开发工作。对于后端人员应该优先实现接口，再实现非接口部分内容，后端人员实现的接口可以自己进行单元测试。而对于前端在进行开发的时候，由于有了接口契约，可以通过Mock的方式提供模拟接口数据，方便进行前端功能开发和测试。
只有这样，才能够真正做到全并行开发和开发后的集成工作。
【微服务架构下的API接口驱动开发，设计和集成】为什么接口驱动很难？
实际在实践的过程中你会感觉到很难，就是前期定义接口往往在后期仍然大量变动和增加，但是这不是不用接口驱动的理由。就如我们不能因为需求会经常变更，而不先进行需求分析和开发一样的道理。