(抖音无人直播合法吗)抖音无人直播协议软件技术开发

本文整理自火山引擎开发者社区 Meetup 的同名演讲抖音无人曲播协议软件手艺开发，次要介绍了抖音春晚红包大规模流量场景下的 Service Mesh 流量治理手艺。

布景与挑战

2021 年的央视春晚红包项目留给营业研发同窗的时间十分少抖音无人曲播协议软件手艺开发，他们需要在有限的时间内完成相关代码的开发测试以及上线。

整个项目涉及到差别的手艺团队，天然也会涉及浩瀚的微办事。那些微办事有各自的语言手艺栈，包罗 Go，C++，Java，Python，Node 等，同时又运行在十分复杂的情况中，好比容器、虚拟机、物理机等。那些微办事在整个抖音春晚活动的差别阶段，可能又需要利用差别的流量治理战略来包管不变性。

因而根底架构就需要为那些来自差别团队、用差别语言编写的微办事供给同一的流量治理才能。

传统微办事架构的应对

说到微办事，抖音无人曲播协议软件手艺开发我们先来看一下传统的微办事架构是怎么处理那些问题的。跟着企业组织的不竭开展，产物的营业逻辑日渐复杂，为了提拔产物的迭代效率，互联网软件的后端架构逐步从单体的大办事演化成了散布式微办事。散布式架构相关于单体架构，其不变性和可不雅测性要差一些。

为了提拔那些点，我们就需要在微办事框架上实现良多功用。例如抖音无人曲播协议软件手艺开发：

微办事需要通过彼此挪用来完成原先单体大办事所实现的功用，那此中就涉及到相关的收集通信，以及收集通信带来的恳求的序列化、响应的反序列化。办事间的彼此挪用涉及办事发现。散布式的架构可能需要差别的流量治理战略来包管办事之间彼此挪用的不变性。微办事架构下还需要提拔可不雅测性才能，包罗日记、监控、Tracing 等。

通过实现以上那些功用，微办事架构也能处理前面提到的一些问题。但是微办事自己又存在一些问题：

在多语言的微办事框架上实现多种功用，涉及的开发和运维成本十分高抖音无人曲播协议软件手艺开发；微办事框架上一些新 Feature 的交付或者版本召回，需要营业研发同窗共同停止相关的改动和发布上线，会形成微办事框架的版本持久割裂不受控的现象。

那我们怎么去处理那些问题呢？在软件工程的范畴有如许一句话：任何问题都能够通过增加一个中间层去处理。而针对我们前面的问题，业界已经给出了谜底，那个中间层就是 Service Mesh（办事网格）。

自研 Service Mesh 实现

下面就给各人介绍一下火山引擎自研 Service Mesh 的实现。先看下面那张架构图。

图中蓝色矩形的 Proxy 节点是 Service Mesh 的数据面，它是一个零丁的历程，和运行着营业逻辑的 Service 历程摆设在同样的运行情况（统一个容器或统一台机器）中。由那个 Proxy 历程来代办署理流经 Service 历程的所有流量，前面提到的需要在微办事框架上实现的办事发现、流量治理战略等功用就都能够由那个数据面历程完成。

图中的绿色矩形是 Service Mesh 的控造面。我们需要施行的路由流量、治理战略是由那个控造面决定的。它是一个摆设在远端的办事，由它和数据面历程下发一些流量治理的规则，然后由数据面历程去施行。

同时我们也能够看到数据面和控造面是与营业无关的，其发布晋级相对独立，不需要通知营业研发同窗。

基于如许的架构就能够处理前文提到的一些问题：

我们不需要把微办事框架浩瀚的功用在每种语言上都实现一遍，只需要在 Service Mesh 的数据面历程中实现即可；同时由数据面历程屏障各类复杂的运行情况，Service 历程只需要和数据面历程通信即可；各类灵敏多变的流量治理战略也都能够由 Service Mesh 的历程控造面办事停止定造。Service Mesh 流量治理手艺

接下来给各人介绍我们的 Service Mesh 实现详细供给了哪些流量治理手艺来保障微办事在面临抖音春晚活动的流量洪峰时可以有一个比力不变的表示。

起首介绍一下贱量治理的核心：

