part2 正文：
上回说到，自己搭建的server，性能不ok，耗时太严重，欲改变tensorflow源码又改不动，走投无路之时，突然在某stackoverflow的某问题回答上出现了tf serving这几个字，瞬间发现新大陆。本章节围绕概要的第三部分基于grpc的tf serving展开。主要从tf serving的基本介绍，tf serving 从github clone，到提交服务的详细步骤。训练好的model如何导出为tf serving需要的形式 3个方面来介绍。
（1）tf的基本介绍，tf serving是一个灵活高性能的为tensorflow 训练的model提供对外服务的server，官网给出的基本逻辑架构图如下所示。
结合上图简要介绍如下几个概念Servables，Servable Versions，Servable Streams，Models，Loaders，Sources，Aspired Versions，Managers，Core然后将上图的整体流程做简述。
Servables，是tf serving最核心的概念，从上图也可以看到，Serverables是被loader加载然后与client交互的，也就是tf serving提供的基础服务如predict，look_up等。典型的Serverables根据自己能提供的计算服务包含两种类型，1是tensorflow训练的model（SavedModelBundle）2是查询embeding 结果的lookup table。
Servable Versions，tensorflow在model export的过程中，生成的文件夹里会有一个数字为文件名的文件夹，标志着model的version，tf serving在提供服务的过程中，可以依次提供多个version的Serverables，默认情况下，tf serving是提供最新版本的model服务。当然也可以指定某个version id。Servable streams，顾名思义就是一系列的servable，只是 servable versions不同罢了。
Loader 是负责掌管一个servable的生命周期的。可以load，以及unload
Source简单的说是servable产生的源头，一般是file system，也就是本地硬盘，也可以是RPC。
Aspired versions，是那些应该被加载的servable versions，source提供给manager每次应该加载和卸载的aspired versions。
Managers 负责通知loader是否加载servable，对外提供服务，以及卸载servable
上图的整体流程可以简单理解成Source创造一个loader来准备加载某个model version。Source通过回调通知Manager 现在的Aspired version，Manager 判断现在是否可以让loader加载这个servable，如果可以那么loader就加载该model version，恢复graph等信息。最后Manager提供一个该model version的handler。这样client就可以访问了。
说了这么多，如果我们训练好了model，到底该如何用tf serving 启动一个服务让外界来访问呢。请看下面的具体步骤.
1.关于tensorflow serving所依赖的一些包／库请参考https://www.tensorflow.org/serving/setup 安装
2.安装完成后git clone --recurse-submodules https://github.com/tensorflow/serving
3.build tensorflow_model_server,请在serving 目录下运行 bazel build -c opt //tensorflow_serving/model_servers:tensorflow_model_server。如果build成功 在bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server处的二进制文件极为server
4.start server, 运行命令bazel-bin/tensorflow_serving/model_servers/tensorflow_model_server --port=9000 --model_name=＊＊＊ --model_base_path=＊＊＊。 需要特别注意里面的model_name 以及model path是你生成的model所在的地方。此时如果看到屏幕上出现server成功启动的log信息输出，那么此时server启动成功。
如果想要改变一下，server的代码，比如我在开发过程中，需要额外输出一些log，这样我能有效的监控服务的请求情况，这时候需要改变/serving/tensorflow_serving/model_servers/main.cc, 改变这个文件需要参考protobuffer生成的api函数，protobuffer请参考https://developers.google.com/protocol-buffers/. tf serving里的proto存在如下几个地方。/serving/tensorflow/core/example/, /serving/tensorflow_serving/apis/, tensorflow/core/framework/,tensorflow/core/protobuf/,tensorflow/core/lib/. 如下几个地方.运行protoc -I=$SRC_DIR --cpp_out=$DST_DIR $SRC_DIR/＊＊.proto.每一个proto会生成两个文件一个.pb.h 一个.cc.我们可以参考这个两个文件里定义的函数以及具体实现来完成我们自己的需求.我当时在main.cc的188行class PredictionServiceImpl final : public PredictionService::Service这个类里面的predict函数里加了如下日志。当然大家可以根据自己的需求来增加。这些都是非常基础的。
最后服务的部署，我的服务根据现在的用户量级，几十万uv，每次请求需要rank的文档ave500个。计算了一下当前线上的峰值qps，然后部署在了16核，64G的机器上，具体几台也不透漏了。在服务上限前对服务进行了压测。压测到当前线上服务的qps峰值的1.5倍依然ok。完成了上线。在平均响应时间方面完全ok,约26ms，与论文所叙述情况基本数量级上不差。
参考：
引用1.https://www.tensorflow.org/serving/serving_basic
引用2.https://www.tensorflow.org/serving/setup
完成于20170826，如转载请注明出处
