Day33-09｜14.3.4 服务网格：把微服务通信治理从业务代码中抽离

一、教材定位与学习目标

14.3.4“服务网格”是云原生微服务治理的重要技术。微服务数量增加后，认证、服务发现、负载均衡、超时、重试、熔断、流量切分、指标、日志和链路追踪等通信逻辑会重复出现在各个服务中。服务网格试图把这些横切能力交给基础设施层统一管理，使业务服务更多关注业务规则。

高级系统架构设计师考试不会只问服务网格的定义，还会考查它如何工作、解决什么问题、带来哪些成本，以及何时不应使用。理解服务网格要建立四个视角：数据面负责实际请求转发，控制面负责策略和配置，业务服务负责业务逻辑，平台负责安全、观测和生命周期治理。

二、服务网格的基本定义

服务网格是一种用于管理服务间通信的基础设施层，通常由部署在服务旁边的数据面代理和负责配置、策略、证书及服务发现的控制面组成。应用请求经过代理，由代理执行路由、负载均衡、安全认证、流量治理和遥测采集。

服务A → A侧代理 ⇄ B侧代理 ← 服务B
            ↑          ↑
            └── 控制面下发策略、证书和服务信息

服务网格主要解决的是东西向流量，即服务与服务之间的通信治理。用户到网关的南北向流量仍可能由 API 网关、WAF、负载均衡和入口控制器处理。两者可以配合，但职责不能混淆。

三、数据面与控制面

3.1 数据面

数据面由代理组成，部署方式可以是每个服务一个边车代理，也可以采用节点级代理或其他拓扑。代理负责接收和转发请求，执行路由、负载均衡、重试、熔断、认证、加密和指标采集。数据面处于请求实时路径，性能和稳定性直接影响业务。

3.2 控制面

控制面不直接转发每个请求，而是维护服务、实例、策略、证书和配置，并把经过验证的配置下发给代理。控制面故障时，数据面应尽量使用最近一次有效配置继续运行；否则控制面短暂不可用就可能导致全网通信中断。

四、服务发现与负载均衡

服务网格可以从注册中心或编排平台获得服务实例、地址、端口、版本和健康状态。代理根据路由策略选择实例，支持轮询、加权、最少连接、区域优先和一致性哈希等方式。

负载均衡策略必须结合业务特征。长连接适合考虑连接数量和连接持续时间，缓存命中可能需要一致性哈希，跨地域调用可以优先就近访问。服务发现信息需要及时更新，实例下线时应先摘除流量再终止，避免请求进入已关闭实例。

服务网格并不会自动解决服务容量问题。代理可能把流量均匀分发到一组已经过载的实例，也可能因为健康检查过于简单而把业务不可用实例判断为健康。因此，健康检查、资源指标和业务错误率应结合使用。

五、流量管理能力

5.1 路由与流量切分

服务网格可以根据请求头、用户、租户、地区、版本或权重选择服务实例，实现灰度、金丝雀和 A/B 测试。例如将 95% 流量发往稳定版本，5% 发往新版本，观察错误率和延迟后再逐步扩大。

流量切分必须有回退条件。新版本错误率、P95 延迟、业务成功率或资源消耗超过阈值时，应停止扩大流量并回滚。不能仅按时间自动放量，因为业务峰值和真实错误可能尚未出现。

5.2 超时与重试

代理可以统一设置超时和重试，但策略要尊重业务语义。读取请求在确认没有副作用时可以有限重试；创建订单、扣款和库存扣减等写请求必须有业务幂等才能重试。代理层应该传递截止时间，避免服务代码和代理各自等待造成总延迟失控。

5.3 熔断、限流和隔离

熔断器根据错误率、超时或并发情况暂时停止访问故障依赖；限流控制请求速率和并发；隔离把不同依赖或业务优先级分配到独立资源。策略要按接口和业务重要性配置，不能把所有服务使用同一阈值。

六、服务间安全与身份认证

在服务网格中，可以通过代理建立服务身份和加密通道，减少业务代码处理证书和加密细节。常见能力包括服务身份签发、双向认证、证书轮换、访问授权和策略审计。

但代理完成传输认证不等于完成业务授权。服务仍需根据用户、租户、资源和操作判断是否允许业务行为；代理不能理解订单所有权和审批规则。入口认证、服务身份和业务授权应分层设计。

安全策略需要遵循默认拒绝和最小权限。服务 A 只允许访问服务 B 的必要接口，不应因为位于同一集群就能访问全部服务；管理面与数据面分离；证书、密钥和策略变更需要审计；策略错误时应有验证、灰度和回滚机制。

七、可观测性

服务网格代理天然处在通信路径中，可以统一采集请求数、成功率、延迟、重试次数、熔断次数、流量版本和连接状态，并为请求注入追踪上下文。这样能够观察服务间的依赖关系和调用拓扑。

代理观测仍然有边界。它知道请求是否成功、耗时多少，却不一定知道业务为什么失败。例如 HTTP 200 但业务结果为库存不足，代理无法替代业务指标。需要把技术遥测与订单成功率、支付完成率、库存命中率等业务指标结合。

代理也会产生额外日志、指标和追踪数据。采样、留存和脱敏策略要合理，避免服务网格引入的观测量超过业务本身。生产排障要保留版本、租户、请求标识和依赖信息，但不能无差别记录敏感正文。

八、服务网格对应用的要求

服务网格能够统一通信治理，但应用仍需遵守基本契约：接口语义清晰、写操作幂等、错误码可区分、超时可接受、优雅关闭、健康检查正确、日志和追踪上下文不丢失。不能把所有可靠性责任推给代理。

