如何將異步+業務權重線程池運用到更多的對第三方系統有依賴，同時又能夠切換多種服務提供者的系統中，需要更好優化異步帶來的性能消耗，同時增加權重線程池共享和限制算法，大限度挖掘潛力。
4. 從去年JavaOne的C/S模式遷移到B/S上提到的Comet，到今年的Html5的推廣，在開放平臺容器的職責上也多了一條Streaming api或者叫做Notify api，內部系統的狀態變化或者消息更新需要通知外部系統，傳統的通知者作為Client模式http請求帶來的服務器消耗是無法接受的，因此采用服務廣播+http長連是提高效率節約成本的一種方式，而jetty容器采用Continuation可以實現類似的功能。但面臨的問題是并發連接數大小，斷連策略，消息推送對客戶端的要求。
數據處理：
1. 統計(歷史數據保存)
每天當前有將近150G的基礎訪問數據(服務訪問，授權)，如果將詳細數據記錄下來，應該會達到250G，而且這個量還在不斷地增長。當前已經做的：每天保留日志分布在各個應用服務器上，交由分布式分析集群來拖取并分析，后將結果存儲，而日志則會在幾日內刪除。
問題：統計規則通過配置即刻生效，但對于歷史數據的再次統計無法做，同時由于歷史數據保留時間不久，因此可能導致后續無法再為數據作分析。需要保存歷史數據，考慮通過Hadoop的HDFS來保存。
2. 問題排查(隱私問題)
每天海量的數據中，定位某一個應用可能操作了某一個用戶的信息變得十分困難，當前通過日志的初步分析和grep。但由于日志的保留時間不久，加上基于用戶統計的數據結果會很龐大，因此只能針對部分用戶和部分應用作統計和跟蹤，為問題排查增加了難度。
考慮：
1. 通過應用，用戶，服務，對象ID(比如商品ID)來制作指紋，后續為比對留下簡單的證據。
2. 采用HBase，正好利用Rowkey， family，column三個維度來標識user，app，api及請求信息，便于檢索和日后的統計分析。其實也利用了上面說的歷史日志保存。(因為HBase是基于Hadoop HDFS)
3. 業務需求(授權，黑名單規則)
當前授權每天的數量已經突破了幾千萬，而且隨著淘寶業務的全面開放，授權和TOPID將會迎來更大的壓力。如何為用戶和ISV提供授權的查看，綁定，解綁，延長成為在海量請求下的大挑戰。當前所做的除了簡單的分庫分表以外，在緩存與數據庫的同步策略也作了一些折中。但授權是開放的第一道門，如何做好容災及降級，不影響服務使用會成為大的挑戰。
黑名單規則當前粒度小在應用+服務，但其實很多時候需要細粒度到用戶，此時的頻率控制計數器的數量，黑名單的數量都會大幅增加，加之未來其他平臺對接時對于控制需求的定制增加，運營活動對短期個性化規則限制的增加，會導致黑名單規則更為復雜，數量更加龐大，如何靈活定制規則及支撐海量計數和黑名單成為挑戰。
4. 多維度告警分析決策
開放平臺很多數據都即時的分析出來(2分鐘一輪)，但往往在出現問題的時候，透明化的數據給出了各種告警，如何結合告警及歷史數據給出有力的問題定位，甚至做到部分自動決策，也成為一種挑戰，挑戰對歷史數據的計算，挑戰對多種問題的關聯配置。例如，突然整個平臺的錯誤率提升了1%，同時很多應用的錯誤率也提高了，此時如果某一個服務的錯誤率提高的話，那么意味著這個服務可能成為問題的源頭。但如果只有一個或者幾個應用出現了問題，而服務的錯誤率并沒有太突出，可能是應用出問題了。等等等等~~~
5. 松散Master-Slave任務分治框架抽象(ISV應用監控，日志分析)
當前開放平臺分析日志采用松散模式的分布式任務分治框架，但由于將MapReduce的處理過多的融入到了分布式分治框架中，導致現在ISV應用監控集群在復用框架的時候不能很好地擴展，只能部分重用底層通信及部分的交互協議，因此了將來大量的分治協作處理場景，需要抽象出與任務處理不相關的框架，同時支持任務來源及工作者處理結果模式(也許本地完成存儲，而不是到Master Reduce)，同時自身的容災及穩定性和任務分配算法需要有更多的優化和措施。
安全：
網站應用和桌面應用安全掃描
對網站應用的回調地址做釣魚掃描及對桌面應用作二進制掃描，是開放平臺對應用安全性的基本的要求，但是實施難度很大。需要有對安全有較為深入的同事參與完成。
