**在Node.js中，有三种I/O模型：BIO（Blocking I/O）、NIO（Non-blocking I/O）和AIO（Asynchronous I/O）。这些I/O模型有不同的实现方式和特点，适用于不同的应用场景。了解它们的区别和优缺点，对于我们编写高性能、高并发的Node.js应用程序非常重要。在本文中，我们将深入讲解Node.js中的这三种I/O模型，包括它们的定义、工作原理、适用场景、优缺点。**




# 基本概念

IO模型就是说用什么样的通道进行数据的发送和接收，Java 共支持3中网络变成 IO 模式：BIO、NIO、AIO。Java 中的 BIO、NIO 和 AIO 理解为是 Java 语言对操作系统的各种 IO 模型的封装。我们在使用这些 API 的时候，不需要关系操作系统层面的知识，也不需要根据不同操作系统编写不同的代码。


在讲 BIO、NIO、AIO 之前先回顾几个概念：同步与异步、阻塞与非阻塞、I/O模型。

### 同步与异步

- **同步：同步就是发起一个调用后，被调用者未处理完请求之前，调用不返回。**
- **异步：异步就是发一个调用后，立刻得到被调用者的回应表示已接收到请求，但是被调用者并没有返回结果，此时可以处理其他的请求，被调用者通常依靠事件、回调等机制来通知调用者其返回结果。**

> 同步和异步的区别最大在于异步的话调用者不需要等待结果处理，被调用者会通过回调等机制来通知调用者返回结果。
> 

### 阻塞和非阻塞

- **阻塞：阻塞就是发起一个请求，调用者一直等待请求结果返回，也就是当前线程会被挂起，无法从事其他任务，只有当条件就绪才能继续。**
- **非阻塞：非阻塞就是发起一个请求，调用者不用一直等着结果返回，可以先去干其他的事情。**

### 常见的 I/O 模型对比

所有的系统 I/O 都分为两个阶段：等待就绪 和 操作。

举例来说，读函数，分为等待系统可读和真正的读；同理，写函数分为等待网卡可以写和真正的写。

需要说明的是等待就绪的阻塞是不使用 CPU 的，是在“空等”；而真正的读操作的阻塞是使用 CPU 的，真正在“干活”，而且这个过程非常快，属于 memory copy，带宽通常在 1GB/s 级别以上，可以理解为基本不耗时。

如下几种常见 I/O 模型的对比：

[https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjU71A8l9b4J4MxvicXVh9YjUQ0tq4eqMGcKhEM2LFyme0bpv5othQXEYg/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1](https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjU71A8l9b4J4MxvicXVh9YjUQ0tq4eqMGcKhEM2LFyme0bpv5othQXEYg/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)

**以socket.read()为例子**：

- **传统的BIO里面socket.read()，如果TCP RecvBuffer里没有数据，函数会一直阻塞，直到收到数据，返回读到的数据。**
- **对于NIO，如果TCP RecvBuffer有数据，就把数据从网卡读到内存，并且返回给用户；反之则直接返回0，永远不会阻塞。**
- **AIO(Async I/O)里面会更进一步：不但等待就绪是非阻塞的，就连数据从网卡到内存的过程也是异步的。**

换句话说，BIO里用户最关心“我要读”，NIO里用户最关心"我可以读了"，在AIO模型里用户更需要关注的是“读完了”。

> NIO一个重要的特点是：socket主要的读、写、注册和接收函数，在等待就绪阶段都是非阻塞的，真正的I/O操作是同步阻塞的（消耗CPU但性能非常高）。
> 

# BIO（Blocking I/O）

同步阻塞 I/O 模式，数据的读取写入必须阻塞在一个线程内等待其完成（一个客户端连接对于一个处理线程）。

### **传统 BIO**

BIO通信（一请求一应答）模型图如下(图源网络)：

[https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUYswQUd4ozJiaRLhP9pBS6J1s7hVrO2lLXkXb4y2UNDeLeGt4zL3kvlA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1](https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUYswQUd4ozJiaRLhP9pBS6J1s7hVrO2lLXkXb4y2UNDeLeGt4zL3kvlA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)

