高可用集群架构的演进

我们项目组是做企业数据总线的，一开始的架构是采用Apache HTTPD + mod_jk 做负载均衡，应用则部署在Tomcat集群上面，该架构方案虽然考虑了Tomcat容器级别的高可用，但并未考虑HTTPD的高可用，该方案的拓扑图如下：



该方案的缺点显而易见，一旦HTTPD宕机，用户将无法访问应用，考虑到系统的高可用性，我把架构改变成如下拓扑图：



在新的架构中，我们决定使用mod_cluster来代替mod_jk, 因为mod_cluster有反向注册功能，也就是说当我需要添加或删除tomcat节点的时候，我只需要在tomcat端做配置，不需要到HTTPD端做配置，这样很好地保证了tomcat节点的动态横向扩展性。新架构中多了一台备用HTTPD服务器，并且主备HTTPD服务器由keepalived来做集群管理，备用HTTPD是热备方案，一旦主HTTPD宕机，备用HTTPD立即升级为主HTTPD接受用户请求。

该架构实现了3个级别的高可用：

1. HTTPD负载均衡器的高可用。

2. Tomcat容器的高可用。

3. Session级别的高可用(使用tomcat的<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>来达到这一点，本质上是各tomcat节点间session复制)。

这个架构的一个不足之处是session共享方面的高可用暂未实现，由以上拓扑图可知，该方案采用的session复制方案，而session复制方案在多tomcat节点的时候会引起广播风暴从而影响性能，而且本质上来说session复制方案也无法跨虚拟机复制，各个虚拟机之间的tomcat session依然不是高可用的，而要达到这一点则必须使用memcached或redis来做分布式session共享，这是下一步要做的。

在性能测试阶段我们发现了一个问题，当LoadRunner的虚拟用户达到100以上之后，系统的响应时间明显变长而且吞吐量下降很严重，仔细查看6个tomcat节点的日志发现真正负载的只有一台机器且日志中包含连接不上mod_cluster的错误，其他5台则完全没有反应，但是其他5台的配置跟那台正常的tomcat的配置是一样的，最后归结为Jboss的mod_cluster组件不稳定，决定放弃mod_cluster，也就是放弃tomcat集群的动态横向扩展这一特性，转而使用Apache原生mod_jk组件来管理tomcat集群，使用mod_jk组件之后，即使LoadRunner上500虚拟用户的并发量，依然能够保证响应时间在100毫秒内并达到了2M每秒的吞吐量，tomcat日志中的错误也消失了。