一、 前言：
“高可用性”（High Availability）通常來描述一個系統經過專門的設計，從而減少停工時間，而保持其服務的高度可用性。所以當我們一說到高可用，我們滿腦子都是以負載均衡為主心骨搭建的拓撲圖，以他為中心，從單節點拓展為多節點，消滅單點故障。但隨著我們業務架構越來越龐大複雜，那麼要考慮的就不再只是服務器維度的高可用了。接下來，我來給大家介紹一下不同維度的“高可用”在架構上是如何實現的。
二、 通用高可用
很多人在搭建業務的時候喜歡用一臺高性能服務器搭建所有業務所需的應用和環境。比如服務器上搭建Nginx、會員系統、訂單系統、自建數據庫等等。這類搭建的初衷大概有簡單省事、預算不足、初期業務量小感覺夠用等因素。
這些困難業主要集中在業務上線初期，都是很現實的問題，不過隨之帶來的是更加現實的困難。性能瓶頸很快到來，後期調整架構會因越來越大的數據量和停服帶來收益減少等等問題。
所以業務初期搭建一個基礎高可用框架，日後根據需要逐漸添加功能。
A、後期業務增加後我們再根據需要逐步擴容，例如數據庫讀寫壓力大了，我們用Redis、數據庫讀寫分離等手段。這樣擴容不用複雜的操作，不用長時間的停服遷移重要的數據信息。
B、再後來業務量進一步擴大，需要短信服務、需要組網、需要安全防護等等，都可以靈活拓展。所以對於服務器層面來說，一開始就搭建一個高可用架構是至關重要的。
三、 進階高可用：
容災方面：
通常對於一個普通的APP、門戶網站、內部系統等等業務，通用高可用已經足夠了。但為了實現客戶們日益提高的對體驗感的的高要求，工程師們不知踏平了多少坑以後實踐出了與之對應的高級高可用架構。這種架構不再針對某一個業務集群做高可用，而是以業務為維度。舉個例子當某一個地域的業務不可用時，能有其他地域的備用集群頂上。
客戶體驗感：
當業務做大到一定程度，客戶群體就不僅僅侷限於一個市或者一個省，乃至一個國家。這時候，因為客戶離業務集群太遠，導致通訊質量不佳，延遲、丟包問題層出不窮。以前我們經常用“三秒”來定義一個網站的好壞，但現在主流網站大多均已採用“1.5秒”來打分了。傳統的單業務節點越來越難滿足了，那就得考慮多節點同時運行承載業務，可通過全局流量來實現。而多節點之間的數據同步可以用阿里雲的雲企業網來實現。
負載均衡從其應用的地理結構上分為本地負載均衡和全局負載均衡。本地負載均衡是指對同地域的服務器群做負載均衡，全局負載均衡是指對分別部署在不同地域有不同網絡結構的服務器群做負載均衡。
全局流量管理利用DNS智能解析和應用服務的運行狀態健康檢查，將用戶訪問定向到最合適的IP地址，使訪問用戶獲得最快捷、最流暢的體驗。
全局流量支持將不同地域的IP地址添加到不同的地址池，並配置健康檢查。在訪問策略配置中，設置默認地址池為地址池甲，Failover地址池為地址池乙，即可以實現應用服務主備IP容災切換。
使用全局流量管理，可以使不同地域的用戶訪問不同的IP地址池，實現用戶分組管理，分組接入，幫助應用服務提高用戶訪問體驗。
這樣我們也就能搭建一個便於客戶就近訪問的業務集群了，而用CEN組網打通各機房VPC，數據同步方面的工作也能變得更簡單。>>直達阿里雲官網雲服務器租賃