背景

家喻户晓python在机器学习实际中的利用宽泛深刻，而在咱们业务中的利用集中在提供线上实时风控输入服务，比方国内业务的模型在线服务架构和海内业务的后盾决策引擎架构。这两种利用的联合就要求咱们思考如何高效平安便捷地来实现模型的在线部署，为上游提供服务。

在咱们的思考中，无论是代码复杂程度和业务场景，还是语言自身的特点，模型部署都有趋于向微服务架构转型的趋势和须要。一方面，须要进行代码拆散来明确责任分工进步开发效率和容错性。另外一个方面，python在CPU密集型的利用中体现是无奈令人满意的。为了应用协程来进步异步性从而解决更多的并发申请，最间接地就是将CPU密集转化为IO密集，因为Python天生就适宜IO密集型的网络应用。

因而，咱们生产中将模型计算抽取为model_lib代码库，并且通过微服务online_model进行交互。这里咱们调研过两种模型部署的形式，最终抉择了第一种。

一、基于flask框架进行模型部署

Flask是一个轻量级的可定制框架，具备灵便、轻便且高效的特点，并且是规范的wsgi接口框架，易于扩大和保护。

1. 为什么选用nginx+uwsgi+flask这种技术架构

1)    Uwsgi搭配nginx性能快，内存占用低，高度可定制，自带详尽日志性能，反对平滑重启。

2)    Flask齐全兼容了wsgi规范； 微框架，扩展性强； 齐全基于unicode，不需解决编码问题；自带服务可独立做单元测试及开发。

3)    咱们客户端采纳了tornado协程，曾经实现了将cpu计算转为io操作，服务端齐全是CPU密集的模型计算，不会开释过程，异步框架放弃大量文件描述符状态消耗内存，因而不实用异步IO框架。

2. 业务流程框架

3. 部署形式：

部署形式采纳nginx+uwsgi+flask的形式，uwsgi可间接承受socket而不是http申请进步性能，再将服务转发给flask框架，这里留神flask此类wsgi标准接口的服务框架比方djangoweb.py在生产中个别不应用自带服务，而是在下层部署uwsgi或者gunicorn作为服务器来进行服务转发，下层再用nginx来做负载平衡，这样能够进步服务稳定性和性能。

4. 性能比对

微服务革新后20并发申请模型：

微服务革新前20并发申请模型：

本机测试并发性能就进步了20%，但留神这是在高并发的状况下，就单条申请来看，微服务并不能显著进步性能。

二、 基于grpc进行在线模型部署

在 gRPC 里客户端利用能够像调用本地对象一样间接调用另一台不同的机器上服务端利用的办法，可能更容易地创立分布式应用和微服务。与许多 RPC 零碎相似，gRPC 也是基于以下理念：定义一个服务，指定其可能被近程调用的办法(蕴含参数和返回类型)。在服务端实现这个接口，并运行一个 gRPC 服务器来解决客户端调用。在客户端领有一个存根可能执行在服务端实现的一样的办法(这个办法就相似于接口)

1. 为什么选用grpc进行模型部署

1)grpc应用ProtoBuf来定义服务、申请返回的数据格式，压缩和传输效率高，语法简略，表达力强。(如下为ProtoBuf的序列化和反序列话性能体现)

2)grpc可反对tensorflow serving的接口调用，tensorflow实现模型训练和部署后，可提供服务接口，给grpc进行调用。实现不便，高效，自带版本治理、模型热更新等，很适宜大规模线上业务，是咱们下一步模型部署的技术方向。

3)gRPC反对多种语言，并可能基于语言主动生成客户端和服务端性能库。

2. 部署形式(业务流程与之前雷同)

部署形式采纳nginx+grpc,要求nginx反对http2.0。在客户端将json特色字典转为protobuf。(https://github.com/NextTuesday/py-pb-converters/blob/master/pbjson.py 这里附上json和protobuf互相转化的脚本。)

3. 服务发现与负载平衡

4. 开发流程

客户端：

服务端：

三、 两种形式线上模型部署比照

1)    grpc应用protbuf更加简单，须要在客户端服务端均保留protbuf文件并做校验，而flask只须要做好对立的接口标准标准即可。

2)    grpc应用http2.0更实用挪动端的在线模型预测，或者基于tensorflowd的大规模线上模型部署和预测，flask更实用后端面向服务的手动模型部署和预测。

3) grpc节俭数据空间，但与python交互须要做json和protbuf数据转换，flask兼容wsgi规范，实用于RESTful类服务，但数据传输占用空间较大。