BobcGn's Notes

服务端引擎

24分钟阅读

0. 背景

服务端引擎是什么？

服务端引擎

在日常开发中，我们经常会接触到这些组合：

  • SpringBoot + Tomcat
  • Spring WebFlux + Netty
  • Ktor + Netty/Jetty/CIO
  • Go web/http

这些都是常用的后端框架与引擎。那么，这些框架下的 “引擎”，究竟是什么？ 从本质上来说，服务端引擎（Server Engine）是负责处理网络通信与请求调度的底层执行系统，它通常承担以下职责：

  • 管理 TCP 连接（建立、复用、关闭）
  • 处理 HTTP 协议（解析请求、构造响应）
  • 调度请求执行（线程、事件循环、协程）
  • 管理并发与资源（线程池、连接池、事件循环） 总而言之： 引擎 = 网络 I/O + 并发调度 + 协议处理

可以把服务端理解成下图：

graph TD
A[业务代码（Controller/Route）] --> B[服务端框架，如Spring、Ktor]
B --> C[服务端引擎（Netty、Tomcat、CIO）]
C --> D[操作系统（epoll、kqueue）]
  • 框架负责“怎么写业务”
  • 引擎负责“怎么处理请求”
  • 操作系统负责“怎么处理网络”

框架 VS 引擎

维度框架（Framework）引擎（Engine）
作用提供开发模型提供执行能力
关注点路由、依赖注入、业务组织网络、并发、调度
示例Spring、Ktor、Vertx等Netty、Jetty、CIO、Tomcat

注意

框架本身不处理网络，它依赖于背后的服务端引擎 而 Go 是一个特例，它通过语言 + runtime + 引擎一体化

为什么需要引擎？

引擎的必要性在哪里？

在刚入门时，我们会写 @RestController或者route()来处理请求。那么，就会有一个疑问：“我能够通过路由来进行请求，那引擎是否是一个可有可无的东西？” 答案是：完全错误！ 原因：

1. 网络通信本身非常复杂

一个看似简单的 HTTP 请求，背后包含了：

  • TCP 三次握手四次挥手
  • 粘包/半包处理
  • Keep-Alive
  • 超时控制
  • TLS 加密

如果没有引擎，用户需要手动处理上述问题

2. 并发模型极其复杂

服务端的核心不是“能否处理请求？”，而是如何高效处理成千上万的请求？ 不同引擎的核心差异就在这里：

  • Tomcat：线程池（一个请求一个线程）
  • Netty：事件循环（少量线程处理大量连接）
  • CIO：协程 + 非阻塞IO
  • Go：goroutine + runtime调度

这部分内容基本不可能靠业务逻辑实现

3. 性能优化需要大量工程积累

成熟的引擎内部通常包含：

  • 零拷贝（Zero Copy）
  • 内存池（Buffer Pool）
  • 批处理（Batching）
  • Native IO（epoll、kqueue）

因此，使用引擎并非仅是使用了一个库，而是使用了一个高度优化的网络系统

关键误区！

框架性能 ≠ 引擎性能

很多人会说：Spring 的性能 不如 Ktor 好 但是真实的原因是：性能的差异往往来源于 引擎 + 使用方式，而不是框架本身 例如：

  • Spring MVC + Tomcat → 偏传统阻塞模型
  • Spring WebFlux + Netty → 高并发能力显著提升 👉 同一个框架，不同引擎，性能表现完全不同

引擎决定一切性能？

虽然引擎很重要，但是在真实的系统中，引擎不是最大的瓶颈。 更常见的瓶颈在于：

  • 数据库访问
  • Json 序列化
  • 阻塞调用（IO、RPC）
  • 线程、协程使用不当
  • GC 压力

Go 比 JVM 更快是因为引擎更强？

这是一个非常常见但不准确的理解。 真实原因是：

  • Go：语言 + runtime + 调度器一体化
  • JVM：引擎只是库，运行时是 JVM 👉 所以： Go 的优势更多来自 调度模型 + 内存模型，而不仅仅是“引擎”

小结

