web开发发展历程-前端、后端、消息队列、后端架构演进

hands_up_down

已于 2024-03-26 23:13:03 修改

阅读量1.3k

点赞数 10

文章标签：前端

于 2024-03-26 01:00:03 首次发布

本文链接： https://blog.csdn.net/hands_up_down/article/details/137022132

版权

摘要

在学习web开发时，面对的总是一个一个技术，这让我感觉很割裂，不踏实。因此，我想了解web开发的发展历程，通过不同历史时期技术上、需求上的变化，更好的把握核心。

视频来源

主要内容

web2.0：ajax。结束了网页只能整存整取的时代，允许网页实现局部刷新。增强了网页的交互性，逼近桌面应用。

移动互联网：2010年，随着智能手机的普及。

万物互联网：在移动互联网的基础上继续发展。元宇宙

前端技术的中间阶段-单页面应用

数据使用json格式进行传输，就是用一个json对象存储各项数据，客户端和服务端都有专门的用于解析json对象的工具。简单说，就是使用json统一了数据传输的格式

vue：既可以做前后端分离的项目，也可以应用于单页面应用，中庸之道

前后端分离

这个构建我倒是挺熟悉的，使用maven提供的构建命令将项目打包，上传到maven仓库，打包好的项目既可以部署，也可以被其他项目作为依赖引用

移动互联网前端：微信小程序

物联网智能设备：摄像头、智能家居。标准不统一，未来要统一通讯协议，就像互联网一样

网络安全：数字人民币，离线情况下也可以交易

异步非阻塞
比如HTTP服务器，对于这些服务器来说，它肯定服务的不只是一个人，它要服务很多人。如果按照同步的方法，那么服务器一次就要被一个客户端独占了。而在我们通常的使用场景中，一个客户端并不是时时刻刻都在向服务器发送请求，比如我们浏览网页的时候，我们点进去一个页面，get到服务器端返回来的页面以后，我们起码也要在这个页面上浏览好几秒钟才会再次向服务器发送请求跳转到下一个页面吧。如果服务器被一个客户端独占了，自然就没有办法响应其它客户端的请求。那肯定不行。怎么办呢？这时候就采用异步的方法。
所谓的同步和异步就好像是打电话和发邮件的区别。打电话得保证双方都得同时占线，而且双方打电话的时候就不能干其它事情了，如果电话那头话说得又非常慢，你还得耐着性子等着他说完。发邮件则不是，你给对方发邮件，对方空闲下来就会去看看邮箱，没有空的时候他就会忙他的事情。你也是，发完邮件以后你就去干自己的事情，不用像打电话一样必须等着对方说完才会去做自己的事情，这样能极大的提高对时间的利用效率。
这里也是，若HTTP服务器采用异步的方法，服务器就不会被一个客户端独占了。你向服务器发送请求，服务器不会马上响应你，而是会等到它忙忘手中的事情才回来理你。这样的话服务器不会马上响应你的需求，影响大吗？得看你的实际需求，如果你是在浏览网页，可能基本上没什么影响，因为你并不是时时刻刻都会向服务器发起请求，而是隔三岔五的请求一下。而对于服务器来说，这样它就能同时服务很多客户端了，而不会被一个客户端长时间占线。

那我还有一个问题，后端服务器是如何实现异步的？？？？总不能是天生的吧

即时响应性，对用户有反应：
对用户有反应我们才说响应，一般我们说的响应，基本上都说得针对跟用户来交互。只要有可能，系统就会及时响应。

回弹性，对失败有反应：
应用失败了系统不能无动于衷，不能等着它挂掉，要有反应，使其具备可恢复性。可恢复性可以通过复制、监控、隔离和委派等方式实现。在可恢复性的系统中，故障被包含在每个组件中，各组件之间相互隔离，从而允许系统的某些部分出故障并且在不连累整个系统的前提下进行恢复。当某个模块出现问题时，需要将这个问题控制在一定范围内，这便需要使用隔绝的技术，避免雪崩等类似问题的发生。或是将出现故障部分的任务委托给其他模块。回弹性主要是系统对错误的容忍。

弹性，对容量和压力变化有反应：
在不同的工作负载下，系统保持响应。系统可以根据输入的工作负载，动态地增加或减少系统使用的资源。这意味着系统在设计上可以通过分片、复制等途径来动态申请系统资源并进行负载均衡，从而去中心化，避免节点瓶颈。如果没有状态的话，就进行水平扩展，如果存在状态，就使用分片技术，将数据分至不同的机器上。

