2、加密链路背景：为什么需要加密？常见加密协议（TLS/mTLS）归纳总结
好，咱们开始聊加密链路。
说实话，做可观测性之前，得先搞清楚我们到底在观测什么。你想想看，如果链路本身是明文传输的，那数据在中间被人截获，就跟明信片一样，谁都能看。这在金融、支付这些场景里，简直是灾难。
我多年前刚接触一个金融系统时，就遇到过这个问题。当时做日志采集，发现流量在公网上裸奔，吓得我赶紧拉了个会，把全链路加密给安排上了。说白了，加密不是可选项，是必选项。
2.1 为什么需要加密？
加密链路的核心目的，说白了就是保护数据在传输过程中不被偷看、不被篡改。具体来说，有三个关键点：
- 机密性（Confidentiality）：数据只有通信双方能看懂，中间人拿到密文也解不开。我习惯用“信封”来比喻，明文是信纸，加密就是封进信封，只有收件人能用钥匙拆开。
- 完整性（Integrity）：数据在传输中没被篡改。万一中间人改了内容，接收方能检测到。这就好比信封上有个防拆封条，撕坏了你就知道。
- 身份验证（Authentication）：确保你是在跟真正的服务器（或者客户端）通信，而不是冒牌货。证书就是它的身份证。
嗯，这里要注意，只加密不验证，等于白干。我在项目中见过有人只用了自签名证书，结果被中间人攻击，数据全泄露了。
2.2 常见加密协议：TLS
TLS（Transport Layer Security），是现在最主流的加密协议。以前的SSL已经被淘汰了，TLS 1.2和1.3是主流版本。操作起来，其实就是客户端和服务器之间走一套握手流程，协商出加密参数，然后才正式通信。
为什么会这样？因为非对称加密太慢了，所以TLS设计成：握手时用非对称加密交换一个临时对称密钥，后续通信全部用对称加密。这样既安全又高效。
TLS握手的基本流程（以TLS 1.2为例）：
- Client Hello：客户端发一个“你好”消息，带上支持的TLS版本、密码套件列表、随机数等。
- Server Hello：服务器从列表里选一套，把选中的版本、密码套件、自己的随机数发回去。
- 证书传输：服务器把自己的数字证书（包含公钥）发给客户端。
- 证书验证：客户端验证证书是否可信（靠CA根证书链），检查域名、有效期、吊销状态。
- 密钥交换：客户端用服务器公钥加密一个“预主密钥”，发给服务器。双方根据预主密钥和两个随机数，各自算出相同的对称密钥。
- Finish：双方发加密的“握手完成”消息，之后进入加密通信。
2.3 双向TLS：mTLS
普通的TLS只验证服务器身份，客户端不用验证。但在微服务之间的内部通信里，服务调用服务，你不光得确认“对方是不是真的服务”，还得确认“我自己是不是有资格调用它”。这种情况下，就需要mTLS了。
mTLS（Mutual TLS）和普通TLS的区别，就在于握手时双方的证书都要验证。客户端也得把自己的证书发给服务器，服务器验证一下。这样双向认证，谁也骗不了谁。
| 维度 | 普通TLS | mTLS |
|---|---|---|
| 证书验证方向 | 仅客户端验证服务器 | 双向验证（服务端和客户端互验） |
| 应用场景 | Web浏览器访问网站、公网API | 微服务内部通信、服务网格（如Istio）、零信任网络 |
| 证书管理复杂度 | 低（只管理服务器证书） | 高（每个服务都需要签发和管理证书） |
| 安全等级 | 高（防中间人攻击） | 更高（防内部横向扩散） |
你想想看，在微服务架构里，服务A呼叫服务B。如果只用普通TLS，服务A只要连上服务B就行，但服务B不知道来的是不是真的是服务A。万一有个恶意进程也连上来，它就能拿到敏感数据。
mTLS怎么解决？服务A拿着自己的私钥和证书，连上服务B时把证书发过去。服务B验证证书确实属于服务A，同时自己也发证书给服务A验证。这样一来，双方都确认了对方身份。
2.4 TLS/mTLS在加密链路中的角色
回到我们的课程主题——可观测性。TLS/mTLS是加密链路的根基，所有后续的可观测性手段（比如链路追踪、日志、指标）都只能基于这个加密隧道去采集。
所以，在搭建可观测性系统时，必须搞清楚：
- 流量是在哪个阶段加密的？（传输层加密？还是应用层自己加密？）
- 证书管理是否自动化？（手动管理容易出漏，影响观测的连续性）
- mTLS是否开启？（如果开启，你的观测代理也需要有相应的证书认证机制）
嗯，搞清楚这些，你才敢放心地在加密链路上做可观测性。
2.5 实践中的几个要点
最后，分享几个我在实际项目里踩过的坑：
- 证书过期：这是最常见的问题。我建议设置证书到期前30天的监控告警，提前更新。曾经有次证书凌晨3点过期，整个线上服务挂了半小时，惨痛教训。
- 密码套件选择：不是越强越好。我建议用前向安全的套件（比如ECDHE+AES-GCM），避免用静态DH。配置错了的话，性能和安全都受影响。
- 性能开销：TLS握手消耗CPU，尤其是在频繁建连的场景下。可以用会话复用（Session Resumption）、TLS 1.3的0-RTT来优化。我在高并发API网关里做过压测，开启复用后握手性能提升了40%以上。
- mTLS的证书管理成本：服务多了以后，证书分发的确是个麻烦。我习惯用控制面自动签发证书（比如SPIFFE/SPIRE），每个服务拿到唯一身份证书，不用手动拷贝。
嗯，这些基础打牢了，下一步才能安心做可观测性。否则，你连加密链路都搞不定，观测数据也采不回来。