想象一栋现代化的写字楼里入驻了十几家公司——它们就是微服务。每家公司都要与其他公司交换文件、订单和报表，这些动作就是服务间通信。如果没有规则，楼道里会挤满人，公司之间互相不信任，快递单格式也千奇百怪。我们要讲的第一件事是双向身份核验：访客要证明自己，主人也要证明自己；第二件事是一趟能同时运多件包裹的高速货梯；第三件事是统一规格的快递单和货箱，让交接更高效；第四件事是物业统一布设的总交换机，所有收发件都从它走，安全规则和路线都集中管理。这篇文章会像翻物业图册一样，帮你把这些通信零件拼成一张整体地图。

岗位关联

学完这节内容，云架构师与 DevOps 工程师能设计出既安全又高效的服务通信链路，并在微服务集群中从容处理 mTLS、HTTP/2、gRPC 与服务网格的搭配与排障。

目录
  1. 可视化演示
  2. mTLS双向认证
  3. HTTP/2多路复用
  4. gRPC与Protobuf
  5. 服务网格流量管理
  6. 通信安全策略
  7. 性能与可靠性
  8. 通信实践落地
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示mTLS双向认证握手流程、HTTP/2多路复用流并行传输、gRPC二进制Protobuf与REST JSON性能对比。

本节配有交互动效（进入视口后自动加载，约 3KB）。

mTLS双向认证握手流程 客户端发送ClientHello及证书 服务端验证客户端证书后回复 双向认证完成建立加密通道 mutual_auth = verify(client_cert) AND verify(server_cert) 零信任架构下服务间双向身份验证

mTLS双向认证

两家公司第一次合作时，谁都不敢先透露底细。A 公司说：先验我的营业执照，你也得出示你的。B 公司回应：没问题，咱俩都验。mTLS（双向 TLS）把这个场景原封不动地搬到了网络世界：每个服务都持有一张由权威 CA 签发的数字证书，通信时不仅客户端要验证服务端，服务端也要验证客户端，任何一方证书无效，连接立即终止。

普通 HTTPS 通常只有客户端验证服务器，就像客户查公司执照，公司却不知道客户是谁。mTLS 则是双方互验工牌。在云原生环境里，每个容器实例会被注入一份短期证书，证书主体（SAN 字段）里写入服务身份；握手时除了交换随机数，还要完成证书请求、证书下发、证书校验三步，之后才开始协商密钥。

密钥协商常用 DH 类算法：双方用各自的私钥和对方的公钥，算出同一个共享密钥。这条密钥只对当前会话有效，即使被截获也解不开历史流量，从而保证服务间通信的机密性。

用物业的语言说，mTLS 就是写字楼的双向门禁：访客和公司都验证过身份，才能进入同一条保险柜通道，而门禁卡只对本次访问有效。

K=gab mod p\displaystyle K = g^{ab} \bmod p
这是迪菲-赫尔曼密钥交换的核心公式。p 是公开的大素数，g 是生成元，a 和 b 是双方各自保密的私钥，最终双方能算出相同的 K，而中间人无法从公开数据直接推出 K。
  1. 约定公开参数通信双方先约定一个大素数 p 和一个生成元 g，所有公钥计算都以此为基底。
    p,g\displaystyle p, g
  2. 生成私有随机数客户端选一个只有自己知道的私钥 a，服务端也选一个私钥 b，两者都不出本地。
    a,b\displaystyle a, b
  3. 交换公钥双方分别把 A = g^a mod p 和 B = g^b mod p 发给对方，即使被窃听也无法反推出 a 或 b。
    A=ga mod p,B=gb mod p\displaystyle A = g^{a} \bmod p, \quad B = g^{b} \bmod p
  4. 计算共享密钥客户端算 B^a，服务端算 A^b，两者都等于 g^{ab}，于是得到同一个会话密钥。
    K=Ba mod p=Ab mod p=gab mod p\displaystyle K = B^{a} \bmod p = A^{b} \bmod p = g^{ab} \bmod p

HTTP/2多路复用

老式 HTTP/1.1 像一条单车道公路：一次只能跑一辆车，而且每辆车都要先办一次通行证（TCP 连接）。HTTP/2 把这条公路改造成高速货梯：电梯井（连接）只有一个，但轿厢可以同时上下好几批货物（流）。

