Node 服务端系统架构设计基本思想及常见场景解决方案,社招面试心得

什么是集群?

刚说到的分布式中,应用和数据库显然在系统中提供着不同的功能,而当我们部署多个相同的应用节点时,这些应用节点就形成了一个应用集群,可见集群就是系统中多个提供相同功能的节点形成的一个整体

典型场景

在集群的概念中其实已经提到了一个典型场景,就是我们在部署node应用时,尤其是在生产环境,一般会部署至少两个以上的应用节点,来提供更强的业务处理能力,同时减少因部分节点宕机对系统整体造成的影响,这样就形成了一个应用集群

架构图

单点故障、高可用


单点故障

什么是单点故障

所谓单点,也就是系统内某个服务只有一个节点,比如我们的node应用,此时如果程序崩溃或服务器宕机,则系统整体对外表现为不可用,于是形成了单点故障

解决方案

同一服务在多个机器部署多个节点,此时一台机器或一个服务出现问题,系统整体对外表现仍可用,所以前面提到的应用服务器集群已经就可以解决这个问题

高可用
什么是高可用

系统可以持久的保持对外正常的服务

解决方案

前面的单点故障其实就是导致系统无法实现高可用的一个典型问题,所以部署多个应用节点形成集群仍然是系统实现高可用的一种基本解决方案

平滑发布


什么是平滑发布

node服务发布时往往需要停止服务,再以新的代码重新启动服务,在此期间如果系统仍可以保持对外的正常服务,则称为平滑发布

解决方案

当系统存在多个应用节点时,实际上已经具备了平滑发布的基本条件,如系统已部署两个应用节点A、B,则只需要在发布时先停止节点A的服务,发布A节点,等A节点发布结束再同理发布B节点即可

负载均衡


什么是负载均衡

如前文提到的,假设系统中应用节点已部署了多个,则客户端请求需要由一个服务根据某种策略来向各应用节点进行请求分发,让多个节点都能对外提供服务,此时客户端请求对系统来说称为负载,而所谓均衡,即使用某种分发策略以达到让多个节点都能相对均匀的分配到客户端请求

解决方案

nginx作为常见的web服务器其实就具备负载均衡的能力,我们可以以一台nginx作为应用集群的前置服务器,nginx可将请求随机分发给多个应用节点,当然也可以配置一些其他策略,如根据ip hash、按节点权重分发等

架构图

持久化存储、缓存、分布式缓存


什么是持久化存储

可以对数据进行长期保存的服务,如mysql等数据库,而要做到持久存储,通常需要将数据以文件的形式存储到磁盘中

什么是缓存

缓存对于前端同学来说应该不陌生,一般将存取速度较快的存储称为缓存,而存取速度的瓶颈往往取决于存储介质,比如持久化存储,一般以磁盘文件的形式保存数据,而磁盘文件的I/O速度显然远低于内存I/O,所以通常缓存都是以内存作为存储介质,如redis,甚至比如在node程序中直接将数据保存到一个js对象中,其实也是一种简易的缓存

分布式缓存

什么是分布式缓存

如前文所述,显然分布式缓存就是独立成一个单独服务的缓存,如redis等

为什么需要分布式缓存

假设我们的系统中存在多个应用节点,客户端发出一个请求存储一些数据,负载均衡将请求分发给某个应用节点,此时如果未使用分布式缓存,该节点将数据缓存在自己node进程的内存中,当客户端再次请求拉取该数据时,此时负载均衡仍会随机分发请求给一个应用节点,而如果此时收到请求的节点和之前存储请求时不一致,则该节点中无对应数据,导致数据拉取失败。可见我们需要一个对应用集群中心化的存储来解决此类问题

解决方案

任意节点收到数据存储请求后,将数据存储到分布式缓存中,如redis,则客户端拉取该数据时,应用节点仍从redis中获取对应数据响应给客户端

架构图

消息队列


什么是消息队列

所谓消息,其实就是一种特定结构的数据,显然,消息队列则是一种特定结构数据形成的一个FIFO的数据结构,通常用redis或其他更专业的mq(message queue)来实现消息队列

