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