一张架构图让我认识到前端的渺小

前言

大家好这里是阳九,一个文科转码的野路子码农,热衷于研究和手写前端工具.

今天我们不聊前端,咱们来聊聊后端,聊聊架构

目的是正视自己的地位和价值,在寒冬中保持清醒

借用若川大佬的一句话: 所知甚少，唯善学

先别问我到底是前端程序员还是后端程序员,我自己也不知道。当然自己也很想在某个领域精进,但是业务嘛,咱们就是一块砖,哪里需要哪里搬,硬着头皮上呗

最近是在维护公司的业务引擎, 对其进行优化并添加功能,技术栈的话大体来讲, 前端是React+Node BFF,后端是GO (Gin框架+原生)

随着看后端代码的时间越来越长,作为一个切图仔,我越来越觉得恐怖。那是一种,看到了过于庞大的未知世界,并深深觉得自己的认知太少的恐怖。

因为这个项目是定制项目,通俗点来讲就是"改装车",不从头造车但是要改装,这里改改哪里改改,一旦改动的点多了,就需要你把整个项目的逻辑全部理顺。

于是乎我在这两个月里,里里外外看了几万行代码。也是硬着头皮把整个架构梳理了一遍。

先在这里放上一张整理出来的架构图

(当然这里根据原系统魔改了的很多地方,并进行了简化,并修改了名称,防止泄密,模块的大小差不多是以核心逻辑代码量来算的,前端的核心代码量有多少咱们前端er应该都懂)

本文目的

想通过一次后端架构分析, 让我们前端人意识到自己的不足与眼界的狭窄,我们前端er需要对一个完整的大型项目有一个整体的认知,意识到自己的不足，才能在这条路上更好的走下去。
不要满足于html拼拼页面,写写样式,做做一些简单的工作。

技术栈介绍

这里先简单介绍一下技术栈, 否则无法理解

• 
  
• 前端 React webpack antd redux ... 前端er都懂,以下省略
  
• Koa框架 一个node后端框架
  
• Gin框架 一个GO后端框架
  
• Docker 容器引擎
  
• K8S Docker集群管理
  
• RabbitMQ 实现AMQP消息队列协议的代理软件,也就是消息队列,用于通信
  
• GFS 分布式文件共享系统,用于大量数据访问
  
• MongoDB 快读读取用数据库
  
• Elastic Search 分布式数据库,进行大批量存储查询
  
• SQL 传统关系型数据库
  
• MobileSuit 后端框架工厂框架,用于创建独立Gin服务
  
• 扩容服务 GO原生实现
  
• 引擎 GO原生实现
  
• 守护进程 GO原生实现
  

关于前端

看到左上角我特意标出来的那一小块红色的UI了吗？我们称之为 前端

数据库

mongo DB : 用于小体积数据的快速读取,用作数据中间传输(原生json,使用方便)

Elastic Search : 分布式数据库, 用于大体积,大批量数据存储和快速检索(动辄十几亿条数据,一条json数据几千个字段)

SQL: 用于存储不变的数据,比如国家信息,公司信息等等,重在稳定。

容器化部署

简单介绍一下什么是容器,当然我这里默认大家都懂。 容器提供了程序所需要运行的环境, 并将其独立隔离出来,

Docker:  是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中

k8s: 是 Google 开源的一个容器集群管理系统

架构中除了守护进程和引擎扩容服务,所有引擎,前后端服务,数据库服务都使用Docker进行容器化,并使用K8S进行统一管理。

引擎

• 
  
• 引擎扩容服务：可以在判断需要并能够提供多个引擎的时候,开启更多的引擎进行处理。
  
• 树状引擎结构: 一个任务可能需要多个引擎协同参与, 而且下级引擎依赖上级引擎的结果
  
• 上级引擎的结果需要经过调度服务,通过MQ进行消息传递,调度后再传递给下级引擎
  
• 最终结果写入数据库
  

调度层

• 
  
• 
  

  任务调度器:提供任务优先级调度,任务状态管理,任务拆分,任务下放等功能

  
  
  
• 
  

  结果处理器; 提供各引擎对应的结果处理解析功能,有大量的数据库查询,结果计算,字符串解析逻辑,体积非常庞大.

  
  
  
• 
  

  当然优先级调度器和引擎结果处理服务是单独运行在Docker中,需要使用MQ和GFS,数据库进行数据交换

  
  
  

数据聚合层

也就是node写的BFF数据聚合层,将gin框架(gopher层)获取来的数据进行聚合,格式化成前端所需的数据结构,并提供前端接口。这里就不赘述了

gopher服务层

提供主体服务, 数据库IO等等,体量最大。提供了各种处理模块,接口等。

架构也是一个简单的类node三层架构,

(Router - controller - Service)
带上validator层和数据库操作层(与node中的Model层区别不大)

守护进程

原生GO写的守护进程,一个部署时直接运行在机器某端口的进程, 主要功能有3个

创建 - 监视 - 代理

• 
  
• 它将整个系统包裹起来, 用于监视各个容器的运行情况,
  
• 提供了一个用于自动注册Gin框架路由的上级自研框架MobileSuit,系统的每个服务都会通过MS框架进行启动,生成一个Gin路由实例。 并挂载到总路由树上。
  

• 
  
• 守护进程包裹了所有的服务, 系统各个服务发出的请求都会首先被代理到守护进程上,守护进程将其统一拦截下来, 方便之后的统一请求代理处理。
  

对前端人和自己的话

不知道小伙伴们看到我整理出来的架构有什么看法？有没有认识到前端的渺小.
我们一定要正视自己的地位,在寒冬中保持清醒。

再聊聊,为什么很多小伙伴会觉得 前端已死？

我想说的是，对比起后端，前端人在几年内吃了太多的互联网红利。这个行业可能需要自我净化，提升整体素质。

我见过包装3年实际一年，连vscode调试都不会的前端人拿很高的月薪。

也见过对算法，原理，底层，优化，都很熟悉的3-4年后端的人拿的不比我这个小外包高多少。

我们前端人一定要明白，普通前端的可替代性实在太强太强。

要么我们深入业务,要么我们深入原理。

对于真正学习计算机科学的人来说,什么webpack代码构建,babel编译,什么react链表结构,vue模板编译,这些看上去比较底层的东西,在他们眼里可能只是基本功,可能只是常识。

如果不深入原理，那么最终真的只能“前端已死”。

• 
  
• 想想在刚入行的时候，读了一下某开源工具的源码，我的反应是
  

“哇这架构好神奇，居然将三层类层层嵌套” “哇一个参数居然能通过观察者模式传三层”

• 
  
• 想想在刚入行的时候,看了一下react渲染的原理
  

"哇他们真聪明,居然能想到将大任务分成多个5ms小任务,运行在浏览器每一帧上,阻止卡顿"

跟一个后端/硬件的朋友讨论,他跟我说"这不是常识吗？调操作系统底层,5ms任务给你掐了"

现在看来，这不过是基础罢了。但很多前端er，连这些都搞不明白，就像原来的我一样。

毕竟，即便是深入了前端的原理，可能也只是到达了软件开发的基本水平吧。

还是借用那句话吧。
所知甚少，唯善学。

前端不会死的，它只是停止了狂奔。