控制面：不处理业务流量，但为配置买单

控制面是网格的中枢，它不终结任何一条业务请求，所有产品页面到评论服务到评分服务的调用都不经过它。它做的是三件事：把用户写的路由规则、分组规则翻译成代理能懂的配置；把 Kubernetes 里的服务、端点、Pod 变化收敛成推送事件；给每个 Sidecar 签发和轮换身份证书。

这三件事的资源消耗特征很特别。控制面的处理器占用主要在配置变更时发生——Pod 上下线、路由规则改动、证书轮转、服务端点变化，都会触发它重新计算受影响代理的配置并推送。在 bookinfo 稳定运行、不做灰度切换时，控制面几乎空闲，处理器占用可忽略；但当你频繁改 VirtualService 权重、频繁扩缩 reviews 三个版本的副本，控制面就会周期性地忙起来。内存占用则和网格规模正相关：它要把全网格的服务模型、端点表、生成的配置缓存放在内存里，服务数和 Pod 数越多，这块内存越大。

天翼云托管网格的好处是控制面资源由平台侧承担，用户不需要给 istiod 设 requests 和 limits，也不承担它 OOM 的风险。但理解它的开销驱动仍然重要：你在本命名空间里每多建一个服务、每多一次配置变更，都会变成控制面的一部分工作量。bookinfo 四个服务、几个子集、几条路由，对控制面是蚊子腿；但如果你在同一个网格里塞进几十个 bookinfo 副本命名空间，控制面的推送频率和内存就会明显上升。

数据面：每个 Pod 都多出一个常驻进程

数据面开销是 bookinfo 资源账目的主体。每个被注入的 Pod 里多出一个代理容器，它常驻、随 Pod 生命周期启动和退出，空闲时也有基线消耗，有流量时随请求速率上升。

代理的空闲基线来自几部分：自身二进制和配置结构的常驻内存、与控制面保持的長连接、统计指标缓冲区、证书缓存、监听器与集群表的静态结构。这部分在没有任何请求时也存在，可以理解为“为了随时能接管流量而预付的租金”。

有流量时的消耗则和请求速率、请求体大小、连接数、启用的功能（追踪、访问日志、重试、超时）正相关。代理在出入方向各拆包一次 HTTP 协议、做路由匹配、可能做重试和超时计时、把遥测数据写本地缓冲区，这些都是处理器周期。内存也会随活跃连接数和配置规模微微上浮。

bookinfo 里产品页面、评论、详情、评分四个服务若各跑一个 Pod，注入后就是四个业务容器加四个代理容器，节点上看到的是八个容器在吃资源。如果 reviews 开三个版本各一 Pod，那就是七个业务容器加七个代理容器。代理的空闲基线叠加起来，在单节点小规模集群里可能只占去一两成可用资源，不痛不痒；但乘以几百 Pod 时，就是一笔独立的、不属于业务本身的算力税。

bookinfo 的具体账目画像

把 bookinfo 默认部署（产品页面、详情、评论 v1/v2/v3、评分各一 Pod，全量注入）摆上桌面：七个业务 Pod 对应七个代理容器。控制面侧，托管组件稳稳睡着，偶尔在你改路由时醒一下。数据面侧，每个代理空闲时占用一部分内存和少量处理器，七个加起来是一笔固定税；当你用脚本刷产品页面接口制造流量时，七个代理的处理器占用随请求速率线性抬头，但绝对量仍小，因为单服务 QPS 不高、请求体是典型小文本。

这时候最容易忽略的隐性开销是配置范围。默认注入下，每个代理都会从控制面拿到全网格的服务发现视图——即便产品页面根本不调评分服务之外的东西，它的代理里也存着评分、详情、评论三套子集的集群与端点信息。bookinfo 规模小看不出问题，但这份“每个代理知道所有服务”的默认行为，正是大网格里单代理内存随规模膨胀的根因。天翼云网格提供的自适应配置分发或 Sidecar 可见性配置，本质就是把这份冗余砍掉：让产品页面的代理只认得它真的会访问的那几个服务，内存和推送体积都降下来。

另一个 bookinfo 特有的观察点是评论服务三个版本并存。v1 不调评分，v3 调评分，代理在处理评论出站时走的集群不同，但代理本身的内存结构差异不大，开销区别主要来自运行期请求是否多一跳。因此三个版本 Pod 的代理空闲基线几乎一样，差异在流量期才显现。