消息驱动，对输入有反应：
响应系统的输入，也可以叫做消息驱动。反应式系统依赖异步消息传递机制，从而在组件之间建立边界，这些边界可以保证组件之间的松耦合、隔离性、位置透明性，还提供了以消息的形式把故障委派出去的手段。

回压：
Backpressure 其实是一种现象,在数据流从上游生产者向下游消费者传输的过程中，上游生产速度大于下游消费速度，导致下游的 Buffer 溢出，这种现象就叫做 Backpressure 出现。这句话的重点不在于”上游生产速度大于下游消费速度”，而在于”Buffer 溢出”。回压和 Buffer 是一对相生共存的概念，只有设置了 Buffer，才有回压出现；只要设置了 Buffer，一定存在出现回压的风险。

比如我们开发一个后端服务，有一个 Socket 不断地接收来自用户的请求来把用户需要的数据返回给用户。我们服务所能承受的同时访问用户数是有上限的，假设最多只能承受 10000 的并发，再多的话服务器就有当掉的风险了。对于超过 10000 的用户，程序会直接丢弃。那么对于这个案例 10000 就是我们设置的 Buffer，当超过 10000 的请求产生时，就造成了回压的产生；而我们程序的丢弃行为，就是对于回压的处理。

对于回压我们一般有两种处理方式，一种就是上面举例中的拒绝或丢弃，这是否定应答的方式，另一种是肯定应答，先收下来，然后再慢慢处理。

反应式编程的实现范式：
反应式编程的规范可以总结为4个接口Publisher，Subscriber，Subscription，Processor

Publisher负责生成数据，并将数据发送给Subscriber。一个Subscriber对应着一个Subscription。Subscriber可以使用Subscription来管理其订阅情况。

首先是Subscriber订阅Publisher。订阅成功以后，Subscriber就会得到一个Subscription对象。Subscription中有两个方法：request方法和cancel方法。

Subscriber得到一个Subscription对象以后，就可以调用该Subscription对象的request方法，请求Publisher发送数据给Subscriber。通过调用cancel方法就可以取消对Publisher的订阅。

Processor则是用来处理Publisher发送给Subscriber的数据。

消息队列发展史

来源
计算机和生活的一个小映射：
肌糖原类似于内存，脂肪类似于磁盘。锻炼首先消耗肌糖原，其次是燃烧脂肪。吃饭首先补充的也是肌糖原，然后多的部分才会累积成脂肪

分区：相当于扩建，比如原来只有面馆1，有多个分区后，就有面馆1，面馆2、面馆i。流量增加之后，就可以通过分区实现水平扩容

早期的消息队列：聚焦同步调用问题。系统之间层层调用导致时延很高，但是同时又要保证同步。于是考虑是否能将一些同步操作异步化

2010：流量持续增大，数据量持续增大。吞吐量，一致性

2012：线上交易兴起。对于数据一致性要求非常高，远远高于对大流量处理的要求。

2012之后：云计算开始兴起，开始考虑标准化，平台化，避免重复造轮子。同时，这个时期的消息队列，计算节点和存储节点在同一个节点上，不利于容器化，服务容器化要求服务没有状态。如果节点有数据，节点挂了之后需要恢复数据。很困难

kafka，rocketmq，pulsar

在共用一个磁盘条件下，topic越多，kafka效率越低

rocketmq：完全顺序写

为了利用磁盘顺序写更快的特性，将所有topic写到一个文件中

但代价就是，读，变得更加复杂了。需要在读取的时候，挑出相应的部分。这就意味着，需要记录额外的状态，记录同一个topic的起始位置和结束位置。增加了索引文件

PS：之前做计算机视觉项目的时候，中间结果要存到txt文件中，我当时就考虑过存多个文件还是一个文件，最后我选择存一个文件。首先需要设计好存储的格式，什么时候换行，什么时候加tab等等。然后读取的时候，需要根据存储的格式，编写相应的读取逻辑来解析存储文件。不得不说，确实，存的时候简单了，读取就变得麻烦

pulsar

计算节点和数据节点分层，服务层全部无状态，无数据，有利于容器化