從建設到治理，從系統到團隊，談高可用架構之道

何為高可用架構，如何高可用架構，一百家互聯網企業可能摸索出數千種探索道路並給出數萬種答案，但符合自身企業技術環境發展的答案可能有且只有一種，如何從海量實踐中提煉出值得借鑒學習的高可用架構之道，相信是不少一線技術管理者需要深思熟慮的問題。

InfoQ：能否簡單介紹您總結的大型促銷備戰方法論？在總結這套方法論的過程中您遇到哪些印象深刻的經驗或教訓？

林世洪：簡單總結一下：「積極防禦、及早發現、快速處理」。實際上，問題的防禦、發現和處理是大家都知道的動作，大家分享得很多了，我原來的分享也分場景列舉了不少，在此不多做解釋，關鍵是這每一個動作前面都加一個副詞來約束，哪個做到都不容易。
1. 積極
指的是意識方面問題。如果不親自參與到系統的運營過程中，研發人員很難體會到防禦設計的必要性。那些參與過系統運營，特別是參與過事件處理的人，對系統缺陷和穩定性有更深刻的認識，回頭再設計系統時考慮就會周全，這是第一層，可以稱為意識培養，即培養可運營化設計的意識。
這種意識的強度往往呈現出周期性波動，過了一段時間就會淡薄，直至有外力強化，包括真實事件強化和培訓強化，這就出現了第二層，可以稱為意識治理。
最後一層藉助一種制度，即系統負責人的制度，系統負責人對系統的穩定和發展負責，他會以主人翁的精神來養育系統，使得系統持續穩定發展，這一層可以稱作意識管理。
2. 及早
這是一個相對的時間概念，通過監控等手段及時發現問題，甚至在問題出現之前就能預測出來，從而儘早介入處理，可以避免或減少對業務的影響。
這裡舉一個針對任務處理系統的監控例子：任務出現積壓，而且積壓在增多，這時監控系統會檢查其吞吐能力和處理延遲，如果處理延遲在增大，吞吐能力在降低，則說明系統有問題，否則系統正常；如果任務沒有積壓，但處理延遲有明顯增大趨勢，則系統出現問題的幾率比較大。
從這個例子看出來，發現問題要綜合看多個指標，同時考慮量（積壓量）和趨勢，才能及時準確地判斷是否發生了問題，以及問題發生在哪裡。
3. 快速
系統運行時可能遇到各種各樣的問題，如果有對應的應急預案，並演練到位、分工明確，各種決策要素可以迅速收集，保證工具齊全，則可從容決策和處理，即達到「快速」的要求。這裡需要強調的是，當真出現了緊急情況，最要緊的並不是去尋找問題的根源，而是果斷採取措施控制住影響。越早決策，影響就越小。有些技術人員喜歡刨根問底找原因，忽略了對業務的影響程度，可能會使一個小事件升級為大事件，大家要特別注意。

InfoQ：多機房部署模式有很多種，例如傳統的兩地三中心到現在的分散式多活中心，能否結合京東的多中心交易系統談談京東在多機房部署模式的選型思路？以及在建設過程中遇到什麼困難最後如何解決的？

林世洪：談到多機房部署方式，最主要的內在決定因素是系統本身，不同的系統對可用性的要求也是不一樣的。我們會對系統進行分級分類治理，例如我們會把電商核心主流程系統，以及主流程系統必需的基礎系統和中間件定義為0級系統，公司會在0級系統傾斜更多的人力和物力資源，設計更加可靠的架構和部署模式。
同樣是0級系統，其部署模式也有區別。我們把系統分為前端系統和後端系統，前端系統如結算頁和下單系統，因對客戶體驗敏感，系統可用性和響應速度都有很高的要求，所以採用了多交易中心的部署策略，一方面通過多個分中心的方案來滿足響應速度的要求，另一方面通過主中心來滿足可用性要求。
後端系統相對更注意吞吐能力和數據一致性等方面的要求，可用性要求和響應速度相對低，往往採用較簡單的主從備架構或者應用多活架構，沒有分中心的設計，這樣系統建設成本和維護成本都相對低，即使出現機房故障，也允許花較長時間來切換機房。
多中心交易系統建設過程遇到不少挑戰：
數據一致性問題，這是比較大的挑戰，多中心交易方案從本質上是一個分散式系統，天然地存在數據分區，也就有數據分區問題，在解決這類問題時，採用了場景化數據分類處理的策略。在正常場景下，交易數據只能從分中心產生，同步到主中心；而交易所需要的主數據則從主中心同步到分中心，在分中心故障場景下交易數據才可以在主中心產生。
數據同步問題，MySQL資料庫提供的同步機制無法滿足及時性問題和異構數據之間的同步問題，我們專門為此開發了一套數據同步中間件系統，它採用匯流排結構，解決了多數據源間的數據異構同步難題；通過併發處理提升了吞吐能力，節省了同步時間；本身通過HA機制實現了高可用。