路由：流量从一个微办事实体动身，可能需要停止一些办事发现或者通过一些规则流到下一个微办事。那个过程能够衍生出良多流量治理才能。平安：流量在差别的微办事之间流转时，需要通过身份认证、受权、加密等体例来保障流量内容是平安、实在、可信的。控造：在面临差别的场景时，用动态调整治理战略来保障微办事的不变性。可不雅测性：那是比力重要的一点，我们需要对流量的形态加以记录、逃踪，并共同预警系统及时发现并处理问题。

以上的四个核心方面共同详细的流量治理战略，能够提拔微办事的不变性，保障流量内容的平安，提拔营业同窗的研发效率，同时在面临黑天鹅事务的时候也能够提拔整体的容灾才能。

下面我们继续来看一下 Service Mesh 手艺详细都供给了哪些流量治理战略来保障微办事的不变性。

不变性战略——熔断

起首是熔断。在微办事架构中，单点毛病是一种常态。当呈现单点毛病的时候，若何保障整体的胜利率是熔断需要处理的问题。

熔断能够从客户端的视角动身，记录从办事发出的流量恳求抵达下流中每一个节点的胜利率。当恳求到达下流的胜利率低于某一阈值，我们就会对那个节点停止熔断处置，使得流量恳求不再打到毛病节点上。

当毛病节点恢复的时候，我们也需要必然的战略去停止熔断后的恢复。好比能够测验考试在一个时间周期内发送一些流量打到那个毛病节点，若是该节点仍然不克不及供给办事，就继续熔断；若是可以供给办事了，就逐步加大流量，曲到恢复一般程度。通过熔断战略，能够容忍微办事架构中个别节点的不成用，并避免进一步恶化带来的雪崩效应。

不变性战略——限流

别的一个治理战略是限流。限流是基于如许的一个事实：Server 在过载形态下，其恳求处置的胜利率会降低。好比一个 Server 节点一般情况下可以处置 2000 QPS，在过载情况下（假设到达 3000 QPS），那个 Server 就只能处置 1000 QPS 以至更低。限流能够主动 drop 一些流量，使得 Server 自己不会过载，避免雪崩效应。

不变性战略——降级

当 Server 节点进一步过载，就需要利用降级战略。降级一般有两种场景：

一种是根据比例丢弃流量。好比从 A 办事发出到 B 办事的流量，能够根据必然的比例（20% 以至更高）丢弃。别的一种是旁路依赖的降级。假设 A 办事需要依赖 B、C、D 3 个办事，D 是旁路，能够把旁路依赖 D 的流量掐掉，使得释放的资本能够用于核心途径的计算，避免进一步过载。

不变性战略——动态过载庇护

熔断、限流、降级都是针对错误发作时的治理战略，其实更好的战略是防患于未然，也就是接下来要介绍的动态过载庇护。

前面提到了限流战略很难确定阈值，一般是通过压测去不雅测一个节点可以承载的 QPS，但是那个上限量级可能会因为运行情况的差别，在差别节点上的表示也差别。动态过载庇护就是基于如许一个事实：资本规格不异的办事节点，处置才能纷歧定不异。

若何实现动态过载庇护？它分为三个部门：过载检测，过载处置，过载恢复。此中最关键的是若何判断一个 Server 节点能否过载。

上图中的 Ingress Proxy 是 Service Mesh 的数据面历程，它会代办署理流量并发往 Server 历程。图中的 T3 能够理解为从 Proxy 历程收到恳求到 Server 处置完恳求后返回的时间。那个时间能否能够用来判断过载？谜底是不克不及，因为 Server 有可能依赖于其他节点。有可能是其他节点的处置时间变长了，招致 Server 的处置时间变长，那时 T3 其实不能反映 Server 是处于过载的形态。

图中 T2 代表的是数据面历程把恳求转发到 Server 后，Server 实正处置到它的时间间隔。T2 能否反映过载的形态？谜底是能够的。为什么能够？举一个例子，假设 Server 的运行情况是一个 4 核 8g 的实例，那就决定了该 Server 最多只能同时处置 4 个恳求。若是把 100 个恳求打到该 Server，剩余的 96 个恳求就会处于 pending 的形态。当 pending 的时间过长，我们就能够认为是过载了。

检测到 Server 过载之后应当若何停止处置？针对过载处置也有良多战略，我们接纳的战略是按照恳求的优先级主动 drop 低优的恳求，以此来缓解 Server 过载的情况。当 drop 了一些流量后 Server 恢复了一般程度，我们就需要停止响应的过载恢复，使得 QPS 可以到达一般形态。

