tensorflow serving-serving a tensorflow model

（学习使用，仅供参考） 详细请参考：https://www.tensorflow.org/serving/serving_basic
这章教你怎样使用tf serving export出一个已经训练好的模型，并使用标准的tensorflow_model_server 将其服务出去。

这章需要两部分代码：
　　a python file:mnist_saverd_model.py,它用来训练和导出模型
　　一个modelsever二进制文件，这个modelserver可以找到新导出的模型并调用gRpc服务将其服务出去。

１．Ｔｒａｉn and Export tf　Model
你可以在mnist_saverd_model.py中看到，训练部分和MNIST For ML Beginners tutorial中的相同，ｔｆ graph在ｓｅｓｓ中开始运行，其输入为ｘ(input tensor[image])，其输出为y(output tensor[softmax score])

 然后我们使用SavedModelBuilder module去export模型，SavedModelBuilder保存一个训练过模型的“snapshot”，以便在预测的时候可以被load。

from tensorflow.python.saved_model import builder as saved_model_builder
...
export_path_base = sys.argv[-1]
export_path = os.path.join(
      compat.as_bytes(export_path_base),
      compat.as_bytes(str(FLAGS.model_version)))
print 'Exporting trained model to', export_path
builder = saved_model_builder.SavedModelBuilder(export_path)
builder.add_meta_graph_and_variables(
      sess, [tag_constants.SERVING],
      signature_def_map={
           'predict_images':
               prediction_signature,
           signature_constants.DEFAULT_SERVING_SIGNATURE_DEF_KEY:
               classification_signature,
      },
      legacy_init_op=legacy_init_op)
builder.save()

SavedModelBuilder.__init__需要下面的参数：
　1.export_path 导出的路径
SavedModelBuilder在没有目录的时候创建目录，在这个例子中，拼接了命令行参数和model_version得到真正的导出目录，FLAGS.model_version指定的模型的版本，下一次导出的版本一定要比上次导出的版本版本号大，每个版本的模型都被导出到同一指定目录下的不同子目录。

你可以使用builder添加子图和变量，用SavedModelBuilder.add_meta_graph_and_variables(),其具有以下参数:
　１．sess 是一个tf session,它包含你导出的训练模型
　２．tags 是一系列的tags，它们用来保存子图，在这个例子里，因为我们想在serving中使用图，我们使用已经在SavedModel tag 常量中定义好的serve　tag.
 　３．signature_def_map指定 。。。，Signature 指定什么类型的模型将会被导出，并指定预测时的input/output

signature_def_map中的serving_default指定默认的serving signature,默认的serving signature def key,和其他的与signature相关的常量一起，被定义为SavedModel signature常量。

如果你想更容易的build signature defs

tensorflow serving－architecture overviw

（学习所需，仅供参考）
TensorFlow服务是一个灵活的，高性能的机器学习模型的服务系统，专为生产环境而设计。 他可以轻松部署新的算法和实验，同时保持相同的服务器体系结构和API。 TensorFlow服务提供与型号的即时集成，但可以轻松扩展到其他类型的型号。

1.关键概念
你首先应该知道下面几个关键的概念。

１．１　Servables
Servables是TF Serving的关键抽象。 Servables是客户端计算图时的隐藏对象。一个Servable的大小和颗粒是灵活的，一个Servable可以包含从单个表到单个模型或者多个模型的所有东西，Servables可以有任意类型和种类的接口，使其能够足够敏捷和扩展：
　 streaming results／experimental APIs／asynchronous modes of operation
Servables不管理自己的生命周期，典型的Servables有以下几种：
　 a TensorFlow SavedModelBundle (tensorflow::Session)
　 a lookup table for embedding or vocabulary lookups

１．1.1 Servable Versions
 TensorFlow服务可以在单个服务器实例的整个生命周期内处理一个或多个可服务的版本。 这使得新的算法配置，权重和其他数据可以随着时间加载。 版本允许同时加载多个可执行版本，支持逐步推出和实验。 在服务时间，客户可以请求特定型号的最新版本或特定版本号。

1.1.2 Servable Streams
可服务的流是可序列化的序列，按照增加的版本号进行排序。

1.1.3 Models
TensorFlow服务表示一个模型作为一个或多个服务。 机器学习模型可以包括一个或多个算法（包括学习权重）和查找或嵌入表。
您可以将复合模型表示为以下任一项：
     多个独立的服务
     单一复合可服务
可服务的也可以对应于模型的一部分。 例如，可以在许多TensorFlow服务实例中分割大型查找表。

１．１．４ Loaders
Loaders管理servables的生命周期，一个Ｌｏａder API支持独立于特定学习的算法。具体来说，Loaders标准化了loading和unloading服务的接口。