服务端引擎是服务端系统的执行核心

  1. 引擎决定请求如何被处理
  2. 框架决定代码如何组织
  3. 性能取决于引擎 + 使用方式 + 业务模型

1. 服务端引擎本质与分类

概述

在理解具体引擎之前，我们必须理解一个底层问题： 服务端引擎的核心差异究竟在哪里？ 答案只有一个： 并发模型

三种核心并发模型

概述

所有的服务端引擎，都可以分为三类：

  • 阻塞模型
  • 事件驱动模型
  • 协程模型

这三类模型，决定了：

  • 请求如何被调度
  • 线程如何使用
  • 系统的并发上限

阻塞模型

介绍

核心思想

一个请求对应一个线程，这也是最直观、最早期的服务端模型

工作方式

请求1 → 线程1 → 执行 → 返回
请求2 → 线程2 → 执行 → 返回
请求3 → 线程3 → 执行 → 返回

每当得到一个请求：

  • 分配一个线程
  • 在线程中同步执行所有逻辑
  • 执行期间线程“被占用”

特点

  • 优点
    • 编程模型简单（同步代码）
    • 易于理解和调试
  • 缺点
    • 线程开销极大（内存+切换成本）
    • 并发能力受线程数量限制（阻塞模型的天然瓶颈）
    • IO 阻塞导致资源浪费

典型代表：

  • Tomcat
  • 早期 JavaWeb
  • 大量传统企业系统

事件驱动模型

介绍

核心思想

少量线程处理大量连接

工作方式

graph TD
A[事件循环线程] --> B[监听所有连接]
B --> C[一个线程处理多个连接]
  • 通过事件循环
  • 通过非阻塞IO
  • 一个线程可以处理多个连接

特点

  • 优点
    • 线程数量少
    • 并发能力强
    • 资源利用率高
  • 缺点
    • 编程模型复杂
    • 容易出现回调地狱（传统实现）
    • 不能随意阻塞

典型代表：

  • Netty
  • Jetty
  • Node.js

一个重要约束： 在事件循环中，任何阻塞操作都会拖垮整个线程

协程模型

介绍

核心思想

用“看起来同步”的代码，编写异步的流程

工作方式

请求1 → 协程1 → 挂起 → 恢复
请求2 → 协程2 → 挂起 → 恢复
  • 协程是轻量级并发抽象，最终仍运行在线程之上
  • 由语言运行时或协程库调度
  • 使用非阻塞挂起式 API 时，IO 等待会挂起协程而不是阻塞线程

特点

  • 优点
    • 写法接近同步
    • 高并发能力
    • 线程利用率高
  • 缺点
    • 强依赖 runtime（调度器）
    • Debug相对复杂
    • 不当使用可能阻塞线程

典型代表

  • goroutine
  • Kotlin + CIO
  • Kotlin + 协程（业务层）

三种模型对比

维度阻塞模型事件驱动协程模型
线程数量多少少
并发能力低高高
编码难度低高中
资源利用率低高高
典型引擎TomcatNettyGo / CIO

引擎 VS 运行时

这是很多人理解不到位的一个 关键点

JVM 世界

在 JVM 中：

  • Netty / Tomcat / CIO 仅是库
  • 线程调度由 JVM 控制
  • GC 由 JVM 控制

结构是：

graph TD
A[应用] --> B[引擎（Netty等）]
B --> C[JVM]
C --> D[操作系统（OS）]

Go 世界

在 Go 中：

  • 引擎（net/http）
  • 调度器（runtime）
  • 协程（goroutine）

结构是一体化设计：

graph TD
A[应用] --> B[Goroutine]
B --> C[OS]

本质差异

  • JVM：引擎只是组件
  • Go：引擎是系统的一部分

为什么这很重要？

  • Go 可以更轻量地调度任务
  • JVM 需要适配已有线程模型
  • Netty 再高性能，也会受到 JVM 的限制

本章小结

本章核心在于记住下列三点

  1. 服务端引擎的核心差异是并发模型
  • 不是 API，不是框架，而是请求如何被调度的
  1. 三种模型各有适用场景
  • 阻塞模型：简单但上限低
  • 事件驱动：高性能但复杂
  • 协程模型：平衡方案
  1. Go 与 JVM的本质区别在于 runtime
  • Go的优势在于语言级并发，而不是单纯的引擎性能高