InfoQ：您談到越來越多的互聯網企業在建設自己的數據中心，為什麼會有這樣的趨勢？如何評估從租賃到自建的轉折點？

林世洪：首先，自建數據中心需要充足的資金，投入的內容包括土地、基建、風火水電等基礎設施、電信資源、IT基礎設施、整個運營環境等等，並且需要專業的運營管理能力。如此巨大的投入，為什麼還要自建呢?
自建數據中心通常是為了解決市場已有數據中心無法滿足需求的矛盾，通常表現在數據中心的規模容量、功能設計、服務保障等等，當商業數據中心在某些方面無法滿足企業的剛需時，企業會選擇自建。
關於由租轉建的轉折點，可以是投入產出比，也可以是核心生產力長期回報，也可以是某種特殊的契機、情景，這要看企業當前發展階段的訴求和矛盾是什麼。但相信，如果自建數據中心帶來的綜合收益明顯大於租用、解決了企業的切實需求，企業就可能要考慮自建，甚至在出現這種趨勢時就會考慮自建，畢竟自建周期比較長，而且需要積累經驗。
另外自建數據中心是企業綜合實力的體現，對整個技術體系和格局會帶來積極的推動作用，形成良性局面后對企業的技術核心競爭力長期發展、成本優化、人才培養都會帶來積極的作用，例如：Google、Facebook等已經從中獲得了顯著的成效。通過足夠的規模效應、技術和管理優化，壓縮成本。通過選擇更低成本的地區、甚至國家，以獲得相對更低的成本。

InfoQ：架構設計要與企業的業務規模和發展趨勢相匹配，架構設計往往需要考慮前瞻性，您認為在業務快速擴張階段如何避免在架構設計上滯后或超前於發展趨勢？

林世洪：凡事預則立，不預則廢，需要給架構設計者一個設計原則，必須遵守，即did原則：design 20倍體量，implement 3倍的體量，deploy 1.5倍的體量。這裡的體量結合非功能要求來說，可以是吞吐量、存儲容量等。
要貫徹這個原則，需要對業務量的發展有預判，對系統處理能力有評估，對設計方案有評審，對資源申請有審核，對線上資源利用率有監督，這些流程對應的手段很多，這裡不多贅述。
除了體量之外，還是一個先進性跟蹤的問題，架構設計上如果過於超前，對於技術開發人員要求較高，往往需要專業的團隊，這樣成本會有相應的增加。如果技術開發人員的水平跟不上的話，就會影響業務的變化。
隨著業務的發展、業務的迅速迭代，系統會變得越來越複雜，系統架構越來越重，往往事與願違。但無論如何，一個企業應該及早地實施服務化，因為它能將一個較大的問題分解為多個較小的問題，非常適合快速成長的企業快速多變的需求特徵；同時應該注意通過流程式控制制系統將流程式控制制邏輯集中處理，避免流程式控制制分散帶來的數據不一致問題。
互聯網技術已走進世界第一梯隊，技術不但不應該成為影響業務發展的瓶頸，反過來應該是推動業務發展的源泉。一個公司在發展的早期，可以不必過分注重技術的先進性，只要業務能發展起來，技術債還起來不是難事，會從債務變成債主。京東和阿里都是這樣的例子，先是技術跟著業務走，逐漸驅動業務發展。

InfoQ：在各業務線上的敏捷開發模式是否會給架構治理帶來困擾，在平衡開發效率和開發約束之間您有什麼經驗可以分享？

