第4章 核心架构组件

第 4 章 · 核心架构组件

章节摘要：本章拆解 gRPC 框架自身的骨架：分层架构全景（从业务代码到传输层的七个层次）、客户端三件套（Channel、Stub、Call）的职责与生命周期、服务端的 Server 与并发线程模型（同步与流式两条路径）。读完本章，你能解释"一个调用在框架内部经历了什么"，并为第 5 章的治理机制找到挂载点。

你能学到什么

阅读完本章，你应当能够：

1. 画出 gRPC 客户端与服务端的分层结构并说明各层职责；
2. 说清 Channel、Stub、Call 三个对象的生命周期与线程安全边界；
3. 解释服务端同步模型与流式模型的并发差异；
4. 判断一个性能问题该在哪一层定位与解决；
5. 正确管理 Channel 的创建、复用与关闭。

核心概念速览

一句话点题：Channel 是连接与策略的容器，Stub 是方法的代理，Call 是一次调用的全部状态——三者寿命从长到短，职责从重到轻。

子章节导航

4.1 分层架构与客户端三件套

从全景分层切入，重点拆客户端：Channel 如何管理连接与负载均衡、Stub 如何从 proto 生成、Call 如何承载一次调用的状态与控制（取消、超时、元数据）。给出 Channel 的工程管理规范（共享复用、优雅关闭、目标寻址格式）。这一节回答一个高频实践问题：客户端对象到底该怎么建、建几个、放哪里。

4.2 服务端架构与并发线程模型

服务端的组件栈（传输、Server、服务注册、分发）与两条并发路径：一元调用的同步处理模型（线程或协程池承载）、流式调用的长占用模型（一个流一个执行流）。落到容量规划：如何用利特尔法则估算服务端并发单元的规模，以及优雅停机与各类上限的配置纪律。这一节是"服务能扛多少"这个问题的答案所在。

子章节之间的逻辑关系

两节分别覆盖一次调用在框架内的前半程与后半程：

[4.1 客户端三件套]           [4.2 服务端与并发]
   调用发起侧的分层     <-->     调用接收侧的分层
   Channel/Stub/Call              Server/分发/线程模型
        \\_____ 同一套拦截器概念贯穿两端 _____//
​

4.1 讲的 Channel 管理与 4.2 讲的线程模型，恰好是"连接两端容量规划"的一对：客户端侧别建太多 Channel，服务端侧别让并发单元失控。拦截器在两侧都出现，是第 5 章的主角，本章只定位它的挂载点。

前置知识与后续延伸

• 前置：第 3 章的流与连接概念（Channel 管理的就是 HTTP/2 连接）；任一语言的并发基础（线程、协程、池）。
• 为后续铺垫：本章的拦截器挂载点是第 5 章治理机制的载体；Channel 的负载均衡与解析器是第 5 章服务发现的知识入口；服务端并发模型是第 6 章性能调优容量估算的前提。

本章要防的一组混淆是 Stub、Channel、Call 的职责边界：新手最常见的错误是把三者当成一个东西（"客户端对象"），于是出现"每次调用建一个客户端"的反模式。记住寿命口诀——Channel 活得像应用、Stub 活得像服务、Call 活得像一次调用——三者的创建成本、共享边界、线程安全属性全部由此推导，不需要死记。

读本章时建议对照自己熟悉的 Web 框架找锚点：Channel 相当于数据库连接池、Server 相当于 Web 容器、拦截器相当于请求过滤器、Call 相当于一次请求的上下文对象。概念对齐之后，gRPC 的架构不是新知识，而是旧知识在新协议上的重排——这也是它能被快速上手的原因。

框架层的知识有个特点：不学也能把 demo 跑起来，学了才能解释为什么 demo 的做法上不了生产。本章正是"能跑"与"能用"之间的那一段。