58同城深度学习推理平台基于Istio的云原生网关实

SACC中国系统架构师大会

2022年10月27日~29日，由IT168旗下ITPUB企业社区平台主办的第十五届中国系统架构师大会（SACC2022）在云端进行网络直播。本届大会以“激发架构性能 点亮业务活力”为主题，按照技术主线分为传统架构线（高可用架构、云架构、分布式存储）、智能运维线（DevOps、安全设计、网络架构、数据中心等）、云原生技术线（云原生架构、微服务、容器、低代码）、前沿技术线（5G、DDD、知识图谱）以及行业架构应用主线（金融行业与制造业），云集国内CTO、研发总监、高级系统架构师、开发工程师和IT经理等技术人群，力争为各路豪杰奉献一场技术的饕餮盛宴。

58同城TEG-AI Lab后端资深工程师魏竹斌受邀出席，于2022年10月28日16:00-16:50在云架构设计与实践专场下分享了《58同城深度学习推理平台基于Istio的云原生网关实践》。

本文根据分享实录整理而成，欢迎大家阅读分享。

01

导读

AI正在驱动行业变革，为加速58同城AI应用的落地，AI Lab自2017年9月开始构建机器学习平台WPAI（Wuba Platform of AI），支持机器学习算法一站式开发，以提高AI工程师的研发效率。

图1 AI Lab产品能力

WPAI包括基础计算平台、算法应用平台两部分：

基础计算平台集中管理GPU、CPU、NPU硬件资源，支持机器学习模型离线训练和在线推理，在线推理服务支持自动扩缩容（弹性推理服务），离线训练作业和在线推理服务支持混合部署（离在线混部）。开发者可以向平台申请离线、在线资源，使用机器学习框架开发模型，打造自己的机器学习服务。

为了进一步提高AI工程效率，我们在基础计算平台之上继续打造了算法应用平台，包括NLP算法平台WubaNLP、图像算法平台凤凰（由58技术委员会AI分会基于WPAI基础计算平台协同共建）、排序学习平台（应用于搜索、推荐、广告系统）等。算法应用平台直接集成了相应领域下的常用模型，以Web的方式提供应用，开发者只需要在Web界面做相应配置即可完成训练和推理，大大提高开发效率。

在AI平台之外，我们还构建了AI周围子系统，如向量检索平台vSearch、AB实验平台日晷，以进一步提高AI工程效率。

WPAI机器学习平台是AI应用的底座，我们基于WPAI打造了灵犀智能语音语义平台、MAI智能营销引擎、智能写稿等，感兴趣可以添加58技术小秘书（jishu-58）咨询。

02

背景

展开全文

深度学习推理平台在架构上属于WPAI的子平台，旨在将算法人员使用深度学习框架训练出来的模型部署到生产环境，提供高性能、高可用的在线推理服务。总体架构如下图所示，底层依托于Kubernetes和Docker，实现了对GPU/CPU等资源的统一调度和管理，网关侧搭配Istio实现了推理服务发现和流量治理功能；算法层集成了TensorFlow、PyTorch和PaddlePaddle等优秀的深度学习框架，同时也支持用户自定义服务；应用层从模型管理、部署、推理加速和服务高可用保障等方向都提供了一系列功能。支撑了58同城在图像、NLP、语音、搜索、推荐、广告、风控领域内的各类AI应用，目前已上线模型数1000+，峰值节点数4000+，日均流量30亿。本文主要介绍深度学习推理平台推理架构的演进过程，以及新架构下在流量治理建设和可观测性建设方面的设计细节。

图2 深度学习推理平台架构

03

推理架构1.0

3.1推理架构1.0设计背景

每一种系统架构的设计都有其特定的历史背景，我习惯从需求驱动和技术支撑两方面去分析。

在WPAI上线之前，为支撑业务的快速发展，实现AI应用的快速落地，集团各业务部门只能选择各自为战，独立开发推理相关功能，但因为缺乏平台化管理、监控等能力，难免会出现研发、运维效率低下的问题；再加上算法与工程没有明确边界，导致算法同学深陷工程泥潭，无法将有限的精力聚焦在模型优化上，模型迭代效率也不尽如人意，所以集团对AI平台化能力有着迫切的需求。

