歡迎來到Tungsten Fabric用戶案例系列文章，一起發現TF的更多應用場景。“揭祕LOL”系列的主人公是Tungsten Fabric用戶Riot Games遊戲公司，作爲LOL《英雄聯盟》的開發和運營商，Riot Games面臨全球範圍複雜部署的挑戰，讓我們一起揭祕LOL背後的“英雄們”，看他們是如何運行在線服務的吧。
作者：Doug Lardo和David Press（文章來源：Riot Games）譯者：TF中文社區
在上一篇文章中，我們討論了Riot針對全球應用程序部署的解決方案rCluster所涉及的網絡的一些內容。具體來說，我們討論了overlay網絡的概念，OpenContrail（編者按：已更名爲Tungsten Fabric，下文中出現OpenContrail之處，均以Tungsten Fabric代替）的實現，以及Tungsten Fabric解決方案如何與Docker配合使用。
本文將在此基礎上深入探討其他主題：基礎架構即代碼、負載均衡和故障轉移測試。如果你對如何以及爲什麼建立這些工具、基礎架構和流程感到好奇，那麼本文正適合你。
基礎架構即代碼
通過Tungsten Fabric提供用於配置網絡的API，我們現在有機會自動化應用程序的網絡需求。在Riot，我們將持續交付作爲發佈應用程序的最佳實踐。這意味着每一次提交給master的代碼都是潛在可釋放的。
爲了達到這個狀態，應用程序必須經過嚴格的測試自動化，並具有完全自動化的構建和部署流程。一旦出現問題，這些部署也應該是可重複且可逆的。這種方法的複雜性之一，是應用程序的功能性不僅在於其代碼上，還在於環境方面，包括它所依賴的網絡功能。
爲了使構建和部署具有可重複性，應對應用程序及其環境的每個部分進行版本控制和審覈，以便知道誰更改了內容。這意味着不僅要在源代碼管理中擁有應用程序代碼的每個版本，並且還描述了其環境並將其版本化。
爲啓用此工作流，我們構建了一個系統，以簡單的JSON數據模型（我們稱爲網絡藍圖）描述應用程序的網絡功能。然後，我們創建了一個週期性工作，從源代碼管理中提取這些藍圖文件，然後將其轉換爲Tungsten Fabric上的API調用以實施適當的策略。使用此數據模型，應用程序開發人員可以定義需求，例如一個應用程序與其它應用程序進行交談的能力。開發人員不必擔心IP尋址或通常只有網絡工程師才能真正理解的任何細節。
應用程序開發人員擁有自己的網絡藍圖。現在，更改它們就像給其藍圖文件發出pull請求，並使對方將其合併到master一樣容易。通過啓用這樣的自主服務工作流，我們的網絡更改不再受限於少數專業網絡工程師。現在，唯一的瓶頸是工程師編輯JSON文件並單擊“提交”的速度。
該系統使我們能夠快速、輕鬆地打開必要的網絡訪問權限，這是安全策略的關鍵要素所在。在Riot，玩家的安全性至關重要，因此我們將安全性融入到了基礎架構當中。我們安全策略的兩個主要支柱是最低特權和縱深防禦。
最低特權，意味着Riot網絡上的任何參與者都只能訪問完成其工作所需的最少資源集。參與者可能是人，也可能是後端服務。通過執行此原則，我們極大地限制了潛在入侵的影響範圍。
深度防禦，意味着我們在基礎架構的多個位置執行安全策略。如果攻擊者破壞或繞過我們的執行點之一，他們將始終碰到更多可抗衡的東西。例如，公共Web服務器被禁止從網絡訪問支付系統，並且該系統還維護自己的一組防禦措施，比如第7層防火牆和入侵檢測系統。
Tungsten Fabric通過其vRouter在每個主機上添加一個執行點來幫助我們。通過基礎設施即代碼JSON描述文件來使用其API ，我們始終可以爲應用程序之間的通信提供最新的、版本化的，並且易於審覈的網絡策略。我們創建了可以掃描網絡規則的工具，以發現違反政策和訪問權限過大的情況。速度、最佳安全實踐，以及審覈能力的結合，構成了一個強大的安全系統，這並不會妨礙開發人員，相反，它使開發人員能夠快速、輕鬆地做正確的事情。
負載均衡
爲了滿足應用程序不斷增長的需求，我們將DNS、等價多路徑（ECMP）和傳統的基於TCP的負載均衡器（例如HAProxy或NGINX）相結合，以提供功能豐富且高度可用的負載均衡解決方案。
在Internet上，我們使用DNS將負載分散到多個全局IP地址上。玩家可以查找“riotplzmoarkatskins.riotgames.com”這樣的記錄（不是真實的，但也許應該是真實的），並且我們的服務器可以使用多個IP地址進行答覆，這些IP地址將響應DNS查詢。一半的玩家可能會收到一個列表，其中服務器A的位置位於頂部，而另一半玩家將看到服務器B的位置位於頂部。如果其中一臺服務器關閉，客戶端將自動嘗試另一臺服務器，因此沒有人會看到服務的中斷。
在網絡內部，我們有許多服務器都配置爲應答服務器A的IP地址。通過應答這個地址的能力，每個服務器都向網絡發佈通告，同時網絡將每個服務器視爲可能的目的地。收到新的玩家連接後，我們將在交換機中執行哈希計算，以確定性地計算出哪個服務器接收了流量。哈希基於數據包頭中的IP地址和TCP端口值的組合。
如果其中一臺服務器“休假”了，我們將嘗試使用一種稱爲“一致性哈希”的技術，最大程度地減少影響，以確保只有使用故障服務器的玩家受到影響。大多數情況下，客戶會通過自動重新啓動新連接來無縫處理此問題，受影響的玩家甚至不會注意到。收到新的連接後，我們已經檢測到並刪除了發生故障的服務器，因此不會浪費時間嘗試向其發送流量。
對於我們的大多數系統，我們會自動啓動一個新實例，一旦它準備好接收流量，系統就會將其重新添加到循環中。我們認爲它非常“漂亮”。負載均衡的最後一層，是通過傳統的基於TCP或HTTP的負載均衡器（例如HAproxy或NGINX）執行的。
當請求來自ECMP層時，它們可能會遇到許多負載均衡的實例。這些負載均衡實例監視每個真實的Web服務器，並確保服務器運行狀況良好，在適當的時間內做出響應，準備接收新的連接等。如果滿足所有這些條件，則服務器會收到請求，並且答覆將一直返回到玩家。
這一層通常是我們進行blue-green部署和智能運行狀況檢查的地方，例如“/index.html加載的響應代碼爲200嗎？”
（編者按：Bule-green部署是一種負載均衡健康檢查的部署方法，請見鏈接：https://blog.christianposta.com/deploy/blue-green-deployments-a-b-testing-and-canary-releases/）
此外，我們可以執行諸如“canary部署”，每10臺服務器中的一臺獲得最新版本的網頁，而其他9臺服務器仍使用舊版本。我們會密切監視新版本，以確保不會出現任何問題，如果進展順利，我們會將10臺服務器中的兩臺移至新版本，依此類推。如果情況不佳，就回退到上一個已知的穩定版本，並找出解決問題的方法。我們隨後將添加測試以更早地發現這些問題，以便不會兩次犯相同的錯誤。這使我們能夠不斷改進服務，同時最大程度地降低生產風險。
通過所有層的協同工作（DNS、ECMP和傳統的TCP或第7層負載均衡），我們爲開發人員和玩家提供了功能豐富、性能穩定，且具有可擴展性的解決方案，使我們能夠儘可能快地將服務器安裝在機架中。
故障切換測試
高可用系統最重要的部分之一，就是當發生故障時，該系統能夠進行故障轉移。當我們剛開始構建數據中心時，通過讓工程師拉出一些電纜，並在這裏和那裏重新啓動一些服務器，來模擬這些問題。但是，一旦數據中心啓動併爲玩家提供服務，這個過程將變得很困難，前後不一致，並且根本無法接受。這鼓勵我們構建一些東西，然後再也不要碰它。我們絕對發現了重要問題，並避免了此過程的中斷，但是還需要認真改進。
首先，我們在過渡環境中構建了按比例縮小版本的數據中心。它足夠完整，可以準確無誤。例如，在過渡環境中，我們有兩個機架，每個機架有五臺服務器。而生產系統在兩個維度上都大得多，不過我們的問題可以通過更小、更便宜的設置來解決。
在這種過渡環境中，我們將測試所有更改，然後再將其交付生產。我們的自動化部署將在這裏變更，對於每一個變更，我們都會對其執行快速的基本測試，以防止我們做完全愚蠢的事情。這消除了我們對於自動化系統變得有知覺，進行了上千次失控改變並最終融化了整個星球的一份擔憂（編者按：本句的原文特別文藝——This removes the fear of our automated systems becoming sentient, making a thousand runaway changes, and eventually melting the whole planet，實際上就是想表達，我們不會過度的依賴自動化系統，因爲擔心自動化系統會放大細微的錯誤而將業務毀於一旦）。相對於生產環境，我們更喜歡在過渡環境中捕獲這些類型的錯誤。
除了基本檢查之外，我們還進行了更爲複雜和破壞性的測試，這些測試破壞了重要組件並迫使系統在降級狀態下運行。儘管四個子系統中只有三個子系統可以運行，但我們知道可以忍受這種損失，並且我們有時間在不影響玩家的情況下修復系統。
全套測試更加耗時，更具破壞性（我們寧願中斷系統並立即開始學習，而不是在生產中學習），並且比基本測試還要複雜，因此我們運行全套故障轉移測試的頻率並不高。
我們讓每個鏈接都失效，重新啓動內核，重新啓動TOR交換機，禁用SDN控制器，以及我們能想到的其他任何方法。然後，我們測量系統進行故障轉移所需的時間，並確保一切仍在平穩運行。
如果事情發生了變化，我們可以查看自上次運行代碼以來對代碼所做的更改，並在將更改交付生產之前，弄清楚我們可能已更改的內容。如果我們在生產中遇到無法預見的問題，而故障切換測試中沒有發現該問題，我們會將該測試快速添加到套件中，以確保不再發生類似情況。我們的目標始終是儘早發現問題，越早發現問題，就可以越快地解決它。當我們以這種方式工作時，不僅可以快速前進，而且更加自信。
結論
在上一篇文章中，介紹了數據中心網絡的核心概念和實現，這次我們介紹瞭如何實現基礎架構即代碼，以及安全策略、負載均衡和故障轉移測試。“變化是唯一不變的東西”，可能是將這些問題結合在一起的最好主題。基礎設施是活着的、有呼吸的，並且在不斷進化的“動物”。我們需要在它生長的時候提供資源，需要在它生病時做出反應，需要在全球範圍內儘快完成所有工作。擁抱這一現實，意味着確保我們的工具、流程和範例能夠對動態環境做出反應。所有這些使我們相信，現在是開發生產基礎架構的絕佳時機。
和往常一樣，非常歡迎與我們取得聯繫，說出你的問題和評論。
更多“揭祕LOL”系列文章
揭祕LOL背後的IT基礎架構丨踏上部署多樣性的征程
揭祕LOL背後的IT基礎設施丨關鍵角色“調度”
揭祕LOL背後的IT基礎架構丨SDN解鎖新基礎架構
關注微信：TF中文社區
