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

優化雜談

Author :放翁

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

         當應用遇到規?；瘑栴}的時候，就是考慮性能優化的時候了。今天同事和我聊起了NIO在客戶端的使用與BIO有什么優勢，也勾起了我前一陣子和其他同學交流優化的一些想法，純粹個人的一點想法。

CPU利用率和Load

         在過去做壓力測試的時候，我們經常會關注兩個指標，CPU和Load。有同學覺得CPU利用率上去了Load肯定也上去了，Load上去了CPU利用率同樣會上去。但是在一些需要優化的場景下，常常會看到Load很高，CPU利用率卻可能比較低（多核更是可能出現分配不均的情況）。Load其實就是等待處理的任務隊列，當你的應用在等待同步消息返回處理的同時，CPU還是會將時間切片分配給這些線程，而真正需要CPU的線程，卻不得不在到了時間片以后暫時放棄工作被掛起。因此在程序設計的時候就要考慮如何利用好CPU的這個資源，如何均勻的將壓力分攤到各個CPU上（有時候就一個線程在不斷循環，導致單個CPU負荷很高）。

NIO在客戶端的使用

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

         NIO和BIO在數據傳輸和處理的模式上有不同，NIO采用的是BufferPacket+Channel的模式，這其實和操作系統本身的傳輸模式很類似，而BIO的Stream的模式是Java自己獨特的模式。在采用NIO的這種數據傳輸模式以后，可以充分利用操作系統本身對傳輸的優化，因此這是一方面好處。另一方面異步和事件機制的使用，可以降低對于昂貴的資源申請，在高并發下提高處理能力。

NIO客戶端的編程模型最大特點：依賴反置，松耦合帶來性能提升。在請求流程協議中支持“票根”，也就是我們說的回執。例如，你今天面試完了，不需要你在阿里巴巴前臺等著結果，直接留個電話，有消息就會直接通知，電話就是通知結果和服務請求者的關聯手段。（此時阿里巴巴前臺和會議室就會有足夠的空間給其他人來面試，這就是資源）

         服務端使用NIO就不多說了，這里主要說一下在客戶端的使用場景。兩者是否真的有很大的差別，是否NIO有絕對的優勢，其實還是和場景有關。簡單說來就一個判斷標準：應用對于通道的利用率是否夠高。下面列了4種場景：

1． 一次請求數據量很少，服務處理速度很快。

2． 一次請求數據量很多，服務處理速度很快。

3． 一次請求數據量很少，服務處理速度很慢。

4． 一次請求數據量很多，服務處理速度很慢。

場景1，傳輸效率很高，服務處理速度很快，一次請求很快就被完成，采用NIO和BIO，在性能優勢上除了操作系統對NIO的優化以外，BIO連接池不輸于NIO。在易用性上，BIO更加容易處理。（NIO的異步機制，就要求消息傳輸協議需要有會話碼來提供異步處理入口選擇如何處理）

場景2，傳輸過程比較長，消耗時間比較多，服務處理速度很快，因此交互的時間大部分都還是在數據通道傳輸上，由于NIO在傳輸過程中依然是串行化的，因此BIO的連接池優于NIO，同時NIO一個客戶端只有一個通道，因此BIO開的連接池越大，并行處理能力越強，因此BIO效率比較好一些。

場景3，傳輸量比較少，服務處理比較慢，很明顯這是通道利用率低的表現，NIO有絕對的優勢，特別是在高并發下。信道和服務端客戶端資源被充分利用。

場景4，傳輸量比較多，服務處理也比較慢，這時候可以發現信道利用率取決于服務事件和傳輸消耗時間的比例，這類場景某些情況下BIO也會優于NIO。

單線程和多線程

         在使用多線程來優化程序的時候，是否考慮過多線程的使用場景，多線程不是萬能藥，在某些情況下還可能是毒藥。使用多線程的過程中，需要考慮這么幾個因素：

1． 資源競爭，復雜度增加。

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

2． 是否是關鍵路徑的工作，占關鍵路徑的比例。

首先，在優化以前需要考慮優化的內容是否是關鍵路徑的工作，如果不是，那么增加復雜度實現的多線程模式，就沒有價值。其次就是看是否是在關鍵路徑中占有比較大的比例，同樣的，還是投入產出比例（多線程帶來的復雜度以及在高并發下的一些資源保護措施都需要很多的維護成本）。

