经历了近三年的平台发展，随着业务量跳跃增长和开放尺度的不断加大，问题随之而来，开放平台技术问题这个小短篇是想摆出问题，有些东西已经起步，有些东西还是空白，有些东西做的粗糙，有些东西还处于想想。希望有类似问题的，有业余时间掺和的，有兴趣加入一起搞的，欢迎随时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模式，可以将容器线程池独立出来处理连接，而业务处理交由后端业务线程池处理，而业务线程池可以根据业务优先级设定一些预留和限制模型，即共享线程池，又限制线程池被独占。当前我们做了：异步模型封装+业务管道化+业务权重线程池，看下图：(开放平台的控制台中权重线程池监控和设置)