如何将异步+业务权重线程池运用到更多的对第三方系统有依赖，同时又能够切换多种服务提供者的系统中，需要更好优化异步带来的性能消耗，同时增加权重线程池共享和限制算法，大限度挖掘潜力。

　　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)，同时自身的容灾及稳定性和任务分配算法需要有更多的优化和措施。

　　安全：

　　网站应用和桌面应用安全扫描

　　对网站应用的回调地址做钓鱼扫描及对桌面应用作二进制扫描，是开放平台对应用安全性的基本的要求，但是实施难度很大。需要有对安全有较为深入的同事参与完成。