英文原文：A Few Good Rules

　　什么是明智的標(biāo)準(zhǔn)化？

　　想象一下第一次和特別的人約會(huì)。當(dāng)你到達(dá)最喜歡的餐館時(shí)，所有的燈都熄滅了，你身處黑暗之中。奇怪的是，從廚房傳來(lái)的聲音又表明這里像往常一樣正在營(yíng)業(yè)中。你聽(tīng)到一位女服務(wù)員走來(lái)，等待著引導(dǎo)你到?jīng)]有燈光照射到的座位上。你的同伴不知所措，并且有一點(diǎn)害怕。你是打算留下，還是找個(gè)正常點(diǎn)的地方吃飯？

　　Web應(yīng)用就像餐館一樣，人們通過(guò)其所提供的體驗(yàn)對(duì)其進(jìn)行評(píng)價(jià)。即使是短暫的中斷也會(huì)影響服務(wù)提供商的口碑或服務(wù)水平。政策和指導(dǎo)方針在防止代價(jià)高昂的服務(wù)中斷中扮演著重要的角色。不幸的是，它們也能導(dǎo)致不理智決策的產(chǎn)生，從而造成更大的損害。比如公司內(nèi)“DevOps團(tuán)隊(duì)”的建立。這將導(dǎo)致所有的運(yùn)維知識(shí)都被隔離在一個(gè)單獨(dú)的團(tuán)隊(duì)中。盡管這樣一個(gè)管理層指令可能預(yù)示著DevOps的到來(lái)，但它什么都不是。

　　工程師鄙視無(wú)邏輯的、官僚主義的規(guī)則。這些規(guī)則是前進(jìn)的障礙物。然而，每家公司至少都會(huì)有一些這樣的規(guī)則。在過(guò)去，可能有好的理由在一些問(wèn)題上制定這樣的規(guī)則。漸漸地，這些規(guī)則過(guò)時(shí)了。但是，規(guī)則制定者不能（或不敢）取消它們。當(dāng)使用C++代碼庫(kù)時(shí)，由于歷史原因，被告知不能使用STL；參與的Java項(xiàng)目被堅(jiān)定地拒絕從1.4遷移到新版本。任何有過(guò)這樣經(jīng)歷的人都明白有些措施可能會(huì)對(duì)生產(chǎn)力產(chǎn)生消極的影響。

　　我們應(yīng)該忘記這些規(guī)則嗎？

　　面對(duì)這些像障礙物一樣的規(guī)則，我們都很想將它們廢除。不幸的是，“無(wú)為”的公司通常都沒(méi)有成功地廢除它們。好的規(guī)則是一種重要的交流形式。這種形式關(guān)乎到長(zhǎng)期策略、從過(guò)去吸取到慘痛教訓(xùn)、以及來(lái)自用戶需求中的發(fā)現(xiàn)。理想情況下，一個(gè)組織制定的與時(shí)俱進(jìn)的規(guī)則，可以幫助個(gè)人增強(qiáng)做出正確決定的信心。在實(shí)踐中， 這樣的情況真的發(fā)生過(guò)嗎？

　　一家公司是否擁有真正有效的指導(dǎo)方針，NETflix就是一個(gè)很好的例子。至少通過(guò)閱讀他們的博客和開(kāi)源的代碼會(huì)給人留下這樣的印象。比如，即使沒(méi)有和NETflix的任何員工聊過(guò)，我也能確定，“構(gòu)建它，運(yùn)行它”是一個(gè)他們?nèi)绾伟验_(kāi)發(fā)和運(yùn)維結(jié)合起來(lái)的不錯(cuò)的想法。另一個(gè)明確的原則是：寫(xiě)代碼是為了構(gòu)建一個(gè)可靠的、可擴(kuò)展的服務(wù)，而不是為了其他目的。他們開(kāi)源了所寫(xiě)的大部分后臺(tái)軟件。這個(gè)事實(shí)比任何事都更具有說(shuō)服力。

　　NETflix已經(jīng)構(gòu)建了NETflix內(nèi)部Web服務(wù)框架（NIWS）。這是一個(gè)自定義的軟件棧，用于創(chuàng)建可靠地運(yùn)行在云上的內(nèi)部Web服務(wù)。NIWS采用了一些不太流行的技術(shù)和不太常用的方法。使用這種與最佳實(shí)踐背道而馳的方法需要有相當(dāng)強(qiáng)的自信。毫無(wú)疑問(wèn)，部分可以歸因于落實(shí)的政策。這些政策讓工程師可以不受限制地考慮問(wèn)題。

　　NETflix的負(fù)載均衡

　　在NETflix如何挑戰(zhàn)常規(guī)的例子中，我最喜歡的是他們是如何在NIWS中實(shí)現(xiàn)負(fù)載均衡的。面向客戶的流量仍使用傳統(tǒng)的負(fù)載均衡處理器（一個(gè)標(biāo)準(zhǔn)的Amazon EC2 ELB），但對(duì)于NETflix服務(wù)器之間的流量，他們選擇了一個(gè)完全不同的方案，稱作客戶端負(fù)載均衡（client-side loadbalancing）。基本思想很簡(jiǎn)單：取消專門(mén)用于負(fù)載均衡的節(jié)點(diǎn)。這些節(jié)點(diǎn)用于在NETflix服務(wù)器間轉(zhuǎn)發(fā)流量。客戶端本身維持著一張列表，記錄了可用的后臺(tái)節(jié)點(diǎn)。當(dāng)客戶端發(fā)送請(qǐng)求時(shí)，直接與所選的后臺(tái)實(shí)例交互。而這樣就沒(méi)有必要使用專門(mén)的負(fù)載均衡器。

