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

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

一、背景

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

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

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

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

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

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

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

前端使用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。