淘寶構建開放平臺的技術歷程(3)

　　但這擔子放下了，那擔子又挑上了，在上面談到去年后臺應用不穩定導致平臺整體不穩定的問題在輕量化以后出現的頻率和次數更多了，因為發布和維護都落到了后臺部門，此時對于各個系統的把控就更弱了，這晚上睡覺不安穩，KPI中的穩定性指標基本就沒法定了。唯一能夠徹底解決問題的辦法就是http服務異步化+ 事件驅動+虛擬隔離線程池。那年年中的時候對Jetty7做了一次壓測，發現Continuations的效果已經可以上正式環境了，于是開始在 Jetty7的基礎上做Http服務異步化+事件驅動的封裝，同時也實現了一個虛擬隔離線程池做配合。具體設計細節這里就不多說了，參看blog，簡單描述原理就是：1.將前端容器線程和業務處理隔離。(類似NIO和BIO的設計差異)2.業務處理如果依賴于外部系統則采用事件驅動的方式來減少線程等待，同時提高線程占用資源的利用率。(這點上來說理想和現實還是有很多細節差異的，在實現的時候必須根據依賴系統消耗時間占總時間的比例看是否需要事件驅動，事件驅動帶來的切換消耗是比較大的)3.通過一個大的線程池虛擬設置不同業務可消耗的最大資源數，來充分的共享資源在異常情況下限制業務占用過多資源(任務處理開始排隊而非無度的占用資源)。這個組件上線以后，沒過幾天就發生了一個典型的案例，一個業務2點開始響應時間從10ms上升到了40ms，然后繼續上升到200ms，當時給這個業務模擬設置最大的線程資源數是20個，就發現那時候由于RT時間提升，線程資源釋放的慢，20個慢慢的被消耗到頂了，此時這個業務的隊列開始從0到100到200到…(當然防止內存過多占用，會丟棄超過隊列長度的業務處理)，而其他業務還是正常的使用著資源，平臺平穩，到了4點多，業務方收到告警修復以后，RT時間下降到了10ms，隊列中的請求數量開始減少，最后隊列清空，線程資源占用下降到正常水平。從此以后震子同學開心的和我說：開放平臺穩定性的KPI可以隨便大膽的寫幾個9了。(技術敢做敢想，才能高枕無憂)

　　11年：市場化。這一年到年底，平臺開放淘寶服務758個，每天調用量19億，這一年SNS熱潮消退，游戲逐漸淡出，賣家市場依舊生意火爆(很多TP的年收益讓人咂舌)，營銷工具嶄露頭角成為開發者新寵，淘寶客成為了開放新寵(這一年返利網和團購一樣火，只是前者收錢，后者燒錢)。

　　就在開放平臺開發者前景一片大好的時候，出現了一個讓開放轉變和收縮的導火索，一家做營銷工具的公司“團購寶”，每天凌晨都會通過接口同步客戶設置的一些優惠商品信息到淘寶網，結果那天凌晨，微博上突然很多人說某些店都是一塊錢的便宜貨，要知道這種事情在微博盛行的時代，傳播速度之快，影響之大，當即很多賣家商品都被1塊錢拍下。最后發現是線下的商品價格不知道怎么全被修改成1塊錢，然后凌晨一同步，就導致出現了上面的一幕。從那時候開始，開放平臺的 KPI中增加了一個重中之重：安全，包括后面的很多技術產品都是圍繞安全展開。此時第一個被波及提升能力的系統就是流式分析集群，20分鐘一輪的數據分析要求壓縮到3分鐘，同時數據量已經從8億每天增長到了19億每天，化了2個月時間斷斷續續的優化集群結構設計和單機處理能力，里面經歷的內容有一天我翻 Hadoop的優化過程時看到了相似的場景，具體就不在這里贅述，詳細內容依然去挖blog。簡單來說：1.充分利用多核能力用計算換內存。2.磁盤換內存，用并行設計來保證整體業務時間消耗不變甚至減少。3. Slave shuffle來減少Mater的合并壓力。4.數據壓縮減少數據傳輸消耗和內存占用。…