那个过程是若何表现动态性的？过载检测是一个实时的过程，它有必然的时间周期。在每一个周期内，当检测到 Server 是过载的形态，就能够渐渐按照必然比例 drop 一些低优恳求。鄙人一个时间周期，若是检测到 Server 已经恢复了，又会渐渐调小 drop 的比例，使 Server 逐步恢复。

动态过载庇护的效果长短常明显的：它能够包管办事在大流量高压的情况下不会瓦解，该战略也普遍地应用于抖音春晚红包项目中的一些大办事。

不变性战略——负载平衡

接下来我们看一下负载平衡战略。假设有一个办事 A 发出的流量要到达下流办事 B，A 和 B 都有一万个节点，我们若何保障从 A 动身的流量到达 B 中都是平衡的？做法其实有良多，比力常用的是随机轮询、加权虚机、加权轮询，那些战略其实看名字就能晓得是什么意思了。

另一种比力常见的战略是一致性哈希。哈希是指按照恳求的一些特征使得恳求必然会路由到下流中的不异节点，将恳求和节点成立起映射关系。一致性哈希战略次要应用于缓存敏感型办事，能够大大提拔缓存的射中率，同时提拔 Server 性能，降低超时的错误率。当办事中有一些新参加的节点，或者有一些节点不成用了，哈希的一致性能够尽可能少地影响已经成立起的映射关系。

还有良多其他的负载平衡战略，在消费场景中的应用范畴并非很普遍，那里不再赘述。

不变性战略——节点分片

面临抖音春晚红包那种超大流量规模的场景，还有一个比力有用的战略是节点分片。节点分片基于如许一个事实：节点多的微办事，其长毗连的复用率长短常低的。因为微办事一般是通过 TCP 协议停止通信，需要先成立起 TCP 毗连，流量流转在 TCP 毗连上。我们会尽可能地复用一个毗连去发恳求搜响应，以制止因频繁地停止毗连、封闭毗连形成的额外开销。

当节点规模十分大的时候，好比说 Service A 和 Service B 都有 1 万个节点，它们就需要维持十分多的长毗连。为制止维持那么多长毗连，凡是会设置一个 idle timeout 的时间，当一个毗连在必然的间隔内没有流量颠末的时候，那个毗连就会被关掉。在办事节点规模十分大的场景下，长毗连退化成的短毗连，会使得每一个恳求都需要成立毗连才气停止通信。它带来的影响是：

毗连超时带来的错误。性能会有所降低。

处理那个问题能够利用节点分片的战略。现实上我们在抖音春晚红包的场景中也长短常普遍地利用了那个战略。那个战略对节点数较多的办事停止节点分片，然后成立起一种映射关系，使得如下图中所示的 A 办事的分片 0 发出的流量必然能抵达 service B 的分片 0。

如许就能够大大提拔长毗连的复用率。关于原先 1000010000 的对应关系，如今就酿成了一个常态的关系，好比 100100。我们通过节点分片的战略大大提拔了长毗连的复用率，降低了毗连超时带来的错误，而且提拔了微办事的性能。

效率战略

前面提到的限流、熔断、降级、动态过载庇护、节点分片都是提拔微办事不变性相关的战略，还会有一些与效率相关的战略。

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

上图中所示的某个功用可能涉及到 a、b、c、d、e、f 六个微办事。泳道能够对那些流量停止隔离，每一个泳道内完好地拥有那六个微办事，它们能够完好的完成一个功用。

染色分流是指按照某些规则使得流量打到差别的泳道，然后借此来完成一些功用，那些功用次要包罗：

Feature 调试：在线上的开发测试过程中，能够把小我发出的一些恳求打到本身设置的泳道并停止 Feature 调试。毛病练习训练：在抖音春晚活动的一些办事开发完成之后，需要停止练习训练以对应对差别的毛病。那时我们就能够把压测流量通过一些规则引流到毛病练习训练的泳道上。流量录造回放：把某种规则下的流量录造下来，然后停止相关回放，次要用于 bug 调试或在某些黑产场景下发现问题。平安战略

平安战略也是流量治理的重要环节。我们次要供给三种平安战略：

