Node 服务端系统架构设计基本思想及常见场景解决方案

2401_85122909

于 2024-06-24 17:48:10 发布

阅读量535

点赞数 19

文章标签：系统架构

本文链接：https://blog.csdn.net/2401_85122909/article/details/139933132

版权

典型场景

服务端开发时需要进行一些数据存储，往往我们会用到mysql这样的数据库，而不是将数据存储在应用节点中，这时其实就已经是一个简单的分布式系统了，应用通过网络协议来读写数据库，同时应用和数据库一起对外形成一个服务整体

架构图

集群

什么是集群？

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

典型场景

在集群的概念中其实已经提到了一个典型场景，就是我们在部署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

跳槽是每个人的职业生涯中都要经历的过程，不论你是搜索到的这篇文章还是无意中浏览到的这篇文章，希望你没有白白浪费停留在这里的时间，能给你接下来或者以后的笔试面试带来一些帮助。

也许是互联网未来10年中最好的一年。WINTER IS COMING。但是如果你不真正的自己去尝试尝试，你永远不知道市面上的行情如何。这次找工作下来，我自身感觉市场并没有那么可怕，也拿到了几个大厂的offer。在此进行一个总结，给自己，也希望能帮助到需要的同学。

面试准备

面试准备根据每个人掌握的知识不同，准备的时间也不一样。现在对于前端岗位，以前也许不是很重视算法这块，但是现在很多公司也都会考。建议大家平时有空的时候多刷刷leetcode。算法的准备时间比较长，是一个长期的过程。需要在掌握了大部分前端基础知识的情况下，再有针对性的去复习算法。面试的时候算法能做出来肯定加分，但做不出来也不会一票否决，面试官也会给你提供一些思路。