http://t.sina.com.cn/fangweng

優(yōu)化雜談

Author :放翁

Blog：http://blog.csdn.net/cenwenchu79/

         當(dāng)應(yīng)用遇到規(guī)模化問(wèn)題的時(shí)候，就是考慮性能優(yōu)化的時(shí)候了。今天同事和我聊起了NIO在客戶(hù)端的使用與BIO有什么優(yōu)勢(shì)，也勾起了我前一陣子和其他同學(xué)交流優(yōu)化的一些想法，純粹個(gè)人的一點(diǎn)想法。

CPU利用率和Load

         在過(guò)去做壓力測(cè)試的時(shí)候，我們經(jīng)常會(huì)關(guān)注兩個(gè)指標(biāo)，CPU和Load。有同學(xué)覺(jué)得CPU利用率上去了Load肯定也上去了，Load上去了CPU利用率同樣會(huì)上去。但是在一些需要優(yōu)化的場(chǎng)景下，常常會(huì)看到Load很高，CPU利用率卻可能比較低（多核更是可能出現(xiàn)分配不均的情況）。Load其實(shí)就是等待處理的任務(wù)隊(duì)列，當(dāng)你的應(yīng)用在等待同步消息返回處理的同時(shí)，CPU還是會(huì)將時(shí)間切片分配給這些線(xiàn)程，而真正需要CPU的線(xiàn)程，卻不得不在到了時(shí)間片以后暫時(shí)放棄工作被掛起。因此在程序設(shè)計(jì)的時(shí)候就要考慮如何利用好CPU的這個(gè)資源，如何均勻的將壓力分?jǐn)偟礁鱾€(gè)CPU上（有時(shí)候就一個(gè)線(xiàn)程在不斷循環(huán)，導(dǎo)致單個(gè)CPU負(fù)荷很高）。

NIO在客戶(hù)端的使用

         Http消息設(shè)置keepalive和采用NIO的方式復(fù)用信道、BIO結(jié)合連接池的方式，最基本的目的就是降低建立TCP產(chǎn)生握手的成本，最大限度的復(fù)用已有的資源，但是否NIO就只有復(fù)用信道這點(diǎn)呢？

         NIO和BIO在數(shù)據(jù)傳輸和處理的模式上有不同，NIO采用的是BufferPacket+Channel的模式，這其實(shí)和操作系統(tǒng)本身的傳輸模式很類(lèi)似，而BIO的Stream的模式是Java自己獨(dú)特的模式。在采用NIO的這種數(shù)據(jù)傳輸模式以后，可以充分利用操作系統(tǒng)本身對(duì)傳輸?shù)膬?yōu)化，因此這是一方面好處。另一方面異步和事件機(jī)制的使用，可以降低對(duì)于昂貴的資源申請(qǐng)，在高并發(fā)下提高處理能力。

NIO客戶(hù)端的編程模型最大特點(diǎn)：依賴(lài)反置，松耦合帶來(lái)性能提升。在請(qǐng)求流程協(xié)議中支持“票根”，也就是我們說(shuō)的回執(zhí)。例如，你今天面試完了，不需要你在阿里巴巴前臺(tái)等著結(jié)果，直接留個(gè)電話(huà)，有消息就會(huì)直接通知，電話(huà)就是通知結(jié)果和服務(wù)請(qǐng)求者的關(guān)聯(lián)手段。（此時(shí)阿里巴巴前臺(tái)和會(huì)議室就會(huì)有足夠的空間給其他人來(lái)面試，這就是資源）

         服務(wù)端使用NIO就不多說(shuō)了，這里主要說(shuō)一下在客戶(hù)端的使用場(chǎng)景。兩者是否真的有很大的差別，是否NIO有絕對(duì)的優(yōu)勢(shì)，其實(shí)還是和場(chǎng)景有關(guān)。簡(jiǎn)單說(shuō)來(lái)就一個(gè)判斷標(biāo)準(zhǔn)：應(yīng)用對(duì)于通道的利用率是否夠高。下面列了4種場(chǎng)景：

1． 一次請(qǐng)求數(shù)據(jù)量很少，服務(wù)處理速度很快。

2． 一次請(qǐng)求數(shù)據(jù)量很多，服務(wù)處理速度很快。

3． 一次請(qǐng)求數(shù)據(jù)量很少，服務(wù)處理速度很慢。

4． 一次請(qǐng)求數(shù)據(jù)量很多，服務(wù)處理速度很慢。

場(chǎng)景1，傳輸效率很高，服務(wù)處理速度很快，一次請(qǐng)求很快就被完成，采用NIO和BIO，在性能優(yōu)勢(shì)上除了操作系統(tǒng)對(duì)NIO的優(yōu)化以外，BIO連接池不輸于NIO。在易用性上，BIO更加容易處理。（NIO的異步機(jī)制，就要求消息傳輸協(xié)議需要有會(huì)話(huà)碼來(lái)提供異步處理入口選擇如何處理）

場(chǎng)景2，傳輸過(guò)程比較長(zhǎng)，消耗時(shí)間比較多，服務(wù)處理速度很快，因此交互的時(shí)間大部分都還是在數(shù)據(jù)通道傳輸上，由于NIO在傳輸過(guò)程中依然是串行化的，因此BIO的連接池優(yōu)于NIO，同時(shí)NIO一個(gè)客戶(hù)端只有一個(gè)通道，因此BIO開(kāi)的連接池越大，并行處理能力越強(qiáng)，因此BIO效率比較好一些。

場(chǎng)景3，傳輸量比較少，服務(wù)處理比較慢，很明顯這是通道利用率低的表現(xiàn)，NIO有絕對(duì)的優(yōu)勢(shì)，特別是在高并發(fā)下。信道和服務(wù)端客戶(hù)端資源被充分利用。

場(chǎng)景4，傳輸量比較多，服務(wù)處理也比較慢，這時(shí)候可以發(fā)現(xiàn)信道利用率取決于服務(wù)事件和傳輸消耗時(shí)間的比例，這類(lèi)場(chǎng)景某些情況下BIO也會(huì)優(yōu)于NIO。

單線(xiàn)程和多線(xiàn)程

         在使用多線(xiàn)程來(lái)優(yōu)化程序的時(shí)候，是否考慮過(guò)多線(xiàn)程的使用場(chǎng)景，多線(xiàn)程不是萬(wàn)能藥，在某些情況下還可能是毒藥。使用多線(xiàn)程的過(guò)程中，需要考慮這么幾個(gè)因素：

1． 資源競(jìng)爭(zhēng)，復(fù)雜度增加。

為什么前面提到的NIO客戶(hù)端在處理數(shù)據(jù)流發(fā)送和讀取的時(shí)候都是采用單線(xiàn)程，數(shù)據(jù)流的發(fā)送和讀取都是在一個(gè)數(shù)據(jù)通道上的，而讀取和發(fā)送本身時(shí)間消耗是固定的（不論是多線(xiàn)程還是單線(xiàn)程），同時(shí)增加了復(fù)雜度（需要處理數(shù)據(jù)包整合問(wèn)題）。這其實(shí)就是在資源上的串行化操作直接導(dǎo)致了任務(wù)的串行化，因此任務(wù)多線(xiàn)程反而起到了反作用。

2． 是否是關(guān)鍵路徑的工作，占關(guān)鍵路徑的比例。

首先，在優(yōu)化以前需要考慮優(yōu)化的內(nèi)容是否是關(guān)鍵路徑的工作，如果不是，那么增加復(fù)雜度實(shí)現(xiàn)的多線(xiàn)程模式，就沒(méi)有價(jià)值。其次就是看是否是在關(guān)鍵路徑中占有比較大的比例，同樣的，還是投入產(chǎn)出比例（多線(xiàn)程帶來(lái)的復(fù)雜度以及在高并發(fā)下的一些資源保護(hù)措施都需要很多的維護(hù)成本）。

3． 任務(wù)的合理切分。

