先簡單交代下背景，好引出為什麼要做這個事情，當專案團隊大了之後我們經常會遇到的問題就是git流程的管理，以及遇到使用某套git管理流程之後所帶來的成本和問題，例如：如果你使用gitflow 流程你就會發現你對開發人員對git操作本身就需要很高的水準，不利於不同層次的人員協同，第二你有可能生產版本不穩定經常需要修bug，不斷拉取hotfix，然後走一套流程過於複雜。中間我們省略過release，或者使用pr模式，最終都以各種各樣得問題徹底放棄了所謂得最佳實踐，所以我決定走出一條自己得路，最後發現自己得路才是真正得最佳實踐。
我們得流程非常簡單如下
但是以上流程存在乙個問題，當多個需求並行開發的時候測試環境如何處理？開發環境如何處理？於是就衍生出了如下方案。因為我的服務可能有上百個但是我本次需求只涉及了2個服務。
根據上圖我做的解決方案就是通過灰度的策略將測試人員的ip繫結到version上。並通過重寫loadblance負載規則將測試人員ip的版本號與服務發現的版本號進行繫結，沒有繫結的使用者將通過預設規則會走原本的穩定環境。同樣這套理論可以應用到開發環境。
所以這裡需要提供的支援如下
1、提供個方便快捷的nginx 頁面配置路由規則
2、註冊中心提**用級別版本管理
3、服務間負載元件提供從註冊中心獲取版本並提供版本策略
文章描述都是文字看起來很複雜的樣子，其實如果你實踐起來之後你會發現非常簡單。可以參考我的另一篇文章【dubbo擴充套件解決開發環境共用問題】目前正在努力構建這套體系，先貼個理論基礎出來。也希望有大牛能把這套體系做的更好。
微服務 見 呼叫請求頭傳遞 微服務平台之灰度發布
灰度發布是指在應用的新 舊版本間平滑過渡的一種發布方式。根據特定的規則，挑選一部分使用者訪問灰度版本的服務，並逐步擴大範圍，最終把所有使用者訪問遷移到新的版本上來。灰度發布時，主要涉及設定流控規則和部署新版本這兩個動作，本次主要是介紹在eos8微服務平台裡灰度發布的流量控制。一 灰度發布介紹 二 灰...
微服務學習筆記 微服務治理得方式
可能會出現一些問題 一 節點管理 1 註冊中心主動摘除機制 服務提供者定時的主動向註冊中心匯報心跳，註冊中心根據服務提供者節點最近一次匯報心跳的時間與上一次匯報心跳時間做比較，如果超出一定時間，就認為服務提供者出現問題，繼而把節點從服務列表中摘除，並把最近的可用服務節點列表推送給服務消費者。2 服務...
利用Dubbo框架搭建微服務
dubbo微服務框架搭建 一 服務端環境搭建 a provider安裝 b consumer安裝 c 註冊中心安裝 d 監控中心安裝 e 管理控制台安裝 二 服務端開發 a provider開發 b consumer開發 c 協議選擇 d 註冊中心選擇 官方英文 1 dubbo微服務框架官方指導 開...