3． 任務的合理切分。

在NIO的客戶端，接受數據的事件將會寫得很輕量級，但是接受到數據然后分析數據還原成業務對象，則會通過線程池的方式來分別處理。就好比監聽連接到來，和實際的去建立連接分成了兩個階段的任務，讓事件型的任務單純，快速執行，讓與業務相關的部分通過多線程并行的方式提高處理效率。總的來說就是把任務劃分成為系統性的任務和業務性的任務，前者消耗時間少，設計盡量簡單高效，采用單線程處理即可，后者通常情況下在處理流程和資源上不沖突的情況可以通過多線程并行提高效率。

         優化應用關注點：

A．關鍵路徑是否可以優化，關鍵路徑的任務拆分。

B．關鍵路徑上的單個任務是否可以拆分并行執行。（是否有資源競爭，是否會有流程上的前后依賴，是否增加復雜度引入新的不穩定因素）

C．系統資源和依賴外部系統是否會成為瓶頸。（單機的CPU,IO都會在一定的壓力下成下降趨勢，并行執行反而降低了處理能力）

因此，可以看到不論是MapReduce設計下的Hadoop，還是Erlang語言級別的特性，都盡量的希望任務之間可以并行執行，相互之間低耦合，通過異步事件消息通知方式來交互，同時數據沒有共享，防止資源競爭導致無法并行高效處理。系統設計還是要根據場景來判斷使用什么方式優化，越簡單越好。

    中午左右收到一個看我blog的朋友的郵件，最近他在研究mapreduce，然后想用hadoop來做一些工作，不過遇到了一些問題，我這邊也貼一下他的幾個問題，同時覺得自己把自己的一些看法分享一下，當然只是自己的一些想法，也許對新學習的同學有幫助。

   問題：

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

   我給回復的郵件內容：

   首先，MapReduce的思想和Hadoop的MapReduce的架構不是一個概念，說的具體一點也就是Hadoop的架構設計只是MapReduce的一個子集思想的實現。每個人都可以根據自己對MapReduce的理解去實現業務處理，簡單來說多線程處理就是MapReduce的一種最簡單的實現，復雜來說多機協調工作就是一種復雜的實現。

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

   a.問題分而治之。（找到流程的關鍵路徑，優化可以并行處理的工作）

   b.計算靠近數據。（這也是hdfs存在的最重要的特點，計算的轉移往往要比數據轉移廉價，特別是對海量數據的處理）

   c.數據規?；S著并行處理成數量級遞減。

   剩下的內容就是各個框架對于非業務性需求的處理，例如容災，如何盡量少穿數據協調處理等等。

   針對他提出的三個問題：

    1. Hadoop的mapreduce從架構上來說最適合的就是統計分析計算。做其他方面的工作需要考慮是否適合，而不是為了技術而技術，先有需求再有技術選型。
    2.  對于你這個需求直接用搜索技術實現就可以了，不一定要硬套在mapreduce上。
    3. 對于海量數據是否一定要到hdsf上，或者就簡單得數據物理或者邏輯切割來直接處理，根據自己業務場景選擇。hdfs的特點就是對文件切割，容災，數據邏輯存儲和物理存儲無關性（便于擴容管理，同時也是計算靠近數據的技術保證）。

    是否使用MapReduce框架，HDFS存儲關鍵還是看你是否真的需要，當現有框架對自己來說并不合適的時候可以對小規模問題定制MapReduce的處理，最簡化就是你去多線程或者多進程處理問題，需求決定技術選型。

當前問題:

1.       不小比重的Rest請求都是無效請求，全部接納數據消耗比較多的時間。

2.       Multipart類型的大文件流請求無法做到合理快速過濾。（參數錯誤請求，數據文件過多請求，文件大小過大請求）

歸結來說，TOP平臺處理的服務在解析參數時比較消耗時間和帶寬(客戶端網絡速度慢導致傳輸字節流比較慢，文件比較大導致帶寬占用嚴重)

處理方式：

通過自行解析字節流方式來lazy化處理請求，減少無效請求對于解析參數時間消耗（導致web容器連接消耗）及帶寬消耗。

優化目標：

         Get由于內容長度有限不列入在優化范圍。

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

具體實現：

        由于現在用的是傳統IO模式，因此可以用流的方式來lazy解析和處理請求（NIO用channel + buffer package就無法lazy了）。

         一共有三個組件角色：

