Python算法模型常用部署方式总结

Python算法模型常用部署方式总结

很绕口的标题,这段时间看了好些Tensorflow、Tensorflow-Serving相关的源码与文档,尝试搭建一个分布式的算法模型线上部署架构。

最开始调研了Tensorflow-Serving(毕竟名字大啊),对于其能自动识别并加装模型、可配置的模型版本管理策略、方便的A/B Test等等很是喜爱。可惜业务优先级调整,得优先部署算法团队基于python版本opencv、dlib实现的人脸识别算法,只好先将Tensorflow-Serving放一放,后续有时间会总结一些Tensorflow(-Serving)架构的源码分析。(后面也想到一种很低效的实现方式)。

言归正传,python算法模型常用部署方式总结:

预期功能

  • 分布式、可扩展、高可用、框架链路响应十毫秒内
  • 支持Python服务
  • 热部署(上线新服务时,无需重启/暂停框架)
  • 多服务(可部署多个算法服务,同时提供服务,服务间无耦合)
  • 多版本(支持单服务多版本同时在线)
  • 服务自动发现、自动部署

部署方案总结

  • 基于web-server(利用Django或Flask),部署python服务,提供restful api

  • 部署SOA + 算法服务

    Note: 即基于SOA框架实现分布式服务,其麻烦点在于绝大部分SOA框架都是基于JAVA/C++编写(例如常用的dubbo),而这里的算法服务却是基于python

    • 将python算法模型改写成JAVA or C++

      • 例如用PMML(JAVA)重新实现算法模型, 然后用JAVA重写个加载模型后的业务处理逻辑

        但是PMML无法封装dlib里的模型dlib_face_recognition_resnet_model_v1

    • JAVA服务类里直接调用shell命令执行python代码

    • 实现Python SOA(饿了么自研,思路开源,代码未开源)

    • 或者自研:python server + zk 构建服务集群,java client thrift调取服务

  • 专门的框架,如tensorflow-serving,可以能很方便的上线部署、灰度测试等等