一张架构图让我认识到前端的渺小
前言
大家好这里是阳九,一个文科转码的野路子码农,热衷于研究和手写前端工具.
今天我们不聊前端,咱们来聊聊后端,聊聊架构
目的是正视自己的地位和价值,在寒冬中保持清醒
借用若川大佬的一句话: 所知甚少，唯善学
先别问我到底是前端程序员还是后端程序员,我自己也不知道。当然自己也很想在某个领域精进,但是业务嘛,咱们就是一块砖,哪里需要哪里搬,硬着头皮上呗
最近是在维护公司的业务引擎, 对其进行优化并添加功能,技术栈的话大体来讲, 前端是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，连这些都搞不明白，就像原来的我一样。
毕竟，即便是深入了前端的原理，可能也只是到达了软件开发的基本水平吧。
还是借用那句话吧。
所知甚少，唯善学。
前端不会死的，它只是停止了狂奔。
来源：juejin.cn/post/7207617774634451000