1． 請求處理配置策略：配置在解析參數時，優先的規則（參數可以從header,uri,post body中獲取，相互之間的優先性），異常拋出規則（字節流長度，文件大小，文件個數限制等），字節流解析模塊的參數配置（字節流解析的窗口大小，超時時間等）。

2． 線程上下文：用來保存處理過的請求參數。一來復用，二來也是由于請求字節流處理不可逆（不保存字節流副本），必須保留。

3． Http請求字節流解析模塊。根據具體的配置以及解析策略來解析字節流，同時將解析結果保存在線程上下文中。主要的實現代碼在于對Post消息體逐步解析部分（普通的Post和multipart）

壓力測試結果：

•    正常請求場景（ 100并發用戶，multipart 文件大小300k，當前業務場景這個值已經滿足了）：

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

  multipart處理能力610TPS。（apache開源項目fileupload，處理能力400TPS左右）

錯誤請求場景

         異常情況的處理有了很大提高，對于遠程客戶端傳輸較慢或者是大流量圖片的錯誤請求都有很大的優化。

優化存在問題：

1． 參數缺失導致優化失效。

2． sign類似的交驗，導致獲取所有的參數。

3． 當前圖片限制在300k，由于考慮處理速度快，就都沒有設置超過閥值存儲到本地，因此在高并發大流量的情況下也會有內存問題，當然已經做了部分保護。

針對上面的兩個問題，作了部分的協議限制，對于API2.0希望將所有的系統參數和業務參數區分開，放入到Http header中或者url中，這樣可以避免系統參數缺失導致優化失敗，同時大量過濾系統參數出現問題的無效請求。

Sign類似的交驗放在流程最后，避免過早獲取所有參數。

作安全保護，設定簡單丟棄或者io交互來緩解這個問題。

         這部分內容還有很多可以做得工作，其實最初的目的就是為了防止系統對于無效請求的處理消耗，我想在很多系統都會有這樣的問題，利用緩存設置黑名單防止攻擊也是這樣的初衷。因此這點可以考慮在很多系統設計的時候都作一樣的優化，對正常的不能優化，起碼對錯誤的可以做一些優化，防止在異常請求高漲的時候，系統被擊垮.

其實想說這句話很久了,和很多同事接觸,有時候或多或少的都會發現大家會陷入在自己的一畝三分地里面.

         主要表現得癥狀

1.       PD的需求就是目標，踏實的實現，不懂的就猜。

2.       經驗蓋過一切，設計系統就是要夠完備夠復雜。

從開發人員角度來看，第一種人多半比較有自己的想法，同時也有不少的工作經驗，同時可能對技術比較著迷。另一種人多半是剛剛工作或者經驗不足，要么就是習慣性把工作當任務，而不是愛好，寫程序也就是一份賺錢的活。但看起來其實各自都在自己的一畝三分地上搗鼓，忘記了作為一個開發人員最基本的原則：“滿足客戶需求”。

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

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

今天下午面試了一個外部的同學，工作年限比我長，看了簡歷也經歷了很多項目，同時在描述的時候寫了對高并發，分布式等等都很熟悉和熱衷，我開始看了簡歷就擔心，可能我這邊不一定要他，因為我怕他開口就是說一大堆如何做高并發和分布式的內容。在我看來如果你沒有搞清楚你什么時候要用牛刀，什么時候要用剪刀的人，和你談論牛刀的構造其實沒啥意思，因為在我看來，技術只要你肯花時間去學，沒什么學不到的，但是做事方式和項目設計經驗卻是長時間積累的。幸好今天和他一談，他對于技術的態度以及架構設計的思想都和我想的比較接近，不是為了技術而技術，不是為了過程而過程，了解如何從簡如繁，再從繁入簡，最終能夠找到自己的目標。當然后來還是談了很多技術細節的問題，畢竟干活還是要一個好手，作了那么多年如果沒有經驗和技術積累也是很可怕的事情。最后我問了他兩個問題：1.你學習一個新技術的過程是怎么樣的？2.你和你同事如果在設計方案上有沖突你怎么解決？他告訴我他學習新技術首先會去考慮這個技術的特點是什么，和其他技術的差別，他的擅長領域是什么，這樣才能夠用到實處。第二個問題他和我說就是開會討論，最后大家群體決定。我對他第一個問題感到很滿意，因為我就需要這樣的同事，第二個問題我給了他一個建議，其實在很多時候，將別人的架構設計的優點融入到自己的設計中，不再以方案作為邊界，那么大家最終就很容易達成一致，因為你在接受別人的思想時其實能夠看到自己的不足，同時對待別人不是用否定的態度，會讓你更容易得到認可和接受。（這點作起來需要不斷的改變程序員自身的好勝個性，我起碼還是出于變化中…）

