2

我讀了Martin Fowler的Blue/Green Deployment文章,非常喜歡它。基本上,這是一個概念,你有2個生產級環境:一個「藍色」LIVE環境和一個「綠色」LIVE環境。在任何特定時間,您只有1個環境被認爲是「真正的」LIVE環境。所以,你在這兩個LIVE環境前面加入了某種路由/交換機制(可能是一箇中介網絡應用或者一個修改過的軟件負載均衡器),這個環境決定了用戶將路由到哪個環境(我們在這裏說的是web應用)。GWT應用程序可以部署藍色/綠色部署嗎?

因此,您已將所有用戶路由到http://green.example.com/myapp的Green LIVE環境。然後,當您準備推出一些新的製作更改時,無需將它們部署到Green LIVE,而是將它們部署到Blue LIVE,然後開始將一小部分(〜10%)用戶轉接到Blue LIVE。典型的策略是讓路由器使用IP地址或cookie來確定用戶是否應該路由到藍色或綠色。

如果您確信生產更改沒有錯誤/問題(適用於Blue LIVE),則重新配置路由器,現在將所有流量重定向到藍色LIVE,網址爲http://blue.example.com/myapp。現在

,到我的問題:

我設計一個GWT應用程序,想實現這個藍色/綠色開關模式。問題是GWT應用程序是客戶端,並且不遵循Spring,Struts,JSP,servlet應用程序使用的正常的服務器端Web應用程序體系結構。

所以我問:我怎麼能有2個Tomcat實例(Blue Tomcat和Green Tomcat),爲藍牙/綠色「路由器」後面的用戶提供兩個不同版本的相同GWT應用程序?通過「路由器」,我可能在談論一箇中介網絡應用http://router.example.com/myapp-router

從外觀上看,這裏的問題:

green.example.com:8080/opt/tomcat/webapps/myapp.war/ --> Green Tomcat 
    myModule/ 
     mymodule.nocache.js 
     mymodule.cache.html } typical GWT app WAR structure... 
    hosts/      this is currently the "real" LIVE 
     index.html    environment where 90% traffic is routed to 
    css/ 
     main.css 
    WEB-INF/ 
     web.xml 
     lib/ 
     classes/ 

blue.example.com:8080/opt/tomcat/webapps/myapp.war/ --> Blue Tomcat 
    myModule/ 
     mymodule.nocache.js 
     mymodule.cache.html } typical GWT app WAR structure... 
    hosts/      new production changes have been deployed here 
     index.html    and 10% of users are routed here 
    css/ 
     main.css 
    WEB-INF/ 
     web.xml 
     lib/ 
     classes/ 

router.example.com:8080/opt/tomcat/webapps/myapp-router.war/ --> Router 
    WEB-INF/ 
     web.xml 
     lib/   } simple headless WAR that inspects HTTP Requests and 
     classes/   determines which environment to redirect user to 

這是基本的架構:問題是,客戶將作出請求router.example.com/myapp-router,並且路由器將上要麼blue.example.com/myappgreen.example.com/myapp轉發請求。我不相信,一旦GWT應用程序下載到客戶端,GWT(我在這裏使用RequestFactory)將最終知道與blue或​​進行通信。

所以我問:這可能嗎?是否有任何特殊的配置/代碼/庫/技術等,我將需要利用,以使這項工作?任何警告或陷阱我沒有想到?提前致謝!

+0

您描述的部署過程實際上是金絲雀部署(增量式),而不是藍綠色部署(全部一次)。這並不會使你的問題無效,但它需要修改。 –

回答

0

無論部署策略如何,都需要進行相同的部署準備工作:藍綠色,金絲雀(請參閱您的其他問題Canary release strategy vs. Blue/Green,瞭解差異的討論)或升級單臺服務器。單個客戶端的成功升級的瀏覽器級視圖是相同的:每個請求都會看到舊版本,發生部署,每個請求現在都會看到新版本。同樣,單個客戶端瀏覽器級別的失敗升級和回滾視圖也是一樣的。

幾年前,當我使用GWT應用程序時,我們的策略是捕獲GWT在服務器上遇到新的不兼容版本時引發的異常,並向用戶顯示一條消息,要求他們刷新其瀏覽器。本文給出了更多細節:http://codebetter.com/kylebaley/2012/01/06/deploying-a-new-version-of-a-gwt-app-2/它還提到,如果您使用Google App Engine,則可以使用GAE的Channel API檢測應用程序的新版本已發佈,然後要求用戶刷新。但是,無論您採用哪種策略,它都適用於任何部署流程。

相關問題