　　客戶端負(fù)載均衡并不是NETflix發(fā)明的。但是， 它是有名的公司里第一個(gè)在基礎(chǔ)架構(gòu)中完全使用這種技術(shù)的（公平地說(shuō)，同一時(shí)期內(nèi)，Twitter和Yahoo也在做基于相同概念的實(shí)驗(yàn)）。在多個(gè)后臺(tái)服務(wù)器上做均衡的標(biāo)準(zhǔn)方法是：通過(guò)一個(gè)負(fù)載均衡器，如Amazon EC2 ELB，或者在服務(wù)器上運(yùn)行類似HAProxy的軟件。對(duì)于這么關(guān)鍵的組件，使用保守的方法和一種大多數(shù)工程師都熟悉的技術(shù)是很有意義的。但是，幾乎沒(méi)有公司在NETflix之前試驗(yàn)客戶端負(fù)載均衡的方法。其真正原因是，他們甚至都沒(méi)有考慮到這種方法。

　　對(duì)于從事大規(guī)模應(yīng)用程序開(kāi)發(fā)的軟件工程師，每天都要和各種庫(kù)和組件打交道。這有點(diǎn)像魚(yú)和水的關(guān)系。在能使用一種特定方法成功地構(gòu)建系統(tǒng)這么多年后（也許幾十年） ，對(duì)已經(jīng)經(jīng)過(guò)考驗(yàn)的方法或者系統(tǒng)的構(gòu)建模塊提出疑問(wèn)，這看起來(lái)是在浪費(fèi)時(shí)間。在許多公司里，這些決定已經(jīng)被寫(xiě)進(jìn)政策中。這些政策基本上是不可變的。但是，NETflix采用了客戶端負(fù)載均衡的方法，并因此取得了顯著的成功。首先，他們從系統(tǒng)中移除了一個(gè)單點(diǎn)故障點(diǎn)（對(duì)于頻繁地在沒(méi)有警告下就停止服務(wù)的EC2實(shí)例，這是一個(gè)重大的勝利）。其次，通過(guò)將負(fù)載均衡的邏輯集成進(jìn)客戶端，負(fù)載均衡的策略可以參考客戶端提供的信息。比如，考慮以下的負(fù)載均衡規(guī)則：

向客戶端的EC2可訪問(wèn)區(qū)域（EC2 Availability Zone）中的可用節(jié)點(diǎn)發(fā)送請(qǐng)求。如果這樣的實(shí)例不存在，則在當(dāng)前區(qū)域中找一個(gè)運(yùn)行已超過(guò)一天的實(shí)例替代。

　　傳統(tǒng)的負(fù)載均衡器并沒(méi)有被設(shè)計(jì)成用來(lái)執(zhí)行這種自定義邏輯。它們也無(wú)法獲取太多關(guān)于客戶端的信息（比如一個(gè)客戶端所屬的EC2可訪問(wèn)區(qū)域）。自定義負(fù)載均衡邏輯變成了應(yīng)用的一部分，使用相同的語(yǔ)言編寫(xiě)。這意味著編寫(xiě)代碼的單元測(cè)試用例變得容易。而在傳統(tǒng)上，這被認(rèn)為是“基礎(chǔ)設(shè)施的東西”。因此，這不僅讓制定更復(fù)雜、更智能的決策成為可能；也使得人們對(duì)工作能如期完成更有信心。從某方面看，NIWS將DevOps帶入了下一個(gè)層次：開(kāi)發(fā)人員和運(yùn)維工程師不僅坐在一起，在同一個(gè)團(tuán)隊(duì)中工作；而且他們使用相同的開(kāi)發(fā)語(yǔ)言，向相同的代碼庫(kù)提交更新。

　　Prezi加入客戶端負(fù)載均衡俱樂(lè)部

　　用一個(gè)內(nèi)部的客戶端負(fù)載均衡實(shí)現(xiàn)替代標(biāo)準(zhǔn)的負(fù)載均衡器，這種讓NETflix受益的技術(shù)只適用于NETflix嗎？不一定。在prezi.com，我們對(duì)內(nèi)部流量也采用了這種技術(shù)。我們的一些應(yīng)用服務(wù)器運(yùn)行著若干個(gè)服務(wù)。當(dāng)這些服務(wù)通信時(shí)，我們希望它們優(yōu)先選擇本地的服務(wù)實(shí)例，而不是向網(wǎng)絡(luò)中發(fā)送請(qǐng)求。然而，如果需要訪問(wèn)的服務(wù)沒(méi)有運(yùn)行在同一臺(tái)服務(wù)器上，那么就可以訪問(wèn)任何一個(gè)該服務(wù)的實(shí)例。對(duì)于Prezi，獲得的好處是，盡可能地避免了網(wǎng)絡(luò)流量、減少了在AWS上的支出和響應(yīng)時(shí)間。目前運(yùn)行于prezi.com產(chǎn)品上的負(fù)載均衡邏輯由以下的這段Scala代碼實(shí)現(xiàn)：

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)} 

it知識(shí)庫(kù)：一些好的規(guī)則，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。