HTTP/2 将所有数据切成二进制帧，帧上标着所属流 ID。多个流的帧交错发送，接收端按 ID 重组，互不干扰。这就是多路复用：一条 TCP 连接可以同时承载几十上百个请求，彻底告别 HTTP/1.1 的队头阻塞。

除了多路复用，HTTP/2 还内置了 HPACK 头部压缩。频繁出现的 header 字段会被收录进静态表，动态表则记录本次连接的重复字段，用几个字节的索引代替整串文本，进一步降低传输体积。

货梯里每个包裹都有独立编号，既不会互相碰撞，又省去每次重新登记的空耗——这就是 HTTP/2 带给服务间通信的流畅感。

η=1−ScompSraw\displaystyle \eta = 1 - \frac{S_{\mathrm{comp}}}{S_{\mathrm{raw}}}
这是头部压缩节省率的计算公式。S_comp 是压缩后的头部体积，S_raw 是未压缩的原始头部体积。eta 越接近 1，说明压缩效果越好。
  1. 统计原始体积把一条 HTTP 请求的所有 header 字段按原始文本累加，得到 S_raw。
    Sraw=∑k=1m∣fieldk∣\displaystyle S_{\mathrm{raw}} = \sum_{k=1}^{m} |\mathrm{field}_k|
  2. 计算压缩体积HPACK 用静态表与动态表把重复字段替换为索引，得到明显更小的 S_comp。
    Scomp≪Sraw\displaystyle S_{\mathrm{comp}} \ll S_{\mathrm{raw}}
  3. 计算节省率用 1 减去压缩后与原始体积的比值，就能量化省下了多少空间。
    η=1−ScompSraw\displaystyle \eta = 1 - \frac{S_{\mathrm{comp}}}{S_{\mathrm{raw}}}

gRPC与Protobuf

光有快还不够，快递员还得和所有公司说同一种语言。gRPC 是 Google 开源的 RPC 框架，默认跑在 HTTP/2 上；它用 .proto 文件定义接口，再自动生成客户端和服务端代码。开发者调用远程服务就像调用本地函数，完全不用关心底层网络细节。

Protocol Buffers（简称 Protobuf）是 gRPC 的序列化格式。它把结构化的消息编码成紧凑的二进制，比 JSON 体积更小、解析更快。比如整数在 Protobuf 里用 varint 编码：小数字只占 1 个字节，大数字按需扩展。

gRPC 还支持四种调用模式：一元调用、服务端流、客户端流、双向流。双向流在物联网或 AI 推理场景特别好用——设备端一边发数据，服务端一边回结果，整个过程复用同一条连接。

如果把 HTTP/2 比作货梯，gRPC 就是货梯里标准化的集装箱：货物按统一尺寸打包，装箱单（.proto）提前定好，分拣和拆包都变成机械操作。

encoded(v)=∑i=0n−1bi×128i,bi∈[0,127]\displaystyle \mathrm{encoded}(v) = \sum_{i=0}^{n-1} b_i \times 128^i,\quad b_i \in [0,127]
这是 Protobuf 中 varint 的数学表示。整数 v 被拆成若干个 7 位片段，每个片段放入一个字节的 7 个低位，再按 128 的幂加权还原。
  1. 按 7 位分组从最低位开始，把整数 v 切成若干 7 位片段 d_i。
    di=(v≫7i) mod 128\displaystyle d_i = (v \gg 7i) \bmod 128
  2. 加继续位除最后一个字节外，每个字节的最高位设为 1，表示后面还有后续字节。
    bi=di+0x80⋅1i<n−1\displaystyle b_i = d_i + 0x80 \cdot \mathbb{1}_{i < n-1}
  3. 解码还原去掉继续位后，把所有 7 位片段乘上 128 的幂再求和，就得到原来的整数 v。
    v=∑i=0n−1(bi mod 128)×128i\displaystyle v = \sum_{i=0}^{n-1} (b_i \bmod 128) \times 128^i

服务网格流量管理

当公司数量从几家涨到几十家，让每家公司自己拉专线、自己记对方地址，很快会乱套。服务网格（Service Mesh）像物业装的总交换机：每家公司门口放一个 Sidecar 边车代理，所有进出消息都从边车经过。

Sidecar 组成了数据平面，负责服务发现、负载均衡、熔断、重试和指标采集。控制平面（如 Istiod）负责下发配置，告诉边车该往哪走、要不要放行。应用代码完全无感知，安全与流量策略都被下沉到基础设施层。

