灰度發佈

灰度發佈，對於大廠來講是必不可少的，對於我這種歷來沒有灰度發佈過的，並非很清楚，估計也有不少人不知道這個東西。之前只是直到灰度發佈，此次稍微瞭解一下。

灰度發佈是指新版本或者新功能經過必定策略選取一些用戶，讓他們先使用，經過使用狀況對功能、性能、穩定性等指標評估是否擴大範圍直至全面發佈。

灰度發佈開始到結束期間的這一段時間，稱爲灰度期。

優勢：

提早收集用戶使用意見，提早優化、修復bug。

讓用戶參與產品測試，增強與用戶互動，下降產品升級所影響的用戶範圍。

選取用戶是很關鍵的一點，能夠經過城市、年齡、id等一系列條件選取少部分用戶，而資源則經過選取以後，判斷是不是灰度用戶，而後指定呈現新版本仍是舊版本。

web前端灰度發佈若是是服務端渲染，經過服務端判斷是不是灰度用戶直接返回對應的版本頁面。若是是經過框架，那麼就須要在一個html裏面判斷，而後分別使用打包後的兩個不一樣資源。若是是原生html的項目，則所須要判斷的會更多。

若是是客戶端的灰度發佈，應該是能夠按照用戶逐漸推送更新安裝包。而服務端的灰度發佈則會相應容易一些，畢竟是在後臺實現。

如今有專門的灰度發佈模式A/B測試，經過業務代碼區分流量訪問不一樣代碼。可是區分流量是業務代碼作的。經過少許用戶到新版本，而後對新舊版本對比，這就是A/B測試。

nginx這塊我不會，因此也不知道能不能實現兩個分支nginx靜態代理。理論上來講是沒有問題。

其實針對大型的系統，還有藍綠部署、滾動發佈等，還有專門的測試雲服務提供商。

灰度發佈除了代碼層面以外，對服務這塊要求仍是蠻大的，灰度發佈不一樣於預發佈，灰度發佈是直接讓線上用戶參與，而通常預發佈是發佈到線上，由測試人員進行測試。

固然，會使用灰度發佈的，通常來講都是千萬級別用戶的項目了，雖然很想使用灰度發佈，但仍是須要考慮實際場景，也但願之後能有機會使用灰度發佈。