随着业务规模的逐渐扩大,系统现有的架构已经渐渐不能适应目前的业务规模,因此需要对系统的架构进行改良,本文就记录一下我在这次架构改良中的一些思考,希望能对读者有借鉴意义。
一、背景
先从我们部门的整体架构说起。
最早期的时候,每个项目组的工程都是独立的,大家各自独立维护自己的微服务,业务逻辑掌握在自己手里,有需求可以随时修改接口,上线及迭代都很方便。
也就是大家常说的“烟囱模式”,每个项目都是一根烟囱。
这种模式虽然开发起来方便,但由于各个项目组的服务不透明,很大程度上造成了资源的浪费,存在重复造轮子的问题。
于是,在去年,随着大中台概念的兴起,我们部门整体也开始了大中台的建设,将各个项目组提供的服务集中管理,形成了一个统一的微服务管理平台,对外统一提供能力。
这是背景,再说一下我们组自己的系统现状。
目前我们的系统是采用的典型的前后端分离架构:
前端使用vue全家桶以及ElementUI,后端大部分采用Springboot提供rest接口,小部分使用flask,数据库使用MySQL,Redis做数据缓存,kafka和activemq作为数据和命令的队列。
这样的业务架构,正常情况下来说是足以满足大部分的业务需要的。
但是,在大中台战略的背景下,这个架构已经渐渐有些不能适应了。
二、存在的问题
目前我们遇到的主要问题,有以下几个方面。
1、项目定位
不同的项目之间的定位不同,有些侧重于数据的处理及存储,有些则侧重于展示及交互,而我们的项目就是后者,主要侧重于展示及交互。
2、接口适配
将所有接口统一管理,带来了很大的方便。
我们在做一个新功能时,会首先看下微服务管理平台是否已存在相应的功能。
如果已存在,就直接拿过来使用,不用再专门开发。
然而,每个项目的需求是不同的,接口的功能有时不能完全满足我们实际的需要,重新开发又有些浪费。
所以,我们会拿到接口数据后,对其进行相应的改造,使之满足我们的需求。
3、技术栈
前面也说了,我们项目组主要侧重于展示及交互,因此同学们大多是前端技术栈。
三、问题分析
好了,前面啰嗦了这么多,其实总结起来就一句话:
前端同学希望加一个中间层来处理与后端的接口适配问题。
有人可能会说了,又不是多么难的问题,直接用springboot来做接口适配不就可以了吗?
但是我觉得不可以。
首先从业务层面来说,做接口适配的目的是服务前端,也就是所谓的BFF,全称是Backends For Frontends(服务于前端的后端)。
再者,从技术角度来讲,我们项目大部分同学是前端技术栈,如果仅仅因为需要适配几个接口而让他们去写java代码,虽然可以增加阅历,但其实对他们的技术水平的提升没有太大作用,总体上来说,不利于整个项目发展。
因此,我决定引入nodejs,使用node作为中间层,来打通中台与前台。
这也是大部分公司采用的方案。
四、技术选型
目前主流的nodejs框架主要有两个,express和koa。
此外,还有基于这两个开发的中间件egg及nestjs等。
经过各方面的权衡,及共同讨论,最终选择了nestjs。
其实在egg和nest之间犹豫了好久,但是因为nestjs对TS的支持比较好,而且注解及OOP的思想也适合我们这些用过spring的人,所以最终还是决定使用nestjs。
您可以选择一种方式赞助本站
支付宝扫一扫赞助
微信钱包扫描赞助