TensorFlow Serving 是一个适用于机器学习模型的灵活、高性能应用系统，专为生产环境而设计.
借助 TensorFlow Serving，可以轻松部署新算法和实验，同时保留相同的服务器架构和 API.
TensorFlow Serving 提供与 TensorFlow 模型的开箱即用型集成，但也可以轻松扩展以应用其他类型的模型和数据.
TensorFlow Serving 可以将训练好的机器学习模型部署到线上，使用 gRPC 作为接口接受外部调用.
TensorFlow Serving 支持模型热更新与自动模型版本管理。这意味着一旦部署 TensorFlow Serving 后，再也不需要为线上服务操心，只需要关心线下模型训练.
1. 核心概念
1.1. Servables
Servables 是 TF Serving 的中心抽象.
Servables 是客户端用来执行计算的底层对象，如查找和推断.
Servables 的尺寸和粒度是灵活的. 单个 Servable 可以是任何东西，从查询表的一个分片，到推断模型元组的单个模型.
Servables 可以是任意类型和任意推断，以确保灵活性和将来的进一步提升，如：
- 流结果
- 试验性 APIs
- 异步操作
Servables 并不管理其自己的生命周期.
Servabels 一般包含如下：
- TensorFlow SavedModelBundle (
tensorflow::Session) - 用于嵌入或词汇查询的查询表
1.2. Servable Versions
TF Serving 可以在耽搁服务器实例的生命周期内，处理一个或多个版本的 servable. 其有助于随着时间更新加载新的算法配置、权重和其他数据.
Servable Versions 支持同时加载多个版本的 servable，支持逐步展开和试验.
在使用服务时，客户端可以请求特定的 version id 或最新版本的特定模型.
1.3. Servable Streams
Servable Streams 是 servable 版本的徐蕾，根据版本号增量排序.
1.4. Models
TF Serving 将 model 表示为一个或多个 servable. 一个机器学习模型包含一个或多个算法(包括学习的权重) 和查询表(或嵌入表).
组合模型(composite model) 可以是如下情形之一：
- 多个独立的 servables
- 单个组合的 servable
此外，一个 servable 还可以对应于一个模型的一部分. 例如，比较大的查询表可以跨很多 TF Serving 实例.
1.5. Loaders
Loaders 管理 servable 的生命周期.
Loader API 支持独立于特定学习算法、数据或产品用例的公共基础设施.
Loader API 标准化了用于 servable 的加载和卸载的 API.
1.6. Sources
Sources 是用于寻找和提供 servable 的插件模块.
每个 Source 提供 0 个或多个 servable streams. 对于每个 servable stream，一个 Source 为每个可供加载的 version，提供一个 Loader 实例.
TF Serving 的 Sources 接口可以用于从任意存储系统中发现 servables. TF Serving 内置了通用参考 Source 实现. 例如，Sources 能够访问诸如 RPC 之类的机制，且可以轮询文件系统.
Sources 能够维护跨多个 servables 或版本所共享的状态. 其有助于使用 delta(diff) 更新不同 versions 间的 servables.
1.7. Aspired Versions
Aspired Versions 表示应该被加载和准备好了的 servable versions 的集合.
Sources 每次为单个 servable stream 传递该 servable visions 集合.
当一个 Source 向 Manager 给定新的 aspired versions 列表时，其将取代 servable stream 的现钱版本. Manager 将卸载列表中不再显示的所有以前加载的版本.
1.8. Managers
Managers 处理 Servables 的完整生命周期，包括：
- 加载 Servables
- 部署 Servables 服务
- 卸载 Servables
Managers 监听 Sources 并追踪所有的 versions.
Managers 尝试完成 Sources 的请求，但如果所需的资源不可用时，则会拒绝加载 aspired version.
Managers 也可以推迟卸载，例如，Manage 可能会等待卸载，直到新版本的完成加载. 这是基于确保始终至少加载一个版本的策略.
TF Serving Manager 提供了简单直接的接口 - GetServableHandle()，用于客户端访问加载的 servable 实例.
1.9. Core
采用标准的 TF Serving APIs, TF Serving Core 管理 servables 的几个方面：
- 生命周期 lifecycle
- 度量 metrics
2. Servable 生命
如图，
广义的来说，
[1] - Sources 创建 Servable Versions 的 Loaders.
[2] - Loaders 被作为 Aspired Versions 送到 Manager，以加载并部署服务到客户端请求.
更细节的来说，
[1] - Source 插件创建特定 version 的 Loader. 该 Loader 包含了 Servable 加载所需的元数据.
[2] - Source 采用回调(callback) 方式通知 Aspired Version 的 Manager.
[3] - Manager 采用配置的 Version Policy 来判断下一步要采取的行动，其可以卸载先前的加载版本或新增版本.
[4] - 如果 Manager 判断其是安全的，则给到 Loader 所需的资源，并告诉 Loader 加载新版本.
[5] - 客户端Clients 查询 Manager 以得到 Servable，或者是显式的指定版本，或者是请求最新版本. Manager 返回 Servable 的句柄(handle).
例如，假设一个 Source 表示一个频繁更新模型权重的 TF graph. 其权重存储在磁盘的文件里.
[1] - Source 检测到模型权重的一个新版本，其会创建一个包含指向磁盘模型数据的指针的 Loader.
[2] - Source 通知 Aspired Version 的 Dynamic Manager.
[3] - Dynamic Manager 根据 Version Policy，加载新版本模型.
[4] - Dynamic Manager 通知 Loader 内存足够. Loader 采用新的权重实例化 TF graph.
[5] - 客户端向模型的最新版本请求一个句柄，Dynamic Manager 返回 Servable 新版本的句柄.
大致思路如下：
[1] - 首先export model，准备计算图的代码，将保存的参数restore进入计算图；
[2] - 然后调用export model的方法，导出模型
[3] - 模型导出之后就直接拉取tensorflow serving的镜像然后创建，这里注意如果是tensorflow-serving-1.x.0的镜像，docker run之后就直接可以访问容器服务，tensorflow-serving-1.x.0-devel的镜像需要docker run之后，再进入容器运行.
[4] - tensorflow_model_server指定容器映射的端口，model_name等等，如果计算图没有其他依赖，直接拉取tensorflow-serving-1.x.0就行
[5] - 创建tensorflow serving镜像时需要指定端口映射，然后可以通过这个端口访问serving服务，还需要将宿主机自身模型的path挂载到容器的/models上
[6] - 如何使用运行好的容器服务？可以通过RESTful API访问，也可以通过gRPC API访问
[7] - 最后模型部分已经全部交给了tensorflow-server，再去写一个web服务包装一下就可以快速部署了.