2. 主流服务端引擎深度分析

在上一章，我们了解到， 服务端引擎的差异来源于并发模型。本章将把这个抽象的概念进行落地，详细分析五大主流服务端引擎：

  • Netty
  • Tomcat
  • Jetty
  • CIO
  • Go net/http 我们重点聚焦于：它们是如何处理API的

Netty

Netty详解

架构概览

Netty 是一个典型的事件驱动型框架，核心组件包括：

  • EventLoop（事件循环）
  • Channel（连接抽象）
  • Pipeline（责任链处理） 请求处理流程：
flowchart LR
   subgraph Group1 [第一步]
       A[连接建立] --> B[注册到 EventLoop]
   end

   subgraph Group2 [第二步]
       C[接收数据] --> D[Pipeline 处理]
   end

   subgraph Group3 [第三步]
       E[业务处理] --> F[写回响应]
   end

   Group1 --> Group2 --> Group3

线程模型

Netty 使用多EventLoop模型：

  • 每个 EventLoop 绑定一个线程
  • 一个线程可以处理多个连接
  • 连接一旦绑定，就无需频繁切换线程 特点：线程少、上下文切换少、吞吐量高

I/O 模型

  • 非阻塞 I/O
  • 支持 epoll/kqueue
  • 支持零拷贝

优点

  • 极高的并发能力
  • 成熟稳定（大量框架依赖）
  • 可扩展性强

缺点

  • 使用复杂（API偏底层）
  • 需要避免阻塞（否则会拖垮事件循环）

适用场景

  • 高并发
  • 网关（Gateway）
  • WebSocket/长连接
  • 微服务基础设施

Tomcat

Tomcat详解

架构概览

Tomcat 是一个 Servlet 容器，本质是：

  • Http 服务器 + Servlet规范实现 请求流程：
graph LR
	subgraph group1
		A[请求] --> B[Connector]
		B --> C[线程池]
	end
	subgraph group2
		D[Servlet] --> E[Filter]
		E --> F[Controller]
	end
	group1 --> group2

线程模型

典型为：线程池 + 每个请求对应一个线程 虽然现代 Tomcat 已经支持了 NIO，但是处理方式依旧偏向于：

  • 请求进入、分配线程
  • 执行期间线程被占用

IO模型

  • BIO（早期）
  • NIO（主流）
  • APR/Native（高性能模式）

优点

  • 非常成熟稳定
  • Servlet 生态完善
  • Spring 默认集成

缺点

  • 线程开销较大
  • 并发能力有限
  • 高负载下性能较弱

适用场景

  • 传统 Web 应用
  • 企业系统
  • Spring MVC项目

一句话总结

Tomcat 优先保证稳定性，而不是极限性能

Jetty

Jetty详解

架构概览

Jetty 是一个现代化异步 HTTP 服务器，强调完全异步 请求流程更接近事件驱动模型：

graph LR
	subgraph group1
		A[请求] --> B[Selector（监听）]
	end
	subgraph group2
		C[任务调度] --> D[Handler]
	end
	group1 --> group2

线程模型

Jetty 使用：

  • 少量的Selector线程（IO）
  • worker 线程池（任务输出）

IO模型

  • 非阻塞 IO
  • 支持 HTTP2 / HTTP3
  • 高性能连接处理

优点

  • 比 Tomcat 更现代
  • 异步支持更好
  • 高并发能力更强

缺点

  • 生态不如 Tomcat
  • 使用起来相对复杂

适用场景

  • 高并发 Web 服务
  • Http2 场景
  • 需要更高吞吐的 Servlet 系统

一句话总结

Jetty 是 Servlet 世界中更接近 Netty的选择

CIO

CIO详解

架构概览

CIO 是 Ktor 提供的协程驱动引擎：

  • 基于Kotlin Coroutine（协程）
  • 使用 Selector 处理 IO

线程模型

核心特点：协程 + 少量线程

  • 每一个请求是一个协程
  • 挂起时不占用线程
  • 调度由 Kotlin 协程库和引擎协作完成

