记一次系统架构选型的思考

本文目录
[隐藏]

随着业务规模的逐渐扩大,系统现有的架构已经渐渐不能适应目前的业务规模,因此需要对系统的架构进行改良,本文就记录一下我在这次架构改良中的一些思考,希望能对读者有借鉴意义。

image

一、背景

先从我们部门的整体架构说起。

最早期的时候,每个项目组的工程都是独立的,大家各自独立维护自己的微服务,业务逻辑掌握在自己手里,有需求可以随时修改接口,上线及迭代都很方便。

也就是大家常说的“烟囱模式”,每个项目都是一根烟囱。

这种模式虽然开发起来方便,但由于各个项目组的服务不透明,很大程度上造成了资源的浪费,存在重复造轮子的问题。

于是,在去年,随着大中台概念的兴起,我们部门整体也开始了大中台的建设,将各个项目组提供的服务集中管理,形成了一个统一的微服务管理平台,对外统一提供能力。

这是背景,再说一下我们组自己的系统现状。

目前我们的系统是采用的典型的前后端分离架构:

前端使用vue全家桶以及ElementUI,后端大部分采用Springboot提供rest接口,小部分使用flask,数据库使用MySQL,Redis做数据缓存,kafka和activemq作为数据和命令的队列。

这样的业务架构,正常情况下来说是足以满足大部分的业务需要的。

但是,在大中台战略的背景下,这个架构已经渐渐有些不能适应了。

二、存在的问题

目前我们遇到的主要问题,有以下几个方面。

1、项目定位

不同的项目之间的定位不同,有些侧重于数据的处理及存储,有些则侧重于展示及交互,而我们的项目就是后者,主要侧重于展示及交互。

2、接口适配

将所有接口统一管理,带来了很大的方便。

我们在做一个新功能时,会首先看下微服务管理平台是否已存在相应的功能。

如果已存在,就直接拿过来使用,不用再专门开发。

然而,每个项目的需求是不同的,接口的功能有时不能完全满足我们实际的需要,重新开发又有些浪费。

所以,我们会拿到接口数据后,对其进行相应的改造,使之满足我们的需求。

3、技术栈

前面也说了,我们项目组主要侧重于展示及交互,因此同学们大多是前端技术栈。

 

三、问题分析

好了,前面啰嗦了这么多,其实总结起来就一句话:

前端同学希望加一个中间层来处理与后端的接口适配问题。

有人可能会说了,又不是多么难的问题,直接用springboot来做接口适配不就可以了吗?

但是我觉得不可以。

首先从业务层面来说,做接口适配的目的是服务前端,也就是所谓的BFF,全称是Backends For Frontends(服务于前端的后端)。

再者,从技术角度来讲,我们项目大部分同学是前端技术栈,如果仅仅因为需要适配几个接口而让他们去写java代码,虽然可以增加阅历,但其实对他们的技术水平的提升没有太大作用,总体上来说,不利于整个项目发展。

因此,我决定引入nodejs,使用node作为中间层,来打通中台与前台。

这也是大部分公司采用的方案。

 

四、技术选型

目前主流的nodejs框架主要有两个,expresskoa

此外,还有基于这两个开发的中间件egg及nestjs等。

经过各方面的权衡,及共同讨论,最终选择了nestjs。

其实在egg和nest之间犹豫了好久,但是因为nestjs对TS的支持比较好,而且注解及OOP的思想也适合我们这些用过spring的人,所以最终还是决定使用nestjs。

您可以选择一种方式赞助本站

支付宝扫一扫赞助

微信钱包扫描赞助

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: