在上一篇文章中，我們示範了如何使用藍綠釋出來實作熱部署，但是在實際生産的場景中，應用的拓撲結構會複雜很多。在本篇文章中我們将會讨論下複雜應用拓撲中的藍綠釋出方案以及藍綠釋出适用的場景。
大于大多數場景而言，對客戶提供服務的軟體的形态有三種。一種是前端類服務，使用者可以直接或者間接通過網頁、接口調用使用該服務提供的能力；一種是後端類服務，使用者無法直接使用該服務提供的功能，該服務主要的使用者是其他服務，并通過其他服務最終将處理後的結果回報給使用者；第三種是排程任務類服務，即不被使用者使用也不被其他服務調用，它的生命周期隻存在在一個任務的執行生命周期中，通常任務的執行周期完畢，服務的生命周期就停止，通常為無狀态資源密集性服務。
對于上述三種場景，以路由權重切換為主要實作方式的釋出政策例如藍綠釋出、a/btest等通常情況下比較适用于前端類服務與後端類服務。下面我們用一個簡單的例子來拆解下如何使用阿裡雲容器服務來實作這兩類服務的藍綠釋出。
在上一篇釋出政策的文章中，有的開發者會問我的應用的拓撲關系不是單體的，不能通過單一容器級别的路由權重切換解決。在此要明确的一件事情，藍綠釋出是一種釋出政策，部署的最小次元是容器，而釋出的最小次元是應用。藍綠釋出的原理是老的應用的版本不變，新的應用版本進行部署，如果新版本與老版本之間應用的名字以及相關的配置沒有改變，那麼會認為這個應用是新老版本中共用的，無需變更；需要進行變更的應用通過名字的不同進行區分。簡單的來講，藍綠釋出是一個應用級别的更新操作，你可以對一個服務進行兩個版本之間的切換，服務是一個邏輯的概念，而不是容器這樣一個實體的概念，藍綠釋出可以做複雜拓撲的應用更新操作。
下面我們通過一個拓撲結構複雜一點的例子來講述藍綠釋出。應用的拓撲結構如下：
serviceb會調用servicea，這兩個都是python建構的，代碼如下：
servicea,通過接口傳回資料 “world!”
serviceb,調用servicea的接口，并将傳回的資料字段前面添加 “hello ”
傳統應用之間的調用方式可以是通過配置ip位址或者域名來調用，也可以通過服務注冊中心中的位址的方式調用，但是對于一個無狀态的多執行個體的服務，常見的做法是使用用戶端的負載均衡器或者伺服器的服務均衡器端點來實作。在容器服務中使用的方式是使用伺服器端的負載均衡端點的方式，提供内部調用的路由端點，來實作後端服務的負載均衡。大緻的調用方式如下。
通路serviceb的對外通路位址，可以得到：
我們最開始基本結構的應用就已經部署完畢了，下面開始進行不同服務的藍綠釋出。
首先我們先看如果做前端服務的藍綠釋出，也就是說要對serviceb進行藍綠釋出的流程。大緻的結構圖如下。
在這個應用中前端服務的藍綠釋出，也就是對serviceb進行藍綠釋出，下面我們修改serviceb的代碼
修改編排模闆，進行藍綠釋出
進行藍綠釋出更新後，可以看到更新後的服務清單，其中黃色的servicea-v1表示目前的應用在藍綠釋出的過程中不會産生變化，serviceb-v1為老版本，serviceb-v2為新版本
通過路由清單選擇相應的權重管理，進行權重的調整，将servicea-v1的權重調整為0，将servicea-v2的權重調整為100，此時通路serviceb的網址可以發現。
驗證完畢，點選确認釋出完成，完成藍綠釋出。
我們再看下如何做後端服務的藍綠釋出，也就是說對servicea進行藍綠釋出。大緻的結構圖如下。
修改編排模闆
部署後的服務清單：
此時可以發現serviceb-v2在本次釋出中不會進行變更，調整服務的權重
此時再通路serviceb的位址，可以得到如下的結果
藍綠釋出是一種用于更新與更新的釋出政策，對于增量更新有比較好的支援，但是對于涉及資料表結構變更等等不可逆轉的更新，并不完全合适用藍綠釋出來實作，需要結合一些業務的邏輯以及資料遷移與復原的政策才可以完全滿足需求，希望給位開發者可以在自己的業務場景中，更靈活的使用和實作藍綠釋出。