负载均衡是流量管理的核心：控制平面为每个后端实例分配权重，边车代理按权重比例把新请求分发到不同实例，实现金丝雀发布和灰度升级。

边车就像每家公司的专属管家，管家之间统一听物业调遣；公司们不用自己研究门路，只要把手里的文件交给管家就行。

Pi=ri∑j=1nrj\displaystyle P_i = \frac{r_i}{\sum_{j=1}^{n} r_j}
这是加权负载均衡的概率公式。r_i 是实例 i 的权重，分母是所有实例权重之和。某个后端被选中的概率等于它的权重占总权重的比例。
  1. 设置实例权重每个后端实例 i 被配置一个权重 r_i，表示它想承担流量的相对份额。
    ri\displaystyle r_i
  2. 计算总权重把所有后端实例的权重加起来，得到分母 R。
    R=∑j=1nrj\displaystyle R = \sum_{j=1}^{n} r_j
  3. 按比例分配一次新请求落到实例 i 的概率就是 r_i / R，权重越大，被选中次数越多。
    Pi=riR\displaystyle P_i = \frac{r_i}{R}

通信安全策略

有了双向门禁之后，物业还要规定访客能进哪几层、不能碰哪些文件。零信任模型给出的答案是：默认不信任，每次请求都要重新验证身份和权限。

在 Kubernetes 环境里，服务身份常由 SPIFFE 标准定义，格式形如 spiffe://cluster/ns/服务名。这个身份被写进 mTLS 证书的 SAN 字段，Sidecar 在握手后获得对端身份，再交给控制平面的授权策略判断。证书轮换不能靠人工，通常由边车自动向 CA 申请 24 小时有效的短期证书，到期自动换。

因此，安全策略不是“加一把锁”，而是一整套证书生命周期管理、身份体系和访问控制策略的组合。任何一环失效，服务间的信任链都可能崩塌。

写字楼的安保手册写得再厚，也要有能自动检查工牌是否过期的系统。通信安全策略，就是那本会自我更新的安保手册。

valid(c,t)=(nbfc≤t≤expc)∧VerifyChain(c,CA)\displaystyle \mathrm{valid}(c, t) = ( \mathrm{nbf}_c \le t \le \mathrm{exp}_c ) \land \mathrm{VerifyChain}(c, \mathrm{CA})
这是证书有效性判断公式。证书 c 在时间 t 有效，必须同时满足两个条件：t 在证书生效时间 nbf 与过期时间 exp 之间；证书签名链能够追溯到受信任根 CA。
  1. 检查有效期证书有生效时间 nbf 与过期时间 exp，当前时间 t 必须落在区间内。
    nbfc≤t≤expc\displaystyle \mathrm{nbf}_c \le t \le \mathrm{exp}_c
  2. 校验证书链从服务证书逐级验证签名，直到受信任的根 CA，确认证书不是伪造的。
    VerifyChain(c,CA)\displaystyle \mathrm{VerifyChain}(c, \mathrm{CA})
  3. 合并判断只有有效期与证书链两个条件同时成立，证书才被认为当前有效。
    valid(c,t)=条件A∧条件B\displaystyle \mathrm{valid}(c, t) = \text{条件A} \land \text{条件B}

性能与可靠性

快递高峰期的货梯如果只会一条道走到黑，很快就会堵死。服务通信也一样，需要连接池、超时、重试、幂等和观测手段一起上阵。

连接池让多个请求复用同一通道，避免反复建连；超时防止一个慢服务拖垮调用方；重试则让临时故障有机会自愈。但重试必须讲究节奏：指数退避让等待时间逐次翻倍，随机抖动防止所有客户端在同一时刻发起重试造成雪崩。

幂等设计是重试的安全网——同一个请求执行两次和一次结果相同，比如支付表中用唯一订单号去重。再加上全链路追踪和指标监控，运维人员才能看到每个请求经过哪些服务、慢了多久。

如果把服务通信比作高峰期配送，指数退避就是一次比一次等得久一点的耐心排队，抖动则是让大家错峰到达，而幂等设计是确保同一张订单送两次也不会重复收款。