１．１．５　Sources
Sources are plugin modules that originate servables; each Source originates zero or more servable streams. For each stream, a Source supplies one Loader instance for each version it wants to have loaded. (To be precise, a Source is actually chained together with zero or more SourceAdapters, and the last item in the chain emits Loaders.)

TensorFlow Serving’s interface for Sources is simple and narrow, so it lets you use arbitrary storage systems to discover servables to load. Sources may access other mechanisms such as RPC. TensorFlow Serving includes common reference Source implementations. For example, TensorFlow Serving can poll a file system.

Sources can house state that is shared across multiple servables or versions, for special cases such as models that efficiently accept delta updates.

1.1.6 Aspired Versions
Aspired Versions代表了可以被装载好了的servable版本的集合，Sources通过一个单独的servable流与其沟通，当Ｓｏｕｒｃｅ把一个新的列表的版本交给Manager时，它就取代了前面的一个版本，


２．Managers
Managers处理Servables的整个生命周期，包括：
　　loading Servables
       serving Servables
       unloading Servables
 Managers监听ｓｏｕｒｃｅｓ并且追踪所有的版本，Managers尝试去实现Sources的请求，但是在请求资源不存在的时候，Managers会拒绝load aspired version,同时，他也有可能推迟unload.例如：一个Manager可能会等待知道一个更新的版本被load完毕，其政策是确保ｌｏａｄ的版本一定是最新的版本。

Managers提供一个简单的接口－GetServableHandle(),让客户端去获取ｌｏａｄed的servable实例。

３．Ｃｏｒｅ
TensorFlow Serving Core manages (via standard TensorFlow Serving APIs) the following aspects of servables:
    lifecycle
    metrics
TensorFlow Serving Core treats servables and loaders as opaque objects.

4.Life of a Servable

一般来说：
　　１．Sources为Ｓｅｒｖａble版本创建Loaders
　　２．Loaders将Aspired versions送到manager,manafer ｌｏａｄ它们，被将它们用来服务来自客户端的请求。
更多的细节：
　　１．一个Ｓｏｕｒｃｅ为具体的版本创建一个Ｌｏａｄｅｒ.这个ｌｏａｄｅｒ包含去load一个servable所需要的一切资源。
　　２．Source通过回传通知Manager Ａｓpired version是什么
　　３．Manager通过配置的版本文件决定下一步的动作，可能是unload先前的版本或者load一个新的版本
　　４．如果Ｍａｎａｇｅｒ确定它是安全的，他就给Ｌｏａｄｅｒ需要的资源并且告诉Loader去load一个新的版本
　　５．客户端向Manager要Ｓｅｒvable,或者具体的某个版本或者仅仅只是请求最新的版本，Manager返回Servable的句柄。

举例来说：
一个Source(代表一个Tf 图，它的权重时常更新，这些权重被存储在文件或者磁盘里)
　　１．Ｓｏｕｒｃｅ检测到模型权重更新到一个新的版本，它创建一个Loader，其包含一个指向模型数据的指针。
　　２．Ｓｏｕｒｃｅ通知Manager　Ａspired version
       3. Manager通过版本策略决定去ｌｏａｄ一个新的版本
　　４．Ｍａnager告诉loader内存足够，Ｌoader用新的权重实例化ＴＦ图
　　５．客户端请求模型的最新版本，Manager返回一个Servable的句柄


５．Ｅｘtensibility(可扩展性)
TensorFlow服务提供了几个扩展点，您可以在其中添加新功能

６．Ｖｅｒsion Policy(上文提到的版本策略)
版本策略指定单个可流式流中版本加载和卸载
TensorFlow服务包括两个适用于大多数已知用例的策略。 这些是可用性保护策略（避免加载零版本;通常在卸载旧版本之前加载新版本）和资源保存策略（避免同时加载两个版本，从而需要两倍资源;卸载旧版本之前加载 一个新的）。 为了简单地使用TensorFlow服务，其中模型的可用性很重要且资源成本低，则可用性保留策略将确保在卸载旧版本之前加载并准备好新版本。 对于TensorFlow服务的复杂使用，例如跨多个服务器实例管理版本，资源保护策略需要最少的资源（无需额外的缓冲区来加载新版本）。

bleu

记录一下：https://wenku.baidu.com/view/891482f5e2bd960591c677d4.html

shell ,bash,tmux

笔者对这几个命令一直很不了解，搜到一篇好文章，准备有时间看，记录如下：
Shell的相关概念和配置方法

优雅地使用命令行：Tmux 终端复用 

Linux下终端利器tmux

隔壁大神的博客： tmux安装使用

记录一下：
linux下常用命令，有时间再看
awk sed wc grep
cat more less
netstat