　　另一方面，由于10年對于jetty7的充分理解和封裝，此時看到了又一個新技術的契機，10年的時候去美國參加Javaone，當時看到有老外用 Jetty7的特性來實現Comet功能，Comet原先主要用于CS結構的應用搬到互聯網上，因為不能用TCP的長連接，所以不得不用Http的長連接來替代原來的模式，同時國外開放平臺也關注很多新型的API設計，其中就有Twitter的Streaming api，這種通過http長連接方式推送消息到外部isv的模式引起了我們的注意。因此我們決定將Jetty7上的封裝近一步升級，支持Comet長連接方式，后端通過事件驅動的模式主動推送內部消息給外部，避免外部輪詢業務接口。這個設計的最重要點就是如何用最有效最少的線程來守護多個長連接，支持到后端事件驅動的數據下行，如果給每一個長連接支持一個數據推送守護線程，自然即時性最高，但代價就是眾多空置連接的守護線程消耗，預知細節挖blog。這種模式剛出來的時候，從上到下都是質疑聲，覺得太不符合常規做法了，常規做法就是pull，認為開發和無法接受，認為穩定性一定不靠譜。經過2011年的雙十一，當天幾個“嘗鮮”的開發者一臺PC就支持幾百萬的訂單高速處理，就讓很多人明白了，技術要敢想，代碼要敢寫，細節要敢專，沒什么不可能。也就從這以后，多樣化服務TQL，Schedule API，ATS從開放平臺的土壤上都長了出來，為更多的場景，更多的終端，提供了各種解決方案和創新實現。

　　12年：垂直化。這一年到現在，平臺開放淘寶服務900多個，每天調用量25億，這一年淘寶客由于公司方向轉變熱潮消退，無線乘勢而起，新業務(機彩票，酒店，理財等)，P4P，數據類服務都開始運營API，開放平臺開發者的客戶群體也從C店賣家增加到了B的品牌商，渠道商等。

　　這是一個業務多變的一年，這也是淘寶內部對開放平臺認可的新階段。第一個階段是放任不管，開放平臺部門自己要開什么，封裝什么。第二階段是開放什么業務方負責支持開放，但開放后的結果概不了解，也無所謂了解。第三階段就是業務主動要開放，開放后開始運營服務，培養isv市場，帶動業務的正向發展。

　　這一年由于業務量的增長以及分析需求到用戶緯度，因此在11年底啟動了流式分析集群重構升級的項目，將新的分析集群項目命名為beatles，希望他能夠象甲殼蟲一樣，小蟲吃樹葉，再多都吃的下。11年底到12年初，用了近2個半月的時間做了一次完整的重構，將那么多年的補丁經驗和老代碼重新設計和實現，并且將Mater根據業務可垂直切分，最終解決Master歸并壓力的問題，當然期間的技術優化點也不少，因為我們的目標從3分鐘壓縮到了1分鐘，而我們的數據量翻番，統計緯度細化到了用戶緯度。(意味著結果也會很大，不靠文件做中轉如何來實現需要更多的分拆和協同設計)

　　這一年起了兩個比較創新的項目：JS SDK和無線SDK(IOS，安卓)，這兩個SDK的出現一定程度上由業務和安全兩方面決定。首先11年年底啟動了社區電子商務化的項目，也就是現在所說的輕電商(XTao)項目，將更多的網站和淘寶銜接起來，此時網站間的融合就要求更輕便和簡易，最成功的案例就是Facebook，于是年初的時候，拿這 FB的JS SDK一陣看，就開始動手寫了，期間很高興拉了UED同學入伙，這才使得這個JS SDK變的更加靠譜，更加專業。(前端這活誰都可以玩，但要玩好最終還是要對那一系列苦逼的瀏覽器兼容有所深入理解，現在想想自己當時還是有點無知者無謂的)。同時有了JS SDK，買家類的服務安全性有所保證，因為原先的REST調用在授權以后是無法知道是否是用戶發起的還是服務器發起的，而JS SDK一定程度上還要校驗Cookie的有效性，可以部分的保證用戶的在場知情。而下半年的無線SDK，就是間或的苦讀1個月的各種文檔，然后就開始動手玩了，由于對Java語言，動態語言，腳本語言都有比較多的使用，因此Obj-c上手并不是那么困難，同時沒有涉及到過多的MVC的內容，做SDK基礎層的東西還是比較得心應手，就這樣IOS的無線SDK版本就出來了，此時在開放平臺的技術團隊內部正在執行一個叫做Hack project的活動，其中一個自主項目就是安卓的SDK，因此一個月后，安卓的SDK順利的誕生了。這兩個無線SDK所擔負的職責就是把控無線安全問題，不僅淘寶，業界其實很多公司都還沒理解無線開放的風險到底有多大，OAuth2基本就無法保證無線的用戶安全，因此如何在SDK和服務端融入更高級別的安全設計，成為了無線SDK誕生的第一個重要需求。

原文轉自：http://www.kjueaiud.com