微信 NLP 算法微服务治理

一、概述

马斯克收购了推特，但对其技术表示不满。认为主页速度过慢是因为有 1000 多个 RPC。先不评价马斯克所说的原因是否正确，但可以看出，互联网上为用户提供的一个完整的服务，背后会有大量的微服务调用。

 

 

以微信读书推荐为例，分为召回和排序两个阶段。

 

 

请求到达后，会先从用户特征微服务拉取特征，把特征组合在一起进行特征筛选，然后调用召回相关的微服务，这一流程还需要乘以一个 N，因为我们是多路召回，会有很多类似的召回流程在同时运行。下面的是排序阶段，从多个特征微服务中拉取相关特征，组合后多次调用排序模型服务。获得最终结果后，一方面将最终结果返回给调用方，另一方面还要将流程的一些日志发送给日志系统留档。

读书推荐只是微信读书整个 App 中非常小的一部分，由此可见，即便是一个比较小的服务后面也会有大量的微服务调用。管中窥豹，可以意料到整个微信读书的系统会有巨量的微服务调用。

大量的微服务带来了什么问题？

 

 

根据日常工作的总结，主要是有以上三方面的挑战：

① 管理方面：主要是围绕如何高效地管理、开发以及部署大量的算法微服务。

② 性能方面：要尽量提升微服务，特别是算法微服务的性能。

③ 调度方面：如何在多个同类算法微服务之间实现高效合理的负载均衡。

二、微服务所面临的管理问题

1、开发和部署：CI/CD 系统提供自动打包和部署

第一点是我们提供了一些自动打包和部署的流水线，减轻算法同学开发算法微服务的压力，现在算法同学只需要写一个 Python/ target=_blank class=infotextkey>Python 函数，流水线会自动拉取预先写好的一系列微服务模板，并将算法同学开发的函数填入，快速搭建微服务。

2、扩缩容：任务积压感知自动扩缩容

第二点是关于微服务的自动扩缩容，我们采取的是任务积压感知的方案。我们会主动去探测某一类任务积压或空闲的程度，当积压超过某一阈值后就会自动触发扩容操作；当空闲达到某一阈值后，也会去触发缩减微服务的进程数。

3、微服务组织：图灵完备 DAG / DSL / 自动压测 / 自动部署

第三点是如何把大量的微服务组织在一起，来构造出完整的上层服务。我们的上层服务是用 DAG 去表示的，DAG 的每一个节点代表一个对微服务的调用，每一条边代表服务间数据的传递。针对 DAG，还专门开发了 DSL（领域特定语言），更好地描述和构造 DAG。并且我们围绕 DSL 开发了一系列基于网页的工具，可以直接在浏览器里进行上层服务的可视化构建、压测和部署。

4、性能监控：Trace 系统

第四点性能监控，当上层服务出现问题时要去定位问题，我们构建了一套自己的 Trace 系统。针对每一个外来请求，都有一整套的追踪，可以查看请求在每一个微服务的耗时，从而发现系统的性能瓶颈。

三、微服务所面临的性能问题

一般来说，算法的性能耗时都在深度学习模型上，优化算法微服务的性能很大一部分着力点就在优化深度学习模型 infer 性能。可以选择专用的 infer 框架，或尝试深度学习编译器，Kernel 优化等等方法，对于这些方案，我们认为并不是完全有必要。在很多情况下，我们直接用 Python 脚本上线，一样可以达到比肩 C++ 的性能。

不是完全有必要的原因在于，这些方案确实能带来比较好的性能，但是性能好不是服务唯一的要求。有一个很著名的二八定律，以人与资源来描述，就是 20% 的人会产生 80% 的资源，换句话说，20% 的人会提供 80% 的贡献。对于微服务来说，也是适用的。

我们可以把微服务分为两类，首先，成熟稳定的服务，数量不多，可能只占有 20%，但是承担了 80% 的流量。另一类是一些实验性的或者还在开发迭代中的服务，数量很多，占了 80%，但是承担的流量却只占用的 20%，很重要的一点是，经常会有变更和迭代，因此对快速开发和上线也会有比较强的需求。