采用 **BIO 通信模型** 的服务队，通常由一个独立的 `Acceptor` 线程负责监听客户端的连接。我们一般通过在 `while(true)` 循环中服务端会调用 `accept()` 方法等待客户端连接的方式监听请求，请求一旦接收到一个连接请求，就可以建立通信套接字在这个通信套接字上进行读写操作，此时不能再接收其他客户端连接请求，只能等待当前连接的客户端的操作执行完成，不过可以通过多线程来支持多个客户端的连接，如上图所示。

如果要让 **BIO 通信模型** 能够同时处理多个客户端的请求，就必须使用多线程（要原因是 `socket.accept()`、 `socket.read()`、 `socket.write()` 涉及的三个主要函数都是同步阻塞的），当一个连接在处理 I/O 的时候，系统是阻塞的，如果是单线程的必然就挂死在哪里。开启多线程，就可以让CPU去处理更多的事情。也就是说它在接收到客户端连接请求之后为每个客户端创建一个新的线程进行链路处理，处理完成之后，通过输出流返回给客户端，线程销毁。这就是典型的 **一请求一应答通信模型**。

其实这也是所有使用多线程的本质：

- **利用多核**
- **当 I/O 阻塞系统，但 CPU 空闲的时候，可以利用多线程使用 CPU 资源。**

> 我们可以设想以下如果连接不做任何的事情的话就会造成不必要的线程开销，不过可以通过 线程池机制 改善，线程池还可以让线程的创建和回收成本相对较低。例如使用FixedTreadPool 可以有效的控制来线程的最大数量，保证来系统有限的资源的控制，实现了N（客户端请求数量）：M（处理客户端请求的线程数量）的伪异步I/O模型（N可以远远大于M）。
> 

> 我们再设想以下当客户端并发访问量增加后这种模型会出什么问题？ 随着并发访问量增加会导致线程数急剧膨胀可能会导致线程堆栈溢出、创建新线程失败等问题，最终导致进程宕机或者僵死，不能对外提供服务。
> 

### **缺点**

1. **IO 代码里 `read` 操作是阻塞操作，如果连接不做数据读写操作会导致线程阻塞，浪费资源；**
2. **如果线程很多，会导致服务器线程太多，压力太大。**

### **应用场景**

BIO 方式适用于连接数目比较小且固定的架构，这种方式对服务器资源要求比较高，但程序简单理解。

[https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUzVFKibbJKQcm9KFvDibhXHl23532sttF5YCsPIS42YzPopibotficgy1LA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1](https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUzVFKibbJKQcm9KFvDibhXHl23532sttF5YCsPIS42YzPopibotficgy1LA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)

# NIO（Non Blocking IO）

同步非阻塞，服务器实现模式为一个线程可以处理多个请求（连接），客户端发送的连接请求都会注册到 **多路复用器 selector** 上，多路复用器轮询到连接有 IO 请求就进行处理。

它支持面向缓冲的，基于通道的I/O操作方法。NIO提供了与传统BIO模型中的 `Socket` 和 `ServerSocket` 相对应的 `SocketChannel` 和 `ServerSocketChannel` 两种不同的套接字通道实现，两种通道都支持阻塞和非阻塞两种模式。

- **阻塞模式使用就像传统中的支持一样，比较简单，但是性能和可靠性都不好；**
- **非阻塞模式正好与之相反。**

> 对于低负载、低并发的应用程序，可以使用同步阻塞I/O来提升开发速率和更好的维护性； 对于高负载、高并发的（网络）应用，应使用 NIO 的非阻塞模式来开发。
> 

### **NIO核心组件**

NIO 有三大核心组件：

- **Channel（通道）**
- **Buffer（缓冲区）**
- **Selector（选择器）**

整个NIO体系包含的类远远不止这三个，只能说这三个是NIO体系的“核心API”。

[https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUzo9tBvUbAWmARt1Fq01PbZruZht5Gaico6y0iaD5Hf0THmqqLHhlv8IA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1](https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUzo9tBvUbAWmARt1Fq01PbZruZht5Gaico6y0iaD5Hf0THmqqLHhlv8IA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)

