高可用架構常見場景

一、 前言：

        “高可用性”（High Availability）通常來描述一個系統經過專門的設計，進而減少停工時間，而保持其服務的高度可用性。是以當我們一說到高可用，我們滿腦子都是以負載均衡為主心骨搭建的拓撲圖，以他為中心，從單節點拓展為多節點，消滅單點故障。但随着我們業務架構越來越龐大複雜，那麼要考慮的就不再隻是伺服器次元的高可用了。接下來，我來給大家介紹一下不同次元的“高可用”在架構上是如何實作的。

二、 通用高可用

        很多人在搭建業務的時候喜歡用一台高性能伺服器搭建所有業務所需的應用和環境。比如伺服器上搭建Nginx、會員系統、訂單系統、自建資料庫等等。這類搭建的初衷大概有簡單省事、預算不足、初期業務量小感覺夠用等因素。

這些困難業主要集中在業務上線初期，都是很現實的問題，不過随之帶來的是更加現實的困難。性能瓶頸很快到來，後期調整架構會因越來越大的資料量和停服帶來收益減少等等問題。

是以業務初期搭建一個基礎高可用架構，日後根據需要逐漸添加功能。

A、後期業務增加後我們再根據需要逐漸擴容，例如資料庫讀寫壓力大了，我們用Redis、資料庫讀寫分離等手段。這樣擴容不用複雜的操作，不用長時間的停服遷移重要的資料資訊。

B、再後來業務量進一步擴大，需要短信服務、需要組網、需要安全防護等等，都可以靈活拓展。是以對于伺服器層面來說，一開始就搭建一個高可用架構是至關重要的。

三、 進階高可用：

容災方面：

        通常對于一個普通的APP、門戶網站、内部系統等等業務，通用高可用已經足夠了。但為了實作客戶們日益提高的對體驗感的的高要求，工程師們不知踏平了多少坑以後實踐出了與之對應的進階高可用架構。這種架構不再針對某一個業務叢集做高可用，而是以業務為次元。舉個例子當某一個地域的業務不可用時，能有其他地域的備用叢集頂上。

客戶體驗感：

        當業務做大到一定程度，客戶群體就不僅僅局限于一個市或者一個省，乃至一個國家。這時候，因為客戶離業務叢集太遠，導緻通訊品質不佳，延遲、丢包問題層出不窮。以前我們經常用“三秒”來定義一個網站的好壞，但現在主流網站大多均已采用“1.5秒”來打分了。傳統的單業務節點越來越難滿足了，那就得考慮多節點同時運作承載業務，可通過全局流量來實作。而多節點之間的資料同步可以用阿裡雲的雲企業網來實作。

        負載均衡從其應用的地理結構上分為本地負載均衡和全局負載均衡。本地負載均衡是指對同地域的伺服器群做負載均衡，全局負載均衡是指對分别部署在不同地域有不同網絡結構的伺服器群做負載均衡。

• 多線路智能化解析服務

全局流量管理利用DNS智能解析和應用服務的運作狀态健康檢查，将使用者通路定向到最合适的IP位址，使通路使用者獲得最快捷、最流暢的體驗。

• 跨地域容災

全局流量支援将不同地域的IP位址添加到不同的位址池，并配置健康檢查。在通路政策配置中，設定預設位址池為位址池甲，Failover位址池為位址池乙，即可以實作應用服務主備IP容災切換。

• 不同地域通路加速

使用全局流量管理，可以使不同地域的使用者通路不同的IP位址池，實作使用者分組管理，分組接入，幫助應用服務提高使用者通路體驗。

這樣我們也就能搭建一個便于客戶就近通路的業務叢集了，而用CEN組網打通各機房VPC，資料同步方面的工作也能變得更簡單。