高可用背景介紹
高並發、高可用是互聯網分布式系統架構設計中必須考慮的因素之一。
首先來說說高並發，啥是高並發，怎樣才算是高並發。個人認為在衡量一個業務系統的並發能力，需要有一個維度，其中最重要的兩個衡量標准是業務復雜度和硬件配置（cpu、內存、磁盤、帶寬、網卡）。高並發的本質並不是一個數字這么簡單，而是需要我們針對現有的業務系統再遇到高並發帶來的問題時如何從架構上、設計上、編碼上解決問題。微門戶系統日均PV 1300W，Node端請求量日均4億級，Java后端單個服務系統請求量日均1500W，個人認為這個量級和大多數公司相比已經很不錯了。
那什么是高可用呢？簡單來說就是減少系統不能提供服務的時間。一個高可用的系統需要支持服務故障自動轉移、服務精准熔斷降級、服務治理、服務限流、服務可回滾、服務自動擴容/縮容等能力。相比高並發，我認為高可用更重要一些。
“硬”投入
F5 VS Array
產品體系架構區別
Array操作系統是ArrayOS，使用自己編制的硬件操作系統，從穩定性來說系統不依賴於底層操作系統的穩定性。從性能來說由於使用了SpeedStack技術，相應的速度要更高。
F5的操作系統是Linux操作系統上起的應用服務（TMOS），從穩定性來說系統以來linux的穩定性。在實際應用中，相應的穩定性會差。從性能來說，采用了分層的處理，降低了數據包處理的速度。
負載均衡功能比較
Array支持L2-L7負載均衡（L4-輪詢、權重、最小連接數、最快響應基於cookie、IP、Qos等會話保持算法，L7-基於cookie、IP、Qos、Header、URL、任意內容的算法），會話保持技術基於cookie、IP、Qos、ssl id、Url、Header、Hostname，服務器健康檢查（ICMP、TCP/UDP、Http、Keyword、TCP/UDP Script）。
F5支持L3-L7負載均衡（L4-輪詢、比率、最小連接數、最快響應、觀察法、預測法，L7-需要使用IRules進行編程），會話保持技術基於cookie、IP、ssl id、SIP、Universal ID，服務器健康檢查（ICMP、TCP/UDP、Http、ECV、EAV）。
域名解析服務器DNS
域名解析流程大致如下所示。
瀏覽器檢查自身DNS緩存
操作系統緩存檢查（本機）+ hosts解析（本機）
本地區域名服務器解析（LDNS）
如果在hosts文件中也沒有找到對應的條目，瀏覽器就會發起一個DNS的系統調用，就會向本地配置的首選DNS服務器發起域名解析請求。
根域名服務器解析（Root Server）
如果LDNS沒有找到對應的條目，則由運營商的DNS代我們的瀏覽器發起迭代DNS解析請求。它首先是會找根域的DNS的IP地址（這個DNS服務器都內置13台根域的DNS的IP地址），找到根域的DNS地址，就會向其發起請求。根域名服務器返回給本地域名服務器一個所查詢域的主域名服務器(gTLD Server)地址，gTLD是國際頂級域名服務器，如.com、.cn、.org等。
主域名服務器(gTLD Server)
本地域名服務器(Local DNS Server)向gTLD服務器發送請求，接受請求的gTLD服務器查找並返回此域名對應的Name Server域名服務器的地址，這個Name Server通常就是注冊的域名服務器。
管理方域名服務器(Name Server)
Name Server域名服務器會查詢存儲的域名和IP的映射關系表，正常情況下都根據域名得到目標IP記錄，連同一個TTL值返回給DNS Server域名服務器。
軟負載均衡Nginx優勢
服務集群
1、通過多台計算機完成同一個工作，達到更高的效率。
2、兩機或多機服務實例，工作過程等完全一樣。如果一台死機，另一台可以起作用。
中間件主備、主從
主備模型
優點：簡單，主備之間只有數據同步，不需要考慮別的情況。就很簡單的配置一下，再搞一台服務器就能組成主備架構了。
缺點：備機等於就拿來備份，浪費了備機這台服務器的資源。上面說的不考慮別的情況指的是主機和備機它們兩之間就只要復制數據，但是有些情況我們人還是得考慮主機掛了如何讓備機上。
主從模型
優點：充分利用了資源，嘿嘿不想備機這么爽了，還得出來干活，對外提供讀操作。而且在主機掛了的時候，如果沒任命新機主之前，讀操作還是能用的。
缺點：客戶端需要多個判斷，也就是不同操作需要發放給不同服務器。主從延遲，讀操作分配給從庫，就會存在數據同步的延遲問題，此時需要考慮延遲問題的一些解決辦法。
雙中心架構
傳統主備模式
主備模式是一個業務只在一個數據中心運行，企業結合災備等級需求和業務需求，在備份中心部署了大量的備份服務器，但備份中心僅為該業務提供災備服務，只有當災難發生、生產數據中心癱瘓時，災備中心的業務系統才啟動這些服務器，造成備份中心服務器資源浪費，廣域網鏈路也無法得到充分的利用。
雙中心優點
充分利用資源，避免了一個數據中心常年處於閑置狀態而造成浪費。通過資源整合，“雙活”數據中心的服務能力是雙倍的。
雙活數據中心如果斷了一個數據中心，另外一個數據中心還在運行，對用戶來說是不可感知的。
而一個災備中心的模式，如果生產數據中心癱瘓，需要半個小時、甚至兩個小時、甚至更長時間才能啟動災備中心，在啟動災備中心的時間里，用戶交易會嚴重受損。
容器自動伸縮容
容器雲平台提供快速部署、資源彈性伸縮等底層技術能力，通過容器雲平台，可滿足外部個性化應用與數字服務雲平台的集成部署要求，進一步提高數字服務雲平台的靈活性，改善服務水平，保障系統的快速交付和平穩運行。
- CI/CD(持續集成/持續發布)
- 彈性伸縮
- 故障隔離
- POD隔離
- 分組分流
- 自動監控
“軟”設計
分層微服務化架構
1、H5前端應用提供了微信、支付寶、獨立微門戶等多渠道下業務功能。
2、Node端作為微門戶的網關層，提供服務路由、灰度發布、用戶鑒權和會話管理功能。業務高峰期，高性能的Node端服務完全可以應對高並發，靜態資源通過壓縮、CDN等技術降低頁面加載時長，提升用戶體驗。
3、基礎服務層是由Java編寫的一系列微服務組成，CSF平台協助微服務之間的調用，緩存組件提升服務響應時間，日志組件繪制整個請求調用鏈，MQ組件便於業務解耦和處理並發分流。
無狀態、冪等
什么是無狀態？是指該服務運行的實例不會在本地存儲需要持久化的數據，並且多個實例對於同一個請求響應的結果是完全一致的。無狀態服務的設計便於水平擴展，提高服務可用性。
什么是冪等？就是用戶對於同一操作發起的一次請求或者多次請求的結果是一致的。一般冪等做法是防止重復提交、Token令牌、樂觀鎖、分布式鎖、建立防重表等。
限流
流量高峰期會出現系統資源不夠，不足以應對大量請求，即系統資源與訪問量出現矛盾的時候，為了保證有限的資源能夠正常服務，需要對系統按照預設的規則進行流量限制或功能限制。常見的限流策略如下。
1、計數器方法
系統維護一個計數器，來一個請求就加1，請求處理完成就減1，當計數器大於指定的閾值，就拒絕新的請求。
基於這個簡單的方法，可以再延伸出一些高級功能，比如閾值可以不是固定值，是動態調整的。另外，還可以有多組計數器分別管理不同的服務，以保證互不影響等。
2、漏桶算法
漏桶算法其實很簡單，可以粗略的認為就是注水漏水過程，往桶中以一定速率流出水，以任意速率流入水，當水超過桶流量則丟棄，因為桶容量是不變的，保證了整體的速率。
3、令牌桶方法
首先還是要基於一個隊列，請求放到隊列里面。但除了隊列以外，還要設置一個令牌桶，另外有一個腳本以持續恆定的速度往令牌桶里面放令牌，后端處理程序每處理一個請求就必須從桶里拿出一個令牌，如果令牌拿完了，那就不能處理請求了。我們可以控制腳本放令牌的速度來達到控制后端處理的速度，以實現動態流控。
微信公眾號系統使用Guava的RateLimiter對接口進行限流，其原理是令牌桶算法，也就是以固定的頻率向桶中放入令牌，
熔斷降級
微信公眾號自助服務模塊引用了Hystrix這款開源的容錯系統，Hystrix能協助開發者碼出強大容錯能力和魯棒性程序，具有如下優點。
- 對依賴的服務（HTTP調用、CSF服務）進行保護， 並且把控住由於依賴服務所帶來的的延遲和失敗
- 防止在一個復雜的分布式系統里出現級聯失效（cascading failures）
- 快速失敗（Fail fast），並且快速恢復依賴服務
- 優雅的降級
- 實時的監控和報警
1、隔離策略：信號量
- 隔離細度較高、CSF客戶端有請求策略的設置
- 線程池隔離開銷過大，還需要考隔離線程下日志同步火眼的問題
2、隔離配置：配置中心
- 省份 + 服務標識 配置隔離分組，不同分組不同的熔斷、降級配置
- run(命令)調用最大的並發數 20
- fallback(降級)調用最大的並發數 15
- 熔斷器半打開時間間隔 2000ms
- 10s中內最少的請求量50，大於該值，斷路器配置生效
- 當出錯率超過50%后熔斷器啟動
- 統計滾動窗口時間5s, 統計滾動窗口桶個數10
服務發現
容器雲使用環境變量或DNS服務插件保證容器中程序發現Pod入口訪問地址。
CSF平台針對眾多業務系統相互間的服務調用，進行完整的服務生命周期治理和服務資源管控，提供系統接入，服務注冊，服務申請，服務調用，日志查詢等功能。
不停服發布
容器雲采用一種平滑過渡的升級方式，通過逐步替換的策略，以確保不會同時關閉所有實例，保證整體系統的穩定，在初始升級的時候就可以及時發現、調整問題，以保證問題影響度不會擴大。
業務補償機制
說到業務補償機制，主要是解決分布式系統環境下業務數據一致性的問題，那不得不提一下兩個重要的分布式理論（BASE 理論 和 CAP理論）。
1、CAP理論
- Consisteny（一致性）
一致性的要求是指，對於任何客戶端來說，每次的讀操作，都能獲得最新的數據。即，當有客戶端向A節點寫入了新數據之后，其它客戶端從B節點中進行讀操作所獲得的數據必須也是最新的，是與A節點數據保持一致的。
- Availability（可用性）
可用性的要求是指，每個請求都能在合理的時間內獲得符合預期的響應（不保證獲取的結果是最新的數據）。
客戶端只要向A節點或B節點發起請求后，只要這兩個節點收到了請求，就必須響應給客戶端，但不需要保證響應的值是否正確。
- Partition tolerance（分區容錯性）
分區容錯性是指，當節點之間的網絡出現問題之后，系統依然能正常提供服務。
CAP理論也就是說在分布式存儲系統中，最多只能實現以上兩點。而由於當前網絡延遲故障會導致丟包等問題，所以我們分區容錯性是必須實現的。也就是NoSqL數據庫P肯定要有，我們只能在一致性和可用性中進行選擇，沒有Nosql數據庫能同時保證三點。（==>AP 或者 CP）。
例如elasticsearch集群/eureka集群是基於AP的，zookeeper集群/redis集群/mongoDB集群是基於CP的。大家都知道eureka和zookeeper都可以做服務注冊中心，使用dubbo作為RPC服務框架時都會用zookeeper作為服務注冊中心，但是使用springcloud框架時默認都是使用eureka作為服務注冊中心，對比一下eureka和zookeeper的設計原則，個人認為eureka更適合做服務注冊中心。
2、BASE理論
BASE理論是對CAP理論的延伸，核心思想是即使無法做到強一致性（Strong Consistency，CAP的一致性就是強一致性），但應用可以采用適合的方式達到最終一致性（Eventual Consitency）。
BASE是指基本可用（Basically Available）、軟狀態（ Soft State）、最終一致性（ Eventual Consistency）。
3、常見補償機制
- TCC模式（二階段提交，Try/Confirm/Cancel）
- 異步確保，MQ異步消息，補償表+定時任務
- 最大努力，通過通知服務器（消息通知）進行，允許失敗，有補償機制（或重發機制）
系統監控告警
為什么做監控？一個鑒權的監控系統可以是實時統計機器系統資源（CPU/內存/網絡/磁盤）、查看JVM虛擬機運行情況、統計接口的調用量、統計接口耗時情況、統計接口錯誤異常、查看具體業務和運營節點流程。通過監控系統數據可以做系統性能告警、服務自動擴容/縮容、更早的發現服務質量問題，保證服務高可用。
為什么做告警？告警系統可以快速幫忙快速定位生產出現的問題是什么，及時通知到具體負責人。個人認為，告警系統對異常統計應該有個緊急程度（如可忽略、通知、告警），不同程度的異常通知划分到不同的責任人，通知渠道划分為短信、企業群、電話等。
微信公眾號系統基於Hystrix Dashboard實現的自助服務調用監控視圖
- 藍色計數: 表示斷路器打開后，直接被短路的請求數
- 黃色計數: 表示請求超時數
- 紫色計數: 表示因為線程池滿而被拒絕的請求數
- 紅色計數: 表示因為異常而導致失敗的請求數
- 灰色百分比: 表示的是10秒內的錯誤率統計
- Hosts: 應用個數
- Median: Command 的中位數時間
- Mean: Command 的平均時間
- 90th/99th/99.5th: P90、P99、P99.5 時間
所有技術和百分比的統計窗口都是10秒（默認值）
總結
分布式系統中，並不是所有的業務在24小時的時間內都處於高並發狀態，也可能有的業務在某一時間段處於流量高峰。面對突如其來的高並發流量，要保證系統的高可用性尤其重要。在設計高可用系統中，要從諸多方面去考慮。用大白話概括為三點，不強依賴第三方系統、自身系統健壯可靠、服務拆分不受其他服務影響。
微門戶系統在高可用這方面的設計還需要繼續加強，由於很多自身服務都要強依賴下游服務，保證自身服務質量尤其重要。當下游服務出現問題並且一定時間內還沒有恢復，需要及時通知到開發人員，這時一套健全的監控和告警系統是必不可少的。