1. **channel 类似于流，每个 channel 对应一个 buffer 缓冲区，buffer 底层就是个数组；**
2. **channel 会注册到 selector 上，由 selector 根据 channel 读写事件的发生将其交由某个空闲的线程处理；**
3. **selector 可以对应一个或多个线程**
4. **NIO 的 Buffer 和 channel 既可以读也可以写**

### **NIO的特性**

我们从一个问题来总结：**NIO 与 IO 的区别**？

如果是在面试中来回答这个问题，我觉得首先肯定要从 NIO 流是非阻塞 IO，而 IO 流是阻塞 IO说起。然后可以从 NIO 的3个核心组件/特性为 NIO 带来的一些改进来分析。

### **IO流是阻塞的，NIO流不是阻塞的**

Java NIO 使我们可以进行非阻塞 IO 操作。比如说，单线程中从通道读取数据到 buffer，同时可以继续做别的事情，当数据读取到 buffer 中后，线程再继续处理数据。写数据也是一样的。另外，非阻塞写也是日常，一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。

Java IO 的各种流是阻塞的，这意味这，当一个线程调用 read() 或 write() 时，该线程被阻塞，直到有一些数据被读取或数据完全写入。该线程在此期间不能再干任何事情了。

### **IO 面向流（Stream oriented），NIO 面向缓冲区（Buffer oriented）**

**Buffer（缓冲区）**

Buffer 是一个对象，它包含一些要写入或者要读出的数据。在 NIO 类库中加入 Buffer对象，体现了新库与原库 I/O的一个重要区别：

- **在面向流的 I/O 中，可以直接将数据写入或者将数据直接读到 Stream 对象中。虽然 Stream 中也有 Buffer 开通的扩展类，但只是流的包装类，还从流读到缓冲区。**
- **NIO 是直接读到 Buffer 中进行操作。在 NIO 库中，所有的数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的；在写入数据时，写入到缓存中。任何时候访问 NIO 中的数据，都是通过缓冲区进行操作。**

> 最常用的缓冲区是 ByteBuffer，ByteBuffer 提供流一组功能用于操作 byte 数组。除了 ByteBuffer 还有其他的一些缓冲区，事实上，每一种 Java 基本类型（除了 Boolean 类型）都对应有一种缓冲区。
> 

### **NIO 通过 Channel（通道）进行读写**

**Channel（通道）**

通道是双向的，可读也可以写，而流的读写是单向的。无论读写，通道只能和 Buffer 交互。因为 Buffer，通道可以异步地读写。

### **NIO 有选择器，而 IO 没有**

**Selectors（选择器）**

选择器用于使用单线程处理多个通道。因此，它需要较少的线程来处理这些通道。线程之间的切换对于操作系统来说是昂贵的。因此，为了提供系统效率选择器是有用的。

### **NIO 读数据和写数据**

通常来说 NIO 中的所有 IO 都是从 Channel（通道）开始的。

- **从通道进行数据读取：创建一个缓冲区，然后请求通道读取数据；**
- **从通道进行数据写入：创建一个缓冲区，填充数据，并要求通道写入数据。**

数据读取和写入操作如下：

