【618備戰巡禮】“三高”之第一高--如何打造高可用系統

前言

我們經常會說網際網路 “三高”，那什麼是三高呢？我們常說的三高，高并發、高可用、高性能，這些技術是建構現代網際網路應用程式所必需的。對于京東 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 大麥。

作者：京東物流 趙勇萍

來源：京東雲開發者社群