大家好，抖音春晚背后的Service Mesh流量管理技术相信很多的网友都不是很明白，包括也是一样，不过没有关系，接下来就来为大家分享关于抖音春晚背后的Service Mesh流量管理技术和的一些知识点，大家可以关注收藏，免得下次来找不到哦，下面我们开始吧！

整个项目涉及到不同的技术团队，自然涉及到很多微服务。这些微服务有自己的语言技术栈，包括Go、C++、Java、Python、Node等，同时也运行在非常复杂的环境中，比如容器、虚拟机、物理机等。这些微服务可能需要使用不同的流量管理策略，保证整个抖音春晚活动不同阶段的稳定性。

因此，基础设施需要为这些来自不同团队、不同语言编写的微服务提供统一的流量管理能力。

传统微服务架构的应对

说到微服务，我们首先看一下传统的微服务架构是如何解决这些问题的。随着企业组织的不断发展，产品的业务逻辑变得越来越复杂。为了提高产品的迭代效率，互联网软件的后端架构逐渐从单一的大服务演变为分布式微服务。分布式架构的稳定性和可观察性不如单体架构。

为了完善这些点，我们需要在微服务框架上实现很多功能。例如：

微服务需要互相调用来完成原来单个大型服务实现的功能，这涉及到相关的网络通信，以及网络通信带来的请求的序列化和响应的反序列化。服务之间的相互调用涉及到服务发现。分布式架构可能需要不同的流量管理策略来保证服务之间相互调用的稳定性。微服务架构下，可观察性能力也需要提升，包括日志、监控、追踪等，通过实现上述功能，微服务架构也可以解决前面提到的一些问题。但微服务本身也存在一些问题：

在多语言微服务框架上实现多种功能涉及非常高的开发和运维成本；微服务框架上的一些新功能的交付或版本召回需要业务研发同学的配合来进行相关的更改和发布，这会导致微服务框架长期碎片化和版本不可控的现象。那么我们如何解决这些问题呢？软件工程领域有一句话：任何问题都可以通过添加中间层来解决。针对我们之前的疑问，业界已经给出了答案。这个中间层就是Service Mesh（服务网格）。

自研 Service Mesh 实现

给大家介绍一下火山引擎自研Service Mesh的实现。首先看下面的架构图。

图中蓝色矩形Proxy节点是Service Mesh的数据平面。它是一个独立的进程，与运行业务逻辑的Service进程部署在同一个运行环境（同一个容器或同一台机器）中。该代理进程将代理流经服务进程的所有流量。前面提到的需要在微服务框架上实现的服务发现、流量管理策略等功能都可以通过这个数据面流程来完成。

图中绿色矩形是Service Mesh的控制面。我们需要实现的路由流量和治理策略都是由这个控制平面决定的。它是远程部署的服务。它和数据平面进程传递一些流量管理规则，然后由数据平面进程执行。

同时我们也可以看到，数据面和控制面与业务无关。它们的发布和升级相对独立，不需要通知业务研发同学。

基于这样的架构，可以解决上面提到的一些问题：

我们不需要每种语言都实现微服务框架的很多功能，只需要在Service Mesh的数据面流程中实现即可；同时，数据面进程屏蔽了各种复杂的运行环境，Service进程只需与数据面进程进行通信即可； Service Mesh的流程控制面服务还可以定制各种灵活的流量管理策略。

Service Mesh 流量治理技术

接下来给大家介绍一下我们Service Mesh实现提供的具体流量管理技术，保证微服务在面对抖音春晚活动的流量高峰时能够有相对稳定的表现。

首先介绍一下流量管理的核心：

路由：流量从一个微服务实体开始，可能需要一些服务发现或通过一些规则流向下一个微服务。这个过程可以衍生出很多流量管理能力。安全性：流量在不同微服务之间流动时，需要进行身份认证、授权、加密等，以保证流量内容安全、真实、可信。控制：采用动态调整的治理策略，保证微服务面对不同场景时的稳定性。可观察性：这是更重要的一点。我们需要记录和跟踪交通状况，配合预警系统及时发现和解决问题。以上四个核心方面，结合具体的流量管理策略，可以提高微服务的稳定性，保证流量内容的安全，提高商科生的研发效率，同时也提高面对黑天鹅时的整体容灾能力。。。能力。

我们继续看一下Service Mesh技术提供的具体流量管理策略来保证微服务的稳定性。

稳定性策略——熔断

第一个是保险丝。在微服务架构中，单点故障是常态。当发生单点故障时，如何保证整体成功率是断路器需要解决的问题。