前面提到的方法，比如 Infer 框架，Kernel 优化等，不可避免的需要额外消耗开发成本。成熟稳定的服务还是很适合这类方法，因为变更比较少，做一次优化能持续使用很久。另一方面，这些服务承担的流量很大，可能一点点的性能提升，就能带来巨大的影响，所以值得去投入成本。

但这些方法对于实验性服务就不那么合适了，因为实验性服务会频繁更新，我们无法对每一个新模型都去做新的优化。针对实验性服务，我们针对 GPU 混合部署场景，自研了 Python 解释器 —— PyInter。实现了不用修改任何代码，直接用 Python 脚本上线，同时可以获得接近甚至超过 C++ 的性能。

 

 

我们以 Huggingface 的 bert-base 为标准，上图的横轴是并发进程数，表示我们部署的模型副本的数量，可以看出我们的 PyInter 在模型副本数较多的情况下 QPS 甚至超越了 onnxruntime。

 

 

通过上图，可以看到 PyInter 在模型副本数较多的情况下相对于多进程和 ONNXRuntime 降低了差不多 80% 的显存占用，而且大家注意，不管模型的副本数是多少，PyInter 的显存占用数是维持不变的。

我们回到之前比较基础的问题：Python 真的慢吗？

没错，Python 是真的慢，但是 Python 做科学计算并不慢，因为真正做计算的地方并非 Python，而是调用 MKL 或者 cuBLAS 这种专用的计算库。

那么 Python 的性能瓶颈主要在哪呢？主要在于多线程下的 GIL（Global Interpreter Lock），导致多线程下同一时间只能有一个线程处于工作状态。这种形式的多线程对于 IO 密集型任务可能是有帮助的，但对于模型部署这种计算密集型的任务来说是毫无意义的。

 

 

那是不是换成多进程，就能解决问题呢？

 

 

其实不是，多进程确实可以解决 GIL 的问题，但也会带来其它新的问题。首先，多进程之间很难共享 CUDA Context/model，会造成很大的显存浪费，这样的话，在一张显卡上部署不了几个模型。第二个是 GPU 的问题，GPU 在同一时间只能执行一个进程的任务，并且 GPU 在多个进程间频繁切换也会消耗时间。

对于 Python 场景下，比较理想的模式如下图所示：

 

 

 

通过多线程部署，并且去掉 GIL 的影响，这也正是 PyInter 的主要设计思路，将多个模型的副本放到多个线程中去执行，同时为每个 Python 任务创建一个单独的互相隔离的 Python 解释器，这样多个任务的 GIL 就不会互相干扰了。这样做集合了多进程和多线程的优点，一方面 GIL 互相独立，另一方面本质上还是单进程多线程的模式，所以显存对象可以共享，也不存在 GPU 的进程切换开销。

PyInter 实现的关键是进程内动态库的隔离，解释器的隔离，本质上是动态库的隔离，这里自研了动态库加载器，类似 dlopen，但支持“隔离”和“共享”两种动态库加载方式。

 

 

以“隔离”方式加载动态库，会把动态库加载到不同的虚拟空间，不同的虚拟空间互相之间看不到。以“共享”方式加载动态库，那么动态库可以在进程中任何地方看到和使用，包括各个虚拟空间内部。

以“隔离”方式加载 Python 解释器相关的库，再以“共享”方式加载 cuda 相关的库，这样就实现了在隔离解释器的同时共享显存资源。

四、微服务所面临的调度问题

多个微服务起到同等的重要程度以及同样的作用，那么如何在多个微服务之间实现动态的负载均衡。动态负载均衡很重要，但几乎不可能做到完美。

为什么动态负载均衡很重要？原因有以下几点：

（1）机器硬件差异（CPU / GPU）；

（2）Request 长度差异（翻译 2 个字 / 翻译 200 个字）；

（3）Random 负载均衡下，长尾效应明显：

