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

接口频繁变动实际本身包括两个方面的原因。
其一是需求本身就不清晰，往往是功能做到哪里想到哪里，这样自然会导致接口不断地增加或者变更，导致大量重复工作。其二是在进行接口定义设计的时候，没有考虑接口应该是提供领域服务能力，而不是提供大量的数据库表的CRUD能力，没有考虑很多逻辑应该是内聚在后端完成聚合和组装，而跑到前端进行组装。
以上两个就是接口频繁变动的关键原因。因此要推进接口驱动，首先要加强需求输出的严谨性，其次要加强领域设计能力，做好接口的设计和抽象。
接口驱动开发过程
文章插图
在这里先看下关于面向接口编程的一些说明。
我们在一般实现一个系统的时候，通常是将定义与实现合为一体，不加分离的，我认为最为理想的系统设计规范应是所有的定义与实现分离，尽管这可能对系统中的某些情况有点麻烦。
在一个面向对象的系统中，系统的各种功能是由许许多多的不同对象协作完成的。在这种情况下，各个对象内部是如何实现自己的,对系统设计人员来讲就不那么重要了；而各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信，大到各模块之间的交互，在系统设计之初都是要着重考虑的，这也是系统设计的主要工作内容。
面向接口编程就是指按照这种思想来编程。
对接口的理解
接口从更深层次的理解，应是定义（规范，约束）与实现（名实分离的原则）的分离。接口的本身反映了系统设计人员对系统的抽象理解。
在设计模式里面经常会提到面向接口而设计，同时强调尽量要少用继承而多用组合。面向接口设计一方面是更加方便的应对和适配底层变化，比如底层实现的变化；另外一个方面就是接口定义清楚后对于接口依赖端可以并行开展工作。
同时还可以看到通过面向接口编程方式，可以最大限度地对外部屏蔽接口内部实现细节，一个模块对外开放能力只需要开放接口定义格式和描述，而不用开放具体的实现细节。
定义和实现分离，达到了进一步的安全方面要求。
接口在架构设计中起到关键作用
在前面已经谈到接口定义和设计在架构设计里面起到关键作用，这种接口的定义除了上述的作用外，更加重要的是实现了系统分解后，各个子系统和模块只要遵守共同的接口定义契约，就可以开始并行开发和实现。
这也是我们在实施大型SOA集成项目经常谈到，接口定义和设计先行，通过统一标准的接口契约来实现接口开发和实现的并行。如下图：
文章插图
接口先行的目的就是大家遵循同样的标准，那么后续各个组件就能够无缝地集成到一起。否则接口实现不一致，那么后续就无法进行集成，导致功能和接口变更。
基于接口驱动来实现完整的产品开发和集成
在微服务开发过程中，整个微服务划分和微服务间的接口设计仍然需要保持高度的架构完整性和概念一致性。即首先通过架构人员进行微服务拆分，关键接口设计，其次才是进行各个微服务模块的开发，在开发完成后进行集成工作。
文章插图
如上图，大家遵循同样的接口契约，那么后端开发，前端开发和测试人员可以并行开始各自的工作。对于前端优先进行接口开发和实现，前端则通过接口契约产生Mock模拟，通过接口模拟实现来进行前端功能的开发。在前后端开发过程中，测试人员也可以根据接口定义进行测试设计工作，同时进行相关的测试脚本设计或录制工作。
接口开发完成后，前端和后端首先各自进行单元测试，在单元测试完成后进行前后端的集成测试和验证。同时测试人员可以启动相应的接口自动化测试工作。
前后端分离后的问题
当我今天写这篇文章的时候，进一步思考了下前后端分离开发的一些问题。
比如在传统开发模式下，一个功能实现都由张三负责，那么前端和后端都是张三来做，张三对整个功能业务和逻辑都了解，因此可以既完成接口层的单元测试，也可以完成前端页面黑盒驱动的功能自测试工作。
当功能进行前后端分离开发后，张三仅负责后端，前端由小敏负责。