MicroServiceDemo是一个微服务示意项目，在版本二的基础上，把它与Docker结合起来
（毕竟，微服务和容器是好基友啊）
如何找到名服务器？
之前的版本中，我们是手动指定名服务的真实IP地址的，这样做有两点不足：
- 名服务可能被部署到不同的物理机器上（虽然可以通过配置指定名服务部署到“主”节点上）
- 被迫开放名服务器的端口（我们不希望外界能够访问到名服务）
在这个版本中，我们直接使用Docker带来的服务端负载均衡技术，即如图：
很容易就解决了之前的问题
容器的网卡数量？
从以上两张图来看，我们的容器至少会有两张网卡，但实际上：
有三张网卡
那么，其它微服务会向名服务注册哪张网卡的地址呢？
（很可能是随机的，或者说是一个极其简单的规则；总之不是我们想要的）
通过docker network inspect microservicedemo_backend_network命令，我们可以知道：我们希望其它微服务向名服务注册的 IP 地址
那怎么做到这件事情（指定需要组册的网卡 / 地址）呢？
注意docker-compose.yml中的网络名称与application.yaml中的网络名称稍有不一致
真正的网络名称可以通过两种方式获得：
docker stack deploy -c docker-compose.yml microservicedemo命令的提示- 通过
docker network ls查看并选取
如何减少编译需要的时间？
有一个“巨坑”是这样的：Docker在执行完每一条命令之后，会删除中间容器；我们下载的缓存也会被清除掉
原因是maven的本地仓库是一个“暂时”目录？
所以我们需要改动settings.xml文件：
把缓存目录设置为/home/repository，这样下载的缓存才不会被删除掉
诸如simpleClient的微服务总是找不到communicationClass依赖项？
（同三号坑）
我们设计的每一个 API 都有其用意，一定是为了验证什么东西
四个方法分别验证：
simpleCLient微服务是否可访问- 通过 Path 传递参数
- 通过 Headers 传递参数
- 通过 Body 传递参数
这一个版本验证：
apiGateway可以转发不同的请求- 普通请求
- 参数放在 Path 的请求
- 参数放在 Headers 的请求
- 参数放在 Body 的请求
apiGateway可以验证用户身份
光看 API 很难知道这是为了什么，所以我们来看看源代码
检验能否调用其它 Java 微服务
检验能否调用非 Java 微服务（ Java -> Sidecar）
检验：通过客户端负载均衡调用自己的 API 接口
好像是配合apiGateway才能展示其作用？
看是否可以通过apiGateway获取用户信息？
大部分同simpleClient + apiGateway，只说一下four这个接口
这说明apiGateway确实可以告诉我们：是哪个用户来访问 API ？
我们再看看不通过apiGateway访问complicatedClient与通过apiGateway访问complicatedClient的区别：
到这里我们确信：apiGateway可以告诉别的微服务当前用户是谁（当然apiGateway还可以提供其它信息）
不妨调用complcaitedClient的one API ，然后看看容器日志：
可以看到使用容器的编号来做客户端负载均衡
而不是使用simpleClient这样的名字来隐式（悄悄地让Docker帮助我们）地做服务端负载均衡
docker build -t micro-service-demo .
docker stack deploy -c docker-compose.yml microservicedemo
docker stack rm microservicedemo构建镜像 + 部署微服务（运行容器）
commit: 90ac74dc04bb80c20b135819e2fab85324fd9f08