高可用集羣架構的演進

咱們項目組是作企業數據總線的，一開始的架構是採用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日誌中的錯誤也消失了。