《框架设计原则》课程资料
服务治理过程演进
在大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。
比Velocity快10倍的模板引擎
在07年的时候，写过一个模板引擎，当时叫CommonTemplate，以前JavaEye有个开源系列介绍：http://www.iteye.com/news/3381，后来功能越来越多，性能却越来越差，在金大为发给我性能对比结果后，看到惨不忍睹的差距，就打算抛弃原设计进行重写，但因工作忙，就搁置了，最近看温少发了几个EL和JSON的解析器，有点手痒，就抽了个周未，拿出来再改了改，主要将模板改成了字节码编译，并简化了语法及缩小使用范围，只针对HTML场景使用，并将名称改成了HTTL，名字含义是把HTML中的M(Marker)改成了T(Template)，放在GoogleCode上：http://code.google.com/p/httl，性能和Java硬编码输出模板内容差不多，比Velocity/FreeMarker等快10倍左右。
DCE使用的问题及其解决方法
目前，国际站目前还是主要在几个应用上，一个应用多的有三四十万行代码。几乎所有的产品线在这个应用上都有代码；采用分支开发，要改的代码可能只有一点也要Check out出整个工程的代码来。
这样大工程，对于开发效率的影响很大，编译一下10分钟，启动一下5分钟。苦闷的等待是时间的浪费，另一方面也是打断了开发的节奏。开发过程中，每修改了一点内容，就要编译工程、重启应用来验证。每个开发员都会要频繁重启，浪费总量上是巨大的。
当然解决大应用的关键是拆根据功能拆分成小应用，这件事国际站也在积极进行中。
Netty内存泄露
在测试中发现，当不停的开关Netty的NioClientSocketChannelFactory（比如大量连接失败重连等情况下），存在Direct Memory泄露。
测试代码：
Grizzly和Netty以及Mina简单性能对比
最近在服务框架中尝试增加了Grizzly传输集成，简单测试后发现，TPS(每秒处理请求数)略低于Netty，略高于Mina，相差并不是很大，但TPS比Netty稳定很多(每秒方差小)，不会出现大幅波动，可以考虑备选。
Mina为ApacheDirectory服务器的底层NIO框架：http://mina.apache.org
Netty为JBoss的NIO框架：http://www.jboss.org/netty