tn=t0×2n−1+ϵ\displaystyle t_n = t_0 \times 2^{n-1} + \epsilon
这是指数退避重试的等待时间公式。t_0 是初始等待时间，n 是重试次数，epsilon 是一个随机抖动，用来避免重试风暴。
  1. 设定初始等待第一次重试前先等待固定时间 t_0，给瞬时故障留出恢复窗口。
    t0\displaystyle t_0
  2. 按指数翻倍第 n 次重试的等待时间在前一次基础上翻倍，避免频繁冲击故障节点。
    t0×2n−1\displaystyle t_0 \times 2^{n-1}
  3. 加入随机抖动叠加一个随机小量 epsilon，让不同客户端的重试时间错开，防止同时打爆服务。
    ϵ∼Uniform(0,j)\displaystyle \epsilon \sim \mathrm{Uniform}(0, j)

通信实践落地

理论最终要落到生产环境。服务间通信的落地选型，往往取决于接口演进、排查工具和性能指标。

接口兼容是第一原则。gRPC 的 Protobuf 支持新增字段而不破坏旧客户端；REST 则通常用 URL 版本号。故障排查时，openssl s_client 可以手测 mTLS 握手，grpcurl 能像 curl 一样调用 gRPC 接口，istioctl 则能检查 Sidecar 配置和证书状态。性能调优时，先看 p99 延迟、连接数和重试率，再决定是调整连接池、开启多路复用，还是引入服务网格。

选型上没有银弹：小型集群直接用 gRPC + mTLS 就够，大型多团队组织则更适合服务网格统一治理。衡量可用性时，MTBF 和 MTTR 是最直观的两个指标。

物业不可能给每家都配一套不同的规则。通信实践落地，就是把这些规则简化成一套大家看得懂、跑得通、出了问题也查得清的写字楼公约。

A=MTBFMTBF+MTTR\displaystyle A = \frac{MTBF}{MTBF + MTTR}
这是系统可用性公式。MTBF 是平均故障间隔时间，MTTR 是平均修复时间。可用性等于正常工作时间占整个周期的比例。
  1. 统计正常时长MTBF 是系统两次故障之间的平均正常工作时间。
    MTBF\displaystyle MTBF
  2. 统计修复时长MTTR 是故障发生后平均恢复时间，包括定位、修复和验证。
    MTTR\displaystyle MTTR
  3. 计算可用性用正常时间除以正常时间与修复时间之和，得到可用性指标。
    A=MTBFMTBF+MTTR\displaystyle A = \frac{MTBF}{MTBF + MTTR}

AI 应用场景

金融支付平台启用全链路 mTLS

阶段：云原生架构设计

解决的问题：传统 HTTP 明文加单向认证无法满足合规审计要求，中间人攻击风险高。通过服务网格开启全局 mTLS，两个服务之间双向认证，且证书自动轮换，不侵入业务代码。

具体案例：某银行支付核心与商户服务之间采用服务网格自动 mTLS，每个 Pod 的 Sidecar 每 24 小时向 CA 申请短期证书；监管抽查时可以直接展示所有服务身份的 SPIFFE ID 和证书链。

电商大促的 gRPC 库存服务

阶段：性能优化与架构演进

解决的问题：下单峰值期 JSON 接口延迟高、带宽消耗大。改用 gRPC + Protobuf 后，消息体缩小 60% 以上，HTTP/2 多路复用让库存查询和扣减共享同一连接。

具体案例：某电商平台在双十一前把库存查询从 REST 改写为 gRPC 双向流，前端网关与库存服务建立一条长连接，批量请求并发传输，p99 延迟从 120ms 降到 35ms。

物联网设备的双向流通信

阶段：服务治理与稳定性保障

解决的问题：设备端需要持续上送遥测数据，服务端也要即时下发指令；轮询既慢又浪费带宽。使用 gRPC 双向流 + mTLS，设备身份即证书身份，鉴权与数据传输一步完成。

具体案例：智能工厂的 10 万台物联网终端与边缘网关建立 gRPC 双向流，借助指数退避处理断线重连，通信可靠率从 99.2% 提升到 99.95%。

Python 演示

