在一般情況下，升級服務器端應用，需要將應用源碼或程序包上傳到服務器，然後停止掉老版本服務，再啓動新版本。但是這種簡單的發佈方式存在兩個問題，一方面，在新版本升級過程中，服務是暫時中斷的，另一方面，如果新版本有BUG，升級失敗，回滾起來也非常麻煩，容易造成更長時間的服務不可用。
爲了解決這些問題，人們研究出了多種發佈策略，下面我們一一介紹。
藍綠部署
所謂藍綠部署，是指同時運行兩個版本的應用，如上圖所示，藍綠部署的時候，並不停止掉老版本，而是直接部署一套新版本，等新版本運行起來後，再將流量切換到新版本上。但是藍綠部署要求在升級過程中，同時運行兩套程序，對硬件的要求就是日常所需的二倍，比如日常運行時，需要10臺服務器支撐業務，那麼使用藍綠部署，你就需要購置二十臺服務器。
滾動發佈
滾動發佈能夠解決掉藍綠部署時對硬件要求增倍的問題。
所謂滾動升級，就是在升級過程中，並不一下子啓動所有新版本，是先啓動一臺新版本，再停止一臺老版本，然後再啓動一臺新版本，再停止一臺老版本，直到升級完成，這樣的話，如果日常需要10臺服務器，那麼升級過程中也就只需要11臺就行了。
但是滾動升級有一個問題，在開始滾動升級後，流量會直接流向已經啓動起來的新版本，但是這個時候，新版本是不一定可用的，比如需要進一步的測試才能確認。那麼在滾動升級期間，整個系統就處於非常不穩定的狀態，如果發現了問題，也比較難以確定是新版本還是老版本造成的問題。
爲了解決這個問題，我們需要爲滾動升級實現流量控制能力。
灰度發佈
灰度發佈也叫金絲雀發佈，起源是，礦井工人發現，金絲雀對瓦斯氣體很敏感，礦工會在下井之前，先放一隻金絲雀到井中，如果金絲雀不叫了，就代表瓦斯濃度高。
在灰度發佈開始後，先啓動一個新版本應用，但是並不直接將流量切過來，而是測試人員對新版本進行線上測試，啓動的這個新版本應用，就是我們的金絲雀。如果沒有問題，那麼可以將少量的用戶流量導入到新版本上，然後再對新版本做運行狀態觀察，收集各種運行時數據，如果此時對新舊版本做各種數據對比，就是所謂的A/B測試。
當確認新版本運行良好後，再逐步將更多的流量導入到新版本上，在此期間，還可以不斷地調整新舊兩個版本的運行的服務器副本數量，以使得新版本能夠承受越來越大的流量壓力。直到將100%的流量都切換到新版本上，最後關閉剩下的老版本服務，完成灰度發佈。
如果在灰度發佈過程中（灰度期）發現了新版本有問題，就應該立即將流量切回老版本上，這樣，就會將負面影響控制在最小範圍內。