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

         淘寶越來越大，公司內部有很多部門和子公司，之間最有效的合作方式就是通過TOP平臺低耦合的集成淘寶基礎服務能力。同時，如何將淘寶的能力和電子商務的能力滲透到傳統行業的方方面面，如何結合各種終端來展現給不同層次的用戶，都需要將服務以不同的方式集成到已有的形態各異的系統或終端中。但到發展到今天的情況來看，在普通開發者這塊的成長是低于預期的，這類應用現在創新力度很低，大部分人都開發收益較快，投入較少，開發維護成本較低的淘客類應用。國內的開發者真的需要多學習國外的一些Mashup的創新精神（也許是國外的API資源豐富），淘客類應用，賣家工具，其實這些應用飽和程度十分高，同質競爭激烈，最后能夠給開發者帶來的收益當然也很低。

系統透明化

         今年我們團隊的定位是服務化團隊，我們需要去探索新的模式，關注新的技術發展，但是最根本的是要做好當前，服務好我們的客戶，系統透明化就是服務化團隊的基礎。系統透明化的作用是什么，拿過去賣跌打膏的一句常說的話：“有病治病，無病防身”（沒有問題的時候知道可能那些地方已經處于非正常狀態或者可以找到一些瓶頸所在，在出了問題，可以迅速防止問題擴大，高效的解決問題）。對于開放平臺來說，服務可用性和服務效率其實是最更本的非業務性需求，當一次請求2-3秒才會返回，請求10次有4次是不通的，那么后面的服務就算再吸引人，都很難讓開發者做出吸引用戶的應用。說一下我在做這塊的幾點收獲：

1.       數據為王。最初透明化的工作就是分析每天的訪問日志記錄，得到系統數據統計報表和業務數據統計報表。通過系統數據統計報表的結果來找到系統的瓶頸，通過業務數據報表來指導業務規劃。例如分析整個服務安全校驗和路由過程，最消耗時間的就在服務請求解析上，因此就考慮如何去減少服務解析帶來的系統消耗：Lazy Parser通過采用流的方式分段解析參數，當發現系統參數校驗失敗時將不再繼續分析整個Http包，減少在錯誤情況下由于載入全部數據帶來的損耗。同時參看Jetty的Continuation的設計，學習在基于事件模式下，如何最小化連接資源分配（復用資源，帶來的問題就是復雜度增加）。另一方面，發現淘客類應用對于服務的請求會反復調用多個接口來拼裝成為一個完整信息，因此優化了淘客類服務，使得應用大幅度減少訪問請求，減少無謂的系統壓力，提高外部應用的效率。簡單來說，啥都需要數據說話，最怕今天跑過來和我說我們要重構和優化了，但是又無法說出為什么這就是我們的瓶頸，優化完有啥指標可以證明有效。只有在系統透明化以后，數據能夠說明一切。優化需要從全局去看，而不是局部，并行處理提高了非關鍵路徑的性能，沒有什么太大的意義。

2.       按需設計，抽象分層。在最初的時候，透明化的目標通過一個單機版的報表分析器就可以完成。（一天6千萬條的訪問日志，3個多G的文件，系統報表3-4張，業務報表5-6張），逐漸數據量不斷膨脹（一天5億左右的訪問日志，8-90個G的數據文件，系統報表和業務報表常規就有20張，還有不少零時的需求提出），因此演變成為一個多機版的報表分析器，與此同時，每日一次的分析不能滿足對于業務系統即時的監控和告警，因此多機版的報表分析器，支持非靜態文本數據源的方式，Slave不斷主動從應用服務器端增量獲取日志數據，演變成為一個即時分析系統。

