作者 | 百度内容生态研发团队
导读
内容了解推理服务是内容了解数据流上的多个推理服务的汇合，对来自百家号、难看、全民、直播等多个发文方的文本、图片、视频等内容进行了解，并标记内容标签，为百度Feed信息流、搜寻等C端用户提供内容。长期的业务迭代，积攒了近千推理服务，存量服务的运维治理和新增服务的高效接入，是十分有挑战性的工作，本文基于理论工作教训分享Punica零碎是如何晋升业务迭代效率和服务稳定性的。
全文5106字，预计浏览工夫13分钟。
01 背景
内容了解服务是对百家号、难看、全民、直播等多个发文方的文本、图片、视频等内容进行了解，并标记内容标签，为百度Feed信息流、搜寻等C端用户提供内容，例如，自媒体用户在百家号提交了一篇对于美食的文章，通过内容了解的举荐策略服务，会进行了解并标记美食标签，而后Feed信息流会基于内容标签和浏览用户的喜好进行匹配举荐。
内容了解服务是架构对立微服务推理框架，不同业务自建服务App，在架构平台上注册和治理，基于PaaS进行调度，共有近千的CPU和GPU类型的服务App。在业务接入、迭代、运维过程中存在如下问题：在开发阶段，推理框架参数多、配置老本高，且推理服务封装后性能升高；在测试阶段，测试数据结构老本高，测试资源有余，且每次补充测试资源均须要创立一个单实例的App，补充老本高；在上线阶段，业务同学须要学习厂内多个PaaS平台的利用创立流程，监控&报警增加繁琐，新服务接入须要操作多个平台，协调期待线上资源，失常状况下实现上线须要两周，而策略迭代频繁，均匀每个月要新增数十策略服务，服务接入存在较高的人力耗费；在部署&运维阶段，因为服务部署依赖较多较大lib包下载，新实例部署耗时20+分钟，服务存在低弹性、扩容止损慢等问题，另外存量服务有近千App，架构降级老本高，架构框架、云原生革新等均须要操作大量App；另外服务的资源利用率低，存在较大的资源节约，业务老本高且新服务上线资源筹备老本高。
02 整体思路
为了解决上述问题，咱们思考如何晋升业务接入、迭代、保护的效率，同时晋升资源利用效率，升高业务老本，次要从两个方面开展：一站式+无人值守。
2.1 一站式平台
平台加一减N：将多个平台对立至Punica平台，缩小用户学习和应用老本，无需创立PaaS服务，提供一站式推理服务接入、迭代、测试、上线、运维等性能。
晋升服务迭代速度：将服务参数配置平台化，提供举荐参数配置，测试期间反对疾速批改验证；测试资源疾速补充，无需创立PaaS服务；提供自动化测试工作，用户仅需提交测试工作，由Punica零碎主动调配闲时资源，主动调节压测参数，用户只需关注最终测试后果；反对业务疾速小流量验证，应用零碎内的冗余资源后行小流量验证成果；对于新服务上线，能够主动减少监控、报警，缩小用户操作老本。
升高业务资源老本：在反对通用性&易用性的Python微服务推理框架的同时，还反对高性能C++微服务推理框架；反对多种GPU卡，例如T4、P4、A10、A30以及高性价比的昆仑卡, 通过联结厂内GPU同学，基于CGPU、MPS、MIG等机制，反对小规格（半卡、1/4卡等）的GPU卡配额；在调度层面，能够主动调度多模型在GPU卡上混部；同时，Punica还集成了PaddlePaddle的模型性能优化流程，从模型层面升高业务资源老本。
通过一站式平台，用户将训练好的模型以及前后置解决代码提交到模型仓库和代码仓库，在Punica平台注册服务、测试、上线，缩小了跨平台操作、测试环境筹备、期待资源投产等耗时，整体上线周期从两周升高到一周，缩小用户学习老本。
2.2 无人值守
Punica在服务部署上解耦推理服务部署包与推理框架、Python、Cuda、Cudnn等lib包，lib包可提前预下载，理论部署时仅需下载推理服务部署包，因而推理FaaS服务具备高弹性能力。
资源主动调度：资源定期回收，通过监控资源利用率，低利用率服务资源回收定期告诉；资源分时复用，在肯定范畴内对服务进行主动扩缩容，在服务间腾挪资源，反对业务小流量、测试、历史数据回溯等，对于线上高优服务容量问题，能够长期腾挪低优资源保障高优服务稳定性。
服务自愈巡检零碎：通过实例自愈，基于业务/容器/机器指标主动决策、处理单实例故障；通过服务成功率巡检&online率巡检，及时发现服务线上稳定性问题；基于算子拓扑的故障决策树，定位服务故障根因。
升高保护老本：PaaS App缩小1个数量级，对于服务云原生革新、监控增加/调整等工作，缩小人力开销；算子接入时即可满足准入要求，算子代码库、接口人、监控等要害信息齐全；架构降级成本低，无需一一App进行上线操作，只需灰度公布，更新算子依赖框架版本即可。
服务自愈巡检零碎会监测各个服务模块实例级/服务级的业务/容器/机器的指标衰弱度，通过决策树断定单服务故障类型，并将故障信息反馈到服务拓扑上，而后再通过决策树断定服务的故障根因。接下来通过一个案例来介绍：一个上游服务存在故障实例，导致上游服务成功率升高，触发入口服务的重试，导致申请流量翻倍，进而引发服务雪崩。对于该案例，服务自愈巡检零碎会在上游服务呈现单实例故障时感知并进行单实例故障处理，进而阻止故障重大；如果呈现服务重试导致流量翻倍状况，自愈零碎会疾速断定零碎容量有余进行容量补充，避免服务雪崩。
在容量治理方面，服务的频繁迭代会带来泛滥问题，例如：新旧服务切换，旧服务没有及时下线，导致资源节约；服务容量评估不精确，线上服务存在容量危险或者资源节约；业务流量变动频繁，服务拓扑结构复杂，人工调整老本高。针对这类问题，从几个方面进行了容量治理：低利用率服务资源回收，解决服务下线、容量评估不精确导致的资源节约问题；基于服务资源负载的容量主动扩缩，解决服务容量危险问题，缩小人工操作老本；基于服务流量预测的分时伸缩，造成肯定的闲时资源池，供应给闲时工作应用。另外，也通过多模型混部、GPU混部等技术解决小卡服务以及极限利用率较低的模型的资源利用率问题。
03 技术计划
首先给大家介绍一下Punica零碎中用到的云原生概念：IaaS，基础设施即服务，容器服务如docker；PaaS，平台即服务，容器调度零碎如EKS、Kubernetes；FaaS，函数即服务，Punica零碎中推理模型即服务。
咱们从FaaS角度，从新定义推理服务，建设一站式平台和无人值守机制，隔离业务与PaaS部署，让业务更轻量、更简洁。通过隔离业务与PaaS根底环境，解耦了业务与根底环境，架构能够对根底环境进行对立治理和收敛，晋升服务部署速度，使业务服务具备高弹性。
整体架构如下图所示，次要包含四局部：FaaS零碎，包含容器框架、调度零碎、Proxy 网关模块，提供推理服务高弹性部署与调度；平台前端，提供对立的推理服务接入、测试、上线、治理页面，资源报表展示，伸缩&自愈事件展示等；平台后端，提供对应页面的后端性能，同时反对OpenAPI调用，提供FaaS服务治理、服务测试迭代、资源管理等；服务治理，提供FaaS服务自愈巡检、容量伸缩等。
其中平台前/后端作为Punica零碎的服务接入、系统管理平台。上面次要介绍FaaS零碎和服务治理机制。
3.1 服务部署
建设Punica容器框架，对接并革新推理微服务框架，将业务环境与根底环境拆散，对根底环境进行托管，同时收敛根底环境的版本；从框架层对接Prometheus监控，将容器、机器、业务指标上报，由百度云Prometheus团队提供对立的监控视图和报警。
上面简略介绍下容器框架的性能点：心跳机制，提供探活能力，上报调度零碎该节点是否失常运行以及该节点上部署的推理服务信息&状态，同时接管调度零碎下发的服务更新、创立、删除等命令；部署能力，反对服务的创立、更新、重启、删除、进行等性能，同时能够配置lib预下载，提前下载相干lib包，服务部署仅需下载模型包即可；干涉机制，反对进行心跳、屏蔽流量、屏蔽心跳命令的干涉接口；Debug机制，反对节点信息查问，包含节点部署门路、部署服务信息等；线下部署能力，反对线下独自部署，用于本地测试。
3.2 服务调度
在调度零碎中，咱们联合推理服务与PaaS服务的部署状况，定义了推理服务到PaaS服务的部署映射关系。PaaS服务在一个Cluster中部署的一组正本（Node）称之为一个部署组（App），推理服务在一个Cluster中部署的一组正本（Replica）称之为一个实例组（Resource），一个Node具备了Replica部署所需的根底环境，只须要加载对应的模型文件和业务前后置代码即可。
基于此，咱们对以后推理服务的运行环境进行归类整顿，依据硬件环境分为CPU、GPU，其中GPU又依据卡类型具体分为T4、P4、A10、A30、昆仑卡。针对不同硬件环境，Node节点会提前预置好相干运行环境。
调度零碎实现了推理服务的Resource到PaaS App、Replica到Node的映射，通过映射关系，实现了推理服务的容量伸缩、实例迁徙、版本更新等机制。
3.3 服务发现
在PaaS上部署的App个别是通过百度对立名字服务来做服务发现的。对于部署在Punica中的推理服务，咱们须要提供对立的服务发现机制。
首先来介绍一下Punica中推理服务部署的拓扑信息如何获取，下面讲到了调度零碎实现了推理服务到PaaS App的映射，因而调度零碎能够提供推理服务每一个Replica部署所在容器的IP、Port。对于一个推理服务，咱们就能够通过查问调度零碎来获取该推理服务部署在Punica中的节点拜访地址列表。
通过调度零碎，咱们能够获取到指定服务的地址列表，为了升高用户的应用老本，同时反对限流和鉴权性能，咱们建设了推理服务对立网关模块。网关模块定义了用户名、token、特色id，由这三个字段定义一组路由配置，具体包含服务地址、鉴权配置、限流配置。通过自定义baidu-rpc的naming插件，查问 Punica服务地址，实现路由能力；通过申请中的用户名、token、特色id进行鉴权；依据用户名、token、特色id减少限流配置。
3.4 策略控制器
咱们心愿通过服务治理策略尽量实现无人值守，缩小策略同学、架构同学的运维老本。次要从以下几个方面进行建设：服务巡检自愈，通过定期&报警回调检测服务要害指标，依据教训决策树+服务拓扑构造进行根因定位，反对机器级别故障、实例级别故障&热点、服务级别故障辨认与主动解决；分时/主动扩缩容，通过在肯定范畴内对服务容量动静扩缩，保障高优服务的容量水位，同时供应出局部闲时资源；服务资源低利用率定期回收，通过定期检测服务长期利用率状况，对资源利用率长期处于较低水位的服务进行缩容或下线解决；资源市场，维持零碎内整体资源的容量水位，对资源供应与生产对立管控；闲时工作，反对历史数据回溯、自动化测试工作等闲时资源应用。
3.5 Punica零碎外部交互
用户将业务代码上传至代码仓库、模型上传至模型仓库，在Punica平台注册服务，填写服务的业务背景、接口人、代码库、运行环境等根底信息，而后发动准入测试工作，Punica平台会依据用户填写的服务信息拉取服务的代码和模型，并生成推理服务部署包，通过Operator模块为用户筹备测试环境，当用户测试实现后，本次测试的推理服务部署包会被调配一个版本号并固化在afs上；用户在平台新建实例组或者对已有实例组更新服务版本时，能够抉择曾经公布的推理服务部署包进行上线更新，Operator模块会管制服务正本滚动更新，容器框架在接管到Operator模块的调度信息后，会依据服务的版本信息更新本地的部署版本；Proxy网关模块会承接所有业务流量，并对流量进行鉴权、限流、负载平衡，而后将流量路由至对应的推理服务正本。
04 总结
咱们从业务迭代、资源提效登程，联合以后推理服务开发、部署、运维现状，尝试了从FaaS角度来建设Punica零碎，晋升业务迭代效率，平台加一减N，新服务上线效率晋升100%，保障线上服务的稳定性，服务扩容速度晋升5倍，升高业务的资源老本，目前已累计回收400+张GPU卡，曾经投产到新业务的迭代倒退。
——END——
举荐浏览：
精准水位在流批一体数据仓库的摸索和实际
视频编辑场景下的文字模版技术计划
浅谈流动场景下的图算法在反作弊利用
Serverless：基于个性化服务画像的弹性伸缩实际
图片动画化利用中的动作合成办法
性能平台数据提速之路