通用高性能服務框架解析

做了多年的后臺服務，1直想將自己這么多年對高性能服務架構的1些粗淺認識寫出來，1方面對自己這個階段成長做個總結， 另外一方面想通過這個與各位做1個交換，妄不吝賜教。

1、最初對服務架構的概念

最初接觸服務端程序應當是2011年，當初基于服務架構的概念是基于這樣1個模型

這是最簡單的1種C/S模型結構，客戶端直接連接服務端，只能適用于對效力、并發量、擴大性要求低的環境，所以當要求量逐步上升，你會發現這類架構的系統，在處理上已不滿足業務的需求了，所以你衍生出下面1種架構。

2、多個App分流模式

這是1個兩層框架，中控層是控制服務只做轉發分流操作，分流的算法通常是輪詢，具體可以根據實際的業務情況去制定。利用層是具體的利用服務，履行具體業務。這類架構的主要優勢有1下幾點:

1、中控層將流量有效散布到各個業務服務，而中控層的利用只做轉發不做業務，在處理要求量上效力要遠遠高于直連業務服務，所以框架相對上面1個在吞吐量上大幅增加

2、較易于擴大，如果發現利用服務不能支持現有業務量時，可以通過增加利用服務來分流。

但是這個種架構隨著業務量的增加也會漸漸不適用，有同學可能會說多弄幾個業務服務分流不就得了，這里得斟酌到資源本錢，管理本錢等等問題，所以這類方式在大要求量下是不適用的，問題就在如何提高利用服務的業務處理速度，我們可以引入緩存機制。

3、加緩存機制的框架

在普通業務處理上，查詢要求量是最多的，如何提高查詢效力，就成為關鍵，1般情況下數據庫或磁盤IO的讀取都能成為瓶頸，所以常常我們會在業務利用與數據庫或磁盤之間添加緩存機制，業務利用先去查緩存，緩存沒有再去查對應的數據庫或磁盤，90%的要求都能在緩存中解決，這樣不但減小了數據庫的壓力，同時也增加業務處理的速度。固然你可能會根據業務的需要多幾個緩存，但是基本的思路不變，具體根據你的業務走，此種架構基本能解決80%的問題。

4、加入容災機制的框架

上面所講的框架只是1種基礎框架，在實際利用中需要斟酌的因素很多，比如服務器宕機了，怎樣平滑過渡，不影響業務等等，這里就得加入容災機制。

監控服務主要負責監控負載均衡服務是不是有宕機情況，如果有，置為相應狀態，客戶端要求監控服務，獲得有效的負載均衡服務的地址，進行連接，這樣即便有1個服務宕機，其實其實不影響全部系統的運行，固然還有數據庫的容災，這里就不多做討論了！

5、總結

影響全部系統性能的因素有很多，這里僅就框架上做了1些粗淺的討論，拋磚引玉，實際情況可能斟酌的因素會更多，至于常見程序上的優化，有時間我也會寫1篇文章總結1些。另外高性能WEB利用的框架搭建可以參考這篇文章：http://www.csdn.net/article/2014⑴1-06/2822529 。 總之增加系統性能的不變原則就是如何快速的處理業務數據。

最后，大家有甚么問題或好提議，可以加入群：291368579

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