如何將異步+業(yè)務(wù)權(quán)重線程池運用到更多的對第三方系統(tǒng)有依賴，同時又能夠切換多種服務(wù)提供者的系統(tǒng)中，需要更好優(yōu)化異步帶來的性能消耗，同時增加權(quán)重線程池共享和限制算法，大限度挖掘潛力。

　　4. 從去年JavaOne的C/S模式遷移到B/S上提到的Comet，到今年的Html5的推廣，在開放平臺容器的職責(zé)上也多了一條Streaming api或者叫做Notify api，內(nèi)部系統(tǒng)的狀態(tài)變化或者消息更新需要通知外部系統(tǒng)，傳統(tǒng)的通知者作為Client模式http請求帶來的服務(wù)器消耗是無法接受的，因此采用服務(wù)廣播+http長連是提高效率節(jié)約成本的一種方式，而jetty容器采用Continuation可以實現(xiàn)類似的功能。但面臨的問題是并發(fā)連接數(shù)大小，斷連策略，消息推送對客戶端的要求。

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

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

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

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

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

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

　　考慮：

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

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

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

　　當(dāng)前授權(quán)每天的數(shù)量已經(jīng)突破了幾千萬，而且隨著淘寶業(yè)務(wù)的全面開放，授權(quán)和TOPID將會迎來更大的壓力。如何為用戶和ISV提供授權(quán)的查看，綁定，解綁，延長成為在海量請求下的大挑戰(zhàn)。當(dāng)前所做的除了簡單的分庫分表以外，在緩存與數(shù)據(jù)庫的同步策略也作了一些折中。但授權(quán)是開放的第一道門，如何做好容災(zāi)及降級，不影響服務(wù)使用會成為大的挑戰(zhàn)。

　　黑名單規(guī)則當(dāng)前粒度小在應(yīng)用+服務(wù)，但其實很多時候需要細(xì)粒度到用戶，此時的頻率控制計數(shù)器的數(shù)量，黑名單的數(shù)量都會大幅增加，加之未來其他平臺對接時對于控制需求的定制增加，運營活動對短期個性化規(guī)則限制的增加，會導(dǎo)致黑名單規(guī)則更為復(fù)雜，數(shù)量更加龐大，如何靈活定制規(guī)則及支撐海量計數(shù)和黑名單成為挑戰(zhàn)。

　　4. 多維度告警分析決策

　　開放平臺很多數(shù)據(jù)都即時的分析出來(2分鐘一輪)，但往往在出現(xiàn)問題的時候，透明化的數(shù)據(jù)給出了各種告警，如何結(jié)合告警及歷史數(shù)據(jù)給出有力的問題定位，甚至做到部分自動決策，也成為一種挑戰(zhàn)，挑戰(zhàn)對歷史數(shù)據(jù)的計算，挑戰(zhàn)對多種問題的關(guān)聯(lián)配置。例如，突然整個平臺的錯誤率提升了1%，同時很多應(yīng)用的錯誤率也提高了，此時如果某一個服務(wù)的錯誤率提高的話，那么意味著這個服務(wù)可能成為問題的源頭。但如果只有一個或者幾個應(yīng)用出現(xiàn)了問題，而服務(wù)的錯誤率并沒有太突出，可能是應(yīng)用出問題了。等等等等~~~

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

　　當(dāng)前開放平臺分析日志采用松散模式的分布式任務(wù)分治框架，但由于將MapReduce的處理過多的融入到了分布式分治框架中，導(dǎo)致現(xiàn)在ISV應(yīng)用監(jiān)控集群在復(fù)用框架的時候不能很好地擴展，只能部分重用底層通信及部分的交互協(xié)議，因此了將來大量的分治協(xié)作處理場景，需要抽象出與任務(wù)處理不相關(guān)的框架，同時支持任務(wù)來源及工作者處理結(jié)果模式(也許本地完成存儲，而不是到Master Reduce)，同時自身的容災(zāi)及穩(wěn)定性和任務(wù)分配算法需要有更多的優(yōu)化和措施。

　　安全：

　　網(wǎng)站應(yīng)用和桌面應(yīng)用安全掃描

　　對網(wǎng)站應(yīng)用的回調(diào)地址做釣魚掃描及對桌面應(yīng)用作二進(jìn)制掃描，是開放平臺對應(yīng)用安全性的基本的要求，但是實施難度很大。需要有對安全有較為深入的同事參與完成。