在NIO的客戶(hù)端，接受數(shù)據(jù)的事件將會(huì)寫(xiě)得很輕量級(jí)，但是接受到數(shù)據(jù)然后分析數(shù)據(jù)還原成業(yè)務(wù)對(duì)象，則會(huì)通過(guò)線(xiàn)程池的方式來(lái)分別處理。就好比監(jiān)聽(tīng)連接到來(lái)，和實(shí)際的去建立連接分成了兩個(gè)階段的任務(wù)，讓事件型的任務(wù)單純，快速執(zhí)行，讓與業(yè)務(wù)相關(guān)的部分通過(guò)多線(xiàn)程并行的方式提高處理效率。總的來(lái)說(shuō)就是把任務(wù)劃分成為系統(tǒng)性的任務(wù)和業(yè)務(wù)性的任務(wù)，前者消耗時(shí)間少，設(shè)計(jì)盡量簡(jiǎn)單高效，采用單線(xiàn)程處理即可，后者通常情況下在處理流程和資源上不沖突的情況可以通過(guò)多線(xiàn)程并行提高效率。

         優(yōu)化應(yīng)用關(guān)注點(diǎn)：

A．關(guān)鍵路徑是否可以?xún)?yōu)化，關(guān)鍵路徑的任務(wù)拆分。

B．關(guān)鍵路徑上的單個(gè)任務(wù)是否可以拆分并行執(zhí)行。（是否有資源競(jìng)爭(zhēng)，是否會(huì)有流程上的前后依賴(lài)，是否增加復(fù)雜度引入新的不穩(wěn)定因素）

C．系統(tǒng)資源和依賴(lài)外部系統(tǒng)是否會(huì)成為瓶頸。（單機(jī)的CPU,IO都會(huì)在一定的壓力下成下降趨勢(shì)，并行執(zhí)行反而降低了處理能力）

因此，可以看到不論是MapReduce設(shè)計(jì)下的Hadoop，還是Erlang語(yǔ)言級(jí)別的特性，都盡量的希望任務(wù)之間可以并行執(zhí)行，相互之間低耦合，通過(guò)異步事件消息通知方式來(lái)交互，同時(shí)數(shù)據(jù)沒(méi)有共享，防止資源競(jìng)爭(zhēng)導(dǎo)致無(wú)法并行高效處理。系統(tǒng)設(shè)計(jì)還是要根據(jù)場(chǎng)景來(lái)判斷使用什么方式優(yōu)化，越簡(jiǎn)單越好。

    中午左右收到一個(gè)看我blog的朋友的郵件，最近他在研究mapreduce，然后想用hadoop來(lái)做一些工作，不過(guò)遇到了一些問(wèn)題，我這邊也貼一下他的幾個(gè)問(wèn)題，同時(shí)覺(jué)得自己把自己的一些看法分享一下，當(dāng)然只是自己的一些想法，也許對(duì)新學(xué)習(xí)的同學(xué)有幫助。

   問(wèn)題：

1. 從Map（K,V）的方式來(lái)看，難道m(xù)apreduce只能做統(tǒng)計(jì)？
2. 目前我想除了日志分析之類(lèi)的功能外，還想做一個(gè)全文檢索的功能，類(lèi)似windows查詢(xún)一下，通過(guò)關(guān)鍵字查詢(xún)文件的位置即可（可能還要根據(jù)匹配度做排序），這個(gè)我很迷茫不知道怎么下手，痛苦ing
3. 你的實(shí)踐是一個(gè)單機(jī)模式，如果用戶(hù)把一個(gè)1G的log已經(jīng)上傳到hdfs了，此時(shí)分割工作已經(jīng)完成，只需要從client那里得到文件基本信息和塊的location就可以了，那mapreduce怎么進(jìn)行下去呢？

   我給回復(fù)的郵件內(nèi)容：

   首先，MapReduce的思想和Hadoop的MapReduce的架構(gòu)不是一個(gè)概念，說(shuō)的具體一點(diǎn)也就是Hadoop的架構(gòu)設(shè)計(jì)只是MapReduce的一個(gè)子集思想的實(shí)現(xiàn)。每個(gè)人都可以根據(jù)自己對(duì)MapReduce的理解去實(shí)現(xiàn)業(yè)務(wù)處理，簡(jiǎn)單來(lái)說(shuō)多線(xiàn)程處理就是MapReduce的一種最簡(jiǎn)單的實(shí)現(xiàn)，復(fù)雜來(lái)說(shuō)多機(jī)協(xié)調(diào)工作就是一種復(fù)雜的實(shí)現(xiàn)。

   MapReduce的思想里面最值得借鑒的：

   a.問(wèn)題分而治之。（找到流程的關(guān)鍵路徑，優(yōu)化可以并行處理的工作）

   b.計(jì)算靠近數(shù)據(jù)。（這也是hdfs存在的最重要的特點(diǎn)，計(jì)算的轉(zhuǎn)移往往要比數(shù)據(jù)轉(zhuǎn)移廉價(jià)，特別是對(duì)海量數(shù)據(jù)的處理）

   c.數(shù)據(jù)規(guī)模化隨著并行處理成數(shù)量級(jí)遞減。

   剩下的內(nèi)容就是各個(gè)框架對(duì)于非業(yè)務(wù)性需求的處理，例如容災(zāi)，如何盡量少穿數(shù)據(jù)協(xié)調(diào)處理等等。

   針對(duì)他提出的三個(gè)問(wèn)題：

    1. Hadoop的mapreduce從架構(gòu)上來(lái)說(shuō)最適合的就是統(tǒng)計(jì)分析計(jì)算。做其他方面的工作需要考慮是否適合，而不是為了技術(shù)而技術(shù)，先有需求再有技術(shù)選型。
    2.  對(duì)于你這個(gè)需求直接用搜索技術(shù)實(shí)現(xiàn)就可以了，不一定要硬套在mapreduce上。
    3. 對(duì)于海量數(shù)據(jù)是否一定要到hdsf上，或者就簡(jiǎn)單得數(shù)據(jù)物理或者邏輯切割來(lái)直接處理，根據(jù)自己業(yè)務(wù)場(chǎng)景選擇。hdfs的特點(diǎn)就是對(duì)文件切割，容災(zāi)，數(shù)據(jù)邏輯存儲(chǔ)和物理存儲(chǔ)無(wú)關(guān)性（便于擴(kuò)容管理，同時(shí)也是計(jì)算靠近數(shù)據(jù)的技術(shù)保證）。

    是否使用MapReduce框架，HDFS存儲(chǔ)關(guān)鍵還是看你是否真的需要，當(dāng)現(xiàn)有框架對(duì)自己來(lái)說(shuō)并不合適的時(shí)候可以對(duì)小規(guī)模問(wèn)題定制MapReduce的處理，最簡(jiǎn)化就是你去多線(xiàn)程或者多進(jìn)程處理問(wèn)題，需求決定技術(shù)選型。

當(dāng)前問(wèn)題:

1.       不小比重的Rest請(qǐng)求都是無(wú)效請(qǐng)求，全部接納數(shù)據(jù)消耗比較多的時(shí)間。

2.       Multipart類(lèi)型的大文件流請(qǐng)求無(wú)法做到合理快速過(guò)濾。（參數(shù)錯(cuò)誤請(qǐng)求，數(shù)據(jù)文件過(guò)多請(qǐng)求，文件大小過(guò)大請(qǐng)求）

歸結(jié)來(lái)說(shuō)，TOP平臺(tái)處理的服務(wù)在解析參數(shù)時(shí)比較消耗時(shí)間和帶寬(客戶(hù)端網(wǎng)絡(luò)速度慢導(dǎo)致傳輸字節(jié)流比較慢，文件比較大導(dǎo)致帶寬占用嚴(yán)重)

處理方式：

通過(guò)自行解析字節(jié)流方式來(lái)lazy化處理請(qǐng)求，減少無(wú)效請(qǐng)求對(duì)于解析參數(shù)時(shí)間消耗（導(dǎo)致web容器連接消耗）及帶寬消耗。

