Rancher有两个特色用起来很方便，那就是扩容和缩容。
一、扩容前的准备工作
为了能直观的查看效果，需要修改下demo_article项目的代码。
修改demo_article项目中ArticleController中的三处代码：
1.注入HttpServletRequest；2在findAll()方法的message参数后面加上request.getLocalAddr()，用于显示从调用的是哪个ip的容器的服务；3.注释掉pom中的instance-id
@Autowired private ArticleService articleService; @Autowired private HttpServletRequest request; @RequestMapping(method = RequestMethod.GET) public Result findAll(){ return new Result(true, "查询成功"+request.getLocalAddr(), articleService.findAll()); }
instance:
prefer-ip-address: true
# instance-id: article.com #如果需要在eureka注册多个服务，不能写死instance-id
修改完成之后，在Idea中，通过DockerMaven插件，重新打包并部署article镜像。
点击Idea界面左小角的Terminal，输入cd demo_article,进入demo_article项目下，再输入mvn clean package docker:build，重新将demo_article打成java包，并构建article镜像，并上传到docker本地仓库(192.168.31.181)中
在docker中，查看article镜像，可以看到article镜像在10秒前发生了变化，表示article镜像更新成功。
$ sudo docker images REPOSITORY TAG IMAGE ID CREATED SIZE article latest c92e406bc72a 10 seconds ago 651MB
...
二、扩容前的注意事项
在浏览器输入http://192.168.31.181:8080，进入rancher管理界面，然后在顶部导航栏中选择test环境，再点击顶部导航栏中的应用—全部，在点击进入microservice应用内：
以需要扩容article为例。
扩容article服务，简单理解就是同一个article服务，要复制并运行多个article服务。那么问题来了，运行的article服务，都是9001端口，而一个容器内，甚至一个系统内只有一个9001端口，这明显是有问题的。所以，需要把该article服务删除点，修改为不指定端口。
删除article服务，点击article服务那行最右边竖着的三点，选择删除即可。
删除之后，article服务就没了，此时我们需要再创建一个没有指定端口的article服务。除不指定端口外，其他都一样。
点击右上角的添加服务，配置图中红色框中的四处外，然后滚动到页面底部，点击创建
注意下图中红色框中的部分，端口号9001已经没了。
在浏览器中访问article服务，看看我们前面demo_article打包并构建后的镜像是否已经更新。由于没了端口，所以我们不能再通过http://192.168.31.181:9001/article访问，而是只能通过zuul网关去访问，也就是http://192.168.31.181:8888/myarticle/article。可能会500错误，由于发布article之后，rancher容器需要一个解析的过程。耐心等待大概一到两分钟，再刷新，即可看到访问成功。（如果还是访问不成功，可查看zuul、article等服务的运行日志，查看是否有错误）。
可以看到界面返回的结果中有查询成功，然后跟了一个ip地址：10.42.113.8，该ip地址是哪里来的呢？可在microservice应用列表管理界面中，点击article，打开article服务的详情界面，可以看到10.42.113.8，即为刚刚创建的没有带端口的article服务的ip地址。如下图所示。
三、扩容
还是以article服务为例。扩容前，先看看microservice应用列表管理界面中的所有服务。可以看到只有4个服务，其中article服务只有一个，而且没有指定端口号。
再来看看eureka注册中心欢迎页中，注册了哪几个服务。可以看到只注册了两个服务，一个DEMO-ARTICLE和DEMO-ZUUL
下面进行扩容操作。扩容操作，其实很简单。
点击顶部导航栏中的API，点击Webhooks
打开Webhooks的列表页面
点击添加接收器，新增一个接收器
配置详解：
名称：自己根据相关随便取，此处为文章扩容。
类型：选择扩缩容服务
操作：选择扩容
目标服务：选择microservice/article
步长：每次扩容多少个服务，可一次或1个或2个或3个，可自由选择扩容个数，此处设置为2个。
最小数量：article服务最小不能小于多少个，此处设置为默认的1个。
最大数量：article服务扩容到多少个就不再扩容了，此处设置为默认的100个。
点击创建，完成扩容接受器的添加操作。
添加完扩容触发器后，此时microservice应用中，还是只有一个article服务。因为还需要一个触发操作才能生效。
怎么触发呢？点击上图中的触发地址的复制图标，复制出触发地址。触发地址，其实就一个URL，需要利用POST请求，去调用一次该URL。
利用POSTMAN，新建一个REQUEST，粘贴触发地址，选择请求类型为POST，然后点击SEND
请求完成之后，点击顶部导航栏的应用，点全部，在打开的应用列表中，点microservice微服务，进入microservice应用列表管理界面
可以看到article服务，已经由以前的单容器，变成了3个容器。
如果需要再扩容两个容器怎么办呢？此时有个快捷操作，不需要再在webhooks中添加接收器，只需要复制刚刚的扩容触发地址，在postman中多send几次即可。
因为扩容的步长的2，所以每send一次请求，容器数量会增加2个。
点击article进入该服务看一下article服务详情。可以看到有了三个不同ip地址的容器（记住这三个IP地址）。
等待三个容器都启动完成（因为是在虚拟机中，机器性能有限，可能需要好几分钟，甚至十多分钟到半个小时，因为虚拟机的性能毕竟有限）。访问eureka，看看eureka注册中心中，注册了几个article服务。可以看到已经注册了三个article服务。
利用POSTMAN，通过zuul网关来访问article服务，多访问几次，看看是否达到负载均衡的效果
运行结果，会依次出现如下结果，这复合预期结果(zuul网关，默认采用的负载均衡机制就是轮询机制）：
四、缩容
缩容操作，和扩容操作很相似。
点击顶部导航栏中的API，点击Webhooks
打开Webhooks的列表页面
点击添加接收器，新增一个接收器
配置详解：
名称：自己根据相关随便取，此处为文章缩容。
类型：选择扩缩容服务
操作：选择缩容
目标服务：选择microservice/article
步长：每次缩容多少个服务，可一次或1个或2个或3个，可自由选择缩容个数，此处设置为1个。最大缩容步长不能大于先有容器数。
最小数量：article服务最小不能小于多少个，此处设置为默认的1个。
最大数量：article服务缩容到多少个就不再缩容了，此处设置为默认的100个。
点击创建，完成缩容接受器的添加操作。
添加完缩容触发器后，还需要一个触发操作才能生效。点击上图中文章缩容后面的触发地址下的的复制图标，复制出触发地址。触发地址，其实就一个URL，需要利用POST请求，去调用一次该URL。
在POSTMAN，新建一个REQUEST，粘贴触发地址，选择请求类型为POST，然后点击SEND
请求完成之后，点击顶部导航栏的应用，点用户，在打开的应用列表中，点microservice微服务，进入microservice应用列表管理界面，可以看到article服务的容器数已经由3个变成了2个。
如果需要再缩容一个容器怎么办呢？此时有个快捷操作，不需要再在webhooks中添加接收器，只需要复制刚刚的缩容触发地址，在postman中多send几次即可。
因为缩容的步长的1，所以每send一次请求，容器数量会减少1个。
访问eureka注册中心，查看注册了几个article服务。可以看到，也只是注册了两个article服务。
