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服務。