優(yōu)化目標(biāo)：

         Get由于內(nèi)容長(zhǎng)度有限不列入在優(yōu)化范圍。

         優(yōu)化Post方式的請(qǐng)求（普通的和Multipart），要求優(yōu)化后：在正常請(qǐng)求處理上兩者處理速度不低于傳統(tǒng)方式，非正常請(qǐng)求在策略命中情況下（后面會(huì)談到什么情況下優(yōu)化失效），性能有明顯提高。

具體實(shí)現(xiàn)：

        由于現(xiàn)在用的是傳統(tǒng)IO模式，因此可以用流的方式來(lái)lazy解析和處理請(qǐng)求（NIO用channel + buffer package就無(wú)法lazy了）。

         一共有三個(gè)組件角色：

1． 請(qǐng)求處理配置策略：配置在解析參數(shù)時(shí)，優(yōu)先的規(guī)則（參數(shù)可以從header,uri,post body中獲取，相互之間的優(yōu)先性），異常拋出規(guī)則（字節(jié)流長(zhǎng)度，文件大小，文件個(gè)數(shù)限制等），字節(jié)流解析模塊的參數(shù)配置（字節(jié)流解析的窗口大小，超時(shí)時(shí)間等）。

2． 線(xiàn)程上下文：用來(lái)保存處理過(guò)的請(qǐng)求參數(shù)。一來(lái)復(fù)用，二來(lái)也是由于請(qǐng)求字節(jié)流處理不可逆（不保存字節(jié)流副本），必須保留。

3． Http請(qǐng)求字節(jié)流解析模塊。根據(jù)具體的配置以及解析策略來(lái)解析字節(jié)流，同時(shí)將解析結(jié)果保存在線(xiàn)程上下文中。主要的實(shí)現(xiàn)代碼在于對(duì)Post消息體逐步解析部分（普通的Post和multipart）

壓力測(cè)試結(jié)果：

•    正常請(qǐng)求場(chǎng)景（ 100并發(fā)用戶(hù)，multipart 文件大小300k，當(dāng)前業(yè)務(wù)場(chǎng)景這個(gè)值已經(jīng)滿(mǎn)足了）：

普通post的處理能力1000TPS。（servlet方式處理差不多，不過(guò)有波動(dòng)）  

  multipart處理能力610TPS。（apache開(kāi)源項(xiàng)目fileupload，處理能力400TPS左右）

錯(cuò)誤請(qǐng)求場(chǎng)景

         異常情況的處理有了很大提高，對(duì)于遠(yuǎn)程客戶(hù)端傳輸較慢或者是大流量圖片的錯(cuò)誤請(qǐng)求都有很大的優(yōu)化。

優(yōu)化存在問(wèn)題：

1． 參數(shù)缺失導(dǎo)致優(yōu)化失效。

2． sign類(lèi)似的交驗(yàn)，導(dǎo)致獲取所有的參數(shù)。

3． 當(dāng)前圖片限制在300k，由于考慮處理速度快，就都沒(méi)有設(shè)置超過(guò)閥值存儲(chǔ)到本地，因此在高并發(fā)大流量的情況下也會(huì)有內(nèi)存問(wèn)題，當(dāng)然已經(jīng)做了部分保護(hù)。

針對(duì)上面的兩個(gè)問(wèn)題，作了部分的協(xié)議限制，對(duì)于API2.0希望將所有的系統(tǒng)參數(shù)和業(yè)務(wù)參數(shù)區(qū)分開(kāi)，放入到Http header中或者url中，這樣可以避免系統(tǒng)參數(shù)缺失導(dǎo)致優(yōu)化失敗，同時(shí)大量過(guò)濾系統(tǒng)參數(shù)出現(xiàn)問(wèn)題的無(wú)效請(qǐng)求。

Sign類(lèi)似的交驗(yàn)放在流程最后，避免過(guò)早獲取所有參數(shù)。

作安全保護(hù)，設(shè)定簡(jiǎn)單丟棄或者io交互來(lái)緩解這個(gè)問(wèn)題。

         這部分內(nèi)容還有很多可以做得工作，其實(shí)最初的目的就是為了防止系統(tǒng)對(duì)于無(wú)效請(qǐng)求的處理消耗，我想在很多系統(tǒng)都會(huì)有這樣的問(wèn)題，利用緩存設(shè)置黑名單防止攻擊也是這樣的初衷。因此這點(diǎn)可以考慮在很多系統(tǒng)設(shè)計(jì)的時(shí)候都作一樣的優(yōu)化，對(duì)正常的不能優(yōu)化，起碼對(duì)錯(cuò)誤的可以做一些優(yōu)化，防止在異常請(qǐng)求高漲的時(shí)候，系統(tǒng)被擊垮.

其實(shí)想說(shuō)這句話(huà)很久了,和很多同事接觸,有時(shí)候或多或少的都會(huì)發(fā)現(xiàn)大家會(huì)陷入在自己的一畝三分地里面.

         主要表現(xiàn)得癥狀

1.       PD的需求就是目標(biāo)，踏實(shí)的實(shí)現(xiàn)，不懂的就猜。

2.       經(jīng)驗(yàn)蓋過(guò)一切，設(shè)計(jì)系統(tǒng)就是要夠完備夠復(fù)雜。

從開(kāi)發(fā)人員角度來(lái)看，第一種人多半比較有自己的想法，同時(shí)也有不少的工作經(jīng)驗(yàn)，同時(shí)可能對(duì)技術(shù)比較著迷。另一種人多半是剛剛工作或者經(jīng)驗(yàn)不足，要么就是習(xí)慣性把工作當(dāng)任務(wù)，而不是愛(ài)好，寫(xiě)程序也就是一份賺錢(qián)的活。但看起來(lái)其實(shí)各自都在自己的一畝三分地上搗鼓，忘記了作為一個(gè)開(kāi)發(fā)人員最基本的原則：“滿(mǎn)足客戶(hù)需求”。

先說(shuō)1類(lèi)型吧，在我們的Team有一個(gè)剛畢業(yè)一年多的同學(xué)，很勤奮，不論從學(xué)習(xí)以及工作，實(shí)實(shí)在在，踏踏實(shí)實(shí)。我們這邊來(lái)需求，通常大需求我們都會(huì)全體過(guò)一下，一些小點(diǎn)的需求他就自己考慮一下就作了。那天正要上線(xiàn)，突然說(shuō)了一下設(shè)計(jì)修改的內(nèi)容，發(fā)現(xiàn)不僅滿(mǎn)足不了PD原有的需求，而且給系統(tǒng)帶來(lái)了緩存暴增的隱患。然后找來(lái)PD一談，其實(shí)他要的功能已經(jīng)在現(xiàn)有系統(tǒng)中已經(jīng)實(shí)現(xiàn)，只是需要做部分的修改，而不需要新的去建立一套機(jī)制。這樣的情況其實(shí)在前前后后出現(xiàn)了不少次數(shù)了，但其實(shí)一直沒(méi)有和他細(xì)談。后來(lái)我下班時(shí)候和他一起回家的時(shí)候說(shuō)：“很多時(shí)候， PD為了讓你理解，從開(kāi)發(fā)的角度想要去描述一個(gè)需求，但其實(shí)最終失去了他自己想要的東西。因此對(duì)你來(lái)說(shuō)第一步不是急忙的去考慮如何實(shí)現(xiàn)PD的想法或者和他爭(zhēng)論他的設(shè)計(jì)是否合理，而是需要先問(wèn)他：你想要什么，想要實(shí)現(xiàn)的東西最終目的是什么，能滿(mǎn)足客戶(hù)的什么需求？當(dāng)他能夠說(shuō)清楚他想要什么，也知道要的東西能給客戶(hù)帶來(lái)什么價(jià)值的時(shí)候，我們?cè)倩剡^(guò)頭來(lái)看，究竟應(yīng)該怎么做？”這其實(shí)和我每次和同學(xué)分享一些設(shè)計(jì)的時(shí)候步驟是一樣的，首先為什么要這么做，然后才是考慮如何從我的目標(biāo)去尋找行動(dòng)的方法方式，不然你會(huì)發(fā)現(xiàn)你和別人討論了許久的東西，實(shí)現(xiàn)出來(lái)的時(shí)候已經(jīng)背離了你的目標(biāo)很遠(yuǎn)。因此在做任何需求或者設(shè)計(jì)的時(shí)候第一個(gè)問(wèn)題就要問(wèn)自己為什么要做，作的過(guò)程中時(shí)刻要記得我的目標(biāo)是什么。這讓我想起了我在離開(kāi)阿軟的那些日子和王堅(jiān)博士談話(huà)以及聽(tīng)他的一些對(duì)于設(shè)計(jì)的理念，很多時(shí)候還沒(méi)有到規(guī)模化的情況下，先解決客戶(hù)的需求，在解決客戶(hù)需求以后，逐步的去考慮規(guī)模化問(wèn)題的設(shè)計(jì)。（當(dāng)然不是說(shuō)第一版設(shè)計(jì)就可以隨便作，良好的基礎(chǔ)能夠提升后續(xù)改進(jìn)的速度）。

