python模型部署到服务器_18 模型部署上线的几种服务发布方式

在前面所有的模型训练和预测中，我们训练好的模型都是直接通过控制台或者 Jupyter Notebook 来进行预测和交互的，在一个系统或者项目中使用这种方式显然不可能，那在 Web 应用中如何使用我们训练好的模型呢？本文将通过以下四个方面对该问题进行讲解：

微服务架构简介；

模型的持久化与加载方式；

Flask 和 Bottle 微服务框架；

Tensorflow Serving 模型部署和服务。

微服务架构简介

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自 DDD 领域驱动设计。

相对于单体架构和 SOA，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

一组小的服务：服务粒度要小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情；

独立部署运行和扩展：每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。

独立开发和演化：技术选型灵活，不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的 API 进行集成。相对单体架构，微服务架构是更面向业务创新的一种架构模式。

独立团队和自治：团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

由此，我们可以看到整个微服务的思想，与我们现在面对信息爆炸、知识爆炸做事情的思路是相通的：通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速地应对变化。

我们为什么采用微服务呢？

“让我们的系统尽可能快地响应变化”

——Rebecca Parson

下面是一个简单的微服务模型架构设计：

模型的持久化与加载方式

开发过 J2EE 应用的人应该对持久化的概念很清楚。通俗得讲，就是临时数据(比如内存中的数据，是不能永久保存的)持久化为持久数据(比如持久化至数据库中，能够长久保存)。

那我们训练好的模型一般都是存储在内存中，这个时候就需要用到持久化方式，在