林世洪：我們的研發分為多條業務線，每條業務線中有多個系統，每個系統相關的研發、測試、產品、業務人員實施敏捷開發，目的是保持溝通的高效率和減少不必要的干擾，保持對業務變化的快速響應。
如果有架構升級相應的工作，通常不會大規模地實施，我們會選擇典型系統作為小白鼠，採取小步快跑的方式進行，不會對所有系統進行統一的架構升級工作，這樣太重了，不夠安全，也不利於品質的保障。
另外我們的技術架構體系是多層次的，也為我們架構升級與業務系統的開發迭代工作的隔離提供了有利條件，所有架構改進的實施必須安全、快速，盡量不打斷正常的產品研發的節奏。架構升級的工作會適應業務系統的每個迭代，每次迭代制定明確的目標。
以升級消息隊列服務為例：
第一個迭代的任務是選擇合適的業務系統進行調研，制定相應的切換升級策略；
第二個迭代是開發，架構師進入到該項目中與業務系統同步，這個迭代與新產品發布同時完成；
第三個迭代是消息隊列系統本身的改進，包括性能、容量、併發上的一些改進，經過幾個迭代后，其他業務系統都可以放心大規模使用新的消息隊列。

InfoQ：能否總結在高可用架構建設中有哪些「天災人禍」可以有效杜絕，以及是如何做到的？進一步地目前還有哪些「天災人禍」還不能有效預防？

林世洪：先說下還有哪些「天災人禍」不能防吧：
用戶端軟硬體故障：例如電腦不顯示了，這個我們沒辦法預防，但可以採取措施減少銷售機會的喪失，如提供手機APP、H5、視頻購物等。如果用戶上不了網了，我們可以提供離線瀏覽功能等等；
出現極端的不可抗力：如不同城市的所有機房同時斷電斷網，這種情況是真的不可抗了。
一般場景都可以有效預防，但有些場景必須特別注意，處理不好就會引起可用性問題，而且問題發生幾率相對高，舉兩個例子：
基礎服務系統全部同時重啟：如果一個基礎服務的客戶端非常多，調用量非常大，這樣做可能是災難性的，如果自我保護措施做的不好，可能產生類似DDoS攻擊的效果；
降級措施自動實施：自動降級一定要小心，經常因檢測手段不可靠造成錯誤操作的情況。
下面再談可以杜絕的問題：
單個伺服器故障：對於無狀態伺服器，使用集群即可應對，對於有狀態伺服器，可以啟用備用伺服器；
某個服務集群故障：切備用集群，也可以準備降級預案，預案可以是多級多策略的；
某個機房故障：可以將切到另外一個機房，如果是多活的應用則不用切換，但有可能需要做流量控制；
出現意料之外的峰值，或因資源等問題造成處理能力下降：措施可以是過載自我保護、啟動非同步降級預案、緊急擴容；
運營商網路故障：網路架構分層，入口在一層，可以將入口切到其它運營商，以下各層不需要切換；
從以上來看，系統的擴展能力和自我防護能力是架構上的標配。另外，雖然這些問題都可以應對，但應對措施是由人來做的（即使有自動化的措施），所以必須加強演練，以提高決策速度和準確度，要有自動檢查機制防止錯誤的命令被執行。

InfoQ：關於大規模服務過載后的恢複流程，能否舉例您是如何盡量減少服務受影響的時間？目前是否遇到不能自動化處理的問題？能否談談你們對大規模故障恢復時長的指標要求以及如何做到？