二類(lèi)型的就比較多了，其實(shí)是很多開(kāi)發(fā)人員的通病，包括有時(shí)候我自己也會(huì)陷入這樣的誤區(qū)。通常情況下有兩種場(chǎng)景會(huì)陷入這樣的誤區(qū)，同時(shí)當(dāng)事人卻又不愿意改變。第一種情況就是覺(jué)得自己有不少的經(jīng)驗(yàn)，同時(shí)對(duì)技術(shù)很執(zhí)著，希望設(shè)計(jì)出來(lái)的都是很完美的，一次發(fā)布就可以滿(mǎn)足個(gè)1，2年，但其實(shí)從這些年的設(shè)計(jì)角度來(lái)看，首先系統(tǒng)都是不斷迭代進(jìn)化的，因此一步到位的說(shuō)法基本上不靠譜（除非就是一模一樣的場(chǎng)景代碼重復(fù)使用），其次系統(tǒng)的架構(gòu)要做的足夠靈活，通常情況就需要先做核心功能，預(yù)留出足夠的空間和切入點(diǎn)，這樣對(duì)未來(lái)擴(kuò)展和需求變化有足夠的適應(yīng)度。從這兩點(diǎn)來(lái)看，其實(shí)設(shè)計(jì)初期就是要求找到客戶(hù)最想要的，擴(kuò)展可以實(shí)現(xiàn)客戶(hù)可能要的，防范客戶(hù)沒(méi)有估量到的。但這其實(shí)就需要和我們的產(chǎn)品設(shè)計(jì)師有充分的交流，好的產(chǎn)品設(shè)計(jì)師不會(huì)告訴你你怎么去實(shí)現(xiàn)，但是他會(huì)告訴你我想要的是什么，這些能給客戶(hù)帶來(lái)什么，這時(shí)候你可以告訴他我能夠通過(guò)什么方式來(lái)滿(mǎn)足你的需求。這樣的開(kāi)發(fā)和產(chǎn)品設(shè)計(jì)交流的結(jié)果才是技術(shù)化的產(chǎn)品，大家各司其職，同時(shí)也通曉對(duì)方領(lǐng)域的一些情況，對(duì)對(duì)方領(lǐng)域的只能給出建議，不是指導(dǎo)，這點(diǎn)在TOP我很慶幸有很好的黑羽同學(xué)，我們的交流就是這樣產(chǎn)生良性互動(dòng)。這有點(diǎn)撤遠(yuǎn)了，剛才說(shuō)了第一種場(chǎng)景，然后說(shuō)說(shuō)第二種場(chǎng)景，就是初期其實(shí)大家都沒(méi)有明確細(xì)節(jié)，但是在實(shí)施過(guò)程中開(kāi)發(fā)人員會(huì)根據(jù)自己的接觸面來(lái)選擇一些技術(shù)和架構(gòu)設(shè)計(jì)，最后看起來(lái)很復(fù)雜，很完美，但其實(shí)越是復(fù)雜的設(shè)計(jì)背后有越多的隱患。但是此時(shí)因?yàn)橐呀?jīng)設(shè)計(jì)好了，就不愿意再去簡(jiǎn)化，也不愿意聽(tīng)任何人的意見(jiàn)，其實(shí)這是很危險(xiǎn)的。我過(guò)去也犯過(guò)類(lèi)似的錯(cuò)誤，但是其實(shí)當(dāng)你冷靜下來(lái)，想想那句話(huà)，我們的目標(biāo)是什么：“滿(mǎn)足客戶(hù)需求”，這時(shí)候你就會(huì)考慮，這么復(fù)雜的系統(tǒng)會(huì)不會(huì)給客戶(hù)帶來(lái)更多的不穩(wěn)定以及復(fù)雜度，其實(shí)客戶(hù)不關(guān)心你背后如何實(shí)現(xiàn)的，但是你需要滿(mǎn)足客戶(hù)的最基本的需求，用起來(lái)方便，高效，實(shí)實(shí)在在提供了解決問(wèn)題的手段。

今天下午面試了一個(gè)外部的同學(xué)，工作年限比我長(zhǎng)，看了簡(jiǎn)歷也經(jīng)歷了很多項(xiàng)目，同時(shí)在描述的時(shí)候?qū)懥藢?duì)高并發(fā)，分布式等等都很熟悉和熱衷，我開(kāi)始看了簡(jiǎn)歷就擔(dān)心，可能我這邊不一定要他，因?yàn)槲遗滤_(kāi)口就是說(shuō)一大堆如何做高并發(fā)和分布式的內(nèi)容。在我看來(lái)如果你沒(méi)有搞清楚你什么時(shí)候要用牛刀，什么時(shí)候要用剪刀的人，和你談?wù)撆５兜臉?gòu)造其實(shí)沒(méi)啥意思，因?yàn)樵谖铱磥?lái)，技術(shù)只要你肯花時(shí)間去學(xué)，沒(méi)什么學(xué)不到的，但是做事方式和項(xiàng)目設(shè)計(jì)經(jīng)驗(yàn)卻是長(zhǎng)時(shí)間積累的。幸好今天和他一談，他對(duì)于技術(shù)的態(tài)度以及架構(gòu)設(shè)計(jì)的思想都和我想的比較接近，不是為了技術(shù)而技術(shù)，不是為了過(guò)程而過(guò)程，了解如何從簡(jiǎn)如繁，再?gòu)姆比牒?jiǎn)，最終能夠找到自己的目標(biāo)。當(dāng)然后來(lái)還是談了很多技術(shù)細(xì)節(jié)的問(wèn)題，畢竟干活還是要一個(gè)好手，作了那么多年如果沒(méi)有經(jīng)驗(yàn)和技術(shù)積累也是很可怕的事情。最后我問(wèn)了他兩個(gè)問(wèn)題：1.你學(xué)習(xí)一個(gè)新技術(shù)的過(guò)程是怎么樣的？2.你和你同事如果在設(shè)計(jì)方案上有沖突你怎么解決？他告訴我他學(xué)習(xí)新技術(shù)首先會(huì)去考慮這個(gè)技術(shù)的特點(diǎn)是什么，和其他技術(shù)的差別，他的擅長(zhǎng)領(lǐng)域是什么，這樣才能夠用到實(shí)處。第二個(gè)問(wèn)題他和我說(shuō)就是開(kāi)會(huì)討論，最后大家群體決定。我對(duì)他第一個(gè)問(wèn)題感到很滿(mǎn)意，因?yàn)槲揖托枰@樣的同事，第二個(gè)問(wèn)題我給了他一個(gè)建議，其實(shí)在很多時(shí)候，將別人的架構(gòu)設(shè)計(jì)的優(yōu)點(diǎn)融入到自己的設(shè)計(jì)中，不再以方案作為邊界，那么大家最終就很容易達(dá)成一致，因?yàn)槟阍诮邮軇e人的思想時(shí)其實(shí)能夠看到自己的不足，同時(shí)對(duì)待別人不是用否定的態(tài)度，會(huì)讓你更容易得到認(rèn)可和接受。（這點(diǎn)作起來(lái)需要不斷的改變程序員自身的好勝個(gè)性，我起碼還是出于變化中…）

