在项目敏捷开发的过程中，经常会遭遇 Api 联调导致项目开发周期紧张的情况。目前国外很多大型互联网公司流行全栈开发概念，所谓全栈开发即一个项目的前后端逻辑都由一个人来完成。这种模式是的好处是基本上在开发环境没有联调的概念只有 Api 调试的概念。但在目前国内大环境背景下，全栈开发无疑是动了前端或后端工程师的“蛋糕”，所以全栈开发在国内依然是以概念的形式存在。如果前端开发人员利用中间层来处理这个问题，那么是否是一种新的解决思路呢？
常规的业务开发流程
后端根据不同的业务需求给到前端特定的数据内容，不同的需求会产生不同的 api，但对于类似功能的需求，后端因为需求的不一致，都需要进行“定制”，即不同的 api 返回不同的内容，这种开发模式下，每次有类似的需求都需要开发不同的 api 来承载需求，久而久之，后端需要维护一大堆相似功能的 api。
根据业务要求查询数据库 -> 生成(过滤)数据 -> 注册前端 api
优势：
- 根据需求查询数据，能直接满足业务的数据需求
- 后端人员对 api 开发经验丰富
劣势：
- 相似业务的数量越多，冗余的 api 也会越来越多
- 与前端需要进行业务 api 的联调
- 每次改动都需要进行后端发版，发版过程会影响少部分的线上用户数据
传统的微服务开发模式
后端通过将 api 逻辑解耦成独立的微服务，后端维护服务 api 的功能可用性，可以最大程度的减少 api 的冗余。对于特殊业务数据需求依然需要开发独立的 api 来满足业务的需求。
微服务 api 获取特定数据 -> 注册服务 api
**根据业务要求查询数据库 -> 生成(过滤)数据 -> 注册业务 api **
优势：
- 根据需求查询数据，能直接满足业务的数据需求
- 微服务的模式可以解决一部分 api 冗余的问题，且可以进行独立的 api 发布
劣势：
- 与前端需要进行业务 api 的联调
- 某些情况下，需要从多个微服务 api 或业务 api 中获取数据并进行数据处理，在访问多个微服务 api 的过程中可能会暴露一些敏感信息
中间层开发模式
后端只需要提供最基本的功能实现，比如用户登录、某个数据库表单的数据查询等，中间层服务器通过对内部 api 的数据获取处理，将业务相关的数据提取出来后，以特定 api 的形式返回给前端。
根据逻辑需求查询数据库 -> 注册底层 api -> 中间层从一（多）个底层 api 获取数据并进行处理 -> 注册前端 api
优势：
- 由于中间层的存在，不同来源的数据内容，可以在中间层进行处理，比如隐藏敏感信息、组合不同数据数据。
- 前端人员可以使用 Node.js 参与中间层的开发，前后端一起开发可以极大的减少联调的时间，开发过程即联调。
- 中间层 api 有问题可以及时回滚和修复不影响后端底层 api。
劣势：
- 前端同事需要一定的 Node.js 开发经验
- 前端开发工作量少量增加
更深入的思考🤔
微服务 + 中间层 ?= 微接口
我在 Gaea 项目里使用了一种新的 api 模式，暂时称之为微接口模式。Gaea 通过管理底层 api，并通过业务注册，对不同的业务予以不同的 api 访问权限。在 Gaea 里注册应用之后，可以申请各类 api 的访问权限，前端项目通过应用 id 和 token 获取 api 的访问权限，前端开发人员可以根据需求自助式地使用服务 api。
这种 api 模式非常适合内部项目的敏捷开发，前端人员在开发一些没有特殊需求的页面时，甚至不需要后端开发人员的参与也可以进行项目开发。
微接口与微服务的关联与差异
微接口是在微服务的基础进行的概念拓展。前端页面对于微服务的开放 api 直接拥有访问权限，对于权限 api 的访问，你需在在对应的微服务 api 里增加访问权限逻辑。微接口的模式则将访问权限解耦成独立的服务控制模式，以应用作为控制载体，在微服务注册中心的基础上增加了应用注册中心，而应用注册中心用于微服务 api 的权限控制。
此为原创文章，转载请注明出处