① P99/P50 差异可达 10 倍；

② P999/P50 差异可达 20 倍。

（4）对微服务来说，长尾才是决定整体速度的关键。

处理一个请求的耗时，变化比较大，算力区别、请求长度等都会影响耗时。微服务数量增多，总会有一些微服务命中长尾部分，会影响整个系统的响应时间。

为什么动态负载均衡难以完美？

方案一：所有机器跑一遍 Benchmark。

这种方案不“动态”，无法应对 Request 长度的差异。并且也不存在一个完美的 Benchmark 能反应性能，对于不同模型来说不同机器的反应都会不同。

方案二：实时获取每一台机器的状态，把任务发给负载最轻的。

这一方案比较直观，但问题在于在分布式系统中没有真正的“实时”，信息从一台机器传递到另一台机器一定会花费时间，而在这一时间中，机器状态就可以发生了改变。比如在某一瞬间，某一台 Worker 机器是最空闲的，多台负责任务分发的 Master 机器都感知到了，于是都把任务分配给这台最空闲的 Worker，这台最空闲的 Worker 瞬间变成了最忙的，这就是负载均衡中著名的潮汐效应。

方案三：维护一个全局唯一的任务队列，所有负责任务分发的 Master 都把任务发送到队列中，所有 Worker 都从队列中取任务。

这一方案中，任务队列本身就可能成为一个单点瓶颈，难以横向扩展。

动态负载均衡难以完美的根本原因是信息的传递需要时间，当一个状态被观测到后，这个状态一定已经“过去”了。YouTube 上有一个视频，推荐给大家，“Load Balancing is Impossible” https://www.youtube.com/watch?v=kpvbOzHUakA。

关于动态负载均衡算法，Power of 2 Choices 算法是随机选择两个 worker，将任务分配给更空闲的那个。这个算法是我们目前使用的动态均衡算法的基础。但是 Power of 2 Choices 算法存在两大问题：首先，每次分配任务之前都需要去查询下 Worker 的空闲状态，多了一次 RTT；另外，有可能随机选择的两个 worker 刚好都很忙。为了解决这些问题，我们进行了改进。

 

 

改进后的算法是 Joint-Idle-Queue。

 

 

我们在 Master 机器上增加了两个部件，Idle-Queue 和 Amnesia。Idle-Queue 用来记录目前有哪些 Worker 处于空闲状态。Amnesia 记录在最近一段时间内有哪些 Worker 给自己发送过心跳包，如果某个 Worker 长期没有发送过心跳包，那么 Amnesia 就会逐渐将其遗忘掉。每一个 Worker 周期性上报自己是否空闲，空闲的 Worker 选择一个 Master 上报自己的 IdIeness，并且报告自己可以处理的数量。Worker 在选择 Master 时也是用到 Power of 2 Choices 算法，对其他的 Master，Worker 上报心跳包。

有新的任务到达时，Master 从 Idle-Queue 里随机 pick 两个，选择历史 latency 更低的。如果 Idle-Queue 是空的，就会去看 Amnesia。从 Amnesia 中随机 pick 两个，选择历史 latency 更低的。

在实际的效果上，采用该算法，可以把 P99/P50 压缩到 1.5 倍，相比 Random 算法有 10 倍的提升。

五、总结

在模型服务化的实践中，我们遇到了三个方面的挑战：

首先是对于大量的微服务，如何进行管理，如何优化开发、上线和部署的流程，我们的解决方案是尽量自动化，抽取重复流程，将其做成自动化流水线和程序。

第二是模型性能优化方面，如何让深度学习模型微服务运行得更加高效，我们的解决方案是从模型的实际需求出发，对于比较稳定、流量较大的服务进行定制化的优化，对于实验型的服务采用 PyInter，直接用 Python 脚本上线服务，也能达到 C++ 的性能。

第三是任务调度问题，如何实现动态负载均衡，我们的解决方案是在 Power of 2 Choices 的基础上，开发了 JIQ 算法，大幅缓解了服务耗时的长尾问题。