前言
最近在進行單元化建設方面的的工作，其中涉及服務分組和藍綠髮布相關的概念，在這裡總結一下了解到的相關知識。
版本更新策略
功能開關
在應用邏輯裡內建功能開關，通過開關的開啟關閉來決定執行新舊邏輯，無需路由機制支援，開發人員可以靈活的控制程式的表現。這種方式需要動態配置中心的支援，目前業界已經有比較完善的解決方案，比如Apollo、spring cloud config等等。具體的方式類似這樣：
if Config.SwitchOn {
//new logic
} else {
//old logic
}
複製程式碼功能開關的方式雖然簡單直觀，但是隨著版本的更新需要經常清理過期配置，維護成本比較高。
灰度部署/金絲雀部署
灰度部署是指先更新一小部分伺服器比如2%，然後對應用進行測試驗證。如果驗證通過，則繼續更新剩餘部分的伺服器，否則進行回滾。灰度部署的好處就是影響面小，出現問題時只會影響很小一部分使用者，適合對新功能信心不足或是對服務可用性要求比較高的場景。
滾動部署
滾動部署更像是灰度部署的增強版，當新版本經過灰度驗證通過之後，我們逐漸增大灰度部署的範圍，直到全部的伺服器都更行到新版本。在部署過程中需要支援平滑切換，即先把伺服器從負載均衡列表中摘除；此外滾動釋出通常是分批次的，比如第一批10%，第二批30%，第三批100%等等。
滾動部署相比灰度部署，需要自動化部署工具以及完善的路由機制支援，這樣才能保證使用者體驗足夠平滑；此外滾動部署比起灰度部署的釋出和回滾時間也會更長。
藍綠部署
藍綠部署技術是指同時維護兩套相同的生產環境，我們可以稱之為藍色環境和綠色環境，而只有一個顏色的環境負責提供完整的服務，另一個環境則完全空閒。當我們需要部署新版本的服務時，我們先在空閒的環境進行部署和驗證，當驗證完畢後，通過操作路由將客戶端流量切換至新版本的環境，而原先的環境則變為空閒環境，依次迴圈交替。
要實現藍綠部署，需要幾個額外支援：
- 完善的、操作成本低的路由控制機制，運維人員可以動態地進行流量切換
- 冗餘資源，任意時刻其中一個環境的資源是閒置的。當然我們可以把閒置的環境作為預發驗證環境，或者把刪除一部分空閒環境的資源，等下次釋出時再擴充資源
藍綠部署的好處：
- 可以降低停機時間，我們的生產環境幾乎沒有停機時間，切換在很短的時間內即可完成
- 可以快速回滾，當新功能不符合預期是我們只需要將流量切換回上一個版本的環境即可
- 可以提高災備能力，當一個環境出現問題時我們可以迅速切換到另一個可用的環境。實際上每次釋出都相當於進行了一次災備切換
藍綠部署的不足：
- 資源利用率不足，因為一般的資源是閒置的
- 當流量切換完畢之後，可能在後端仍有業務邏輯沒有處理完畢，需要額外的機制保證。你可以在設計時就保證兩個環境可以同時處理事務，這樣就不需要考慮這個問題了；也可以在切換流量前先將服務設定為“只讀模式”，流量切換完畢再回到“讀寫模式”等等。
- 新舊版本可能會涉及資料庫表結構的變化，這時我們需要額外的資料庫相容措施。當切換到新的環境發生問題時，可能會因為新的邏輯導致資料差異。要解決這種問題可以將資料庫重構與應用釋出分開：先進行資料庫重構以保證新舊版本相容，資料庫重構完畢後再進行應用釋出。
其他概念
單伺服器組合雙伺服器組
前面提到的藍綠部署需要兩個環境，實際上就相當於雙伺服器組。二灰度部署和滾動部署也可以用於雙伺服器組。比如雙伺服器組中的灰度部署就是在藍綠環境切換時不是一刀切，而是先切換一小部分到新環境，驗證通過後再全量切換到新環境；而滾動部署在雙伺服器組中就是分批次切換到新環境。
伺服器組
在進行伺服器組劃分時，可以有不同程度的劃分：根據資料中心劃分，比如A機房為一組、B機房為一組；根據邏輯分組劃分，比如A、B機房的一半機器分為一組、剩下的另一半機器分為一組。無論如何分組，請求在服務之間傳遞時都是需要識別某個機器的分組標識的，比如在註冊中心中服務例項的後設資料裡需要有類似"group=group1"這樣的標識，這樣客戶端或者代理節點在進行路由時才能識別服務端例項所在的分組。
路由機制
前面提到的各種部署策略，實際上都需要不同程度的路由機制支援。對於HTTP服務可以使用代理節點的方式，在域名解析過程中分發到不同的下游節點；RPC服務則需要實現配套的路由機制了。