我記得我小時(shí)候上政治課的時(shí)候，老師給我們劃分了三種人：有能力但是沒(méi)有道德的人是危險(xiǎn)的人，沒(méi)有能力但是有道德的人是對(duì)社會(huì)無(wú)害的人（覺(jué)得像葛優(yōu)說(shuō)的那個(gè)對(duì)社會(huì)無(wú)害的海龜一個(gè)概念），有能力同時(shí)也有道德的人是對(duì)社會(huì)有益的人。我覺(jué)得其實(shí)程序員也就可以從兩個(gè)緯度看：

1.       有能力，有經(jīng)驗(yàn)，對(duì)技術(shù)有追求。

2.       對(duì)產(chǎn)品化和客戶(hù)沒(méi)有任何感覺(jué)。

擁有了素質(zhì)1但是沒(méi)有素質(zhì)2，那么最多也就只能說(shuō)是試驗(yàn)室的花朵，在大學(xué)搞搞研究還不錯(cuò)，實(shí)際要做出產(chǎn)品來(lái)可能就是紙上談兵，好鋼始終用不到刀刃上，有力沒(méi)地使。

素質(zhì)1有所欠缺，素質(zhì)2很明晰，對(duì)自己目標(biāo)不斷追求，其實(shí)這樣的人，有時(shí)候笨鳥(niǎo)也會(huì)飛的比聰明的鳥(niǎo)更高。

擁有1，2的人，當(dāng)然就是最好的人，只需要學(xué)會(huì)做人那么就可以發(fā)揮自己的能量。（程序員有時(shí)候就是很難改變自己的個(gè)性，去學(xué)會(huì)如何溝通和理解）
         最后一類(lèi)就是自以為有1和2的人，這類(lèi)人最怕就是面試的時(shí)候被考官通過(guò)，那么后續(xù)的問(wèn)題就大了。