我記得我小時候上政治課的時候，老師給我們劃分了三種人：有能力但是沒有道德的人是危險的人，沒有能力但是有道德的人是對社會無害的人（覺得像葛優說的那個對社會無害的海龜一個概念），有能力同時也有道德的人是對社會有益的人。我覺得其實程序員也就可以從兩個緯度看：

1.       有能力，有經驗，對技術有追求。

2.       對產品化和客戶沒有任何感覺。

擁有了素質1但是沒有素質2，那么最多也就只能說是試驗室的花朵，在大學搞搞研究還不錯，實際要做出產品來可能就是紙上談兵，好鋼始終用不到刀刃上，有力沒地使。

素質1有所欠缺，素質2很明晰，對自己目標不斷追求，其實這樣的人，有時候笨鳥也會飛的比聰明的鳥更高。

擁有1，2的人，當然就是最好的人，只需要學會做人那么就可以發揮自己的能量。（程序員有時候就是很難改變自己的個性，去學會如何溝通和理解）
         最后一類就是自以為有1和2的人，這類人最怕就是面試的時候被考官通過，那么后續的問題就大了。

說了怎么多，其實也無非想說出一個程序員這些年的經歷，從做開發到做基礎平臺，到做業務平臺，該怎么踏實做事，該在什么時候找到自己的瓶頸，該在什么時候改變自己的狀態，都需要自己好好的讓自己冷靜下來想想。做基礎平臺需要耐得住寂寞，同時也要知道自己是有客戶的，服務不好客戶，那么基礎組件平臺就是玩具。做業務平臺需要學會去分析和溝通，需要去了解每一個層次的設計如何協作，同時在兼顧業務需求的同時滿足隱性需求（穩定性，可用性，響應速度，規模化等等）。但歸根到底，能給開發人員不斷能量的不是技術本身，而是你用技術給你的客戶帶來的價值，對你的認可是長期做事的一個最基本的動力，因為當你現在覺得純做技術能夠支持你不斷向前走的時候，其實在不遠的將來你會體會到原來過程和目標是同樣重要的。走出自己的一畝三分地，給自己多一點的空間，會讓自己看得更遠，走的更高。

   今年blog更新的速度比去年慢很多，當然最大的原因就是工作的轉變。當選擇留在云公司還是去淘寶，自己做了很快的抉擇，去淘寶。其實在阿軟的后面這一年，對自己來說是一個技術提升的階段，工作任務不緊，技術預研范圍較大，但對于自己這么一個已經到了30的人來說，應該是把技術轉變為產品的時候了，因此義無反顧地選擇了TOP作為我新的開端。

    其實每個人都會有自己不同的階段，任何階段都有自己的目標，同時當你發現在一個階段停留很久，都沒有什么突破，或者漸漸失去目標的時候，那么就需要考慮如何找到新的起點。對我來說，技術追求和提升是沒有止盡的，但是需要真正的將所學的作出一點實在的產品，同時在參與產品團隊的過程中，學會溝通，交流，分析問題，全面地看問題，這些也是不可缺少的成長經驗，如果僅僅局限在狹隘的某一個技術立領域，那么就和普通的學生無異。

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

    去年年底我寫了關于對于Open API的思考和探索的一篇文章作為年底總結，今年一樣，對于當前自己的工作將會有一份總結和規劃，即是對今年平臺發展的一個回顧，也是對平臺未來的一點思考，大致已經列了一個綱要，對外可能部分內容不能全寫出來，不過就算不寫細節也會將一些思路寫一下，大家可以相互探討一下。這部分內容也將會成為我12月份參加淘寶內部淘寶大學講課的內容，希望能夠將今年新進淘寶的同學吸引到TOP來，為TOP增加人氣。

   下面是一個mind 圖，大致描述了一些內容：

   今天是轉崗到淘寶的第七天，也算是一周吧，期待來這個團隊已經有快大半年了，這次阿軟的重組給了一個機會，過去的就過去吧，不再回首有任何的抱怨和遺憾，需要面對的是新的將來。

    很奇怪，來到淘寶，都是熟人，Boss是早就相識的菲青，TOP團隊的自雪，鳳先，秀芳及我不認識但是認識我的其他同學都很熱情，運營，PD,OST都是以前阿軟的老同學，還有其他幾個團隊的朋友，感覺回到了家，而不是離開了家。

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

    這七天過的很快，全身心投入的工作，時間總是過的很快，而且過去那種沉悶的心情和處事的態度在這里得到了改變。明天基本上就看完了TOP的大部分代碼，整理了一些review的建議，同時昨天還花了一些時間去看了看google appengine，寫了幾個小應用，看了看源碼（部分反編譯），因為要給boss對于小應用hosting方面的一些想法。

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

   有兩個能夠用人，擔得起起技術團隊發展的Boss，有這么一些年輕有沖勁的小同學，有這么一些樂于傾聽分享協作的老同學，有這么一些很有商業feeling的非技術團隊同學，要做好TOP，我想只有三個字：“沒問題”。這是我在入職七天寫的隨記，一年后再來回看我今天說的這些話，在來看看這個團隊創造的價值。

   附：在淘寶申請好了花名：放翁。陸游的字，武俠小說的人就連掃地的都沒有了，歷史名人也沒有了，不過詩人倒是沒有人用，指不定還開創了淘寶同學入職的花名新取法。

   好好工作，天天向上，為了TOP，為了家里的BB，為了自己的一點理想，踏踏實實的走自己的路，讓別人開車去吧，^_^

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/cenwenchu79/archive/2009/08/12/4440248.aspx

   昨天是去淘寶工作的第一天，最近最頭痛的就是花名，在我兒子出生的時候我就知道起名字是最麻煩的事情，而起花名更是痛苦，因為你的選擇余地更小，同時還不能和前人重復，好不容易找到兩個還不錯的，結果一個給其他部門的老大保留了，一個因為拼音和一個同學相似而無法使用。想用文初，結果還給一個淘寶的活躍用戶使用了，問了HR不取花名是否可以，回答說，不可以，太折騰了。

   昨天開了一整天的會，主要還是協調兩個平臺之間將來的合作模式，同時也梳理了雙方的現有功能，將未來雙方的邊界做了初步定奪，同時也對將來的一些需求做了初步的規劃，系統的模塊化也提上了最近的日程。

  今天會化一些時間看看已有的代碼熟悉一下Top的情況，同時也看看一些流程性的文檔，希望能夠盡快的對Top全方位的了解，這樣便于從細節實現到整體架構設計都能給出自己的意見。

  初來乍到不容易，很多需要從新開始的，不過對我來說合作的人，做的事情還是有一定的基礎，因此只是需要一周左右的過渡期，后續應該會走的更加順暢。