使用场景

见下文紧接着的异步任务部分

异步任务、定时任务


异步任务

一个常见场景是我们的node应用对外提供基于http的服务,系统收到一个http请求,执行一些业务逻辑,再通过http响应给客户端。现在假设业务场景是用户注册,服务端业务逻辑需要执行一系列操作,如创建用户、保存用户到数据库、再给该用户邮箱发一封邮件等等,此时如果所有操作同步执行完成再响应给客户端用户创建成功,可能耗时很久,而系统响应速度是用户体验或者说系统性能的一个重要指标。于是可以将部分耗时且对主要业务业务成功与否影响较小的逻辑(如这里的发送邮件)的待处理数据先发送到消息队列保存起来,然后立刻向客户端响应用户创建成功,然后异步的从消息队列获取用户数据并执行发送邮件的操作,而消息队列的FIFO特性可以让这些任务以http请求的顺序来依次处理

架构图

定时任务

定时任务比较好理解,如我们的node服务中可以起一些进程以一定时间周期去执行一些任务,如每天计算一次当天访问系统的用户年龄的平均值

长连接和websocket


什么是长连接

简单来说,当客户端与服务端建立一个长时间的网络连接,则称为长连接。而常见http协议,底层基于tcp,虽然tcp本身并不对连接时长做限制,但由于http自身作为应用层协议的设计理念,一次请求响应模型结束后即可断开连接,而当我们在node服务中使用websocket和客户端进行长时间、多次往返的双工通信时,则可称为长连接

使用场景

如前文所述,当需要处理的业务不适合由一次简单的请求响应模型来解决,而客户端和服务端双方需要进行长时间、多频次的双向数据交互时,则可考虑使用长连接,如websocket

高并发


最后简单聊下高并发,所谓高并发就是指同一时间系统需要处理大量客户端请求的场景,而我们的nodejs使用了单线程、非阻塞I/O配合事件驱动的底层模型,此模型在处理高并发请求时有着天然的优势(当然并不绝对)。好了,关于nodejs的高并发本文不深入讨论,如果有兴趣可参考我之前的一篇文章:https://juejin.cn/post/6844904054120792071

实际案例


前端统一打包服务的分布式改造、多节点部署

背景

公司前端发布系统底层由一个统一打包服务提供前端项目的打包功能,技术上是一个使用了eggjs的node项目。基本业务逻辑是客户端发起打包请求,服务端接受请求,从代码仓库下载项目代码,安装依赖,执行打包脚本,并通过websocket向客户端推送打包过程中产生的log,打包结束后将最终的打包结果上传到服务器。可参考下面的流程图

自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。

深知大多数前端工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!

因此收集整理了一份《2024年Web前端开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上前端开发知识点,真正体系化!

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你觉得这些内容对你有帮助,可以扫码获取!!(备注:前端)

最后

基础知识是前端一面必问的,如果你在基础知识这一块翻车了,就算你框架玩的再6,webpack、git、node学习的再好也无济于事,因为对方就不会再给你展示的机会,千万不要因为基础错过了自己心怡的公司。前端的基础知识杂且多,并不是理解就ok了,有些是真的要去记。当然了我们是牛x的前端工程师,每天像背英语单词一样去背知识点就没必要了,只要平时工作中多注意总结,面试前端刷下题目就可以了。

什么?你问面试题资料在哪里,这不是就在你眼前吗(滑稽

**

最后

基础知识是前端一面必问的,如果你在基础知识这一块翻车了,就算你框架玩的再6,webpack、git、node学习的再好也无济于事,因为对方就不会再给你展示的机会,千万不要因为基础错过了自己心怡的公司。前端的基础知识杂且多,并不是理解就ok了,有些是真的要去记。当然了我们是牛x的前端工程师,每天像背英语单词一样去背知识点就没必要了,只要平时工作中多注意总结,面试前端刷下题目就可以了。

什么?你问面试题资料在哪里,这不是就在你眼前吗(滑稽

资料领取方式:戳这里免费领取

  • 3
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值