說(shuō)了怎么多，其實(shí)也無(wú)非想說(shuō)出一個(gè)程序員這些年的經(jīng)歷，從做開(kāi)發(fā)到做基礎(chǔ)平臺(tái)，到做業(yè)務(wù)平臺(tái)，該怎么踏實(shí)做事，該在什么時(shí)候找到自己的瓶頸，該在什么時(shí)候改變自己的狀態(tài)，都需要自己好好的讓自己冷靜下來(lái)想想。做基礎(chǔ)平臺(tái)需要耐得住寂寞，同時(shí)也要知道自己是有客戶(hù)的，服務(wù)不好客戶(hù)，那么基礎(chǔ)組件平臺(tái)就是玩具。做業(yè)務(wù)平臺(tái)需要學(xué)會(huì)去分析和溝通，需要去了解每一個(gè)層次的設(shè)計(jì)如何協(xié)作，同時(shí)在兼顧業(yè)務(wù)需求的同時(shí)滿(mǎn)足隱性需求（穩(wěn)定性，可用性，響應(yīng)速度，規(guī)模化等等）。但歸根到底，能給開(kāi)發(fā)人員不斷能量的不是技術(shù)本身，而是你用技術(shù)給你的客戶(hù)帶來(lái)的價(jià)值，對(duì)你的認(rèn)可是長(zhǎng)期做事的一個(gè)最基本的動(dòng)力，因?yàn)楫?dāng)你現(xiàn)在覺(jué)得純做技術(shù)能夠支持你不斷向前走的時(shí)候，其實(shí)在不遠(yuǎn)的將來(lái)你會(huì)體會(huì)到原來(lái)過(guò)程和目標(biāo)是同樣重要的。走出自己的一畝三分地，給自己多一點(diǎn)的空間，會(huì)讓自己看得更遠(yuǎn)，走的更高。

   今年blog更新的速度比去年慢很多，當(dāng)然最大的原因就是工作的轉(zhuǎn)變。當(dāng)選擇留在云公司還是去淘寶，自己做了很快的抉擇，去淘寶。其實(shí)在阿軟的后面這一年，對(duì)自己來(lái)說(shuō)是一個(gè)技術(shù)提升的階段，工作任務(wù)不緊，技術(shù)預(yù)研范圍較大，但對(duì)于自己這么一個(gè)已經(jīng)到了30的人來(lái)說(shuō)，應(yīng)該是把技術(shù)轉(zhuǎn)變?yōu)楫a(chǎn)品的時(shí)候了，因此義無(wú)反顧地選擇了TOP作為我新的開(kāi)端。

    其實(shí)每個(gè)人都會(huì)有自己不同的階段，任何階段都有自己的目標(biāo)，同時(shí)當(dāng)你發(fā)現(xiàn)在一個(gè)階段停留很久，都沒(méi)有什么突破，或者漸漸失去目標(biāo)的時(shí)候，那么就需要考慮如何找到新的起點(diǎn)。對(duì)我來(lái)說(shuō)，技術(shù)追求和提升是沒(méi)有止盡的，但是需要真正的將所學(xué)的作出一點(diǎn)實(shí)在的產(chǎn)品，同時(shí)在參與產(chǎn)品團(tuán)隊(duì)的過(guò)程中，學(xué)會(huì)溝通，交流，分析問(wèn)題，全面地看問(wèn)題，這些也是不可缺少的成長(zhǎng)經(jīng)驗(yàn)，如果僅僅局限在狹隘的某一個(gè)技術(shù)立領(lǐng)域，那么就和普通的學(xué)生無(wú)異。

    到了TOP，自己的工作分成了三大塊：1.救火及防火。2.整體架構(gòu)支持。3.核心代碼的編寫(xiě)。前期花了不少時(shí)間在1上，同時(shí)和各個(gè)Team交流，參與各個(gè)團(tuán)隊(duì)的關(guān)鍵性設(shè)計(jì)評(píng)審，以及對(duì)平臺(tái)的統(tǒng)一規(guī)劃，讓我實(shí)實(shí)在在的作了一點(diǎn)2的事情。（說(shuō)道實(shí)實(shí)在在，記得在阿軟很多團(tuán)隊(duì)都抱怨我所在的架構(gòu)組整天派一個(gè)人掛個(gè)名字，然后就算是架構(gòu)支持了，當(dāng)然這有很多原因造成，并不一定是負(fù)責(zé)架構(gòu)的同學(xué)的問(wèn)題）。對(duì)于3這點(diǎn)當(dāng)然是自己最樂(lè)意做的，也是自己一直告誡自己要不斷提升的，不論自己有多少理由說(shuō)自己忙碌，寫(xiě)代碼是我們這種人的生命所在，不然就會(huì)漂浮在空中，漸漸的走向“另一個(gè)世界”。 但自己覺(jué)得其實(shí)還少了一塊，就是對(duì)業(yè)界的發(fā)展深入了解，這會(huì)讓我看的不夠遠(yuǎn)（幸好我們的產(chǎn)品經(jīng)理黑羽同學(xué)總還會(huì)給我一些新的思路），到了年底將會(huì)多花一點(diǎn)時(shí)間作這部分內(nèi)容。

    去年年底我寫(xiě)了關(guān)于對(duì)于Open API的思考和探索的一篇文章作為年底總結(jié)，今年一樣，對(duì)于當(dāng)前自己的工作將會(huì)有一份總結(jié)和規(guī)劃，即是對(duì)今年平臺(tái)發(fā)展的一個(gè)回顧，也是對(duì)平臺(tái)未來(lái)的一點(diǎn)思考，大致已經(jīng)列了一個(gè)綱要，對(duì)外可能部分內(nèi)容不能全寫(xiě)出來(lái)，不過(guò)就算不寫(xiě)細(xì)節(jié)也會(huì)將一些思路寫(xiě)一下，大家可以相互探討一下。這部分內(nèi)容也將會(huì)成為我12月份參加淘寶內(nèi)部淘寶大學(xué)講課的內(nèi)容，希望能夠?qū)⒔衲晷逻M(jìn)淘寶的同學(xué)吸引到TOP來(lái)，為T(mén)OP增加人氣。

   下面是一個(gè)mind 圖，大致描述了一些內(nèi)容：

   今天是轉(zhuǎn)崗到淘寶的第七天，也算是一周吧，期待來(lái)這個(gè)團(tuán)隊(duì)已經(jīng)有快大半年了，這次阿軟的重組給了一個(gè)機(jī)會(huì)，過(guò)去的就過(guò)去吧，不再回首有任何的抱怨和遺憾，需要面對(duì)的是新的將來(lái)。

    很奇怪，來(lái)到淘寶，都是熟人，Boss是早就相識(shí)的菲青，TOP團(tuán)隊(duì)的自雪，鳳先，秀芳及我不認(rèn)識(shí)但是認(rèn)識(shí)我的其他同學(xué)都很熱情，運(yùn)營(yíng)，PD,OST都是以前阿軟的老同學(xué)，還有其他幾個(gè)團(tuán)隊(duì)的朋友，感覺(jué)回到了家，而不是離開(kāi)了家。

    原先來(lái)淘寶是比較堅(jiān)決的，同時(shí)也得到王博士的支持，心里還是比較有底的，不過(guò)就是擔(dān)心過(guò)來(lái)以后和淘寶已有的團(tuán)隊(duì)合作可能會(huì)有磨合期，因?yàn)閾?dān)心有“小圈子”。結(jié)果卻是很出乎我的意料，TOP的人就和做的事情一樣，是一批開(kāi)放的人，自雪，鳳先，張三各個(gè)都很放的開(kāi)的和我聊，對(duì)于架構(gòu)，對(duì)于技術(shù)，對(duì)于未來(lái)的發(fā)展，這些人坐在一起什么都可以說(shuō)，自己覺(jué)得自己早先是用老思維來(lái)看待這個(gè)團(tuán)隊(duì)了。這個(gè)團(tuán)隊(duì)很年輕，很有活力和創(chuàng)造力，缺少的只是一些經(jīng)驗(yàn)，而我經(jīng)驗(yàn)是有一些，但是那些斗志已經(jīng)在去年一年被磨礪的差不多了，正好是我回爐好好再熱一熱的時(shí)候了。來(lái)之前就和黑羽有過(guò)接觸，也看過(guò)他對(duì)于TOP的一些構(gòu)想，在我的計(jì)劃中就有和他交流的部分，上周找了一個(gè)時(shí)間碰了一下，果然有很多和我一致的想法，同時(shí)還有一些比我更加深入的idea，特別是對(duì)于大淘寶未來(lái)的一個(gè)構(gòu)想。其實(shí)來(lái)到TOP我所要做的就是在技術(shù)的架構(gòu)上找到商業(yè)的感覺(jué)，讓商業(yè)驅(qū)動(dòng)技術(shù)，技術(shù)沉淀積累來(lái)支持商業(yè)的暢想。

    這七天過(guò)的很快，全身心投入的工作，時(shí)間總是過(guò)的很快，而且過(guò)去那種沉悶的心情和處事的態(tài)度在這里得到了改變。明天基本上就看完了TOP的大部分代碼，整理了一些review的建議，同時(shí)昨天還花了一些時(shí)間去看了看google appengine，寫(xiě)了幾個(gè)小應(yīng)用，看了看源碼（部分反編譯），因?yàn)橐oboss對(duì)于小應(yīng)用hosting方面的一些想法。

   總的來(lái)說(shuō)還是和我原先的計(jì)劃一樣，商業(yè)上和PD運(yùn)營(yíng)交流，了解未來(lái)TOP商業(yè)發(fā)展方向，以及對(duì)技術(shù)架構(gòu)的一些需求。架構(gòu)上從代碼和文檔看起，文檔不是很多，所以就只好每個(gè)工程看過(guò)來(lái)，也不錯(cuò)，看到自雪同學(xué)寫(xiě)的代碼還是不錯(cuò)的，同時(shí)也看到了淘寶的基礎(chǔ)組件的推廣力度之大，這比在阿里軟件強(qiáng)的多，其實(shí)也是我一直希望看到的，人人都是技術(shù)牛人，都在做重復(fù)的事情，但是卻沒(méi)有技術(shù)沉淀，其實(shí)大家完全可以吧自己的構(gòu)想增強(qiáng)在別人的基礎(chǔ)之上，而不是什么都自己搞一套，淘寶的技術(shù)應(yīng)該來(lái)說(shuō)在政策上得到了支持，技術(shù)積累效果還是不錯(cuò)的，這里還不得不提到我的淘寶同學(xué)畢玄同學(xué)的服務(wù)基礎(chǔ)框架HSF，雖然現(xiàn)在還沒(méi)有接觸，但是應(yīng)該已經(jīng)發(fā)展的挺好的。

   有兩個(gè)能夠用人，擔(dān)得起起技術(shù)團(tuán)隊(duì)發(fā)展的Boss，有這么一些年輕有沖勁的小同學(xué)，有這么一些樂(lè)于傾聽(tīng)分享協(xié)作的老同學(xué)，有這么一些很有商業(yè)feeling的非技術(shù)團(tuán)隊(duì)同學(xué)，要做好TOP，我想只有三個(gè)字：“沒(méi)問(wèn)題”。這是我在入職七天寫(xiě)的隨記，一年后再來(lái)回看我今天說(shuō)的這些話(huà)，在來(lái)看看這個(gè)團(tuán)隊(duì)創(chuàng)造的價(jià)值。

   附：在淘寶申請(qǐng)好了花名：放翁。陸游的字，武俠小說(shuō)的人就連掃地的都沒(méi)有了，歷史名人也沒(méi)有了，不過(guò)詩(shī)人倒是沒(méi)有人用，指不定還開(kāi)創(chuàng)了淘寶同學(xué)入職的花名新取法。

   好好工作，天天向上，為了TOP，為了家里的BB，為了自己的一點(diǎn)理想，踏踏實(shí)實(shí)的走自己的路，讓別人開(kāi)車(chē)去吧，^_^

本文來(lái)自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/cenwenchu79/archive/2009/08/12/4440248.aspx

   昨天是去淘寶工作的第一天，最近最頭痛的就是花名，在我兒子出生的時(shí)候我就知道起名字是最麻煩的事情，而起花名更是痛苦，因?yàn)槟愕倪x擇余地更小，同時(shí)還不能和前人重復(fù)，好不容易找到兩個(gè)還不錯(cuò)的，結(jié)果一個(gè)給其他部門(mén)的老大保留了，一個(gè)因?yàn)槠匆艉鸵粋€(gè)同學(xué)相似而無(wú)法使用。想用文初，結(jié)果還給一個(gè)淘寶的活躍用戶(hù)使用了，問(wèn)了HR不取花名是否可以，回答說(shuō)，不可以，太折騰了。

   昨天開(kāi)了一整天的會(huì)，主要還是協(xié)調(diào)兩個(gè)平臺(tái)之間將來(lái)的合作模式，同時(shí)也梳理了雙方的現(xiàn)有功能，將未來(lái)雙方的邊界做了初步定奪，同時(shí)也對(duì)將來(lái)的一些需求做了初步的規(guī)劃，系統(tǒng)的模塊化也提上了最近的日程。

  今天會(huì)化一些時(shí)間看看已有的代碼熟悉一下Top的情況，同時(shí)也看看一些流程性的文檔，希望能夠盡快的對(duì)Top全方位的了解，這樣便于從細(xì)節(jié)實(shí)現(xiàn)到整體架構(gòu)設(shè)計(jì)都能給出自己的意見(jiàn)。

  初來(lái)乍到不容易，很多需要從新開(kāi)始的，不過(guò)對(duì)我來(lái)說(shuō)合作的人，做的事情還是有一定的基礎(chǔ)，因此只是需要一周左右的過(guò)渡期，后續(xù)應(yīng)該會(huì)走的更加順暢。

Author : 岑文初

