放翁（文初）的一畝三分地

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

優(yōu)化雜談

Author :放翁

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

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

CPU利用率和Load

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

NIO在客戶端的使用

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

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

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

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

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

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

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

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

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

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

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

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

單線程和多線程

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

1． 資源競爭，復(fù)雜度增加。

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

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

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

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

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

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

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

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

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

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

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

   問題：

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

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

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

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

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

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

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

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

   針對他提出的三個問題：

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

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

當(dāng)前問題:

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

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

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

處理方式：

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

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

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

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

具體實現(xiàn)：

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

         一共有三個組件角色：

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

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

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

壓力測試結(jié)果：

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

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

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

錯誤請求場景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.       對產(chǎn)品化和客戶沒有任何感覺。

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

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

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

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

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

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

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

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

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