利用 Node.js 中间层进行高效的敏捷开发思考

在项目敏捷开发的过程中,经常会遭遇 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 的权限控制。

此为原创文章,转载请注明出处