断路器可以从客户端的角度记录从服务发送到每个下游节点的流量请求的成功率。当到达下游的请求成功率低于一定阈值时，我们会对节点进行熔断，使流量请求不再到达故障节点。

当故障节点恢复时，我们还需要一定的策略来熔断后恢复。例如，您可以尝试在一段时间内向故障节点发送一些流量。如果节点仍然无法提供服务，则继续中断；如果能够提供服务，则逐步增加流量，直至恢复正常水平。通过熔断策略，可以容忍微服务架构中个别节点的不可用，防止进一步恶化带来的雪崩效应。

稳定性策略——限流

另一种治理策略是限流。限流是基于当服务器过载时，其请求处理成功率会下降。例如一个Server节点正常情况下可以处理2000QPS。在过载情况下（假设达到3000 QPS），服务器只能处理1000 QPS甚至更低。限流可以主动丢弃一些流量，使服务器本身不会过载，防止雪崩效应。

稳定性策略——降级

当Server节点进一步过载时，需要使用降级策略。降级一般有两种情况：

一是按比例减少流量。例如，从服务A发送到服务B的流量可以按照一定比例（20%或更高）丢弃。另一个是旁路依赖的降级。假设服务A需要依赖B、C、D三个服务，D为旁路。可以切断Bypass所依赖的D流量，从而将释放的资源用于核心路径计算，防止进一步过载。

稳定性策略——动态过载保护

断路器、限流和降级都是发生错误时的管理策略。其实最好的策略是防患于未然，这就是接下来要介绍的动态过载保护。

如前所述，限流策略的阈值很难确定。一般情况下，通过压力测试来观察节点所能承载的QPS。但由于运行环境的不同，这个上限级别在不同的节点上可能会有不同的表现。动态过载保护的基础是，相同资源规格的服务节点不一定具有相同的处理能力。

如何实现动态过载保护？分为过载检测、过载处理、过载恢复三个部分。最关键的是如何判断某个Server节点是否过载。

上图中的Ingress Proxy就是Service Mesh的数据面流程。它代理流量并将其发送到服务器进程。图中的T3可以理解为从Proxy进程收到请求到Server处理完请求返回的时间。这个时间可以用来判断过载吗？答案是否定的，因为Server可能依赖于其他节点。有可能其他节点的处理时间变长，导致服务器的处理时间变长。这种情况下，T3无法反映服务器处于过载状态。

检测到服务器过载后应该做什么？过载处理的策略有很多种。我们采取的策略是根据请求的优先级主动丢弃低质量请求，以缓解服务器过载的情况。当服务器掉掉一些流量后恢复到正常水平时，我们需要进行相应的过载恢复，使QPS恢复到正常状态。

这个过程是如何动态的？过载检测是一个实时过程，有一定的时间周期。在每个周期中，当检测到服务器过载时，可以按照一定的比例慢慢丢弃一些低质量的请求。在接下来的时间段内，如果检测到服务器已经恢复，就会慢慢降低掉线率，让服务器逐渐恢复。

动态过载保护的效果非常明显：可以保证在大流量、高压的情况下服务不会崩溃。这一策略在抖音春晚红包项目中的一些大型服务中也被广泛应用。

稳定性策略——负载均衡

接下来我们看一下负载均衡策略。假设有一个流量从服务A 到达下游服务B。A 和B 都有10,000 个节点。如何保证A到B的流量均衡？其实方法有很多。比较常用的有随机轮询、加权虚拟机、加权轮询。其实只要看它们的名字你就可以知道这些策略的含义。

另一种常见的策略是一致性哈希。哈希是指根据请求的一些特征将请求路由到下游的同一个节点，并在请求和节点之间建立映射关系。一致性哈希策略主要用于缓存敏感的服务，可以大大提高缓存命中率，提高服务器性能，降低超时错误率。当有一些新的节点加入到服务中，或者一些节点不可用时，哈希的一致性可以尽可能少地影响已建立的映射关系。

其他的负载均衡策略还有很多，但是它们在生产场景中的应用范围并不是很广，这里不再赘述。

稳定性策略——节点分片

面对抖音春晚红包等超大流量场景，另一个有用的策略是节点分片。节点分片是基于对于节点较多的微服务来说，长连接的复用率很低。由于微服务一般通过TCP协议进行通信，因此需要先建立TCP连接，流量在TCP连接上流动。我们会尽可能重用一个连接来发送请求和响应，以避免频繁连接和关闭连接带来的额外开销。