Author : 岑文初

Email: wenchu.cenwc@alibaba-inc.com

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

Date: 2009-5-26

目錄

需求轉而學習

“軟”負載均衡

LVS （Linux Virtual Server）

Virtual Server三種模式介紹

Virtual Server三種模式的比較

Virtual Server三種模式實踐

三種模式下的簡單壓力測試

HA-Proxy

HA-Proxy安裝和使用

HA-Proxy的壓力測試結果

“軟”負載學習心得

需求轉而學習

         很多時候不少做開發的同學都認為技術更新的快，新技術、新概念層出不窮，大家樂此不疲的去跟隨著所謂的“技術趨勢”走在風頭浪尖上，但其實往往忘記了一個最重要的問題“滿足客戶需求”。其實技術就是為滿足需求服務的，用最小的代價來滿足用戶的需求，以最簡單高效的方式來達到目標，就是每個開發者應該追求的。（不要因為自己的架構很簡單就臉紅拿不出手，只要你在滿足用戶當前需求的基礎上對未來有所考慮，那么化繁為簡就是一種能力的表現）

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

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

         在過去也嘗試過Apache等Web容器自己的一些load balance特性，當然效果不是很好，和硬件基本無法比擬，而一些專有的“軟”負載均衡方案和開源項目也沒有深入的去了解，因此借著這次機會，好好深入的挖一挖“軟”負載均衡。

