經歷了近三年的平臺發展，隨著業務量跳躍增長和開放尺度的不斷加大，問題隨之而來，開放平臺技術問題這個小短篇就是想擺出問題，有些東西已經起步，有些東西還是空白，有些東西做的粗糙，有些東西還處于想想。希望有類似問題的，有業余時間摻和的，有興趣加入一起搞的，歡迎隨時mail：fangweng@taobao.com 。開放平臺內部將會有少量人各自負責一些內容作為專題來做精做足。開放平臺團隊的優勢是有業務試驗田（每天10多億的調用而且正在翻翻），劣勢就是時間要自己擠（不論你是業余還是團隊內），我們有業務的壓力和其他創新的需求，而提出的這些技術問題當前是從系統技術角度談的，業務上的難點就不提在這里了，廢話不多說。
Web容器：
省，快，穩，新
1． 每天10億次的服務調用，如果能夠在讀取所有數據前就攔截掉一些系統或業務校驗不通過錯誤請求，那么節省的上行帶寬和連接資源就是一筆不小的財富。這僅僅只是省的一種方式，當前我們做了streaming Lazyparser。如何省的更多，還待在容器上做更多文章。
2． 測試過Jetty，tomcat，jbossweb3，最終選擇了Jetty，不是因為jetty最快，而是在類似于Servlet3的Continuation特性下我們妥協了部分性能的損失。但Jetty的底層卻有很大的機會去提升（特別是Jetty的框架可植入，給了我們很大的靈活性，Jetty的整體事件驅動模型是做的很不錯的），所以如何讓容器更快，需要我們做更多的事。
3． 先看看下面的圖：
這是開放平臺后端的服務其中一部分處理時間統計，有快有慢，同時這些系統的容量規劃，發布時間和服務質量都參差不齊，但開放平臺就是一個對外的門戶，由于Http請求的同步性+容器管理線程生命周期，使得隔離單個服務不可用波及平臺，最終導致后端服務都無法被訪問，需要改變傳統容器的請求處理方式。（假如A服務出現問題，同時3秒鐘為服務調用超時時間，如果一個應用服務器最大500個容器線程，那么單機最差情況1秒就只能處理500/3個請求，這意味正常的后段服務由于得不到路由中轉也被外部認為不可用），因此采用Jetty的Continuation模式，可以將容器線程池獨立出來處理連接，而業務處理交由后端業務線程池處理，而業務線程池可以根據業務優先級設定一些預留和限制模型，即共享線程池，又限制線程池被獨占。當前我們做了：異步模型封裝+業務管道化+業務權重線程池，看下圖：（開放平臺的控制臺中權重線程池監控和設置）
如何將異步+業務權重線程池運用到更多的對第三方系統有依賴，同時又能夠切換多種服務提供者的系統中，需要更好優化異步帶來的性能消耗，同時增加權重線程池共享和限制算法，最大限度挖掘潛力。
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），同時自身的容災及穩定性和任務分配算法需要有更多的優化和措施。
安全：
網站應用和桌面應用安全掃描
對網站應用的回調地址做釣魚掃描及對桌面應用作二進制掃描，是開放平臺對應用安全性的最基本的要求，但是實施難度很大。需要有對安全有較為深入的同事參與完成。
今天就先寫到這里，更多的內容期待你的參與和挖掘。希望有類似問題的，有業余時間摻和的，有興趣加入一起搞的，歡迎隨時mail：fangweng@taobao.com。