林世洪：首先，設計合理的架構都會有過載保護機制，來避免大規模服務過載的發生。舉個例子：
A系統調用B系統，曾出現檢測出A端服務響應時間長，可用率降低的同時，B端檢測到服務響應時間和可用率都很正常的情況。這個例子里B端做了過載保護，限制了併發調用量，所以B保持了自身的健康。
再舉一個發生了服務過載的例子：
A系統是一個自動工作流系統，它會依次調用BCD等若干個服務，有一次出現較大的峰值，BCD負載飈高，服務響應時間不斷增加。A收到了報警，顯示各環節出現積壓，且吞吐量出現下降，表明BCD已出現問題。這時A啟用降級流程，將BCD的調用頻率降低，BCD緊急擴容后，A恢復調用頻率，整個流程恢復正常。這是一個客戶端流程量控制的例子。
簡單總結下減少影響時間的幾個舉措：
一定要遵循一個原則，發現問題后，並不是急於找到發生問題的根本原因，而是要考慮如何將業務影響控制到最小的範圍內，果斷決策，迅速處理。為了提高決策的效率和準確度，應該做好數據收集工作，這個工作可以由人工和系統來做，要逐步提高係數據收集的自動化，另外還要與各方保持暢通的聯絡；
需要事先準備好預案，並且做好演練；
做好預防措施。常見預防措施是做流量控制，有服務端控制、客戶端控制、服務平台控制三種，其中服務端自身流量控制是必須的。服務端和客戶端應該約定好SLA，包括流量上限、超過上限后的措施、出現問題后的應急措施等。
一個比較好的實踐是通過服務調用的併發數來控制，這樣評估資源需求、控制流量都容易量化，這種方法特別適用於後端系統，比傳統的按流量來控制容易得多。
另外一個比較顯著的措施是將高峰值的系統獨立部署，例如電商秒殺系統，雖然大部分邏輯與正常下單是一致的，但獨立出來可以做專門設計（如防作弊），同時可以起到隔離作用，即使秒殺系統出現問題，也不會影響正常下單。
提到自動化措施，對於數據收集、系統降級等，盡量提高自動化程度，但要避免誤判。舉例說明：系統存活的判別工作經常由獨立部署的監控服務來完成，有時候被監控對象與監控伺服器之間網路出現問題，但被監控對象正常，這時會發生誤判，可以通過增加監控伺服器、監控伺服器與被監控對象臨近部署、藉助客戶端監控等手段來避免。
某些事關全局的操作，例如IDC的切換，因為切換后處理成本較大，建議用半自動化方式，即人工決策和干預后批量自動處理。
故障處理一定要明確時間上的要求，而且還要有流程上的要求，而且級別超高，要求越嚴格。要求事件發生多長時間介入處理、多長時間控制影響、彙報關係、彙報頻率等，出現損失會有懲罰措施，懲罰力度有章可循。這些要求會促使團隊不斷改進系統、改善運營，團隊也在這個過程中得到成長。
總結一下保障措施：
監控與報警；
自動化數據收集；
制定應急預案並演練；
自動化和半自動化的運營工具；
事件分級與處理流程，懲罰制度；
系統負責人制度；

InfoQ：系統高可用是互聯網企業系統架構的基礎要求之一，您認為一個架構師應該構建怎樣的知識體系可以更全面地看待架構發展從而減少架構的短板和瓶頸？

林世洪：第一，你的知識體系里必須有業務，要了解業務架構的梳理和設計方法。可以從自己所負責的系統所支撐的業務起，了解業務整體，了解系統支撐的業務在整體中的位置，進而可以識別核心業務、識別核心業務流程、識別業務領域邊界，分析各業務對技術的要求；
第二，系統運行環境對可用性有直接關係，運行環境的高可靠是應用高可用的基礎保障，所以你的知識體系里要包括應用的運行環境，包括網路知識、系統知識、簡單的硬體知識；
第三，需要有系統運營知識和經驗，深刻體會高可用的價值所在，設計上會更有針對性；
第四，注意學習和總結，掌握一些架構設計和治理原則，如：系統、服務、數據的分級分類分層的設計和治理、系統的拆分和依賴設計原則、分散式系統設計，可以研究典型的廣泛應用於互聯網應用的開源系統的高可用設計，如分散式緩存、分散式文件系統、分散式調度系統等，多了解走在技術前沿的互聯網企業的技術架構。

InfoQ：感謝林世洪老師接受我們的採訪，期待ArchSummit全球架構師峰會上您策劃的高可用架構之道專題。

受訪嘉賓介紹

林世洪，畢業於北京交通大學，2011年加入京東，先後負責京東訂單履約體系和零售平台架構工作，連續兩屆架構委員會成員，此期間主導和參與了京東研發若干規範的制定，著力推動電商核心繫統架構升級，總結形成了大型促銷備戰方法論，保障了電商主流程系統的穩定性，降低了整體系統建設成本。個人技術方面更多關注根據業務特點和技術要求對系統進行可運營化改造和治理。