如何將異步+業(yè)務(wù)權(quán)重線程池運(yùn)用到更多的對(duì)第三方系統(tǒng)有依賴，同時(shí)又能夠切換多種服務(wù)提供者的系統(tǒng)中，需要更好優(yōu)化異步帶來的性能消耗，同時(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)求帶來的服務(wù)器消耗是無法接受的，因此采用服務(wù)廣播+http長(zhǎng)連是提高效率節(jié)約成本的一種方式，而jetty容器采用Continuation可以實(shí)現(xiàn)類似的功能。但面臨的問題是并發(fā)連接數(shù)大小，斷連策略，消息推送對(duì)客戶端的要求。

　　數(shù)據(jù)處理：

　　1. 統(tǒng)計(jì)(歷史數(shù)據(jù)保存)

　　每天當(dāng)前有將近150G的基礎(chǔ)訪問數(shù)據(jù)(服務(wù)訪問，授權(quán))，如果將詳細(xì)數(shù)據(jù)記錄下來，應(yīng)該會(huì)達(dá)到250G，而且這個(gè)量還在不斷地增長(zhǎng)。當(dāng)前已經(jīng)做的：每天保留日志分布在各個(gè)應(yīng)用服務(wù)器上，交由分布式分析集群來拖取并分析，后將結(jié)果存儲(chǔ)，而日志則會(huì)在幾日內(nèi)刪除。

　　問題：統(tǒng)計(jì)規(guī)則通過配置即刻生效，但對(duì)于歷史數(shù)據(jù)的再次統(tǒng)計(jì)無法做，同時(shí)由于歷史數(shù)據(jù)保留時(shí)間不久，因此可能導(dǎo)致后續(xù)無法再為數(shù)據(jù)作分析。需要保存歷史數(shù)據(jù)，考慮通過Hadoop的HDFS來保存。

　　2. 問題排查(隱私問題)

　　每天海量的數(shù)據(jù)中，定位某一個(gè)應(yīng)用可能操作了某一個(gè)用戶的信息變得十分困難，當(dāng)前通過日志的初步分析和grep。但由于日志的保留時(shí)間不久，加上基于用戶統(tǒng)計(jì)的數(shù)據(jù)結(jié)果會(huì)很龐大，因此只能針對(duì)部分用戶和部分應(yīng)用作統(tǒng)計(jì)和跟蹤，為問題排查增加了難度。

　　考慮：

　　1. 通過應(yīng)用，用戶，服務(wù)，對(duì)象ID(比如商品ID)來制作指紋，后續(xù)為比對(duì)留下簡(jiǎn)單的證據(jù)。

　　2. 采用HBase，正好利用Rowkey， family，column三個(gè)維度來標(biāo)識(shí)user，app，api及請(qǐng)求信息，便于檢索和日后的統(tǒng)計(jì)分析。其實(shí)也利用了上面說的歷史日志保存。(因?yàn)镠Base是基于Hadoop HDFS)

　　3. 業(yè)務(wù)需求(授權(quán)，黑名單規(guī)則)

　　當(dāng)前授權(quán)每天的數(shù)量已經(jīng)突破了幾千萬(wàn)，而且隨著淘寶業(yè)務(wù)的全面開放，授權(quán)和TOPID將會(huì)迎來更大的壓力。如何為用戶和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ì)大幅增加，加之未來其他平臺(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í)的分析出來(2分鐘一輪)，但往往在出現(xiàn)問題的時(shí)候，透明化的數(shù)據(jù)給出了各種告警，如何結(jié)合告警及歷史數(shù)據(jù)給出有力的問題定位，甚至做到部分自動(dòng)決策，也成為一種挑戰(zhàn)，挑戰(zhàn)對(duì)歷史數(shù)據(jù)的計(jì)算，挑戰(zhàn)對(duì)多種問題的關(guān)聯(lián)配置。例如，突然整個(gè)平臺(tái)的錯(cuò)誤率提升了1%，同時(shí)很多應(yīng)用的錯(cuò)誤率也提高了，此時(shí)如果某一個(gè)服務(wù)的錯(cuò)誤率提高的話，那么意味著這個(gè)服務(wù)可能成為問題的源頭。但如果只有一個(gè)或者幾個(gè)應(yīng)用出現(xiàn)了問題，而服務(wù)的錯(cuò)誤率并沒有太突出，可能是應(yīng)用出問題了。等等等等~~~

　　5. 松散Master-Slave任務(wù)分治框架抽象(ISV應(yīng)用監(jiān)控，日志分析)

　　當(dāng)前開放平臺(tái)分析日志采用松散模式的分布式任務(wù)分治框架，但由于將MapReduce的處理過多的融入到了分布式分治框架中，導(dǎo)致現(xiàn)在ISV應(yīng)用監(jiān)控集群在復(fù)用框架的時(shí)候不能很好地?cái)U(kuò)展，只能部分重用底層通信及部分的交互協(xié)議，因此了將來大量的分治協(xié)作處理場(chǎng)景，需要抽象出與任務(wù)處理不相關(guān)的框架，同時(shí)支持任務(wù)來源及工作者處理結(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ì)安全有較為深入的同事參與完成。