从技术支撑角度看，由于K8S集群内外网络是不联通的，所以我们需要在集群边缘架设网关来打通整套推理流程，而当时集团自研的Java系RPC框架-SCF在经过多次版本迭代和集团多条业务线在生产环境的检验后，已经具备成熟的服务治理能力（如超时、限流、监控、告警等）、强大的横向扩展能力及高可用保障，并且对业务方来说基本没有学习和使用成本，所以为了满足业务方快速接入的需求，我们选用SCF作为网关实现搭建了我们1.0版推理架构。

图3 SCF整体架构

3.2推理架构1.0设计实现

推理架构1.0中的SCF网关属于传统API网关实现，下面我将使用当下比较流行的数据面和控制面概念对其进行描述。

控制面侧主要包括三大模块：

1、向下连接K8S集群，通过K8S List/Watch机制实现了服务注册发现功能，基于Endpoints构建了面向模型的、细粒度的gRPC连接池。

2、向上连接AI管理平台，通过WConfig（58自研配置中心）实现模型运行时参数的实时同步功能，例如超时时间、限流阈值等。

3、基于WOS（58自研对象存储服务）打造了协议转换jar插件中心。这里需要着重解释下：因为SCF网关无法透传gRPC请求，这要求我们在网关内部将每一个SCF请求转换为gRPC请求后，再转发给后端模型服务，返回数据同理。为实现这一功能，平台提供了标准协议转换接口，算法人员需要在模型上线前基于平台提供的接口实现模型特有的请求和返回数据数据转换逻辑，打成jar包后再通过平台管理界面上传到插件中心。

数据面侧则围绕服务治理相关功能打造了请求处理的Pipeline：包括鉴权、秒级限流、协议转换jar包热加载（收到模型第一次推理请求时通过自定义类加载器加载jar包）、Request/Response协议转换、加权负载均衡、流量转发、日志与异常处理等功能。

图4 推理架构1.0实现

3.3 推理架构1.0不足

推理架构1.0的上线，很好地解决了集团在线推理平台化能力缺失的问题，解耦了算法同学和工程同学的工作职责，提高了算法迭代和工程研发的工作效率。但随着接入方不断增多，业务方模型迭代需求的增加，1.0架构逐渐暴露出一些不足：

业务接入角度：协议解析Jar包的编写和上传，使得接入流程稍显复杂，增加了算法人员模型调试成本，而且接入方式单一，不支持HTTP方式接入。

服务性能角度：一方面SCF与gRPC协议互转会增加推理耗时；另一方面，SCF网络通信层是基于Netty实现的，Netty会给每一个SocketChannel分配一定的缓冲区（ByteBuffer）用于数据的读取，缓冲区大小直接影响服务的性能（分配过大会增加GC的回收压力，分配过小又会触发扩容，进而执行内存拷贝操作）。在Netty实现中，提供了一种“可预测性”的缓冲区分配机制来解决这个问题（核心实现参见io.netty.channel.AdaptiveRecvByteBufAllocator class），然而这套机制对size较大请求不太友好，例如图片美化类推理场景，当输入图片的size超过1M的时候，缓冲区会扩容到16M，所以SCF客户端连接数直接决定服务端JVM老年代的内存占用情况，随着接入规模增加会因为GC问题导致推理性能抖动。

开发运维角度：网关实现与第三方库紧密耦合，集成新功能或第三方库升级都需要对网关进行整体升级，成本较高（此处不得不提Log4j）。

04

推理架构2.0

4.1 Istio云原生网关

为了解决1.0推理架构这种传统网关实现所暴露的问题，我们决定升级推理架构，拥抱云原生网关Istio。Istio的定义关联甚广，快速了解Istio最好的方式就是从它的诞生时间线入手：

2012-2013年移动互联网开始兴起，企业对服务迭代效率提出了更高的要求，应用程序架构开始从单体逐渐转向微服务，服务规模开始初步增长。

2013年Docker开源，提供了更轻量级的虚拟化方案，解决了应用封装、隔离和移植性问题。

2014年Google宣布开源Kubernetes，为容器编排和生命周期管理提供了标准解决方案，集群向大规模、分布式快速发展，服务数量激增，拓扑链路复杂。

2016年Buoyant公司CEO William Morgan首次提出ServiceMesh定义：服务网格是一个基础设施层，用于处理服务间通信；云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭；在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。并同年发布第一代ServiceMesh产品—Linkerd。

2016年Envoy代理开源，在Lyft作为边缘代理得到生产级验证，作为可编程代理时代里程碑产品，其定义的

扫码加微信详细咨询太和智慧养老产品和平台服务！

扫码加微信详细咨询太和智慧养老产品和平台服务！