“軟”負載均衡

         作為互聯網應用，隨時都需要做好用戶量突然增大，訪問量突然上升的準備。今年熱門的詞匯“云”我就不多說了，這里就簡單說說服務器的橫向擴展。其實和DB，文件系統等一樣，當資源成為瓶頸的時候，就需要考慮如何通過擴展或者提升資源能力來滿足用戶的需求，這就是我們常說的橫向擴展和縱向擴展。（對于橫向擴展和縱向擴展的優劣大家應該都很清楚了，這里也不做贅述）橫向擴展中就會要求使用負載均衡的能力，如何根據資源能力不同以及資源在運行期負荷動態變化將負載合理分配是判斷負載均衡優劣的標準。

         軟件負載均衡一般通過兩種方式來實現：基于操作系統的軟負載實現和基于第三方應用的軟負載實現。LVS就是基于Linux操作系統實現的一種軟負載，HA Proxy就是基于第三應用實現的軟負載。（后面會詳細介紹這兩種方式的使用）

         最早期也是最原始的軟負載均衡：“Round Robin DNS”，通過輪詢方式在DNS綁定多個IP的情況下，將用戶對于同一個域名的請求分配到后端不同的服務節點。這種方案的優點：配置簡單，負載分配效率高。缺點：無法知曉后端服務節點服務情況（是否已經停止服務），無法保證在一個Session中多次請求由一個服務節點服務，每一個節點都要求有一個外網IP。

         另一種較為常見的就是基于分發器的Load balance。服務使用者通過向分發器發起請求獲得服務，分發器將請求分發給后端實際服務處理的節點，給客戶提供服務，最常說的反向代理模式就是典型的分發器Load Balance。這類負載均衡處理可以基于應用級轉發，也可以基于IP級別轉發，當然基于應用轉發效率和損耗比較大，同時分發器本身也會成為瓶頸。

LVS （Linux Virtual Server）

         LVS是在Linux操作系統基礎上建立虛擬服務器，實現服務節點之間的負載均衡。LVS主要是處理OSI模型中的4層消息包，根據一定的規則將請求直接轉發到后端的服務處理節點，有較高轉發效率。

         Virtual Server是Load Balancer和一組服務器的邏輯組合統稱，使用服務者只需要與Virtual Server進行交互就可以獲得高效的服務。真實服務器和Load Balancer通過高速ＬＡＮ進行交互。Load Balancer能夠將請求分發到不同的服務端，在一個虛擬IP下并行處理多個請求。

Virtual Server三種模式介紹

Virtual Server有三種基于IP級別的負載均衡實現方式：IP address translation（NAT）、Direct routing、IP Tunneling。

         NAT(Network address translation)：由于IPV4的某些缺陷和安全原因，某些網段例如（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）不能被用于互聯網，因此常常被用作內部局域網，通過網絡地址翻譯的方式可以讓這些網段的服務器訪問互聯網或者被互聯網訪問。網絡地址翻譯主要作用就是將一組ip地址映射到其他的一組ip地址，當映射比例為1:1的時候通常稱作靜態映射，而當映射地址為M:N(M>N)的時候（M為被映射地址數量，通常是內部ip），則成為動態映射。而對于Virtual Server的NAT模式來說，就是利用了NAT的特性，將內部的一組服務器通過映射到一個虛擬的IP，然后以一個外網虛擬服務節點的身份對外提供服務。

         上圖是一個實際的NAT范例，對外的服務IP為202.103.106.5，內部建立了虛擬IP為172.16.0.1，然后將內部其他兩臺實際服務的服務器172.16.0.2，172.16.0.3映射到172.16.0.1這個虛擬IP?？蛻舳讼?/span>202.103.106.5發起請求服務，Load Balancer查看請求數據包，如果是請求目標地址是注冊的虛擬IP及監聽端口的時候，那么通過NAT按照一定算法選擇某一臺實體服務器，再重寫報文目標地址，轉發請求到實際的目標服務器，當目標服務器處理完畢以后，將處理結果返回給Load Balancer，由Load Balancer修改源地址，返回給客戶端。

         IP Tunneling：IP管道技術是在IP報文上再次封裝IP報文協議的一種技術。允許將一個目標為A的IP數據報文封裝成為目標為B的IP數據報文，在特定的IP 管道中傳輸。

         上圖就是IP Tunneling模式的運作原理。首先客戶端還是通過訪問對外的一個服務IP請求服務，當Load Balancer接受到請求以后，檢查VIP注冊信息，然后根據算法選擇實際的一臺后臺服務器，通過IP管道封裝技術對IP報文再次封裝，然后將消息通過IP管道轉發到實際的服務器，實際的服務器通過解包處理請求，然后根據包體內實際的服務請求地址，將處理結果直接返回給客戶端。

         Direct routing：利用Load Balancer和實際服務器共享同一VIP，簡單的通過修改消息報體目標MAC地址，轉發請求，然后再通過實際服務器配置VIP為本地回環，直接處理消息報文，而不再轉發，當處理完以后，直接將處理結果返回給客戶端。

         上圖就是Direct Routing的運作流程，當外部請求到Load Balancer時，通過查找VIP注冊信息，直接選擇一臺后端服務器作為新的目標地址，修改消息報文中的目標地址Mac地址，轉發到目標服務器，目標服務器由于配置VIP在本地網卡回路中，因此直接處理消息，將處理完的結果直接返回給客戶端。