python64 行
import hashlibimport hmacimport struct CA_SECRET = b"root-ca-thumbprint"  def issue_cert(name):    """模拟 CA 为服务签发证书，hmac 签名"""    return hmac.new(CA_SECRET, name.encode(), hashlib.sha256).hexdigest()  def verify_cert(cert, name):    return hmac.compare_digest(cert, issue_cert(name))  def mutual_handshake(service, peer):    """双向认证：双方都校验对方证书"""    if not verify_cert(peer.cert, peer.name):        raise PermissionError("peer certificate invalid")    if not verify_cert(service.cert, service.name):        raise PermissionError("own certificate invalid")    return True  class Service:    def __init__(self, name):        self.name = name        self.cert = issue_cert(name)        self.secret = hashlib.sha256(name.encode()).hexdigest()     def send(self, peer, message):        mutual_handshake(self, peer)        body = message.encode()        mac = hmac.new(self.secret.encode(), body, hashlib.sha256).hexdigest()        return struct.pack(">I", len(body)) + body + mac.encode()     def recv(self, frame):        mutual_handshake(self, frame.peer)        n = struct.unpack(">I", frame.data[:4])[0]        body = frame.data[4:4 + n]        mac = frame.data[4 + n:]        expected = hmac.new(self.secret.encode(), body, hashlib.sha256).hexdigest()        if not hmac.compare_digest(expected, mac.decode()):            raise ValueError("message tampered")        return body.decode()  class Frame:    def __init__(self, peer, data):        self.peer = peer        self.data = data  def main():    order = Service("order-service")    payment = Service("payment-service")    frame = order.send(payment, "create order")    message = payment.recv(Frame(order, frame))    print("[mTLS] " + payment.name + " verified " + order.name + " and got: " + message)  if __name__ == "__main__":    main()
目的：用纯 Python 模拟服务间 mTLS 双向认证与带长度前缀的帧传输，展示身份校验、签名和防篡改的核心思想。
  1. issue_cert(name)类似 CA 给服务签证书，用 HMAC 生成不可伪造的签名。
  2. mutual_handshake(service, peer)双方都校验对方证书，模拟 mTLS 的双向认证。
  3. struct.pack(">I", len(body))用 4 字节长度前缀模拟帧头，方便接收端切分消息。
  4. hmac.compare_digest(expected, mac.decode())使用常数时间比较 HMAC，防止消息被篡改。

常见误区

误区很多初学部署环境的人觉得“反正都上了 HTTPS，证书也装了，mTLS 无非就是再申请一张证书”。

正解mTLS 的关键不是“多一张证书”，而是“两个方向都验证”。普通 HTTPS 只有客户端验证服务端；mTLS 要求服务端也验证客户端证书，身份校验发生在握手阶段。即便双方都有证书，如果证书链不受信任或有效期校验失败，连接也不会建立。就像写字楼不只检查访客，也检查每一家公司前台的身份。

为何常见：日常浏览网页时只接触单向 HTTPS，大家容易忽略“客户端也需要证书”这一层。

误区有人以为只要把 REST 换成 gRPC，性能就能提升，原因是 HTTP/2 多路复用。

正解多路复用确实减少了连接开销，但 gRPC 的主要优势还来自 Protobuf 二进制序列化——同样一个订单对象，protobuf 编码后的体积通常只有 JSON 的 20%-40%，CPU 解析成本也更低。换句话说，gRPC 快在“货箱更小、电梯更顺”两者的组合，不能只归功于货梯。

为何常见：因为 HTTP/2 是 gRPC 的传输层，且多路复用概念更易被记住，新手容易把功劳全记在它头上。

误区部分运维同学以为 Sidecar 自动加密后，证书申请、续期、分发都可以放任不管。

正解自动 mTLS 虽然把轮换自动化，但证书生命周期仍需治理：CA 配置、SPIFFE 身份命名、证书最短有效期、轮换失败告警都必须在控制平面层维护。证书过期或 CA 信任链配置错误，会导致所有服务间握手瞬间失败，比明文通信故障更隐蔽、更难排查。

为何常见：服务网格把很多操作封装成了“自动”，让人误以为背后的信任链不需要人工设计。

误区听到“一条连接并发多个流”，就以为 HTTP/2 下请求永远不会排队等待。

正解HTTP/2 解决了 HTTP 层的队头阻塞，但底层仍是 TCP。如果某个 TCP 包丢失，后续所有流都要等重传，这就是 TCP 层队头阻塞。HTTP/3 改用 QUIC/UDP 才进一步缓解。因此在高丢包场景下，仍需要关注网络质量。

为何常见：多路复用的“并行”表象容易让人忽略底层 TCP 的可靠性机制。

面试题

Q1. mTLS 和普通 HTTPS 的核心区别是什么？

单选题 · easy

  • A.改用了不同的 TCP 端口
  • B.只有服务器端需要证书
  • C.客户端必须出示并验证证书← 正确答案
  • D.使用更高级的对称加密算法

