這是學習筆記的第 2060 篇文章
最近在完善Consul相關的一些高可用方向的更新，目前是基于MHA+Consul的方案，對于Consul方面算是做一些普及和推廣，而對于MHA則是處于保守的維護狀态，相信不久就會使用orch來做替代。
當然前提是一些版本規劃能夠統一，而且是與時俱進，在此補充幾點關于service_name測試的一些建議。
首先對于線上業務來說，要做高可用更新，基本上對于服務的影響是非常短暫的，對于很多應用來說，從業務的閃斷到更新完成，這個過程需要大概是1-2秒鐘，可以了解這種釋出是可持續的，而如果要完整模拟MHA的故障過程，需要的時間是遠大于2秒的，是以對于有些業務來說，就難以接受了，是以我設想了如下的一些改進方案。
1）首先業務方需要對基于Consul的域名服務進行連接配接性測試，這種情況下可以直接使用最新配置的域名服務，做一些業務側的驗證和測試，如果要做更新，則可以了解在業務低峰期直接做切換測試，然後測試驗證無誤後切換到線上服務。
2）而如果對一些業務優先級較高的業務，做線上切換是不現實的，也即上面所說的閃斷會大于2秒以上，則可以使用平行的業務測試來進行對接。 比如我們搭建一套平行的環境，端口配置不同，則可以和業務方進行對接測試，測試的時候使用的都是新的端口，這樣我們可以線上上真實的模拟服務的切換情況，而等待測試完成之後，則将環境重置，恢複原來的端口和服務配置，這可以了解是一種配置的平滑切換，是目前較為折中的測試方案。
3）線上更新服務，有了基于域名的服務之後，保證應用重連機制，那麼我們可以對MySQL服務做線上更新，比如與時俱進，把服務的版本從5.7.16更新到5.7.26，而整個切換的過程時間是在1秒鐘左右，對于業務幾乎無感覺。
4）在第3步的基礎之上，我們可以開啟新的服務的MGR特性，然後重新建構新的MGR secondary節點，這樣我們就可以快速的把MySQL服務從原本的MHA切換到了MGR,前提是應用的基礎配置滿足（比如表要有主鍵等，節點在同機房内）
5）在滿足一些基礎業務的前提下，對已有的讀請求做負載均衡，可以配置同樣的域名服務，挂載多個讀節點，由consul實作負載均衡。
6）對于域名的使用，對于很多業務來說，其實會有更高的要求，我們可以借助ACL實作這種Consul API服務，即應用端可以通過接口的方式來得到對應的資料庫服務IP資訊，而應用端本身是有連接配接池的配置，在應用端需要時可以進行輪詢獲得相應的資訊，這樣一來應用一來的就不是單純的域名服務，而是對這兩類服務做了解耦，當然從這個層面來看，對于應用端的邏輯改造會有一定的代碼量，但是收益也是巨大的。