蚂蚁Service Mesh探索与思考(上)：打造不一样的基础能力

• 1. 链路加密

为了达到一个更高的安全水位，我们预期在蚂蚁内部所有的通信 100% 加密覆盖，这就是链路加密。

• 设计

1. 必须简化大规模场景下的运维复杂度问题，需要具备可灰度、可回滚的能力。
2. 灰度运行期间，明文和加密切换不能对业务请求造成影响，需要进行热切换。
3. 开启加密以后，对性能的影响必须控制在可接受的范围内。

1. 通过统一的管控面控制服务端应用的配置，基于动态服务发布与订阅机制，在服务端支持加密能力以后，客户端自动进行加密的切换，运维人员只需要控制服务端配置节奏完成灰度；在灰度运行期间，服务端同一个端口需要同时支持明文和加密的能力。
2. 相比于明文通信，基于 TLS 加密的通信主要消耗在连接建立的握手期间，服务端和客户端采用长连接的方式，减少连接的建立，以减少开启加密对性能的影响。
3. 客户端在感知到服务端明文和加密状态变化以后，需要在不同的长连接之间进行稳定的切换，后文会详细介绍。

• 加密状态热切换：连接淘汰机制

• 优化

• 2. 自适应限流

•  技术原理

1. 系统资源检测：秒级检测系统资源占用情况，如果连续超过阈值 N 秒则触发基线计算，同时开始拒绝压测流量进入。
2. 基线计算：将当前所有的接口统计数据遍历一遍，通过一系列算法找出资源消耗大户，再把这些大户里明显上涨的流量找出来，把他们当前的资源占用做个快照存入基线数据中。
3. 基线调节器：将上一步骤存入的基线数据根据实际情况进行调整，根据系统资源检测的结果秒级的调整基线值，若系统水位超过阈值则按比例下调基线值，否则按比例恢复基线值，如此反复。
4. 限流决策：根据上述步骤生产的基线数据决策是否限流。

• 技术原理

• 3. 精细化引流

• 单应用引流

单应用切流是指在单元化的架构下，利用 MOSN 对流量的代理和调度能力，将应用粒度的流量从当前部署单元引流到另外的部署单元。

1. 灰度发布：当应用 B 需要做新的迭代发布，可以先将流量都 100% 切到单元 1，然后完成单元 2 集群的发布，再将单元 1 的流量逐量回切回来，中间有问题随时回切。
2. 容灾：当应用 B 的其中一个单元因为代码配置变更或其它原因导致长时间不可用时，可将流量都切到其它部署单元。
3. 机房新建：可将已有部署单元的应用的流量用该方式引流到新机房内的部署单元做验证。而当新的部署单元都完整引流后，这个时候如果出现个别应用有问题，也不必将整个部署单元的流量回切，利用单应用切流将出问题应用的流量切回原部署单元即可。

• 引流压测

随着业务发展，应用不断发布，在多次迭代之后，应用的性能水位离之前的基线已经走远多少了呢。如果没有一个好的性能管理方式，日常机器集群不断扩容，增加成本。每次大促临近，大家开始梳理变更，设计压测方案，然后反复压测发现性能问题，再迭代发布解决问题，时间存在风险，问题的积累不可控。引流压测利用 MOSN 的精细化引流能力，将线上集群流量引流到单机进行性能压测。每天自动回归，常态化地绘制出应用的性能基线。

• 业务链路隔离
  

当你给别人转账，这笔流量其实会经过一条具有 n 个应用的链路的处理。微服务的架构带来了诸多好处，也会带来如稳定性的一些挑战。如这笔转账流量所涉及到链路中的 n 个应用，任意一个应用出现了不可用，就会导致这笔支付失败。是否可以让这些应用都识别出如支付这样重要的链路，为其提供高可用的保证。基于 MOSN 的引流能力我们做到了业务链路隔离的方案。

• 4. 服务自愈