|
|
英文原文：A Few Good Rules
什么是明智的標準化？
想象一下第一次和特別的人約會。當你到達最喜歡的餐館時，所有的燈都熄滅了，你身處黑暗之中。奇怪的是，從廚房傳來的聲音又表明這里像往常一樣正在營業中。你聽到一位女服務員走來，等待著引導你到沒有燈光照射到的座位上。你的同伴不知所措，并且有一點害怕。你是打算留下，還是找個正常點的地方吃飯？
Web應用就像餐館一樣，人們通過其所提供的體驗對其進行評價。即使是短暫的中斷也會影響服務提供商的口碑或服務水平。政策和指導方針在防止代價高昂的服務中斷中扮演著重要的角色。不幸的是，它們也能導致不理智決策的產生，從而造成更大的損害。比如公司內“DevOps團隊”的建立。這將導致所有的運維知識都被隔離在一個單獨的團隊中。盡管這樣一個管理層指令可能預示著DevOps的到來，但它什么都不是。
工程師鄙視無邏輯的、官僚主義的規則。這些規則是前進的障礙物。然而，每家公司至少都會有一些這樣的規則。在過去，可能有好的理由在一些問題上制定這樣的規則。漸漸地，這些規則過時了。但是，規則制定者不能（或不敢）取消它們。當使用C++代碼庫時，由于歷史原因，被告知不能使用STL；參與的Java項目被堅定地拒絕從1.4遷移到新版本。任何有過這樣經歷的人都明白有些措施可能會對生產力產生消極的影響。
我們應該忘記這些規則嗎？
面對這些像障礙物一樣的規則，我們都很想將它們廢除。不幸的是，“無為”的公司通常都沒有成功地廢除它們。好的規則是一種重要的交流形式。這種形式關乎到長期策略、從過去吸取到慘痛教訓、以及來自用戶需求中的發現。理想情況下，一個組織制定的與時俱進的規則，可以幫助個人增強做出正確決定的信心。在實踐中， 這樣的情況真的發生過嗎？
一家公司是否擁有真正有效的指導方針，NETflix就是一個很好的例子。至少通過閱讀他們的博客和開源的代碼會給人留下這樣的印象。比如，即使沒有和NETflix的任何員工聊過，我也能確定，“構建它，運行它”是一個他們如何把開發和運維結合起來的不錯的想法。另一個明確的原則是：寫代碼是為了構建一個可靠的、可擴展的服務，而不是為了其他目的。他們開源了所寫的大部分后臺軟件。這個事實比任何事都更具有說服力。
NETflix已經構建了NETflix內部Web服務框架（NIWS）。這是一個自定義的軟件棧，用于創建可靠地運行在云上的內部Web服務。NIWS采用了一些不太流行的技術和不太常用的方法。使用這種與最佳實踐背道而馳的方法需要有相當強的自信。毫無疑問，部分可以歸因于落實的政策。這些政策讓工程師可以不受限制地考慮問題。
NETflix的負載均衡
在NETflix如何挑戰常規的例子中，我最喜歡的是他們是如何在NIWS中實現負載均衡的。面向客戶的流量仍使用傳統的負載均衡處理器（一個標準的Amazon EC2 ELB），但對于NETflix服務器之間的流量，他們選擇了一個完全不同的方案，稱作客戶端負載均衡（client-side loadbalancing）。基本思想很簡單：取消專門用于負載均衡的節點。這些節點用于在NETflix服務器間轉發流量。客戶端本身維持著一張列表，記錄了可用的后臺節點。當客戶端發送請求時，直接與所選的后臺實例交互。而這樣就沒有必要使用專門的負載均衡器。
客戶端負載均衡并不是NETflix發明的。但是， 它是有名的公司里第一個在基礎架構中完全使用這種技術的（公平地說，同一時期內，Twitter和Yahoo也在做基于相同概念的實驗）。在多個后臺服務器上做均衡的標準方法是：通過一個負載均衡器，如Amazon EC2 ELB，或者在服務器上運行類似HAProxy的軟件。對于這么關鍵的組件，使用保守的方法和一種大多數工程師都熟悉的技術是很有意義的。但是，幾乎沒有公司在NETflix之前試驗客戶端負載均衡的方法。其真正原因是，他們甚至都沒有考慮到這種方法。
對于從事大規模應用程序開發的軟件工程師，每天都要和各種庫和組件打交道。這有點像魚和水的關系。在能使用一種特定方法成功地構建系統這么多年后（也許幾十年） ，對已經經過考驗的方法或者系統的構建模塊提出疑問，這看起來是在浪費時間。在許多公司里，這些決定已經被寫進政策中。這些政策基本上是不可變的。但是，NETflix采用了客戶端負載均衡的方法，并因此取得了顯著的成功。首先，他們從系統中移除了一個單點故障點（對于頻繁地在沒有警告下就停止服務的EC2實例，這是一個重大的勝利）。其次，通過將負載均衡的邏輯集成進客戶端，負載均衡的策略可以參考客戶端提供的信息。比如，考慮以下的負載均衡規則：
向客戶端的EC2可訪問區域（EC2 Availability Zone）中的可用節點發送請求。如果這樣的實例不存在，則在當前區域中找一個運行已超過一天的實例替代。
傳統的負載均衡器并沒有被設計成用來執行這種自定義邏輯。它們也無法獲取太多關于客戶端的信息（比如一個客戶端所屬的EC2可訪問區域）。自定義負載均衡邏輯變成了應用的一部分，使用相同的語言編寫。這意味著編寫代碼的單元測試用例變得容易。而在傳統上，這被認為是“基礎設施的東西”。因此，這不僅讓制定更復雜、更智能的決策成為可能；也使得人們對工作能如期完成更有信心。從某方面看，NIWS將DevOps帶入了下一個層次：開發人員和運維工程師不僅坐在一起，在同一個團隊中工作；而且他們使用相同的開發語言，向相同的代碼庫提交更新。
Prezi加入客戶端負載均衡俱樂部
用一個內部的客戶端負載均衡實現替代標準的負載均衡器，這種讓NETflix受益的技術只適用于NETflix嗎？不一定。在prezi.com，我們對內部流量也采用了這種技術。我們的一些應用服務器運行著若干個服務。當這些服務通信時，我們希望它們優先選擇本地的服務實例，而不是向網絡中發送請求。然而，如果需要訪問的服務沒有運行在同一臺服務器上，那么就可以訪問任何一個該服務的實例。對于Prezi，獲得的好處是，盡可能地避免了網絡流量、減少了在AWS上的支出和響應時間。目前運行于prezi.com產品上的負載均衡邏輯由以下的這段Scala代碼實現：
override def choose(key: Scala.Any): Server = Option(getLoadBalancer).map(lb => lb.getServerList(true).filter{server => server.getHost == config.getHostname && serverIsAvailable(lb, server) }).getOrElse(Seq()) match { case Seq() => super.choose(key) case matchedServers => matchedServers(0)}
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