Virtual Server三種模式的比較

         下表是官方整理出的關于Virtual Server三種不同模式的區別：

	NAT	TUNNEL	DR
服務器要求	無要求	需要支持IP管道	無 arp組件（當前也有補?。?/span>
網絡要求	Private	LAN/WAN	LAN
可支持后端服務器節點數	較少（10-20）	較多	較多
服務網關	Load Balancer	本身	本身

NAT：根據其實現原理，可以知道這種模式對于操作系統，網絡都沒有太多的要求和約束，但是由于消息需要打解包，同時消息的響應都必須經過Load Balancer，因此Load Balancer自身成為了瓶頸，這樣一個Load Balancer能夠支持的后端服務節點數量就有限了。當然可以采用混合模式來解決這個問題，也就是通過TUNNEL或者DR模式作為前端模式串聯起多個NAT模式Balancer。

TUNNEL：這種模式要求操作系統支持IP Tunnel，通過對IP報文再次封裝轉發，達到負載均衡的目的。設計這種模式的初衷是考慮，對于互聯網很多服務來說，服務請求數據量和返回數據量是不對稱的，返回的數據往往要遠遠大于請求的數據量，因此如果請求和返回都走Load Balancer會大量占用帶寬，影響處理能力。IP Tunnel設計中請求是通過Load Balancer，但是返回是直接返回到客戶端的，因此節省了返回的帶寬，提高了請求處理的能力。

DR：這種模式要求Load Balancer和后端服務器處于同一個局域網段。DR模式處理消耗最小，消息轉發和回復基本沒有損耗，因此效率應該是最高的，但是約束是相對來說最多的。

    小A，30，所在公司在去年的經濟危機中沒有倒下，但是在今年卻倒下了。小A覺得能夠把一個公司混倒閉了，也算是人生的一點經歷。

    公司是沒了，但是工作還要繼續，生活還要繼續，現在將要面對一個新的環境，環境很陌生，但也比較熟悉，工作職責很清晰，但也充滿了挑戰。人過30，有了孩子，真的成熟了很多，知道了什么叫做責任感，知道了未來真的需要好好規劃，需要一個機會，需要一個平臺來找到自己，實現自己的價值，不讓這黃金時代就這么過去。

   小A將要面對的挑戰在心里面已經做好了準備，也有了自己的一套短期的規劃及工作安排，要成長有時候就要有壓力。在小A即將離開原來團隊的時候，和手下的一個同學發了火，因為在這陣子調整過程中，同學的心態一直變的很差，但是小A已經竭盡全力去分析他的未來，雖然聽進去，但是過幾天依然又開始放棄自己，這種態度讓小A原本很看好他發展的心情變得很沉重，最后就在那個探討會上說了他一些比較重的話，雖然說完以后自己也有些后悔，可能我對他和對我自己一樣，要求太高了吧，就像博士說的，如果對一個人沒有想法了，就恭維幾句即可，大家你好我好大家好，只有當對這個人還存在一定的期望的時候才會表現出這種比較急切的感覺。

   新的開始，新的挑戰，新的環境，新的機遇，新的難題，新的稱呼

   好的心態，好的溝通，好的未來

   一切都需要小A用自己的能力去證明，走自己的路，讓自己走的更好。