前言
我們經常會說互聯網“三高”，那什么是三高呢？我們常說的三高，高并發、高可用、高性能，這些技術是構建現代互聯網應用程式所必需的，對于京東618備戰來說，所有的中臺系統服務，無疑都是圍繞著三高來展開的，對于一個程式員，或多或少都能說出一些跟三高系統有關的技術點，而我本篇文章的目的，就是幫大家系統的梳理一下三高系統中的第一高：高可用性，
首先來說，互聯網的業務特點決定了他必須保證“三高”， 同時，高并發，高可用，高性能，這三高之間并不是孤立的，而是強相關，一個高可用的系統，一定也需要應對高并發場景對系統帶來的沖擊，保證系統在高流量訪問情況下，系統的服務的正常運轉，同時，一個能夠支撐高并發的系統也一定要滿足高性能，否則也無法實作高流量的承載，
回到我們本文的主旨，我們這里所說的高可用性是指，系統在遇到任何困難的情況下仍能正常運行的能力，
在京東618備戰期間，系統的高可用對我們來說至關重要，因為系統的崩潰，不止帶來直接經濟上的損失，還會導致用戶信任的丟失，接下來我通過一張思維導圖展開我的分享，幫大家梳理一下一個高可用系統所需要考慮的技術點，
開發時
1. 首先技術架構方案選型很重要,切記避免過度設計，
比如我們常說的單體應用架構和微服務架構，兩種架構單純來對比，單體應用架構的可用率要比微服務架構高的，因為多服務之間的依賴一定會降低系統的可用率，比如一個依賴10個微服務的對外介面，假設每個服務的可用率是99%，那么這個介面對外提供服務的整體可用率就直接降到了90.4%，這中間還要考慮到服務之間的網路延遲，資料一致性的問題，
還有例子就是中間件選擇，比如一個快取業務場景，我可以用記憶體快取，也可以使用redis分布式快取，那么使用哪個呢？使用記憶體快取系統可用率會高，因為如果引來redis，系統的可用率又得乘以一個redis的可用率，當然如果我們的業務場景必須使用redis，那么也是完全可以的，但這里切記系統的過度設計，也是設計復雜的系統，也需要更多的高可用相關的保證，所付出的資源代價和運維代價也是幾何增長，
2. 其次就是代碼質量，
其實這個可能是很多人忽略的一點，因為很多人更喜歡高談闊論分布式，集群，壓測，故障演練等等，但在我看來，一個代碼開發質量的好壞，或者說一個程式員對代碼的掌控力，對系統可用性起到至關重要的作用，以下舉幾個代碼維度的例子，
第一個就是例外處理，一個代碼質量的好壞，要看他對例外處理能力，一個本科生的課程設計代碼，可能都是主業務邏輯，一條路寫到黑，不考慮任何例外情況，而一個畢業幾年的程式員，經歷過線上業務的拷打，可能會用在代碼里找到很多的try-catch，用于捕捉各種不確定邏輯，而一個資深程式員，反而他的代碼里你看不到任何try-catch, 因為他全部用AOP的方式實作了例外的捕捉，這就是代碼維度的考量，一個優秀的代碼，一定是防御式編程，同時還會配合單元測驗等，
第二個講述一個什么是對代碼的掌控力，在大廠里，你更多場景是接手別人的老代碼，想必所有程式員都深有體會，接手別人的老代碼是一件極其痛苦的經歷，尤其是別人寫了一半的代碼，老話前人種樹后人乘涼，但在程式員圈，前人種樹，后人只能涼涼了..... 調侃歸調侃，但有些事情需要面對，前期你需要對業務場景和代碼邏輯進行抽絲剝繭的梳理，這個很重要，如果你無法對老代碼進行充分熟悉，那么你就不敢去改寫和重構它，如果在不熟悉的前提下貿然修改代碼或者配置，然后上線，那么很大幾率會帶來線上系統問題，影響系統可用率，換一個角度來說，我們寫的代碼未來也可能交接給別人，如何不讓別人痛苦，也是我們的責任，所以合理使用設計模式，遵循代碼規范，書寫代碼架構和設計檔案，這些也是很重要的一點，他的重要可能會關乎系統未來的可用率，
對于代碼開發這塊，京東技術平臺也沉淀了一些自己的經驗，內部有自己的java代碼開發規范說明檔案，也在京英學習平臺上可以進行考試，而京東的coding平臺，可以在你代碼提交時，配置代碼開發規范掃描和代碼安全性掃描，同時，可以配置代碼評審人，這些都可以用來提升我們代碼質量，
部署時
1. 冗余性和備份
在部署維度，我們首先考慮的是冗余性和備份設計，這個可能是大家已經很熟悉的情況了，我們可以通過集群的方式，多個服務器、磁盤或者網路介面來減少故障點的數量，說到集群，根據實作方式和目的不同，我幫大家梳理一下集中集群型別：
（1）高可用集群，
有多個獨立服務器組成的系統，旨在提高系統可用性，當主節點出現故障時，通過失敗轉移（Failover）讓備用節點自動接管服務，這個我們常見的有zookeeper集群，etcd集群等等，這類集群是基于共識演算法實作的， 通過選舉的方式，來保證當主節點故障時，可以有自動備份節點自動接管，
（2）負載均衡集群，
在負載均衡系統中，流量被分散到多個服務器中，每個服務器都獨立地處理請求，當一個服務器負載過高或出現故障時，請求會自動被轉移到其他可用的服務器上，從而保證系統的可用性和性能，負載均衡可以在多個層面上實作，包括應用層、傳輸層和網路層，在應用層負載均衡中，負載均衡器通常通過HTTP代理來分發請求，并根據請求的特定屬性（例如URL或Cookie）進行路由，在傳輸層負載均衡中，負載均衡器通常在傳輸層（例如TCP或UDP）上運行，并根據埠號或其他特定協議進行路由，在網路層負載均衡中，負載均衡器通常是一個獨立的網路設備，用于在不同的服務器之間分發網路流量，
（3）資料庫集群，
這里的資料庫可以理解為廣義資料庫，就是資料的存盤媒介，對于資料庫的的集群實作方式，分為如下幾個：主從復制，復制集，磁區，
關于這幾種實作方案，這里可以elasticsearch舉例說明，ES有分片和副本的概念，所謂的分片，就是將資料水平劃分到多個節點，每個節點存盤部分資料，當查詢資料時，需要在多個節點上進行查詢，最后將結果合并，磁區可以實作資料的高可用性和可擴展性，但需要考慮資料一致性問題，
同時ES的每個分片都可以配置多個副本，副本跟主從復制類似，或者說更像一個集群內的高可用子集，允許多個副本實體同時存在，并支持自動故障轉移和成員選舉，保證了資料的高可用性和負載均衡，
此外，對于集群方案來說，還要額外考慮多機房部署問題，異地多活，換句話說，我所有服務實體，不能放在一個籃子里，因為網路的抖動和不穩定性，對系統可用性來說是很大的威脅，
2. 發布檢測
在部署維度，第二個關鍵點是發布檢測，有統計資料表明，我們大部分的穩定性問題來源于系統變更，也就是系統的發布上線，那么如何保證一個平穩的系統上線呢？
首先，要完善自動化測驗和單元測驗，每次發版前，必回歸測驗，當然這塊如果交給人工來做，費時費力，不一定能起到他的效果，所有說，完善的自動化測驗流程，對于系統穩定性部署來說，至關重要，
其次就是做好發布的自動化，在發版程序中，減少人為參與，這樣也就減少了出錯的可能性，京東的行云部署本身就支持部署編排，利用部署編排，可以穩定且高效的實線滾動發版，同時也可以在行云上的流水線中配置CI/CD流程，實作繼續集成和持續部署的串聯，
最后就是要實作發版的可觀測，可灰度，可回滾，發版前要有checklist，發版時采用灰度發布驗證的方式，可以降低因為發版引起的線上故障，最后如果發版發現失敗，可以實作快速的回滾操作，這個就要在發版前的checkList里，做好回滾流程的備案，
運維時
在運維時，我們的目標是能夠快速止損線上問題，做到問題早發現，快定位，速解決，
1. 系統全鏈路觀測和監控
在互聯網系統中，從用戶請求開始，經過所有的系統組件或服務，直到回應回傳給用戶，對整個系統的性能、穩定性和可用性進行全面觀測和監控的程序，這包括了對硬體、網路、存盤、軟體等方面的觀測，監控，
在京東618備戰期間，所有應用系統都必須完成自建，完善UMP監控埋點，對核心介面方法的可用率，TP99，呼叫量進行實時監控，同時，也對需要對云主機，中間件等資源維度，包括CPU，記憶體，資源占有率進行實時監控，
此外，針對監控，要做好日志監控做好采集作業，因為日志記錄了系統中各個組件或服務的運行狀態，可以提供豐富的資訊用于問題排查和分析，
在京東內部采用logbook進行日志采集，對于核心業務需要審計留存的，可以單獨搭建ELK，將歷史日志存入ES中，
2. 值班與報警，
針對618備戰期間，需要額外安排固定人員進行每日值班，做到對線上問題可以及時反饋，
針對報警機制，有一點需要切記，要把握好報警的閾值問題，如果閾值偏低，會導致研發人員頻繁收到報警，導致警惕性降低，而如果閾值偏高，會錯過一些線上問題，導致問題沒有及時發現，致使故障擴大化，
3. 故障演練及應急機制，
京東內部有兩大利器，一個是ForceBot，一個是Chaos Monkey，
前者是做全鏈路軍演壓測用的，一般618大促前要進行三次軍演壓測，通過這些軍演，讓各個應用系統發現系統中的薄弱點，并針對性解決，forcebot是通過部署在全國各地的CDN節點，模擬真實用戶發起的大規模訪問流量，這種接近實戰的壓測，可以讓我們做到防患于未然，同時，通過壓測，可以針對性的優化服務資源，能夠更針對性的進行擴容，
第二個我們有時候會叫猴子搗亂測驗，也會叫混沌測驗，它能夠通過模擬包括網路，中間件，流量等在內的各種故障，通過故障的隨機注入，來演練我們對系統故障的反應能力，
這里就該提到所謂的應急機制，該機制就像一本類似醫院給發的急救指南手冊，需要在日常做到對各種不確定的故障進行反應能力，比如遇到突發高流量，系統出現了熔斷，如何快速擴容云主機和各類中間件資源；比如網路突然發生延遲，介面請求超時情況下，如何做好降級方案等等，
總結
本文寫于京東618備戰開門紅前夜值班之時，
以上的所有關于系統高可用的總結，都源于一次次的前人的實踐經驗總結出來的，每次備戰略細節有不同，但大的方向原則是不變的，
祝：京東618 大麥，
作者：京東物流 趙勇萍
來源：京東云開發者社區
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/554473.html
標籤：架構設計
下一篇：返回列表