Email: wenchu.cenwc@alibaba-inc.com

Blog: http://blog.csdn.net/cenwenchu79

Date: 2009-5-26

目錄

需求轉(zhuǎn)而學(xué)習(xí)

“軟”負(fù)載均衡

LVS （Linux Virtual Server）

Virtual Server三種模式介紹

Virtual Server三種模式的比較

Virtual Server三種模式實(shí)踐

三種模式下的簡(jiǎn)單壓力測(cè)試

HA-Proxy

HA-Proxy安裝和使用

HA-Proxy的壓力測(cè)試結(jié)果

“軟”負(fù)載學(xué)習(xí)心得

需求轉(zhuǎn)而學(xué)習(xí)

         很多時(shí)候不少做開(kāi)發(fā)的同學(xué)都認(rèn)為技術(shù)更新的快，新技術(shù)、新概念層出不窮，大家樂(lè)此不疲的去跟隨著所謂的“技術(shù)趨勢(shì)”走在風(fēng)頭浪尖上，但其實(shí)往往忘記了一個(gè)最重要的問(wèn)題“滿(mǎn)足客戶(hù)需求”。其實(shí)技術(shù)就是為滿(mǎn)足需求服務(wù)的，用最小的代價(jià)來(lái)滿(mǎn)足用戶(hù)的需求，以最簡(jiǎn)單高效的方式來(lái)達(dá)到目標(biāo)，就是每個(gè)開(kāi)發(fā)者應(yīng)該追求的。（不要因?yàn)樽约旱募軜?gòu)很簡(jiǎn)單就臉紅拿不出手，只要你在滿(mǎn)足用戶(hù)當(dāng)前需求的基礎(chǔ)上對(duì)未來(lái)有所考慮，那么化繁為簡(jiǎn)就是一種能力的表現(xiàn)）

         SIP（服務(wù)集成平臺(tái)）5.7版本中對(duì)于未來(lái)多個(gè)服務(wù)提供商，多種類(lèi)型的服務(wù)，在每日幾億的調(diào)用壓力下，需要找到一個(gè)解決方案：可以分流不同服務(wù)提供商的服務(wù)，分流不同類(lèi)型的服務(wù)，服務(wù)隔離化來(lái)減少服務(wù)相互之間影響以及服務(wù)提供商之間的影響。

         當(dāng)前SIP的前端是通過(guò)硬件F5作負(fù)載均衡，因此是無(wú)狀態(tài)無(wú)差別的服務(wù)負(fù)載，這也使得無(wú)法區(qū)分不同的服務(wù)提供商的服務(wù)請(qǐng)求和不同類(lèi)型的服務(wù)請(qǐng)求，導(dǎo)致服務(wù)提供商之間的服務(wù)會(huì)產(chǎn)生相互影響（旺旺即時(shí)通信類(lèi)API在峰值占用了大部分的服務(wù)處理資源，淘寶寶貝上傳類(lèi)API占用了大量的帶寬）。近期還有更大的兩類(lèi)API將會(huì)接入，因此尋找一個(gè)服務(wù)可分流的方案勢(shì)在必行。（當(dāng)然過(guò)去也考慮通過(guò)三級(jí)域名配置在負(fù)載均衡上來(lái)解決這些問(wèn)題，但是這樣首先對(duì)于開(kāi)發(fā)者來(lái)說(shuō)不透明，其次也是一種比較僵化的設(shè)計(jì)方案，擴(kuò)展和維護(hù)也有一定的難度）

         在過(guò)去也嘗試過(guò)Apache等Web容器自己的一些load balance特性，當(dāng)然效果不是很好，和硬件基本無(wú)法比擬，而一些專(zhuān)有的“軟”負(fù)載均衡方案和開(kāi)源項(xiàng)目也沒(méi)有深入的去了解，因此借著這次機(jī)會(huì)，好好深入的挖一挖“軟”負(fù)載均衡。

“軟”負(fù)載均衡

         作為互聯(lián)網(wǎng)應(yīng)用，隨時(shí)都需要做好用戶(hù)量突然增大，訪問(wèn)量突然上升的準(zhǔn)備。今年熱門(mén)的詞匯“云”我就不多說(shuō)了，這里就簡(jiǎn)單說(shuō)說(shuō)服務(wù)器的橫向擴(kuò)展。其實(shí)和DB，文件系統(tǒng)等一樣，當(dāng)資源成為瓶頸的時(shí)候，就需要考慮如何通過(guò)擴(kuò)展或者提升資源能力來(lái)滿(mǎn)足用戶(hù)的需求，這就是我們常說(shuō)的橫向擴(kuò)展和縱向擴(kuò)展。（對(duì)于橫向擴(kuò)展和縱向擴(kuò)展的優(yōu)劣大家應(yīng)該都很清楚了，這里也不做贅述）橫向擴(kuò)展中就會(huì)要求使用負(fù)載均衡的能力，如何根據(jù)資源能力不同以及資源在運(yùn)行期負(fù)荷動(dòng)態(tài)變化將負(fù)載合理分配是判斷負(fù)載均衡優(yōu)劣的標(biāo)準(zhǔn)。

         軟件負(fù)載均衡一般通過(guò)兩種方式來(lái)實(shí)現(xiàn)：基于操作系統(tǒng)的軟負(fù)載實(shí)現(xiàn)和基于第三方應(yīng)用的軟負(fù)載實(shí)現(xiàn)。LVS就是基于Linux操作系統(tǒng)實(shí)現(xiàn)的一種軟負(fù)載，HA Proxy就是基于第三應(yīng)用實(shí)現(xiàn)的軟負(fù)載。（后面會(huì)詳細(xì)介紹這兩種方式的使用）

         最早期也是最原始的軟負(fù)載均衡：“Round Robin DNS”，通過(guò)輪詢(xún)方式在DNS綁定多個(gè)IP的情況下，將用戶(hù)對(duì)于同一個(gè)域名的請(qǐng)求分配到后端不同的服務(wù)節(jié)點(diǎn)。這種方案的優(yōu)點(diǎn)：配置簡(jiǎn)單，負(fù)載分配效率高。缺點(diǎn)：無(wú)法知曉后端服務(wù)節(jié)點(diǎn)服務(wù)情況（是否已經(jīng)停止服務(wù)），無(wú)法保證在一個(gè)Session中多次請(qǐng)求由一個(gè)服務(wù)節(jié)點(diǎn)服務(wù)，每一個(gè)節(jié)點(diǎn)都要求有一個(gè)外網(wǎng)IP。

         另一種較為常見(jiàn)的就是基于分發(fā)器的Load balance。服務(wù)使用者通過(guò)向分發(fā)器發(fā)起請(qǐng)求獲得服務(wù)，分發(fā)器將請(qǐng)求分發(fā)給后端實(shí)際服務(wù)處理的節(jié)點(diǎn)，給客戶(hù)提供服務(wù)，最常說(shuō)的反向代理模式就是典型的分發(fā)器Load Balance。這類(lèi)負(fù)載均衡處理可以基于應(yīng)用級(jí)轉(zhuǎn)發(fā)，也可以基于IP級(jí)別轉(zhuǎn)發(fā)，當(dāng)然基于應(yīng)用轉(zhuǎn)發(fā)效率和損耗比較大，同時(shí)分發(fā)器本身也會(huì)成為瓶頸。

LVS （Linux Virtual Server）

         LVS是在Linux操作系統(tǒng)基礎(chǔ)上建立虛擬服務(wù)器，實(shí)現(xiàn)服務(wù)節(jié)點(diǎn)之間的負(fù)載均衡。LVS主要是處理OSI模型中的4層消息包，根據(jù)一定的規(guī)則將請(qǐng)求直接轉(zhuǎn)發(fā)到后端的服務(wù)處理節(jié)點(diǎn)，有較高轉(zhuǎn)發(fā)效率。

         Virtual Server是Load Balancer和一組服務(wù)器的邏輯組合統(tǒng)稱(chēng)，使用服務(wù)者只需要與Virtual Server進(jìn)行交互就可以獲得高效的服務(wù)。真實(shí)服務(wù)器和Load Balancer通過(guò)高速ＬＡＮ進(jìn)行交互。Load Balancer能夠?qū)⒄?qǐng)求分發(fā)到不同的服務(wù)端，在一個(gè)虛擬IP下并行處理多個(gè)請(qǐng)求。