答案：C。普通 HTTPS 只有客户端验证服务器证书，像客户查公司执照；mTLS 则要求双方互相出示证书，服务端也要验证客户端身份。端口和加密算法都不是关键差异。

Q2. gRPC 默认的传输层协议是什么？

单选题 · easy

  • A.HTTP/2← 正确答案
  • B.HTTP/1.1
  • C.WebSocket
  • D.UDP

答案：A。gRPC 将 HTTP/2 作为传输层，利用多路复用和二进制帧；WebSocket 和 UDP 都不符合 gRPC 默认传输设计。

Q3. 关于 HTTP/2 多路复用，下列说法正确的有？

多选题 · mid

  • A.多个请求可以共享同一条连接← 正确答案
  • B.数据被拆成帧并携带流标识← 正确答案
  • C.客户端必须串行等待每个响应
  • D.流之间可以设置依赖与优先级← 正确答案

答案：ABD。HTTP/2 以帧为单位在多条流上交错传输，客户端不再串行等待；流还可以声明依赖和优先级。C 是 HTTP/1.1 的队头阻塞表现，不是 HTTP/2。

Q4. 服务网格中负责实际转发流量的组件是？

单选题 · mid

  • A.控制平面组件
  • B.数据平面 Sidecar← 正确答案
  • C.服务注册中心
  • D.统一 API 网关

答案：B。服务网格由控制平面与数据平面组成，数据平面的 Sidecar 代理负责转发每个服务的进出流量；控制平面只做配置下发，不参与用户请求路径。

Q5. 零信任模型下，服务间通信的默认策略是？

单选题 · mid

  • A.同局域网内可以信任
  • B.默认拒绝并按策略放行← 正确答案
  • C.同集群内全部信任
  • D.只依赖 IP 白名单

答案：B。零信任把“网络位置”从信任依据中移除，默认不信任任何请求；每次通信都要通过身份与访问策略校验。IP 白名单或内网位置都不能替代零信任。

Q6. Protobuf 用 varint 编码整数 127，需要多少个字节？

单选题 · easy

  • A.1 个字节← 正确答案
  • B.2 个字节
  • C.4 个字节
  • D.8 个字节

答案：A。varint 每个字节用 7 位表示数据，127 小于 128，可以放进第一个字节，因此 1 字节足够。这也是小整数在 protobuf 中特别省空间的原因。

Q7. 下面哪些做法能提升服务间通信的可靠性？

多选题 · hard

  • A.指数退避机制重试← 正确答案
  • B.重试时加入随机抖动← 正确答案
  • C.对非幂等请求无限重试
  • D.设置调用超时时间← 正确答案

答案：ABD。指数退避和抖动能避免重试风暴，超时能防止慢依赖拖垮调用方。非幂等请求无限重试可能造成重复下单或重复扣款，必须配合幂等键或限制次数。

Q8. gRPC 的 .proto 文件主要作用是什么？

单选题 · mid

  • A.生成客户端与服务端代码← 正确答案
  • B.管理容器镜像构建发布
  • C.配置服务网格路由策略
  • D.编写数据库迁移脚本

答案：A。.proto 是 gRPC 的 IDL 契约文件，定义服务方法与消息结构，并据此自动生成多语言代码，让远程调用像本地函数一样。

Q9. 可用性计算公式通常写作？

单选题 · hard

  • A.A = MTBF / (MTBF + MTTR)← 正确答案
  • B.A = MTTR / (MTBF + MTTR)
  • C.A = MTBF / MTTR
  • D.A = MTTR / MTBF

答案：A。MTBF 是正常工作时间，MTTR 是修复时间，可用性 = 正常时间 / 总时间。其他公式要么表示故障占比，要么没有实际工程意义。

Q10. 服务网格中自动化管理 mTLS 证书的常见做法包括？

多选题 · extreme

  • A.Sidecar 向 CA 申请短期证书← 正确答案
  • B.每 24 小时自动轮换一次← 正确答案
  • C.在服务代码中手动更新证书
  • D.按 SPIFFE 身份标识签发证书← 正确答案

答案：ABD。Sidecar 代表业务进程向 CA 申请短期证书，按周期轮换，并将 SPIFFE 身份写入 SAN 字段。若依赖业务代码手动更新证书，会破坏自动化的零信任体系，不是常见做法。