但整體結構如下：

                                               

           整個體系的演進只影響到任務管理組件和數據傳輸組件。在單機版的時候，數據傳輸組件不存在，都是多線程之間的任務分配和數據合并。多機版就是增加了數據傳輸組件，業務性統計規則引擎都采用已有的抽象設計。即時分析系統則在任務管理組件上擴展了數據源獲取的方式。

           首先我并沒有直接去考慮多機版的實現，因為我的設計可以滿足當前的需求：靈活（基于配置在運行期創建規則分析各種弱數據類型的日志），高效（任務切分，多線程并行計算分析）。最重要的是在短時間內給出了一個可用的版本，解決了當務之急。（很多時候就是要權衡時間和設計，不斷的迭代產出階段性成果，才能夠降低風險，不斷提升成熟度，通過反饋指導設計的方向）。其次，整個演進過程中，業務抽象設計部分一直保持較為穩定的狀態，將底層的任務管理和傳輸不斷的根據需求去擴展和優化。（這其實就是要求在設計上有分層的思想，業務領域的設計需要與非業務性需求分開考慮，便于擴展，同時降低不同層次的耦合度，增加未來多系統復用的可能性），下圖是當前即時分析的一個簡單的部署圖：

                                               

Master的工作很簡單，就列出的4步。Slave是一個純粹的“勞動者”，根據Master給的任務去執行分析。（任務中包括了資源的來源描述，可能是靜態文件系統（ftp，分布式文件系統）等，也可能是一些應用服務器。任務中也包括了分析規則引擎數據）

客戶第一

         今天在業務統計分析中，淘客應用占有的比例很高。為什么？開放平臺需要讓開發者“簡單的賺錢”。“簡單的賺錢”，兩個詞說明一切，投入少，回報高，站在開發者角度多考慮一些問題才能夠指導ISV去開發出更多更有價值的應用。當前通過API來開發應用成本較高，同時周期也較長，因此針對這些問題，TOP平臺有在業務創新上的一系列規劃，降低應用開發者開發和維護成本，讓開發者更多關注在業務創新上，而不是基礎服務的使用上。如下圖：

                            

         從服務的使用者和服務的提供者兩方面去提升用戶體驗，在某些時候工具類或者輔助類的服務并不僅僅是錦上添花，它可能成為產品化成敗的關鍵點。（細節決定成敗，老生常談），但是實際中需要去了解和體會用戶的需求，一來自己就去用API開發，二來從業務分析數據上來分析不同用戶群的行為和趨勢。

平臺要死，哪里會是致命的一擊

         幾周以前，整個TOP的技術和業務團隊的部分同學在西溪濕地開了一個會議。目的是讓大家說出自己工作中的問題和難處，同時為將來的TOP發展明確方向。其中提到了整個阿里巴巴和淘寶都會找自己失敗的問題所在，因為只有你自己知道了自己在什么情況下會失敗，才會去改進自己的不足，避免走到無可挽回的地步。

         TOP如果要死，那么什么是它的致命一擊？對我來說，如果每個人心里少了產品化的理念，那么TOP就會失敗。產品化意味著什么，對研發人員來說，意味著你每一個技術實現都需要清楚的理解它背后的商業需求和客戶需求，在PD和運營同學提出想法的時候需要從一個客戶的角度多考慮易用性，擴展性。（簡單來說，不要做一個“死”寫代碼的，做個臨時演員都要有職業素養，做一個程序員更要有程序員的“修養”）對于一個PD來說，需要協同技術團隊做好產品規劃，用數據來指導產品設計，用技術提升用戶體驗。（簡單來說，除了多說，更要多聽多看，開發團隊也有很多同學對商業和產品有自己獨到的見解）。對于運營團隊來說，要將用戶的聲音“過濾”并“轉化”，讓開發和PD能夠收取到更多有用的信息。

         因此，TOP要死，前提是在每個人心里面“TOP”已死，我記得鳳先同學一直說一句話：“每個人心中都有一個TOP。”當大家心中的“TOP”不死，產品化思想不死，那么TOP就總會有希望，因為TOP就是我們這么一群人不斷奮斗的目標。

太累了，搞完代碼再寫blog，很多東西可以寫，不過實在吃不消……，有興趣想了解細節的同學可以直接和我聯系。