[https://mmbiz.qpic.cn/mmbiz_jpg/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUlexhrYibDtlno5kQhaRYD9mXrJ0hPrVzFh8oNgROlWPQ9od9DYQ0CEg/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1](https://mmbiz.qpic.cn/mmbiz_jpg/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUlexhrYibDtlno5kQhaRYD9mXrJ0hPrVzFh8oNgROlWPQ9od9DYQ0CEg/640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)

### **应用场景**

NIO 方式适用于连接数目多且连接比较短（轻操作）的架构，比如聊天服务器、弹幕系统、服务器间通讯、编程比较复杂。

[https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUEzOAgBicF9XBQOYLILtYVktZjtRBJdicggO4Y5mz4ibwFIjDCPd8Fa7dA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1](https://mmbiz.qpic.cn/mmbiz_png/x0aJCHEALOWFY8mMbsZ10A3HCohYKWjUEzOAgBicF9XBQOYLILtYVktZjtRBJdicggO4Y5mz4ibwFIjDCPd8Fa7dA/640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1)

### **总结**

NIO 模型的 selector 就像一个大总管，负责监听各种 I/O 事件，然后转交给后端线程去处理。

NIO 相对于 BIO 非阻塞的体现就在：BIO 的后端线程需要阻塞等待客户端写数据（比如 read 方法），如果客户端不写数据线程就要阻塞。

NIO 把等到客户端操作的时候交给了大总管 selector ，selector 负责轮询所有已注册的客户端，发现有事件发生了才转交给后端线程处理，后端线程不需要做任何阻塞等待，直接处理客户端事件的数据即可，处理完马上结束，或返回线程池供其他客户端事件继续使用。还有就是 channel 的读写是非阻塞的。

> Redis 就是典型的 NIO 线程模型，selector 收集所有的事件并且转给后端线程，线程连续执行所有事件命令并将结果写回客户端。
> 

# AIO（Asynchronous I/O）

异步非阻塞， 由操作系统完成后回调通知服务端程序启动线程去处理， 一般适用于连接数较多且连接时间较长的应用。

AIO 也就是 NIO 2。在 Java 7 中引入了 NIO 的改进版 NIO 2,它是异步非阻塞的IO模型。异步 IO 是基于事件和回调机制实现的，也就是应用操作之后会直接返回，不会堵塞在那里，当后台处理完成，操作系统会通知相应的线程进行后续的操作。

> AIO 是异步IO的缩写，虽然 NIO 在网络操作中，提供了非阻塞的方法，但是 NIO 的 IO 行为还是同步的。对于 NIO 来说，我们的业务线程是在 IO 操作准备好时，得到通知，接着就由这个线程自行进行 IO 操作，IO操作本身是同步的。（除了 AIO 其他的 IO 类型都是同步的）
> 

### **应用场景**

AIO 方式适用于连接数目多且连接比较长（重操作）的架构。

# 参考
[BIO 、NIO 、AIO 总结](https://mp.weixin.qq.com/s/7DrH3vdl0xVJp97Q-fjTAA)

BIO、NIO、AIO

**SaaS（Software as a Service）是一种云计算模式，指的是将软件以服务的形式提供给用户，用户可以通过互联网访问和使用该软件。随着云计算和大数据技术的发展，SaaS模式在企业应用中得到了越来越广泛的应用。在这种模式下，企业可以将自己的业务系统、服务或应用程序放到云上，让用户通过互联网访问和使用，从而实现快速部署、灵活扩展、成本节约等优势。**



# SaaS模式

SaaS的一个比较正式的定义：SaaS（Software as a Service，软件即服务）是云计算的服务形式之一，即通过互联网为用户提供应用程序。服务提供商将应用程序统一部署在服务器上，用户根据实际需要向服务提供商订购及支付费用，并通过互联网最终获得服务。

传统的软件买卖模式和超市里的任何商品一样，一手交钱一手交货，成交后商品完全属于买方，可使用任意时长、任意次数。而SaaS有点类似于租车，想用车，不一定要自己买一辆，从租车公司租一辆就好。客户不拥有这辆车的所有权，只是付出租金获得一定时限的使用权。

也类似于租房，用房租获得使用权。
前面谈到的租车和租房两个例子，其实代表了两种典型的场景：

1.租车——需要的商品并不是时时刻刻都需要使用，完全拥有这件商品其实意味着大多数时候是闲置的。按使用量付费完全可以节约成本。

2.租房——这种商品是一直需要的，只是太过昂贵，如果没有足够财力，无法承担购买的一次性费用。租用就成了一种细水长流的模式。

对应到软件的世界里，

百度网盘是SaaS

印象笔记是SaaS

processOn在线画图工具是SaaS

设计师爱用的蓝湖是SaaS

公司现在的企业邮箱用的腾讯邮箱也是SaaS

短信服务

ZOOM视频会议

。。。。。。

太多太多，不一而足。根据业务特点不同，会采取按用量付费、按月付费、按年付费等等模式。

# SaaS有什么优势？
从购买方的角度来讲，SaaS带来的好处：

1. 大大减少现金流压力，一次性买断的费用变成了按月付费或者按年付费；在不需要使用的阶段，甚至可以选择暂时不续费

2. 在有续费压力的情况下，供应商会主动努力提供优质服务

3. 服务不到位的情况下可选择到期更换供应商，避免了绑死一家供应商，降低试错成本

4. SaaS持续无感知的更新模式，使得购买方可以及时享受到最新、最完善的服务

我认为其中优点1是最能打动客户的点，也是SaaS模式可以成功的最最重要的因素。

举例来说，我个人自用的印象笔记，每年100左右的费用，年年续费，可能会用5年、10年、20年、30年。。。。但是如果让我一次性买断软件终身使用，这个定价会是1000？2000？我还能像第一次下单100块那样爽快吗？恐怕就会放弃这个软件。

放到企业身上也类似，假设一套OA系统买断价80w，小企业直接就放弃购买了，大中企业就算打算购买也是一笔较大费用，需要谨慎的挑选供应商和走公司内的管理流程。但是SaaS化运营的OA系统第一年的费用可能是10～15w，这样小企业就有可能购买，中大企业对于这种低成本的采购也可以快速决策。如果企业的存活时期长，十年以后，续费的收入可能已经超过买断价80w，因此对于卖方来讲，这也是好的生意模式。

而从售卖方来讲，SaaS模式的好处是：

1. 首期费用与买断费用相比大幅度降低，财力有限的客户从买不起变成买得起，极大的扩展的客户范围

2. SaaS用户共享一套生产环境，大大降低了运维的成本

3. 客户群体的扩大有利于形成标准化的产品，减少开发成本，增加边际效用

4. 持续获得用户使用反馈，有利于产品的持续改进

5. 续费的模式使得公司可以保持稳定的现金流，可以活下去

综上，SaaS模式的本质是续费。资本市场在评估SaaS公司的估值时，会充分考虑其续费带来现金流。

# 为什么说SaaS的核心在于续费？
传统上，企业需要购买自建的数据库系统，但现在他们也可以直接购买SaaS服务。数据库SaaS不仅可以解决传统数据库在安全性、可扩展性、易用性等方面的痛点，还可以帮助企业全面提升智能化、精细化的运维能力。

可以看出，SaaS正在成为云计算的重要赛道。目前，国内SaaS销售额约占整个云计算市场的30%，而在欧美市场，这一比例接近60%。SaaS赛道的想象空间非常大，进入者越来越多。2020年，中国有40家估值超过2亿美元的SaaS公司。到2021年，已有近80家SaaS公司。

国内的SaaS玩家大致可以分为三类:

第一类是像腾讯云和阿里云这样的大家伙，他们正在布局自己的SaaS生态系统。

第二类是独立玩家，包括为企业提供一般SaaS服务的公司，如在线营销和电子签名。还包括各行业垂直领域的SaaS公司，如家装的酷家乐、建筑的广联达、房地产营销的明园云等。

第三类是像用友、金蝶、东软等公司。，也就是做SaaS改造。

传统软件是一次性购买，而SaaS是一种订阅费。更本质的区别是，传统软件是本地搭建的，而SaaS是云端搭建的；传统软件更加定制化，而SaaS更加标准化；传统软件无法获取客户数据，而SaaS可以通过积累客户大数据为客户提供数据增值服务，等等。

有趣的是，“SaaS的本质是更新”。正是“续费”的商业模式，决定了SaaS企业的服务模式和公司估值与传统软件企业完全不同。

比如传统软件实施部署后，经常会出现客户使用效果不佳，导致项目失败的情况。业界通常将这种情况归结于客户需求的快速变化或者客户组织内部执行力差。吴昊老师认为，问题的根源其实是传统软件的买断式销售模式。

因为是一次性销售，所以销售时难免会有对客户的过度承诺，甚至给执行部门“挖坑”，导致后期执行一地鸡毛。实施后，没有人真正关心客户用得好不好，客户遇到问题，客服部门也是被动回应。反正取得了销售业绩，后续每年最多会有15%的服务费。能得到就能得到，不能得到也就算了。这是收费机制导致的问题，不是纪律或者个人责任可以完全消除的。

SaaS的订阅费可以改变这种情况。一套售价30万元的传统企业软件，如果变成SaaS产品，可以报价10万元年费。签订合同并实施部署后，客户成功部门将接管客户，成功部门的业绩来源于客户的续费。

所以客户成功部的目标只有一个:想办法让客户用好软件，让客户明年才续费。如果客户在使用中出现大问题，客户成功部门甚至会重做需求调研，进行二次实施，这一切都是为了留住客户的体验。

不同的收费机制使得两类公司的估值标准完全不同。成熟的SaaS公司的客户续签率可以达到90%，而中国的SaaS公司达不到这个水平。续约率低于70%的SaaS公司是没有价值的，只能按照传统软件公司来估值，而不是按照SaaS公司销售额的10倍来估值。

如果一家SaaS公司的续保率低于60%，就说明出了问题，一定要非常警惕。要么是产品本身有问题，要么是客户成功部的服务没有做好，要么是销售部门根本找错了客户。简而言之，续保率是反映SaaS公司业务健康程度的最重要指标。

为了让反馈更加敏捷，SaaS公司可以设置退款条件，即客户在实施和部署后的一定期限内如果不满意，可以申请退款。如果没有退款机制，客户认为“大不了明年不续签”，问题得不到解决只能自己承担。也就是说，公司可能要等一年才能发现问题的严重性。退款机制可以立即引起公司的重视，迫使所有部门发现产品和服务的问题并立即改进。

# 参考
[关于产品SaaS化的一点思考](https://www.jianshu.com/p/07003a378c4c)
[为什么说“SaaS的本质是续费”？](https://zhuanlan.zhihu.com/p/467442476)

关于 SaaS 化的思考

**在前端开发中，webpack-dev-server是一个非常常用的工具，它可以为我们提供热更新的功能，使得开发变得更加高效。那么，webpack-dev-server是如何实现热更新的呢？**

**在本文中，我们将深入探讨webpack-dev-server的热更新原理。我们将介绍热更新的概念、如何在webpack-dev-server中启用热更新、热更新的工作原理以及如何使用热更新提高前端开发效率。无论您是初学者还是有一定经验的前端工程师，本文都将为您提供有价值的信息。**



# 双向通讯机制

`webpack-dev-server`启动时，会先启动本地静态资源服务，然后在启动`websocket`服务，

`websocket`服务此时会和本地静态资源服务建立连接，

接着在`webpack entry`里面加入本地服务和`websocket`通讯的相关代码

```jsx
// 修改后的entry入口
// 在入口新增两个文件，就会一起打包到bundle文件中去，在线上运行。
{
  entry: {
    main: [
      // 上面获取的clientEntry
      'xxx/node_modules/webpack-dev-server/client/index.js?http://localhost:8080',
      // 上面获取的hotEntry
      'xxx/node_modules/webpack/hot/dev-server.js',
      // 开发配置的入口
      './src/main.js'
    ]
  }
}

```

这样就实现了双向通讯机制

# webpack监听文件变化

```jsx
webpack-dev-server：负责启动服务和前置准备工作
webpack-dev-middleware：负责本地文件的编译和输出以及监听。
```

当`webpack-dev-middleware`监听到文件发生变化时，就会给浏览器发送ok和hash事件

还记得我们上面说的修改entry入口么？ 这个文件会被打包到bundle.js中，并运行在浏览器中。

`xxx/node_modules/webpack-dev-server/client/index.js?[http://localhost:8080](https://link.juejin.cn/?target=http%3A%2F%2Flocalhost%3A8080)`

看一下这个核心代码：

```jsx
// webpack-dev-server/client/index.js
var socket = require('./socket');
var onSocketMessage = {
  hash: function hash(_hash) {
    // 更新currentHash值
    status.currentHash = _hash;
  },
  ...
  ...
  ok: function ok() {
    sendMessage('Ok');
    // 进行更新检查等操作
    reloadApp(options, status);
  },
}

socket(socketUrl, onSocketMessage);

// webpack-dev-server/client/util/reloadApp.js
function reloadApp() {
	if (hot) {
    log.info('[WDS] App hot update...');

    // hotEmitter其实就是EventEmitter的实例
    var hotEmitter = require('webpack/hot/emitter');
    hotEmitter.emit('webpackHotUpdate', currentHash);
  }
}
```

reloadApp()方法中，利用了`node.js`的`EventEmitter`，发出`webpackHotUpdate`消息，发出了这个消息之后，`webpack`接下来会做什么呢？

# 通知浏览器刷新

我们之前entry入口中，除了新增 `xxx/node_modules/webpack-dev-server/client/index.js?[http://localhost:8080](https://link.juejin.cn/?target=http%3A%2F%2Flocalhost%3A8080)`, 还有新增了一个文件：`xxx/node_modules/webpack/hot/dev-server.js`

那我们看看这个文件的内容：

```jsx
// node_modules/webpack/hot/dev-server.js
var check = function check() {
  module.hot.check(true)
    .then(function(updatedModules) {
    // 容错，直接刷新页面
    if (!updatedModules) {
      window.location.reload();
      return;
    }

    // 热更新结束，打印信息
    if (upToDate()) {
      log("info", "[HMR] App is up to date.");
    }
  })
  .catch(function(err) {
    window.location.reload();
  });
};

var hotEmitter = require("./emitter");
hotEmitter.on("webpackHotUpdate", function(currentHash) {
    lastHash = currentHash;
    check();
});
```

但是`module.hot.check`这个是来自哪里呢？他是来自`webpackConfig`的hot值

利用上一次保存的hash值，调用 `hotDownloadManifest` 发送 `xxx/hash-update.json`的ajax请求，调用`hotDownloadUpdateChunl` 发送 `xxx/hash.hot-update.js`请求（JSONP）

# hotApply 热更新模块替换

热更新的核心在 hotApply 这个函数中。具体做了：

- 删除过期的模块，就是需要替换的模块 （通过hotUpdate可以找到旧模块）

```jsx
var queue = outdatedModules.slice();
while (queue.length > 0) {
  moduleId = queue.pop();
  // 从缓存中删除过期的模块
  module = installedModules[moduleId];
  // 删除过期的依赖
  delete outdatedDependencies[moduleId];

  // 存储了被删掉的模块id，便于更新代码
  outdatedSelfAcceptedModules.push({
    module: moduleId
  });
}
复制代码
```

- 将新的模块添加到modules中

```jsx
appliedUpdate[moduleId] = hotUpdate[moduleId];
for (moduleId in appliedUpdate) {
  if (Object.prototype.hasOwnProperty.call(appliedUpdate, moduleId)) {
    modules[moduleId] = appliedUpdate[moduleId];
  }
}
复制代码
```

- 通过__webpack_require__执行相关模块的代码

```jsx
for (i = 0; i < outdatedSelfAcceptedModules.length; i++) {
  var item = outdatedSelfAcceptedModules[i];
  moduleId = item.module;
  try {
    // 执行最新的代码
    __webpack_require__(moduleId);
  } catch (err) {
    // ...容错处理
  }
}
```

# 参考
[webpack 热更新原理](https://juejin.cn/post/7000933849152782366#heading-1)

Webpack-Dev-Server原理

前端基础知识复习

## **liveness** 活性探测

📚 Kubelet 使用活性探测来知道何时重新启动容器。例如，活性探测可能会捕捉到一个死锁，这时应用程序正在运行，但无法取得进展。在这种状态下重新启动容器有助于使应用程序更可用，尽管存在 bug。


## readiness 就绪探针

📚 Kubelet 使用准备好的探测来知道容器何时准备好开始接受流量。当所有的容器都准备好时，一个 Pod 就被认为是准备好了。此信号的一个用途是控制哪些 Pods 用作服务的后端。当一个 Pod 没有准备好时，它会从 Service 负载平衡器中移除。


## startup启动探针

📚 Kubelet 使用启动探测来知道容器应用程序何时启动。如果配置了这样的探测，它将禁用活性和准备状态检查，直到成功，以确保这些探测不会干扰应用程序的启动。这可以用来对缓慢启动的容器进行活性检查，避免它们在启动和运行之前被 kubelet 杀死。


liveness 活性探测