理解和实现分布式TensorFlow集群完整教程
分布式TensorFlow简介
前一篇《分布式TensorFlow集群local server使用详解》我们介绍了分布式TensorFlow的基本概念，现在我们可以动手搭建一个真正的分布式TensorFlow集群。
分布式TensorFlow集群由多个服务端进程和客户端进程组成，在某些场景下，服务端和客户端可以写到同一个Python文件并起在同一个进程，但为了简化代码让大家更好理解分布式架构，我们将启动两个worker并使用单独的客户端进程。
确认TensorFlow版本
首先我们需要安装和确认TensorFlow的版本，注意0.8版本以前的TensorFlow不支持分布式，使用以前版本需要重新合Patch和打包。
python -c "import tensorflow; print(tensorflow.__version__)"
使用TensorFlow容器
如果本地已安装Docker，通过容器使用TensorFlow环境更加简单，只需一行命令。
sudo docker run -it tensorflow/tensorflow bash
Docker除了实现资源隔离，还可以管理不同版本的环境，例如可以很容易试用最新的RC版本。
sudo docker run -it tensorflow/tensorflow:r0.9rc0 bash
实现TensorFlow服务端
很多开发者读过TensorFlow官方的Distributed Guide，想把分布式TensorFlow运行起来却十分困难，主要原因是官方文档没有提供完整的例子，而且提供的代码片段只能在0.9中运行，因此很多人尝试修改那段代码还是跑不起来。
其实分布式TensorFlow使用非常简单，我们并不需要一个通用的程序，只要用几行代码分别实现服务端和客户端即可，最简单的服务端代码如下worker1.py。
import tensorflow as tf
worker1 = "10.235.114.12:2222"
worker2 = "10.235.114.12:2223"
worker_hosts = [worker1, worker2]
cluster_spec = tf.train.ClusterSpec({ "worker": worker_hosts})
server = tf.train.Server(cluster_spec, job_name="worker", task_index=0)
server.join()
这里我们定义了两个worker，其中job名都是“worker”，官方文档中还定义了名为“ps”的job，实际上有没有都可以，而worker可以是本地不同端口的两个进程或者多台服务器上的进程。
为了模拟分布式环境，我们编写worker2.py启动第二个worker，注意代码上稍有区别，因为index变了不能与前面的冲突，为了避免端口被容器隔离我们可以使用原来的Docker容器。
import tensorflow as tf
worker1 = "10.235.114.12:2222"
worker2 = "10.235.114.12:2223"
worker_hosts = [worker1, worker2]
cluster_spec = tf.train.ClusterSpec({ "worker": worker_hosts})
server = tf.train.Server(cluster_spec, job_name="worker", task_index=1)
server.join()
可以看到worker1和worker2分别监听本地的2222和2223端口，接下来可以单独写客户端应用，连接这两个targe即可。
实现TensorFlow客户端
Client的代码我们写得稍微复杂些，就是构造写线性数据，其中斜率是2、截距是10，如果梯度下降算法正确的话最终w和b的输出应该也接近2和10。
如我们所料，最终结果相当接近2和10，同时指定了第一个worker的CPU来执行梯度下降的算法，通过cluster spec我们还可以定义更灵活的集群，客户端也可以通过"tf.device"来动态指定CPU和GPU计算资源。在生产环境下，官方推荐使用ps服务器存储Variables，而ps其实是和我们定义的worker一样，只是job名不同，架构可以参见官方文档的tasks图。
最后总结
希望通过这个完整的使用教程，大家都能亲自实现分布式TensorFlow集群，并且编写灵活的服务端和客户端应用。
而在搭建过程中，大家可能发现TensorFlow只是一个深度学习的Library，我们需要实现和部署服务端、客户端应用，而在集群定义中存在一个较严重的问题，就是cluster spec需要在进程启动时指定，无法实现动态的扩容或缩容，这个问题社区希望通过引入Kubernetes集群管理工具来解决。还有一个问题就是我们的服务端应用启动时只能bind localhost，我们也在Github建了对应Issue，如果大家都这些问题感兴趣，也请继续关注我和我们后续的文章。
