站點的高可用架構設計的主要目的就是保證server硬體故障時服務依舊可用、資料依舊儲存並能夠被訪問。
實現上述高可用架構的主要手段是資料和服務的冗餘備份及失效轉移。
典型的分層模型是三層，即應用層、服務層、資料層；各層之間具有相對獨立性，應用層主要負責詳細頁面邏輯處理；服務層負責提供可復用的服務；資料層負責資料的儲存於訪問。中小型站點在詳細部署時，通常將應用層和服務層部署在一起，而資料層則另外部署。
在複雜的大型站點架構中，劃分的粒度會更小、更詳細，結構更加複雜，server規模更加龐大，但通常還是能夠把這些服務劃分到這三層中。
應用層主要處理站點應用的業務邏輯，因此有時也稱作為業務邏輯層，應用的乙個顯著特點是應用的無狀態性。
通過負載均衡進行無狀態服務的失效轉移
負載均衡，顧名思義，主要使用在業務量和資料量較高的情況下。當單臺server不足以承擔全部的負載壓力時，通過負載均衡手段，將流量和資料分攤到乙個集群組成的多台server上，以提高總體的負載處理能力。
眼下，無論是開源免費的負載均衡軟體還是昂貴的負載均衡硬體。都提供失效轉移功能。
應用server集群的session管理
應用server的高可用架構設計主要基於服務無狀態這一特性，可是其實，業務總是有狀態的。
web應用中將這些多次請求改動使用的上下文物件稱作會話（session)，單機情況下，session可由部署在server上的web容器管理。在使用負載均衡的集群環境中，由於負載均衡server可能會將請求分發到集群不論什麼一台應用server上，所以保證每次請求依舊能夠獲得正確的session比單機時要複雜非常多。
集群環境下。session管理主要有下面幾種手段。
session複製：方案簡單。從本機讀取session資訊也非常高速。但僅僅能使用在集群規模比較小的情況下。當集群規模較大時，集群server間須要大量的通訊進行session複製。占用server和網路的大量資源，系統不堪重負。
session繫結：能夠利用負載均衡的源位址hash演算法實現，負載均衡server總是將**於同一ip的請求分發到同一臺server上（也能夠更具cookie資訊將同乙個使用者的請求總是分發到同一臺server上，當然這是負載均衡server必須工作在http層上）。可是session繫結的方案顯然不符合我們隊系統高可用的需求。由於一旦某台server宕機，那麼該機器的session就不復存在了，使用者請求切換到其它機器後由於沒有session而無法完畢業務處理。
利用cookie記錄session：能夠利用瀏覽器支援的cookie記錄session。可是有一些缺點，比方受cookie限制大小，能記錄的資訊有限，每次請求響應都須要傳輸cookie；假設關閉cookie。訪問就會不正常。
sessionserver：利用獨立部署的sessionserver（集群）統一管理session。應用server每次讀寫session時，都訪問sessionserver。這樣的解決方式實際上是將應用server的狀態分離。分為無狀態的應用server和有狀態的sessionserver，然後針對這兩種server的不同惡性分別設計其架構。
可復用的服務模組為業務產品提供公共服務，大型站點中這些服務通常都獨立分布式部署，被詳細應用遠端呼叫。可復用的服務和應用一樣。也是無狀態的服務，因此能夠使用相似負載均衡的失效轉移策略實現高可用的服務。
除此之外。詳細實踐中，還有下面幾點高可用的服務策略。
分級管理
運維上將server進行分機管理，核心應用和服務有限使用更好的硬體，在運維響應速度上爺格外迅速。顯然。使用者及時付款購物比能不能評價商品更重要，所以訂單、支付服務比評價服務有更高優先順序。同事在服務部署上也進行必要的隔離，避免故障的連鎖反應。
超時設定
在應用程式中設定服務呼叫的超時時間，一旦超時，通訊框架就丟擲異常，應用程式依據服務排程策略，可選擇繼續重試或者將請求轉移到提供同樣服務的其它server上
非同步呼叫
應用對服務的呼叫通過訊息佇列等非同步方式完畢。避免乙個服務失敗導致整個應用請求失敗的情況。
當然不是多有服務呼叫都能夠非同步呼叫，對於獲取使用者資訊這類呼叫，採用非同步方式會延長響應時間。得不償失。
對於那些必須確認服務呼叫成功才幹繼續下一步操作的應用也不合適使用非同步呼叫。
服務降級
降級有兩種手段：拒絕服務及關閉服務
冪等性設計
有些服務天然具有冪等性，比方講使用者性別設定為男性，無論設定多少次，結果都一樣。可是對轉賬交易等操作，問題就會比較複雜，須要通過交易編號等資訊進行服務呼叫有效性校驗。僅僅有有效的操作才幹繼續執行。
（注：冪等性是系統的介面對外一種承諾(而不是實現), 承諾僅僅要呼叫介面成功, 外部多次呼叫對系統的影響是一致的. 宣告為冪等的介面會覺得外部呼叫失敗是常態, 而且失敗之後必定會有重試.）
保證資料儲存高可用的手段主要是資料備份和失效轉移機智。
「不同意沒有監控的系統上線「，這是很多站點架構師在做專案上線評審時常說的一句話。
站點執行監控對於站點運維和架構設計優化至關重要，運維沒有監控的站點。宛如駕駛沒有儀表的飛機。盲人騎瞎馬，夜班臨深淵而不知。生死尚且未卜，提高可用性、降低故障率就更無從做起了。
監控資料採集：使用者行為日誌收集；server效能監控；執行資料報告；
監控管理：系統報警；失效轉移；自己主動優雅降級；
可用性測試
工作一直緊張，但今天還是岔出了一件事情，就是對我負責的模組進行使用者可用性測試。兩個小時的測試還是有點收穫，小記之。剛剛從公司的培訓課程中學到了 usability test 沒想到這麼快就用到了實踐中，雖然這次的可用性測試不是很正式的從公司外部請使用者來做，也沒有用單面透視玻璃對使用者行為作 暗訪...
IT系統可用性
it系統可用性重新認識 今天看了一篇關於it系統可用性研究的文章，有些自己的想法，一併記載下來，若以後在此基礎上有新的發現，將及時更新。it系統可用性定義 what it系統中計算機軟硬體，網路等對使用者有效使用和令人滿意的程度。換句話說，盡量縮短因系統崩潰所導致的停機時間。包括確保機器的響應速度，...
可用性測試
1.頁面部分 1.頁面清單是否完整 是否已經將所需的頁面全部都列出來了 2.頁面是否顯示 在不同解析度下頁面是否存在，在不同瀏覽器版本中頁面是否顯示 3.頁面在視窗中的顯示是否正確 美觀 在調整瀏覽器視窗大小時，螢幕重新整理是否顯示 4.頁面特殊效果顯示是否正確 2.頁面元素部分 2.元素是否顯示 ...