当节点规模非常大时，例如服务A和服务B都有10000个节点，需要维护大量的长连接。为了避免维持如此多的长连接，通常会设置空闲超时。当在一定时间内没有流量通过某个连接时，该连接将被关闭。在服务节点规模非常大的场景下，长连接退化为短连接，这就需要每个请求都建立一个连接进行通信。其影响是：

连接超时导致的错误。性能将会降低。为了解决这个问题，可以使用节点分片策略。事实上，我们在抖音春晚红包场景中也非常广泛地使用了这个策略。该策略对节点数量较多的服务进行节点分片，然后建立映射关系，使得服务A的shard 0发出的流量一定能到达服务B的shard 0，如下图所示。

这样可以大大提高长连接的复用率。原来的1000010000的对应关系现在变成了正常的关系，比如100100。通过节点分片策略，我们大大提高了长连接的复用率，减少了连接超时带来的错误，提高了微服务的性能。

效率策略

前面提到的限流、熔断、降级、动态过载保护、节点分片等都是与提高微服务稳定性相关的策略，另外还有一些与效率相关的策略。

我们先介绍一下泳道和染料分离的概念。

上图所示的某个功能可能涉及到a、b、c、d、e、f六个微服务。泳道可以隔离这些交通流。每个泳道都有这六个微服务，它们可以完成一个功能。

染色分流是指让流量按照一定的规则流入不同的泳道，然后利用此来完成一些功能。这些功能主要包括：

功能调试：在线开发和测试过程中，您可以将一些个人发送的请求放入您设置的泳道中，进行功能调试。故障演练：抖音春晚活动部分服务开发完成后，需要进行针对不同故障的处理演练。这时，我们可以通过一些规则将压测流量引流到故障演练泳道上。流量记录和回放：按照一定的规则记录流量并回放。主要用于bug调试或者某些黑产场景下发现问题。

安全策略

安全策略也是流量管理的重要组成部分。我们主要提供三种安全策略：

授权：授权是指限制某个服务可以被哪些服务调用。双向加密（mTLS）：为了防止流量内容被窥探、篡改或攻击，需要使用双向加密。通过上述策略，我们提供可靠的身份认证、安全的传输加密，防止传输的流量内容被篡改或攻击。

春晚红包场景落地

通过上面提到的各种策略，可以大大提高微服务的稳定性和业务研发的效率。但是我们在实现这个架构的时候，也会遇到一些挑战。主要挑战是性能问题。我们知道，通过增加中间层，虽然扩展性和灵活性得到了提升，但必然会产生一些额外的开销。这个开销就是性能。如果没有Service Mesh，微服务框架的主要开销来自序列化和反序列化、网络通信、服务发现和流量管理策略。使用Service Mesh后，还会产生两点开销：

协议分析

进程间通信

数据平面进程将代理业务进程的流量，通常通过iptables。这种方案的开销非常高，因此我们通过与微服务框架约定一个unix域socket地址或者本地端口来进行进程间通信，然后进行相关的流量劫持。虽然这种方法相对于iptables 会有一些性能提升，但也有一些额外的开销。

我们的解决方案是通过共享内存来完成的。共享内存是Linux下性能最高的进程间通信方式，但它没有相关的通知机制。当我们将请求放入共享内存后，其他进程并不知道已经放入了请求。因此，我们需要引入一些。。通知机制来让数据面进程知道。我们通过unix域socket完成了这样一个过程，起到了减少内存复制开销的作用。同时，我们引用共享内存中的一个队列，可以批量收获IO，从而减少系统调用。其效果也是非常明显的。在抖音春晚活动的部分风控场景下，性能可提升24%。

完成这些优化之后，实施的阻力就不会那么大了。

总结

稳定性：面对上亿QPS的瞬时流量峰值，Service Mesh提供的流量管理技术保证了微服务的稳定性。安全性：Service Mesh提供的安全策略保证服务之间的流量安全可信。高效：春晚活动涉及到很多用不同编程语言编写的微服务。 Service Mesh天然为这些微服务提供了统一的流量管理能力，提高了开发者的研发效率。

QA

问：为什么共享内存中的IPC通信可以减少系统调用？

A：当Client进程向共享内存中放入请求时，我们需要通知Server进程来处理。将会有一个唤醒操作。每次唤醒都意味着一次系统调用。当服务器还没有被唤醒，或者正在处理一个请求，下一个请求到来时，不需要执行同样的唤醒操作。这意味着我们在请求密集的场景下不需要频繁唤醒。这具有减少系统调用的效果。

Q：自研的Service Mesh实现是纯自研还是基于Istio等社区产品？如果是自研的话，应该用Go语言还是Java语言？您在数据平面上使用Envoy 吗？ iptables是否用于流量劫持？

一个：