《Akka應用模式：分佈式應用程序設計實踐指南》讀書筆記8

可用性

　　簡單點來講就是系統可否正常使用。若是系統可以及時響應一個請求，則認爲是可用的；若是響應時間過長或者根本不響應，則是不可用的。系統在停機或超載時是不可用的。通常用系統正常運行時長的百分比來計量系統的可用性，例如經常用N個9表示系統的可用性。故障時間秒數=(1-可用性) * 365 * 24 * 3600

描述	通俗叫法	可用性級別	年度停機時間
基本可用性	2個9	99%	87.6小時
較高可用性	3個9	99.9%	8.8小時
具備故障自動恢復能力的可用性	4個9	99.99%	53分鐘
極高可用性	5個9	99.999%	5分鐘

 　　與可用性相關的幾個概念在這裏稍微提一下，雖然本書並無說起。

　　RPO：（Recovery Point Obejective，恢復點目標）是指業務系統所容許的在災難過程當中的最大數據丟失量，用來衡量容災系統的數據冗餘備份能力。

　　RTO：（Recovery Time Objective，恢復時間目標）是指信息系統從災難狀態恢復到可運行狀態所需的時間，用來衡量容災系統的業務恢復能力。

　　第七章提到了不少致使系統不可用的因素，並且沒法徹底避免出現故障。可用性則要求在出現故障時能夠找到緩解故障的方法，儘量快的恢復系統。

微服務和單體式應用

　　應用程序通常由兩種構建方法：單體式架構、微服務架構。通常處於兩者中間狀態。

　　單體式應用程序是指把全部組件都部署爲單個單元的應用程序。通常建立各類獨立的庫隔離複雜性，而後把這些庫編織在一塊兒構建成一個完整的大系統。微服務則經過較大的應用程序分紅較小的服務來構建，以隔離的方式執行很是細微的任務，複雜性被隔離在各個獨立的微服務以內，而後經過其餘微服務進行組合。

　　其實兩種架構是對「分而治之」思想的不一樣粒度的解釋。單體式應用從微觀的角度拆分系統，微服務從總體的角度拆分系統。由此來看，並非拆分的越細越好。

　　雖然可用性跟哪一種架構沒太大關聯，但系統拆分的粒度不一樣，則提供可用性和可擴展性的方法就不一樣。單體式應用只有一個可部署的單元，此時提升可用性通常就是把部署單元複製多份。這個實施起來簡單粗暴，還有效。但有時候不必定能奏效。好比部署單元能夠複製多份，可是數據庫卻不能簡單的複製多份，畢竟數據纔是王道。

　　微服務就是把單體式應用拆分爲多個子系統，每一個系統是獨立的，子系統能夠看作單體式應用按照複製的方法提升可用性。

　　Akka爲多個微服務通訊提供相關的工具。

用有界上下文劃分微服務

　　其實微服務的劃分方法，每一個人有不一樣的看法。我比較傾向於做者的劃分方法，也就是從業務的角度劃分微服務。DDD提供了一種將應用程序劃分爲較小部件的方法，有界上下文就是劃分的界限。但有些人傾向於從系統的角度劃分微服務，其實就是將系統的各個模塊抽象、獨立出來成爲一個子系統。好比將一組邏輯上相關的jar包封裝起來對外提供服務。這一點就見仁見智吧。其實DDD能夠很天然的映射到Akka的相關技術，這裏就不對做者提到的方法進行闡述了，讀者自行體會吧。

細粒度的微服務

　　有界上下文是劃分應用程序的完美起點，但有時候須要分解成更小的規則。Akka常常把界面和域分紅單獨的微服務，這樣就能夠獨立地擴展雙方。關於這一點就須要咱們根據系統的實際狀況來平衡了。但我以爲基本的出發點就是封裝變化，並對其進行擴展。

集羣感知路由器

　　使用本地的單個actor系統構建時，路由器能夠提升可擴展性。處理分佈式系統時，還能夠將路由器做爲一個提供可用性的工具。集羣感知路由器與普通路由器相似，只不過它的路由可能駐留在集羣中的其餘節點上，容許這些路由器在可擴展性以外提供可用性。其實路由器有點相似於註冊中心，路由器負責分發消息。集羣感知路由器能夠自動感知節點的位置，並根據路由策略發送消息。若是一個節點出現故障，路由器能夠簡單的把消息路由到另一個不經過的活躍節點上。這就額外得到了可用性。

　　集羣感知路由器與本地路由器的路由策略稍有不一樣。好比使用最小郵箱的路由器不知道集羣中哪一個節點的郵箱比較小。集羣感知路由器經過actor的相對路徑收集集羣中全部符合條件的actor，與單例代理不一樣，它不會緩存消息，也就是消息可能丟失。

 分佈式數據

　　在最終一致的分佈式系統中，有時候會遇到瞬態數據，其實也就是臨時數據。他們不須要保存在數據庫，只存在應用程序運行期間，好比用戶的會話信息。瞬態信息在全部節點上保持可用性對系統來講很是重要。好比用戶信息若是在新節點上不可用，系統就沒法繼續爲該用戶提供正常的服務。其實吧，我以爲若是瞬態數據很是重要，那就保存在數據庫唄，實在不行保存在分佈式緩存也是好的。Akka爲此還單獨提供了相關的組件，真是考慮周到啊。

　　Akka爲咱們提供了一種分佈式的、最終一致的存儲和檢索數據的方法。這種最終一致的數據類型被稱爲無衝突複製數據類型或CRDT（Conflict-Free Replicated Data Types）。關於這個CRDT網上的資料不是不少啊。Akka實現了稱爲分部署數據的CRDT，目前還不穩定。