例如代理设置了重试，但应用没有幂等键，重复请求仍可能造成重复扣款；代理实现了熔断，但应用没有降级页面，用户仍然只看到错误；代理收集了延迟，但服务内部慢查询没有指标，问题仍难定位。基础设施治理和应用治理必须共同设计。

九、服务网格的性能与运维代价

9.1 性能开销

请求经过额外代理会增加网络跳转、序列化、加密和资源消耗。每个服务一个代理还会增加 CPU、内存和连接数量。低延迟、高吞吐或资源非常紧张的场景，需要通过压测确定开销，并考虑节点级代理、内核加速或只在必要命名空间启用。

9.2 运维复杂度

服务网格增加了控制面、代理、策略、证书和版本管理对象。出现问题时要区分业务代码、代理、控制面、网络和依赖故障。升级策略需要灰度，控制面与数据面版本要兼容，策略必须经过校验和回滚验证。

9.3 调试复杂度

同一个请求可能在网关、多个代理和业务服务中留下日志。需要统一请求标识、版本和错误语义，并提供拓扑和配置查看能力。否则“治理统一”反而会让排障链路更长。

十、何时适合使用服务网格

服务网格更适合服务数量多、通信治理规则复杂、多个团队需要统一安全与观测标准、并且已有成熟容器平台和运维能力的系统。它可以减少每个服务重复实现通信治理的成本。

对于服务数量少、团队小、调用关系简单或延迟极其敏感的系统，直接使用应用库、网关和平台基础能力可能更简单。引入服务网格前要评估资源成本、人员能力、故障诊断、供应商绑定和收益是否真实。

十一、案例分析：金融风控平台引入服务网格

某金融风控平台包含用户、规则、评分、授信和审计服务，要求服务间通信加密，版本发布要灰度，发生局部故障时不能影响全部交易。现有服务各自实现重试、日志和认证，规则不一致，排障困难。

可以采用服务网格统一处理服务身份、加密、服务发现、路由、超时、有限重试、熔断和基础遥测；通过控制面管理策略和证书，通过数据面代理执行请求；按版本和租户进行灰度，并以风控决策成功率、延迟和错误率作为放量依据；对评分服务配置隔离和降级，评分不可用时按照业务规则决定拒绝、人工审核或使用缓存，不能由代理擅自放行；对授信和资金类写操作确保业务幂等，禁止仅因代理有重试就重复执行。

实施过程应先在非核心服务试点，进行代理资源和链路延迟压测，再逐步扩大；控制面和策略变更要可审计、可校验、可回滚；建立网格故障演练，包括控制面不可用、代理异常、证书过期、错误策略和网络分区。这样既获得统一治理，又控制引入的新风险。

十二、课后练习

练习一：选择题

服务网格中，负责实际请求转发和流量治理的主要是（ ）。

A. 数据库

B. 数据面代理

C. 业务控制器

D. 离线报表程序

答案：B。 数据面代理处于请求路径中，执行转发、负载均衡、安全、超时和遥测；控制面负责策略和配置管理。

练习二：简答题

为什么服务网格不能替代业务层的幂等和授权？

参考答案： 服务网格理解通信和基础治理，不理解订单、支付、库存和资源所有权等业务语义。代理可以重试请求，但只有业务层知道重复执行是否安全；代理可以验证服务身份，却不能判断某用户是否有权操作某订单。因此幂等、业务授权、状态机和事务规则仍由业务服务负责。

练习三：案例题

某团队引入服务网格后，服务间延迟上升、内存占用增加，出现策略配置错误导致部分服务无法访问。请提出治理方案。

参考答案： 首先通过压测和链路指标区分代理转发、加密、序列化和业务处理耗时，评估每服务代理的资源开销，必要时使用节点级代理或只对需要治理的服务启用；为代理设置资源请求和上限，避免挤压业务资源。控制面策略采用版本管理、静态校验、依赖检查、审批和灰度下发，错误时支持快速回滚并保留上一版有效配置；建立默认拒绝但可恢复的访问策略和紧急处理流程。统一采集代理与业务的日志、指标和追踪，明确故障定位手册。升级控制面和代理时先在非核心环境验证兼容性，再分批发布。

十三、论文写作素材

论文中写服务网格，应按“通信治理痛点—网格结构—关键策略—性能与风险—实施效果”展开。痛点可以是服务间认证、重试和日志重复实现，策略可以是数据面代理、控制面配置、双向认证、流量灰度、超时熔断和统一遥测。必须补充代理开销、运维复杂度、策略误配和业务幂等边界，体现权衡。

案例题中最好画出控制面与数据面的区别，并说明控制面失效时数据面如何使用最后有效配置继续服务。还要明确网格负责通信治理，业务服务负责业务规则，避免把服务网格写成万能治理平台。

十四、今日复盘清单

• 我能否解释数据面和控制面的职责区别？
• 我能否区分服务网格与 API 网关的治理范围？
• 我能否说明服务网格如何实现流量切分、熔断、认证和追踪？
• 我能否解释代理重试为什么不能替代业务幂等？
• 我能否分析服务网格带来的资源、性能和运维代价？
• 我能否给出服务网格的渐进式引入和故障演练方案？

本节的核心结论是：服务网格通过数据面代理和控制面管理，把服务间通信治理从业务代码中抽离，适合复杂微服务体系的统一安全、流量和观测管理。但它不是万能中间件，仍需业务层负责幂等、授权、状态和事务，并通过压测、灰度、配置审计和故障演练控制新增复杂度。