IO模型

  • 非阻塞 IO
  • selector 机制
  • HTTP/2等高级协议能力通常不如Netty完整

优点

  • 与 Kotlin 协程天然契合
  • 编程模型简洁
  • 轻量

缺点

  • 功能不如 Netty 完整
  • 高级协议和生态能力相对有限
  • 生态成熟度较低

适用场景

  • 中小型服务
  • 内部系统
  • Ktor 轻量应用

一句话总结

CIO 是“最Kotlin的引擎”，但不是最强大的引擎

Go net/http

Go 引擎详解

架构概览

Go 的 net/http 并不是一个“库式引擎”，而是语言 + runtime + 网络系统的一体化实现 请求流程：

graph LR
	subgraph group1
		A[连接] --> B[goroutine]
	end
	subgraph group2
		C[handler] --> D[执行]
	end
	group1 --> group2 --> E[响应返回]

线程模型

  • goroutine（用户态线程）
  • M : N 调度模型 这使得一个线程可以使用成千上万个 goroutine

IO模型

  • 非阻塞 IO
  • runtime 调度 epoll/kqueue
  • 自动调度挂起/恢复

优点

  • 极高并发能力
  • 编程模型简单
  • runtime 优化深度高

缺点

  • 灵活度较低
  • GC 在极端场景下仍可能延迟

适用场景

  • 高并发API
  • 微服务
  • 网络服务

一句话总结

Go 的优势不仅在于引擎，更在于语言级别的并发系统

本章总结

引擎模型并发能力复杂度
Netty事件驱动极强高
Tomcat阻塞弱低
Jetty事件驱动较强中
CIO协程较强低
Go net/http协程极强低

3. 性能模型与对比

关键性能指标

性能不是一个单点数字

评价服务端引擎时，不能只看 QPS。一个系统的“快”，通常由以下几个指标共同决定：

  • 吞吐量（Throughput）：单位时间可以处理多少请求
  • 延迟（Latency）：单个请求从进入到返回需要多久
  • 尾延迟（P95/P99）：最慢的那一小部分请求有多慢
  • 并发连接数（Connections）：可以同时维持多少连接
  • 资源占用（CPU / Memory）：完成同样请求需要多少机器资源
  • 稳定性（Backpressure）：高压下是否能够限流、排队、拒绝，而不是整体崩溃

服务端引擎的性能分析图：

flowchart TD
    A[客户端请求] --> B[网络接入]
    B --> C[协议解析<br/>HTTP/TLS/WebSocket]
    C --> D[调度模型<br/>线程/事件循环/协程]
    D --> E[业务代码]
    E --> F[外部依赖<br/>DB/Redis/RPC/MQ]
    F --> G[序列化响应]
    G --> H[写回客户端]

    D --> I{是否阻塞?}
    I -->|是| J[线程/事件循环被占用<br/>吞吐下降]
    I -->|否| K[挂起或事件回调<br/>释放执行资源]

    F --> L{外部依赖是否慢?}
    L -->|是| M[尾延迟升高<br/>连接堆积]
    L -->|否| N[请求快速完成]

理论性能对比

不同模型的理论差异

模型连接处理方式请求执行方式优势主要风险
阻塞线程模型连接进入后分配工作线程同步执行直到返回易理解、调试简单线程数成为瓶颈
事件驱动模型少量 EventLoop 监听大量连接事件到来后回调处理高连接数、高吞吐不能阻塞事件循环
协程模型少量线程承载大量协程IO 挂起、完成后恢复写法接近同步，高并发需要正确区分阻塞与挂起

尾延迟比平均延迟更重要

对真实服务来说，平均耗时 20ms 但 P99 达到 2s，用户体验依然很差。 服务端引擎在高压下的核心价值，不只是“跑得快”，而是：

  • 请求不会无限排队
  • 慢请求不会拖死全部连接
  • 背压能及时传递到上游
  • 资源耗尽前可以限流、降级、拒绝

高并发接口的瓶颈定位

假如一个接口在压测中 QPS 上不去，可以按照下面的链路排查：

