开放平台内部将会有少量人各自负责一些内容作为专题来做精做足。开放平台团队的优势是有业务试验田(每天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可以实现类似的功能。但面临的问题是并发连接数大小，断连策略，消息推送对客户端的要求。