經(jīng)歷了近三年的平臺(tái)發(fā)展，隨著業(yè)務(wù)量跳躍增長(zhǎng)和開放尺度的不斷加大，問(wèn)題隨之而來(lái)，開放平臺(tái)技術(shù)問(wèn)題這個(gè)小短篇就是想擺出問(wèn)題，有些東西已經(jīng)起步，有些東西還是空白，有些東西做的粗糙，有些東西還處于想想。希望有類似問(wèn)題的，有業(yè)余時(shí)間摻和的，有興趣加入一起搞的，歡迎隨時(shí)mail：fangweng@taobao.com 。開放平臺(tái)內(nèi)部將會(huì)有少量人各自負(fù)責(zé)一些內(nèi)容作為專題來(lái)做精做足。開放平臺(tái)團(tuán)隊(duì)的優(yōu)勢(shì)是有業(yè)務(wù)試驗(yàn)田（每天10多億的調(diào)用而且正在翻翻），劣勢(shì)就是時(shí)間要自己擠（不論你是業(yè)余還是團(tuán)隊(duì)內(nèi)），我們有業(yè)務(wù)的壓力和其他創(chuàng)新的需求，而提出的這些技術(shù)問(wèn)題當(dāng)前是從系統(tǒng)技術(shù)角度談的，業(yè)務(wù)上的難點(diǎn)就不提在這里了，廢話不多說(shuō)。
Web容器：
省，快，穩(wěn)，新
1． 每天10億次的服務(wù)調(diào)用，如果能夠在讀取所有數(shù)據(jù)前就攔截掉一些系統(tǒng)或業(yè)務(wù)校驗(yàn)不通過(guò)錯(cuò)誤請(qǐng)求，那么節(jié)省的上行帶寬和連接資源就是一筆不小的財(cái)富。這僅僅只是省的一種方式，當(dāng)前我們做了streaming Lazyparser。如何省的更多，還待在容器上做更多文章。
2． 測(cè)試過(guò)Jetty，tomcat，jbossweb3，最終選擇了Jetty，不是因?yàn)?/span>jetty最快，而是在類似于Servlet3的Continuation特性下我們妥協(xié)了部分性能的損失。但Jetty的底層卻有很大的機(jī)會(huì)去提升（特別是Jetty的框架可植入，給了我們很大的靈活性，Jetty的整體事件驅(qū)動(dòng)模型是做的很不錯(cuò)的），所以如何讓容器更快，需要我們做更多的事。
3． 先看看下面的圖：
這是開放平臺(tái)后端的服務(wù)其中一部分處理時(shí)間統(tǒng)計(jì)，有快有慢，同時(shí)這些系統(tǒng)的容量規(guī)劃，發(fā)布時(shí)間和服務(wù)質(zhì)量都參差不齊，但開放平臺(tái)就是一個(gè)對(duì)外的門戶，由于Http請(qǐng)求的同步性+容器管理線程生命周期，使得隔離單個(gè)服務(wù)不可用波及平臺(tái)，最終導(dǎo)致后端服務(wù)都無(wú)法被訪問(wèn)，需要改變傳統(tǒng)容器的請(qǐng)求處理方式。（假如A服務(wù)出現(xiàn)問(wèn)題，同時(shí)3秒鐘為服務(wù)調(diào)用超時(shí)時(shí)間，如果一個(gè)應(yīng)用服務(wù)器最大500個(gè)容器線程，那么單機(jī)最差情況1秒就只能處理500/3個(gè)請(qǐng)求，這意味正常的后段服務(wù)由于得不到路由中轉(zhuǎn)也被外部認(rèn)為不可用），因此采用Jetty的Continuation模式，可以將容器線程池獨(dú)立出來(lái)處理連接，而業(yè)務(wù)處理交由后端業(yè)務(wù)線程池處理，而業(yè)務(wù)線程池可以根據(jù)業(yè)務(wù)優(yōu)先級(jí)設(shè)定一些預(yù)留和限制模型，即共享線程池，又限制線程池被獨(dú)占。當(dāng)前我們做了：異步模型封裝+業(yè)務(wù)管道化+業(yè)務(wù)權(quán)重線程池，看下圖：（開放平臺(tái)的控制臺(tái)中權(quán)重線程池監(jiān)控和設(shè)置）
如何將異步+業(yè)務(wù)權(quán)重線程池運(yùn)用到更多的對(duì)第三方系統(tǒng)有依賴，同時(shí)又能夠切換多種服務(wù)提供者的系統(tǒng)中，需要更好優(yōu)化異步帶來(lái)的性能消耗，同時(shí)增加權(quán)重線程池共享和限制算法，最大限度挖掘潛力。
4． 從去年JavaOne的C/S模式遷移到B/S上提到的Comet，到今年的Html5的推廣，在開放平臺(tái)容器的職責(zé)上也多了一條Streaming api或者叫做Notify api，內(nèi)部系統(tǒng)的狀態(tài)變化或者消息更新需要通知外部系統(tǒng)，傳統(tǒng)的通知者作為Client模式http請(qǐng)求帶來(lái)的服務(wù)器消耗是無(wú)法接受的，因此采用服務(wù)廣播+http長(zhǎng)連是提高效率節(jié)約成本的一種方式，而jetty容器采用Continuation可以實(shí)現(xiàn)類似的功能。但面臨的問(wèn)題就是并發(fā)連接數(shù)大小，斷連策略，消息推送對(duì)客戶端的要求。
數(shù)據(jù)處理：
1． 統(tǒng)計(jì)（歷史數(shù)據(jù)保存）
每天當(dāng)前有將近150G的基礎(chǔ)訪問(wèn)數(shù)據(jù)（服務(wù)訪問(wèn)，授權(quán)），如果將詳細(xì)數(shù)據(jù)記錄下來(lái)，應(yīng)該會(huì)達(dá)到250G一天，而且這個(gè)量還在不斷地增長(zhǎng)。當(dāng)前已經(jīng)做的：每天保留日志分布在各個(gè)應(yīng)用服務(wù)器上，交由分布式分析集群來(lái)拖取并分析，最后將結(jié)果存儲(chǔ)，而日志則會(huì)在幾日內(nèi)刪除。
問(wèn)題：統(tǒng)計(jì)規(guī)則通過(guò)配置即刻生效，但對(duì)于歷史數(shù)據(jù)的再次統(tǒng)計(jì)無(wú)法做，同時(shí)由于歷史數(shù)據(jù)保留時(shí)間不久，因此可能導(dǎo)致后續(xù)無(wú)法再為數(shù)據(jù)作分析。需要保存歷史數(shù)據(jù)，考慮通過(guò)Hadoop的HDFS來(lái)保存。
2． 問(wèn)題排查（隱私問(wèn)題）
每天海量的數(shù)據(jù)中，定位某一個(gè)應(yīng)用可能操作了某一個(gè)用戶的信息變得十分困難，當(dāng)前通過(guò)日志的初步分析和grep。但由于日志的保留時(shí)間不久，加上基于用戶統(tǒng)計(jì)的數(shù)據(jù)結(jié)果會(huì)很龐大，因此只能針對(duì)部分用戶和部分應(yīng)用作統(tǒng)計(jì)和跟蹤，為問(wèn)題排查增加了難度。
考慮：
1. 通過(guò)應(yīng)用，用戶，服務(wù)，對(duì)象ID（比如商品ID）來(lái)制作指紋，后續(xù)為比對(duì)留下簡(jiǎn)單的證據(jù)。
2. 采用HBase，正好利用Rowkey， family，column三個(gè)維度來(lái)標(biāo)識(shí)user，app，api及請(qǐng)求信息，便于檢索和日后的統(tǒng)計(jì)分析。其實(shí)也利用了上面說(shuō)的歷史日志保存。（因?yàn)?/span>HBase就是基于Hadoop HDFS）
3． 業(yè)務(wù)需求（授權(quán)，黑名單規(guī)則）
當(dāng)前授權(quán)每天的數(shù)量已經(jīng)突破了幾千萬(wàn)，而且隨著淘寶業(yè)務(wù)的全面開放，授權(quán)和TOPID將會(huì)迎來(lái)更大的壓力。如何為用戶和ISV提供授權(quán)的查看，綁定，解綁，延長(zhǎng)成為在海量請(qǐng)求下的最大挑戰(zhàn)。當(dāng)前所做的除了簡(jiǎn)單的分庫(kù)分表以外，在緩存與數(shù)據(jù)庫(kù)的同步策略也作了一些折中。但授權(quán)是開放的第一道門，如何做好容災(zāi)及降級(jí)，不影響服務(wù)使用會(huì)成為最大的挑戰(zhàn)。
黑名單規(guī)則當(dāng)前粒度最小在應(yīng)用+服務(wù)，但其實(shí)很多時(shí)候需要細(xì)粒度到用戶，此時(shí)的頻率控制計(jì)數(shù)器的數(shù)量，黑名單的數(shù)量都會(huì)大幅增加，加之未來(lái)其他平臺(tái)對(duì)接時(shí)對(duì)于控制需求的定制增加，運(yùn)營(yíng)活動(dòng)對(duì)短期個(gè)性化規(guī)則限制的增加，會(huì)導(dǎo)致黑名單規(guī)則更為復(fù)雜，數(shù)量更加龐大，如何靈活定制規(guī)則及支撐海量計(jì)數(shù)和黑名單成為挑戰(zhàn)。
4． 多維度告警分析決策
今天開放平臺(tái)很多數(shù)據(jù)都即時(shí)的分析出來(lái)（2分鐘一輪），但往往在出現(xiàn)問(wèn)題的時(shí)候，透明化的數(shù)據(jù)給出了各種告警，如何結(jié)合告警及歷史數(shù)據(jù)給出有力的問(wèn)題定位，甚至做到部分自動(dòng)決策，也成為一種挑戰(zhàn)，挑戰(zhàn)對(duì)歷史數(shù)據(jù)的計(jì)算，挑戰(zhàn)對(duì)多種問(wèn)題的關(guān)聯(lián)配置。例如，突然整個(gè)平臺(tái)的錯(cuò)誤率提升了1%，同時(shí)很多應(yīng)用的錯(cuò)誤率也提高了，此時(shí)如果某一個(gè)服務(wù)的錯(cuò)誤率提高的話，那么意味著這個(gè)服務(wù)可能成為問(wèn)題的源頭。但如果只有一個(gè)或者幾個(gè)應(yīng)用出現(xiàn)了問(wèn)題，而服務(wù)的錯(cuò)誤率并沒(méi)有太突出，可能就是應(yīng)用出問(wèn)題了。等等等等~~~
5． 松散Master-Slave任務(wù)分治框架抽象（ISV應(yīng)用監(jiān)控，日志分析）
當(dāng)前開放平臺(tái)分析日志采用松散模式的分布式任務(wù)分治框架，但由于將MapReduce的處理過(guò)多的融入到了分布式分治框架中，導(dǎo)致現(xiàn)在ISV應(yīng)用監(jiān)控集群在復(fù)用框架的時(shí)候不能很好地?cái)U(kuò)展，只能部分重用底層通信及部分的交互協(xié)議，因此了將來(lái)大量的分治協(xié)作處理場(chǎng)景，需要抽象出與任務(wù)處理不相關(guān)的框架，同時(shí)支持任務(wù)來(lái)源及工作者處理結(jié)果模式（也許本地就完成存儲(chǔ)，而不是到Master Reduce），同時(shí)自身的容災(zāi)及穩(wěn)定性和任務(wù)分配算法需要有更多的優(yōu)化和措施。
安全：
網(wǎng)站應(yīng)用和桌面應(yīng)用安全掃描
對(duì)網(wǎng)站應(yīng)用的回調(diào)地址做釣魚掃描及對(duì)桌面應(yīng)用作二進(jìn)制掃描，是開放平臺(tái)對(duì)應(yīng)用安全性的最基本的要求，但是實(shí)施難度很大。需要有對(duì)安全有較為深入的同事參與完成。
今天就先寫到這里，更多的內(nèi)容期待你的參與和挖掘。希望有類似問(wèn)題的，有業(yè)余時(shí)間摻和的，有興趣加入一起搞的，歡迎隨時(shí)mail：fangweng@taobao.com。