初識架構之高可用

架構和架構師，能夠說是大部分技術人的目標或追求吧。
但架構類比於內功或修爲，它不是一門武功，不能學一招走天下。
同一個架構方案在不一樣公司甚至不一樣團隊都不必定能適用，因此更可能是經驗和思考。
所以，一直以爲應該寫下來，不按期的更新和總結，亦或分理論學習篇和實戰篇來寫都好。
恰好最近在讀基本架構書籍，因此就從讀書筆記開始，點滴記錄好了。
此篇筆記主要來自於，《大型網站技術架構》。

一、高可用的定義

什麼是高可用？百科的解釋是：一般來描述一個系統通過專門的設計，從而減小停工時間，而保持其服務的高度可用性。通常會用可用時間佔比來度量，如99.9%、99.99%，甚至99.999%等。講完了什麼是高可用後，做者從典型的「應用、服務、數據」三層架構，分別展開來說不通層次的架構。

二、高可用應用

做者把應用層的特色歸爲高可用、業務層等。分有狀態和無狀態兩種。
無狀態的服務：這種相對來說比較之間，基本均可以橫向擴容，經過Nginx、Haproxy等負載均衡代理層來進行流量轉發和失效轉移便可。以集羣部署的方式提供服務，確保高可用。
有狀態的服務：書裏舉例是Session的狀態以及如何管理Session的狀態，但除了應用層的session，實戰中還有不少服務也可能被設計爲有狀態的。例如：某個服務每一個實例負責處理不通的號碼段，A服務處理id：1-10000號的用戶，B服務處理id：10001-20000...。

回到書裏，關於Session管理的手段：
seesion複製：僅適用於小型網站。缺點是集羣規模一旦稍微大點，大量的session通訊會佔用很多資源。
session綁定：利用負載均衡的hash算法，使同一用戶請求落到同一臺機器上。缺點很明顯一旦出現某臺機器宕機，該機器上用戶的session信息都會丟失。
利用cookies來記錄session：來回傳；簡單但大小受限。不過，仍是許多網站採用了這種方案。
session服務：利用如分佈式緩存等技術服務開發搭建session服務。集中化管理，特別是實現SSO單點登陸的場景。

三、高可用服務

做者將經過提供Rpc調用的基礎服務歸爲此類，實際上我以爲跟應用層差異不大。
無狀態服務，同樣能夠經過負載均衡加心跳檢測等手段去部署集羣，確保故障轉移來作到高可用。
這一節主要的幾點筆記：
分級管理：有點水，講的是核心服務分配更好的硬件以及隔離部署。其實實戰中，核心服務或大型活動都應該隔離部署，這樣能夠避免故障引發連鎖反應。好比同一臺機器混布，cpu等資源被其餘服務佔滿。同理，機房帶寬等資源也有相似的可能。
超時設置：繼續水。講應用層調用服務層應該設置超時，避免服務層掛了請求還在那長時間佔用資源。其實實戰中無論怎麼分層，也不論是同層仍是跨層調用，只要發起一個Rpc調用都應該有超時機制。
異步調用：主要講運用消息隊列將非強依賴的邏輯異步化，如註冊過程的發郵件或歡迎短信等操做，能夠優先保證核心流程，至於發送郵件等能夠丟個消息隊列異步執行便可。其實，異步化在實戰中很經常使用，但我我的以爲跟高可用沒啥直接相關，更可能是業務解耦。
服務降級：分拒絕服務和關閉服務。拒絕服務又分按優先級拒絕或隨機拒絕，實戰中隨機較容易，只要設置好服務的閾值，達到閾值的時候丟棄請求便可。而關閉服務，則比較果斷，好比秒殺的時候關閉評論、追評或者確認收貨；又好比大型直播結束後，關閉一些本來平常會進行的相關興趣推薦等。
冪等性設計：請求可屢次提交或叫作可重放，服務能保證最終結果正確性。有些修改是自然的冪等性：資料設置。反之，加減金額、獎勵發放等就不是自然冪等的，這類服務就當心對待這個問題。實戰中常見手段是，利用一些流水號等方式，目的其實都是校驗惟一性。

四、高可用數據

做者對數據層的介紹就是CAP、數據備份和失效轉移。
CAP：初步CAP原理的Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性）。以及說大型網站通常保證AP，而後在某種程度上放棄C（一致性）；而後再將數據一致性分爲：數據強一致、數據用戶一致和數據最終一致。並提到數據不一致一般出如今系統高併發寫操做或集羣狀態不穩（故障恢復或集羣擴容）的狀況。
我我的以爲實戰中，大多數時候採用的方案就是保證最終一致。除了上面提到的集羣狀態不穩定外，獎勵、訂單等涉及多個分佈式服務時均可能出現不一致，所以糾錯、對帳、補償都是很經常使用的手段。

數據備份：定時冷備、異步熱備、同步熱備。
失效轉移：失效確認、訪問轉移、最後再數據恢復後當好備胎。

五、高可用開發流程

服務發佈：經過切流量的方式一臺臺灰度發佈。
自動化測試：推薦Web的自動化測試工具ThoughtWorks。
預發佈環境：搭建一套與現網一致，甚至與現網打通，但只能配置host內部訪問的環境。用於預發佈驗證。
代碼控制：主幹發佈、分支開發的模式。仍是推薦Git。
自動化發佈：這個感受有點難。。
灰度發佈：按Set灰度、按機器灰度、按號碼段灰度，還能夠作A/B Test。

六、網站運行監控

開源性能監控工具：Ganglia
監控數據採集：一、用戶行爲採集 二、服務&服務器性能操做採集 三、按期數據報告
監控管理：一、系統告警 二、失效轉移 三、自動降級