受权：受权是指限制某一个办事可以被哪些办事挪用。鉴权：当一个办事领受到流量时，需要判定流量来源的实在性。双向加密（mTLS) ：为了避免流量内容被窥探、窜改或被攻击，需要利用双向加密。

通过以上的那些战略，我们供给了可靠的身份认证，平安地传输加密，还能够避免传输的流量内容被窜改或攻击。

春晚红包场景落地

通过前面提到的各类战略，我们能够大大提拔微办事的不变性以及营业研发的效率。但是当我们落地那一套架构的时候也会碰到一些挑战，最次要的挑战是性能问题。我们晓得，通过增加一个中间层，固然提拔了扩展性和灵敏性，但同时也一定有一些额外的开销，那个开销就是性能。在没有 Service Mesh 时，微办事框架的次要开销来自于序列化与反序列化、收集通信、办事发现以及流量治理战略。利用了 Service Mesh 之后，会多出两种开销：

协议解析

关于数据面历程代办署理的流量，需要对流量的协议停止必然的解析才气晓得它从哪来到哪去。但是协议解析自己的开销十分高，所以我们通过增加一个 header (key 和 value 的集合) 能够把流量的来源等办事元信息放到那个 header 里，如许只需要解析一两百字节的内容就能够完成相关的路由。

历程间通信

数据面历程会代办署理营业历程的流量，凡是是通过 iptables 的体例停止。那种计划的 overhead 十分高，所以我们接纳了历程间通信的体例，通过和微办事框架约定一个 unix domain socket 地址或者一个当地的端口，然后停止相关的流量劫持。固然那种体例相关于 iptables 会有一些性能提拔，它自己也存在的额外的一些开销。

我们是若何降低历程间通信开销的呢？在传统的历程间通信里，好比像 unix domain socket 或者当地的端口，会涉及到传输的内容在用户态到内核态的拷贝。好比恳求转发给数据面历程会涉及到恳求在用户态和内核态之间拷贝，数据面历程读出来的时候又会涉及内核态到用户态的拷贝，那么一来一回就会涉及到多达 4 次的内存拷贝。

我们的处理计划是通过共享内存来完成的。共享内存是 Linux 下更高性能的一种历程间通信体例，但是它没有相关的通知机造。当我们把恳求放到共享内存之后，别的一个历程其实不晓得有恳求放了进来。所以我们需要引入一些事务通知的机造，让数据面历程晓得。我们通过 unix domain socket 完成了如许一个过程，它的效果是能够削减内存的拷贝开销。同时我们在共享内存中引用了一个队列，那个队列能够批量收割 IO，从而削减了系统的挪用。它起到的效果也长短常明显的，在抖音春晚活动的一些风控场景下，性能能够进步 24%。

完成那些优化之后，要去落地的阻力就没那么大了。

总结

本次分享次要为各人介绍了 Service Mesh 手艺可以供给哪些流量治理才能来包管微办事的不变和平安。次要包罗三个核心点：

不变：面临瞬时亿级 QPS 的流量洪峰, 通过 Service Mesh 供给的流量治理手艺，包管微办事的不变性。平安：通过 Service Mesh 供给的平安战略，包管办事之间的流量是平安可信的。高效：春晚活动涉及浩瀚差别编程语言编写的微办事，Service Mesh 天然为那些微办事供给了同一的流量治理才能，提拔了开发人员的研发效率。Q&A

Q：共享内存中的 IPC 通信为什么可以削减系统挪用？

A：当客户端历程把一个恳求放到共享内存中之后，我们需要通知 Server 历程停止处置，会有一个唤醒的操做，每次唤醒意味着一个系统挪用。当 Server 还没有被唤醒的时候，或者它正在处置恳求时，下一个恳求到来了，就不需要再施行不异的唤醒操做，如许就使得在恳求密集型的场景下我们不需要去频繁的唤醒，从而起到降低系统挪用的效果。

Q：自研 Service Mesh 实现是纯自研仍是基于 Istio 等社区产物？若是是自研利用的是 Go 仍是 Java 语言？数据面用的是 Envoy 么？流量劫持用的 iptables 么？

A：

数据面是基于 Envoy 停止二次开发的，语言利用 C++。流量劫持用与微办事框架约定好的的 uds 或者当地端口，不消 iptables。Ingess Proxy 和营业历程摆设在同样的运行情况里，发布晋级不需要重启容器。