开放平台的技术问题

经历了近三年的平台发展，随着业务量跳跃增长和开放尺度的不断加大，问题随之而来，开放平台技术问题这个小短篇就是想摆出问题，有些东西已经起步，有些东西还是空白，有些东西做的粗糙，有些东西还处于想想。希望有类似问题的，有业余时间掺和的，有兴趣加入一起搞的，欢迎随时mail：[email protected] 。开放平台内部将会有少量人各自负责一些内容作为专题来做精做足。开放平台团队的优势是有业务试验田（每天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：[email protected] 。