flowchart LR
    A[QPS 上不去] --> B{CPU 是否打满?}
    B -->|是| C[检查序列化<br/>业务计算<br/>GC]
    B -->|否| D{线程是否阻塞?}
    D -->|是| E[检查 DB/RPC/文件IO<br/>是否占用工作线程]
    D -->|否| F{连接是否堆积?}
    F -->|是| G[检查连接池<br/>限流<br/>超时配置]
    F -->|否| H{下游是否慢?}
    H -->|是| I[缓存/异步化/降级]
    H -->|否| J[检查压测方式和网络]

4. 工程实践与选型策略

选型决策树

实际项目怎么选？

服务端引擎不能只按“谁性能最高”选择，而要结合业务模型、团队经验、生态和维护成本。

flowchart TD
    A[新建服务] --> B{是否大量长连接?}
    B -->|是| C{团队是否熟悉事件驱动?}
    C -->|是| D[Netty / WebFlux / Ktor Netty]
    C -->|否| E[Ktor CIO / Go net/http]

    B -->|否| F{是否传统企业系统?}
    F -->|是| G[Spring MVC + Tomcat]
    F -->|否| H{是否 Kotlin 技术栈?}
    H -->|是| I[Ktor + CIO/Netty]
    H -->|否| J{是否追求简单部署和高并发?}
    J -->|是| K[Go net/http]
    J -->|否| L[Spring Boot 默认方案]

常见选择

  • 后台管理、CRUD、企业系统：Spring MVC + Tomcat 足够稳定
  • 网关、IM、推送、WebSocket：Netty 更合适
  • Kotlin 轻量服务：Ktor + CIO/Netty 都可以
  • 极简高并发 API：Go net/http 开发和部署成本低
  • 响应式链路完整：Spring WebFlux + Netty，前提是全链路避免阻塞

实际瓶颈分析

很多服务并不是引擎慢

在真实项目中，请求通常卡在这些地方：

  • 数据库慢查询
  • 连接池太小
  • Redis 大 Key 或热 Key
  • JSON 序列化和反序列化
  • 日志同步刷盘
  • 第三方接口超时
  • 阻塞调用放进 EventLoop 或协程默认调度器

阻塞调用放错位置

Netty / WebFlux / Ktor 这类模型里，最危险的问题是：在少量调度线程中执行阻塞任务。

sequenceDiagram
    participant Client as 客户端
    participant EL as EventLoop/协程调度线程
    participant DB as 慢数据库
    participant Other as 其他连接

    Client->>EL: 请求 A 到达
    EL->>DB: 同步慢查询
    Note over EL,DB: 调度线程被占用
    Other->>EL: 请求 B/C/D 到达
    EL-->>Other: 无法及时处理
    DB-->>EL: 查询返回
    EL-->>Client: 响应 A

正确做法：

  • 对阻塞 JDBC 使用独立线程池
  • 对协程使用 withContext(Dispatchers.IO)
  • 对响应式框架保持全链路 Reactive
  • 给所有外部依赖设置超时、重试和熔断

5. 总结与决策指南

最终结论

服务端引擎不是业务框架的替代品，而是业务框架背后的执行系统。 理解引擎，本质上是在理解一个请求从网络进入系统后，到底由谁接收、谁调度、谁执行、谁写回。

决策指南

目标推荐方向原因
快速开发企业应用Spring Boot + Tomcat生态成熟、排错资料多
高并发长连接Netty事件驱动，连接承载能力强
Kotlin 后端服务Ktor + CIO/Netty协程友好，代码简洁
轻量 API 服务Go net/httpruntime 与网络模型一体化
响应式系统WebFlux + Netty适合全链路非阻塞

最重要的工程原则

记住这几条

  1. 不要在 EventLoop 中执行阻塞操作
  2. 不要只用平均延迟评价性能
  3. 不要让请求无限排队，必须有超时和限流
  4. 不要把框架性能和引擎性能混为一谈
  5. 不要忽略数据库、缓存、消息队列这些真实瓶颈

一句话

框架决定写法，引擎决定执行模型，业务链路决定最终性能。

关系图谱