容量規劃的一些探討與實踐

以前產品線上發生過若干次由於tomcat鏈接池被耗盡而致使宕機的故障，而具體根源緣由則各不盡相同。有由於調用和被調用的服務申請相同的分佈式鎖而致使死鎖的，有由於發送內部或外部的JMS消息發生堵塞的，有由於某個存在性能問題的接口被較多調用致使的，還有某些超高頻接口沒有作好專門優化而致使的。。。

       全部上述問題的本質解決，確定是要針對各類問題根源，分別予以解決。解決死鎖問題，外部接口作好嚴格的訪問超時控制，非核心業務邏輯儘可能異步處理，儘量的經過增長cache來減小數據庫壓力等等。但除此以外，系統中任何一個業務點均可能拖垮整個系統，系統總體的脆弱程度值得深思。爲何瘸了腿的人會死？不，他應該還要能編程。

        其實，這個問題的本質在於tomcat只有一個共享線程池，全部的業務請求都會分配給一個線程，直至請求處理完畢，線程纔會被回收。任何一個長請求，都會長期侵佔致使寶貴的tomcat鏈接池資源。這點其實在tomcat7上已經作了優化支持，tomcat7支持了異步處理。此特性將http線程池和業務service線程池作了分離，這樣一個IO等待的業務請求，只會侵佔業務service線程池。但這沒有解決本質問題，由於雖然解決了http線程池的資源問題，但累積膨脹的業務service線程池，對jvm內存、cpu，數據庫等還是一個威脅。壞孩子和調皮的孩子其實放到哪裏都是問題，他們須要被好好管理。須要控制他們的發言次數，這樣哪些無辜的乖孩子纔有機會發言，老師也才能聽到有意義的反饋。

 

        那麼，咱們須要作什麼呢?

 1.咱們須要作好資源隔離，防止任何一個業務功能消耗過多的鏈接池資源，甚至，在必要的時候，能夠徹底禁止這個問題業務功能。

 2.業務功能的流量閾值或開關，可以及時、動態的予以調整。

 3.業務功能若是流量超限，能夠定製的作異常處理。

 

         解決問題一，咱們設計了一個Aspect。它攔截了全部的業務功能請求，而後根據具體業務功能的流量閾值對請求進行控制。若是未超限，則放行，放行前增長計數，業務功能執行完成後回收計數；若是超限，則獲取相應的異常處理策略進行處理。主要包含了流量計數器，閾值管理器和異常處理器這3個部分。

框架簡圖以下：

處理流程圖以下：

解決問題二和三，即閾值和處理策略動態調整的問題。顯然，配置文件是不合適的，那意味着要作應用重啓。將配置信息保存到memcache中？那意味着每一個業務請求都須要訪問至少2次網絡請求，這是不小的開銷。那看來，若是能將這些信息冗餘在服務器節點的內存裏會性能不錯，那內容如何獲取和更新呢？服務器節點應該初始化的時候從一箇中心節點拉取配置，而後經過長鏈接的方式監聽在中心節點的配置變動時間，在發生變動新，從中心節點拉取相應新內容。中心節點最好還能是高可用的，高性能的，以及擁有良好的一致性。聽起來美好，要真開發起來可還真不簡單。幸運的是，牛人們早已爲咱們鋪好大路了，那就是Zookeeper！它從核心上完美地解決了咱們的需求。不過，到這裏，其實還不夠。咱們的配置須要能持久保存，若是zookeeper真的掛了怎麼辦？最好有個漂亮的配置管理界面，你會喜歡在一個黑乎乎的界面上瘋狂的敲打鍵盤嗎，那是黑客帝國的劇情。此外，最好還能有很是方便的客戶端編程接口API，不，甚至不要給我任何API，我添加幾個註解就一切搞定最好，好吧，咱們程序員就是懶！~

        讓咱們來看看開源的配置管理服務框架吧，diamond（阿里），disconf（百度），qconf（奇虎360）。隨都是師出名門，但因爲研發年代、測重點都會略有不一樣。先看看Diamond和Disconf的對比：

 

推拉模型和編程模型上，disconf都更加符合咱們的需求。可能後來者好是由於能站在前面巨人的肩膀上。下圖的disconf的核心流程圖：

更完整的的關於disconf的信息請你們看：

https://github.com/knightliao/disconf/wiki/%E5%88%86%E5%B8%83%E5%BC%8F%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86%E5%B9%B3%E5%8F%B0Disconf 。

至於qconf，基本特性同disconf差很少，當相關文檔比較少，也沒有特別詳細，也就沒有考慮了。感興趣的同窗能夠看下：

https://github.com/Qihoo360/QConf/blob/master/README_ZH.md ，和http://v.youku.com/v_show/id_XOTI1NTI2ODI0.html（視頻教程）

如今增長到併發攔截監控到公司監控系統。下圖是一個某段時間內的監控結果。

本文章爲做者原創

🈲禁止🈲

其餘公衆帳號轉載，如有轉載，請標明出處