从 bookinfo 外推到生产规模

bookinfo 的价值不在于它自己多大，而在于它让开销结构可见，然后你可以按线性关系外推（注意控制面不是纯线性）。假设单代理空闲内存几十兆、空闲处理器几十毫核，流量期随 QPS 增加；那么一百个 Pod 的网格，数据面代理总开销就是几十核处理器与数吉字节内存的量级；几百个 Pod 时这笔开销已经足以影响节点调度，必须单独留资源池。控制面在托管场景下用户无感，但自建控制面时，它的内存随服务数和端点数走，处理器随变更频率走，大网格里给控制面留一吉字节以上内存是常态。

外推时有个非线性拐点：当网格大到一定程度，默认全量配置下发会让单代理内存随服务数而不是 Pod 数增长，这时候单 Pod 注入的代价不再只是“一个代理的基线”，而是“一个代理背负全网格服务模型的代价”。bookinfo 碰不到这个拐点，但它是理解拐点的起点——你看着七个代理各自安安静静，要能想象出千 Pod 时它们各自内存翻数倍的模样。

配置范围优化：把开销砍在源头

在 bookinfo 上就可以练手的两类优化，生产环境同样适用。

其一是限制代理的出口可见性。通过配置让产品页面只看到产品页面、评论、详情三个服务，评分服务若不被产品页面直连就从它的视图里剔除；让评论服务只看到评分服务。这样每个代理的配置体积缩小，控制面推送时也只推相关片段，内存和处理器都省。天翼云网格的自适应配置分发做的就是这件事，且能按实际调用自动收敛。

其二是收敛遥测粒度。代理默认开指标、可能开访问日志和追踪采样，每一层都在代理里占一点处理器和内存、在后端占存储。bookinfo 演示可以把访问日志关掉或只留错误级，追踪采样率调低，指标维度不追加自定义标签。这一项在大规模时比代理基线更影响总账，因为遥测是“每个代理都采、后端都收”的乘法效应。

其三是稳变更频率。控制面开销峰值在变更时，不要把路由权重调整写成每秒改一次的脚本。bookinfo 做灰度演示时，人工改几次无所谓；生产里若把权重抖动交给自动化且频率过高，控制面处理器会持续被占用，代理也频繁重配，数据面处理器随之波动。

排障视角：开销异常怎么定位

bookinfo 跑起来后若发现节点资源吃紧，按三层查。

先看是不是注入范围过大：命名空间打了注入标签，但里面混入了不需要治理的 Job 或调试 Pod，它们也带代理，白吃基线。用标签把真正需要网格的服务隔离出来。

再看代理配置体积：进某个代理容器看配置摘要大小，或看控制面推送的端点数，若产品页面代理里出现了几十个无关服务，就是可见性没收敛。

最后看流量形状：评论服务 v3 若被压测脚本狂打，它的代理处理器占用会明显比 v1 高，这不是泄漏也不是 bug，是代理在认真干活。区分“基线税”和“流量期劳动”很重要，前者靠限制注入和可见性优化，后者只能靠给节点留余量或升级实例规格。

控制面若自建，观察推送频率和收敛时间两个指标：推送频繁且收敛慢，说明变更多或控制面处理器不够；内存持续涨不落，说明服务模型或缓存没释放，可能要调控制面副本数。

结语

bookinfo 在分析控制面与数据面资源开销时，是一面缩小镜：它把“每个 Pod 多一个常驻代理”的基线税、“控制面不为流量买单只为配置买单”的分工、“配置范围决定代理内存”的隐藏杠杆，全部浓缩成七个或八个 Pod 就能看懂的账目。在天翼云应用服务网格上跑它，控制面资源被平台托底，数据面开销则诚实落在你的节点上——这笔开销不是惩罚，而是换来了无侵入治理、统一遥测、细粒度路由的能力。开发工程师要做的不是被开销吓退，也不是假装它不存在，而是像看 bookinfo 里红星星黑星星那样，把资源面板上的每条曲线和具体机制对上号：哪段是代理基线，哪段是控制面推送，哪段是遥测采样，哪段是 reviews v3 多调一次评分的代价。对账清楚，网格才既不是黑盒也不是奢侈品。