　　CRDT要求數據類型必須包含一個無衝突的合併方法，此方法具備接收兩種不一樣狀態的數據（來自集羣中兩個不一樣位置）並將其合併在一塊兒以建立最終結果的能力。若是合併完成沒有遇到衝突，那麼就可使用此數據結構來跨節點進行復制。這就是CRDT的工做原理，當一個節點收到對數據更新的命令時，它將當前狀態廣播給其餘節點。其餘節點收到更新的狀態時，與本身的狀態進行合併，而後存儲最終結果。關於這個CRDT能夠參考wikipedia。不建議使用這個東西，畢竟用一個數據庫或者分佈式緩存就能夠搞定了，還這麼麻煩進行廣播。這個技術只能說明Akka的強大和複雜而已。

優雅降級

　　將應用程序分解爲微服務的好處之一就是能夠實現優雅降級，但前提是你的系統得支持優雅降級。優雅降級須要你衡量系統的重要性、優先級，也就是說那些服務是能夠降級的。熔斷器模式能夠實現優雅降級。好比檢測外部系統的故障是一個耗時的操做，若是每一個後續請求都要等待鏈接超時知道資源再次可用，整個系統將承擔不少額外的負擔。熔斷器能夠快速的使後續請求快速失敗，能夠有效減小系統的負載，便於系統故障恢復，也能夠提升系統的可用性。

　　其實熔斷器是「分而治之」的逆向思惟，有時候過渡分解不是一件好事，把檢測超時這個功能向上抽象彙總，提供統一的處理方式，能夠有效的減小系統的負載，帶來上述的好處。看來系統並不必定是越精細越好。

 部署

　　即便應用程序提升了可用性，但若是部署時仍須要關閉整個應用程序，那麼可用性就會大打折扣。因此提升可用性是一件比較困難的事情。

分階段部署/滾動重啓

　　致使節點在系統中不可用的最多見的緣由並非錯誤，而是升級！這聽起來挺扯的。即便你的應用程序設計的完美，不會宕機，但若是升級的時候須要停機，那麼可用性這個指標就不會過高。特別是你有100臺機器須要升級版本的時候，那就更加痛苦了。若是你的版本不兼容，那麼就意味着100臺機器須要同時關掉，而後一臺臺部署。想一想就以爲呵呵。固然了，若是你的自動化運維比較完善，就會省事兒不少。

　　分佈式系統最經常使用的方法就是使用分階段部署，也成爲滾動重啓。滾動重啓有一個比較關鍵的技術就是對請求進行分流，也就是能夠將系統的請求暫時路由到舊有系統，當新節點可用時，再將請求迴流。固然了，這只是涉及一個系統，若是涉及多個系統，那就更麻煩了。若是兩個系統必須同步升級，好比接口變化了，且版本不兼容，想一想是否是更加以爲呵呵？另外一個關鍵的技術就是版本兼容了。因此可用性並非一件容易的事兒。

藍綠部署

　　滾動升級的替代方案被稱爲藍綠部署，其實仍是滾動升級。把50%的節點指定爲「藍色」，剩下的50%指定爲「綠色」。綠色節點處理請求時，升級藍色節點，檢查運行狀態，而後交替升級。

崩潰恢復/運維監測

　　集羣可用性的關鍵指標是可以識別出故障是何時發生的，而後對其進行適當的處理。固然是越早發現越好，這樣就能夠提升 可用時間。此時運維監測就很是重要了。

健康檢查和應用狀態頁面

　　大多數監測工具都是依賴某種健康檢查機制。執行健康檢查的最多見機制是使用HTTP狀態頁面，這一點感受做者說的有點侷限，只能說這是一種常見的顯示機制，而不是執行機制。即便應用程序不須要HTTP接口，包含Akka HTTP健康檢查頁面也是一件好事。徹底使用actor通訊的微服務也能夠從用Akka HTTP端點搭建的監控中收益。這個頁面具體包含什麼信息比較靈活，做者建議把外部依賴是否可用、應用程序版本號或提交HASH包含進來。

度量

　　健康檢查是一個很好的工具，但它具備滯後性，只能在出現問題的時候纔去適當的措施。那麼能不能預防故障的發生呢？常見的是使用服務指標度量系統，一般是一個時間序列數據庫。把系統的服務指標進行可視化展現和響應的分析，就能夠作到提早檢測系統問題了。基於Akka或其餘方式的分佈式系統通常都會將入口點周圍的計時器包裹到系統中，用來記錄操做開始和結束的時間，計算差別值，而後存儲。但須要特別說明的是，必定要注意時間字段獲取的準確性！一般狀況下，分佈式節點的時間不必定同步或者有必定的偏差！特別是在金融業務系統中，不少機器都會且日跑批量神馬的，比較麻煩。

　　度量是一個技術活，度量後如何分析就須要根據各個業務系統自行設計了。不屬於Akka的範疇，就再也不過多分析了。

日誌

　　度量以後發現了異常，下一步就須要肯定緣由，日誌就變得相當重要了。基於Akka開發分佈式一個好處就是，日誌是異步打印的，不太會影響系統的性能。不少時候，生產商通常不開日誌，由於怕影響性能，因此日誌每每會被忽略。

看門狗工具

　　發現了問題就須要採起對應的措施，首先須要某種通知機制提醒運維人員或者開發人員。經常使用的通知機制有郵件、短信、電話、微信。但不能只是簡單粗暴的進行預警，若是預警多了，就會減小運維人員的注意力。若是可以採起一些糾正措施就更好了，好比重啓。

　　其實應用監測是一個比較大的議題，遠超出了Akka的範圍。不少工具須要組合使用，才能發揮最大的做用。

結論

　　從本章能夠看出，提升系統的可用性是一個系統工程，須要多種工具、策略來確保。這有時候比分佈式系統自己更加複雜。