Virtual Server三種模式介紹

Virtual Server有三種基于IP級(jí)別的負(fù)載均衡實(shí)現(xiàn)方式：IP address translation（NAT）、Direct routing、IP Tunneling。

         NAT(Network address translation)：由于IPV4的某些缺陷和安全原因，某些網(wǎng)段例如（10.0.0.0/255.0.0.0, 172.16.0.0/255.240.0.0 and 192.168.0.0/255.255.0.0）不能被用于互聯(lián)網(wǎng)，因此常常被用作內(nèi)部局域網(wǎng)，通過(guò)網(wǎng)絡(luò)地址翻譯的方式可以讓這些網(wǎng)段的服務(wù)器訪問(wèn)互聯(lián)網(wǎng)或者被互聯(lián)網(wǎng)訪問(wèn)。網(wǎng)絡(luò)地址翻譯主要作用就是將一組ip地址映射到其他的一組ip地址，當(dāng)映射比例為1:1的時(shí)候通常稱(chēng)作靜態(tài)映射，而當(dāng)映射地址為M:N(M>N)的時(shí)候（M為被映射地址數(shù)量，通常是內(nèi)部ip），則成為動(dòng)態(tài)映射。而對(duì)于Virtual Server的NAT模式來(lái)說(shuō)，就是利用了NAT的特性，將內(nèi)部的一組服務(wù)器通過(guò)映射到一個(gè)虛擬的IP，然后以一個(gè)外網(wǎng)虛擬服務(wù)節(jié)點(diǎn)的身份對(duì)外提供服務(wù)。

         上圖是一個(gè)實(shí)際的NAT范例，對(duì)外的服務(wù)IP為202.103.106.5，內(nèi)部建立了虛擬IP為172.16.0.1，然后將內(nèi)部其他兩臺(tái)實(shí)際服務(wù)的服務(wù)器172.16.0.2，172.16.0.3映射到172.16.0.1這個(gè)虛擬IP。客戶(hù)端向202.103.106.5發(fā)起請(qǐng)求服務(wù)，Load Balancer查看請(qǐng)求數(shù)據(jù)包，如果是請(qǐng)求目標(biāo)地址是注冊(cè)的虛擬IP及監(jiān)聽(tīng)端口的時(shí)候，那么通過(guò)NAT按照一定算法選擇某一臺(tái)實(shí)體服務(wù)器，再重寫(xiě)報(bào)文目標(biāo)地址，轉(zhuǎn)發(fā)請(qǐng)求到實(shí)際的目標(biāo)服務(wù)器，當(dāng)目標(biāo)服務(wù)器處理完畢以后，將處理結(jié)果返回給Load Balancer，由Load Balancer修改源地址，返回給客戶(hù)端。

         IP Tunneling：IP管道技術(shù)是在IP報(bào)文上再次封裝IP報(bào)文協(xié)議的一種技術(shù)。允許將一個(gè)目標(biāo)為A的IP數(shù)據(jù)報(bào)文封裝成為目標(biāo)為B的IP數(shù)據(jù)報(bào)文，在特定的IP 管道中傳輸。

         上圖就是IP Tunneling模式的運(yùn)作原理。首先客戶(hù)端還是通過(guò)訪問(wèn)對(duì)外的一個(gè)服務(wù)IP請(qǐng)求服務(wù)，當(dāng)Load Balancer接受到請(qǐng)求以后，檢查VIP注冊(cè)信息，然后根據(jù)算法選擇實(shí)際的一臺(tái)后臺(tái)服務(wù)器，通過(guò)IP管道封裝技術(shù)對(duì)IP報(bào)文再次封裝，然后將消息通過(guò)IP管道轉(zhuǎn)發(fā)到實(shí)際的服務(wù)器，實(shí)際的服務(wù)器通過(guò)解包處理請(qǐng)求，然后根據(jù)包體內(nèi)實(shí)際的服務(wù)請(qǐng)求地址，將處理結(jié)果直接返回給客戶(hù)端。

         Direct routing：利用Load Balancer和實(shí)際服務(wù)器共享同一VIP，簡(jiǎn)單的通過(guò)修改消息報(bào)體目標(biāo)MAC地址，轉(zhuǎn)發(fā)請(qǐng)求，然后再通過(guò)實(shí)際服務(wù)器配置VIP為本地回環(huán)，直接處理消息報(bào)文，而不再轉(zhuǎn)發(fā)，當(dāng)處理完以后，直接將處理結(jié)果返回給客戶(hù)端。

         上圖就是Direct Routing的運(yùn)作流程，當(dāng)外部請(qǐng)求到Load Balancer時(shí)，通過(guò)查找VIP注冊(cè)信息，直接選擇一臺(tái)后端服務(wù)器作為新的目標(biāo)地址，修改消息報(bào)文中的目標(biāo)地址Mac地址，轉(zhuǎn)發(fā)到目標(biāo)服務(wù)器，目標(biāo)服務(wù)器由于配置VIP在本地網(wǎng)卡回路中，因此直接處理消息，將處理完的結(jié)果直接返回給客戶(hù)端。

Virtual Server三種模式的比較

         下表是官方整理出的關(guān)于Virtual Server三種不同模式的區(qū)別：

	NAT	TUNNEL	DR
服務(wù)器要求	無(wú)要求	需要支持IP管道	無(wú) arp組件（當(dāng)前也有補(bǔ)丁）
網(wǎng)絡(luò)要求	Private	LAN/WAN	LAN
可支持后端服務(wù)器節(jié)點(diǎn)數(shù)	較少（10-20）	較多	較多
服務(wù)網(wǎng)關(guān)	Load Balancer	本身	本身

NAT：根據(jù)其實(shí)現(xiàn)原理，可以知道這種模式對(duì)于操作系統(tǒng)，網(wǎng)絡(luò)都沒(méi)有太多的要求和約束，但是由于消息需要打解包，同時(shí)消息的響應(yīng)都必須經(jīng)過(guò)Load Balancer，因此Load Balancer自身成為了瓶頸，這樣一個(gè)Load Balancer能夠支持的后端服務(wù)節(jié)點(diǎn)數(shù)量就有限了。當(dāng)然可以采用混合模式來(lái)解決這個(gè)問(wèn)題，也就是通過(guò)TUNNEL或者DR模式作為前端模式串聯(lián)起多個(gè)NAT模式Balancer。

TUNNEL：這種模式要求操作系統(tǒng)支持IP Tunnel，通過(guò)對(duì)IP報(bào)文再次封裝轉(zhuǎn)發(fā)，達(dá)到負(fù)載均衡的目的。設(shè)計(jì)這種模式的初衷是考慮，對(duì)于互聯(lián)網(wǎng)很多服務(wù)來(lái)說(shuō)，服務(wù)請(qǐng)求數(shù)據(jù)量和返回?cái)?shù)據(jù)量是不對(duì)稱(chēng)的，返回的數(shù)據(jù)往往要遠(yuǎn)遠(yuǎn)大于請(qǐng)求的數(shù)據(jù)量，因此如果請(qǐng)求和返回都走Load Balancer會(huì)大量占用帶寬，影響處理能力。IP Tunnel設(shè)計(jì)中請(qǐng)求是通過(guò)Load Balancer，但是返回是直接返回到客戶(hù)端的，因此節(jié)省了返回的帶寬，提高了請(qǐng)求處理的能力。

DR：這種模式要求Load Balancer和后端服務(wù)器處于同一個(gè)局域網(wǎng)段。DR模式處理消耗最小，消息轉(zhuǎn)發(fā)和回復(fù)基本沒(méi)有損耗，因此效率應(yīng)該是最高的，但是約束是相對(duì)來(lái)說(shuō)最多的。