互聯網高併發架構設計模式

前言

隨着互聯網的快速發展，不少傳統行業都開始將原有的產品互聯網化移動化，這其中就涉及到對原有系統的改造，由於以前大部分時間都是在傳統銀行工做因此對於原先的系統設計咱們也有一個套路，相似傳統的SSH、LAMP這種，可是隨着技術的不斷快速發展，互聯網高併發的架構設計也有了新的模式，本文就介紹下基本的高併發設計模式。互聯網大部分系統的設計採用本文的設計模式都是能夠的，可是對於一些超高併發的特殊場景的系統仍是須要根據具體業務場景單獨去設計的，下面咱們就對高併發設計模式進行講解。

分層

分層設計是企業應用系統中常見的設計模式，爲了保證後續系統的可拆分和可複用，通常會將系統拆分爲應用層、服務層、數據層，這也是傳統的系統分層拆分模式。經過分層，能夠更好的將一個龐大的軟件系統切分爲不一樣的部分，便於分工合做並行開發和維護。每層都是獨立的，互相經過接口進行調用，各層能夠根據業務狀況的變化獨立做出調整，只須要保證接口一致性便可。

分層比較大的挑戰就是合理規劃和劃分每一層的邊界和接口，在實施過程當中禁止躍層調用。對於分層架構不是一成不變的，通常來講在實際過程當中，會根據具體的狀況再細化分層，應用層能夠分爲視圖層、業務邏輯層等，服務層也能夠細分爲數據接口適配層、邏輯處理層等。

分層架構對網站支持高併發分佈式的發展方向相當重要，因此在系統剛開始建的時候最好就要採起分層架構，這樣後續分層會比較容易。

分割

分層是對系統的橫向的切分，分割則是對系統縱向的切分。系統越大，分割的就會越細，例如銀行系統咱們會切分爲核心系統、帳戶系統、支付系統、現金管理系統、營銷系統等等，基本上你在網銀或者手機銀行上看到的每一個功能背後基本都是一個系統去支撐，例如咱們常見的手機銀行裏的帳戶交易查詢，就這麼一個簡單的交易查詢功能，對於有必定規模的銀行來講，都會單建一個交易查詢系統提供全渠道的查詢服務。

按照這樣將功能從業務層面分割之後，各個系統承載的壓力天然也就降低下來，並且擴展性也會比較好。不過功能分割對於大型網站的分割粒度通常會比較小，對於小規模的公司來講通常不必上來就分割成不少子系統，隨着業務的發展再進行分割就能夠。

分佈式

分佈式由來已久，分佈式意味着能夠經過增長機器完成一樣的功能，機器越多，cpu資源、內存、磁盤都是隨着機器的增長而線性增長，機器越多可以處理的併發訪問和數據量就越大，從而能爲更多的用戶提供服務。

分佈式架構須要考慮不少問題，並非簡單的加機器就能夠了。實施分佈式之後須要考慮用戶會話如何管理，數據在分佈式環境中如何保持數據一致性，分佈式事務如何保證一致性，分佈式的日誌維護等都是須要考慮的問題，因此分佈式設計要根據具體狀況而來，不要爲了分佈式而分佈式。

分佈式方案有如下幾種：

1）分佈式應用和服務：將分層和分割後的應用分佈式部署，這樣能夠提升網站性能和併發，加快開發和發佈速度，還可讓不一樣應用交叉複用共同的應用，便於功能擴展。

2）分佈式靜態資源：網站的靜態資源獨立分佈式部署，並採用獨立的域名，這就是動靜分離。靜態資源的分佈式部署能夠減小應用服務器的壓力，使用獨立域名能夠加快加載速度，也能夠下降靜態資源服務器的壓力。

3）分佈式數據和存儲：大型網站處理的數據都是P級的，單臺服務器沒法提供這麼大的存儲空間，這麼大的數據須要分佈式存儲。除了分佈式文件存儲，還有關係型數據庫和Nosql都有分佈式的部署方案。經過分佈式可以提供海量的數據存儲空間。

4）分佈式計算：對於不少後臺批量處理的任務都是採用分佈式計算方案，經常使用的有Hadoop和MapReduce分佈式計算框架。分佈式計算框架內容比較多。

集羣

分佈式部署的應用和服務部署了不少機器後還須要將其集羣化才能對外提供服務，多臺服務器部署相同應用構成一個集羣，經過負載均衡設備共同對外提供服務。

當業務量不斷增大之後，能夠在集羣中不斷增長服務器就能夠知足業務增加了，當一臺服務器壞了也不會影響對外的服務提供，只是性能有所降低。

緩存

緩存是高併發系統的殺手鐗，在真正有高併發需求的系統通常會設計多級緩存來減小真正的服務計算，而是直接經過緩存提供服務。像微博、朋友圈這些高QPS的系統都是採用了多級緩存的架構方案。

1）CDN：CDN供應商通常都部署在距離用戶最近的網絡服務商，用戶的請求老是先到網絡服務商，在這裏緩存網站的靜態資源，能夠就近將靜態數據返回給用戶。通常來講對於電商、社交應用、新聞門戶或者視頻網站這些高QPS網站，都建議使用CDN來環節源系統的壓力。

2）反向代理：反向代理屬於網站前端架構的一部分，部署在網站的前端，當用戶請求到達網站的數據中心時，最早訪問到的就是反向代理服務器，這裏將網站的靜態資源緩存起來，這樣不須要繼續轉發應用服務器，直接從反向代理緩存中返回就能夠了。

3）本地緩存：對於應用服務器被訪問的高熱點數據，應用程序能夠在服務器內存中緩存這些熱點數據，這樣就不須要訪問服務器磁盤或者數據庫了，可以將內存中的熱點數據直接返回。

4）分佈式緩存：不少系統數據量很是大，光靠本地緩存可能內存空間不夠，這時候就能夠考慮使用分佈式緩存了，經常使用的分佈式緩存有redis、memcache這些key-value分佈式緩存，這些分佈式緩存通常也都提供了集羣版本，可以作到很好的高可用和高性能。

異步

異步也是處理高併發的一把利器，也是處理解耦的手段之一，業務系統之間的消息傳遞不是同步調用，而是將一個業務操做分爲多個階段，每一個階段之間經過共享數據的方式異步執行。

在單一服務器內部可經過多線程共享隊列的方式實現異步，處在業務操做前面的線程將輸出的內容寫入隊列，後面的處理線程從隊列中取出數據進行處理；在分佈式系統中，多個服務器集羣經過分佈式消息隊列實現異步。

對於簡單的異步實現能夠經過內存隊列來實現，對於須要高可用和高併發的系統通常來講都依靠商用的消息隊列中間件產品，Websphere MQ、Rabbit MQ、Rocket MQ等都是比較好的消息中間件產品。

冗餘

爲了保證系統的高可用，咱們通常會對服務器和數據都進行冗餘備份，這樣能夠保證在服務器宕機的狀況下系統依然能夠保證提供服務。

訪問和負載很小的應用服務也必須部署至少兩臺服務器組成一個集羣，就是爲了經過冗餘來實現高可用。數據庫要按期進行全量備份，天天還要進行增量備份，防止數據庫服務器出現異常致使數據丟失，對於實時的數據備份能夠經過數據庫自帶的日誌來進行恢復。

總結

上面介紹的這些就是經常使用的一些高併發的設計模式，其中每一條都值得深刻的研究，本文只是介紹了高併發設計時須要考慮的設計方案簡介，能夠經過這些方案緩解壓力提升併發性能和高可用。、

感興趣能夠加Java架構師羣獲取Java工程化、高性能及分佈式、高性能、深刻淺出。高架構。性能調優、Spring，MyBatis，Netty源碼分析和大數據等多個知識點高級進階乾貨的直播免費學習權限 都是大牛帶飛 讓你少走不少的彎路的 羣..號是：855801563 對了 小白勿進 最好是有開發經驗

注：加羣要求

一、具備工做經驗的，面對目前流行的技術不知從何下手，須要突破技術瓶頸的能夠加。

二、在公司待久了，過得很安逸，但跳槽時面試碰壁。須要在短期內進修、跳槽拿高薪的能夠加。

三、若是沒有工做經驗，但基礎很是紮實，對java工做機制，經常使用設計思想，經常使用java開發框架掌握熟練的，能夠加。

四、以爲本身很牛B，通常需求都能搞定。可是所學的知識點沒有系統化，很難在技術領域繼續突破的能夠加。

5.阿里Java高級大牛直播講解知識點，分享知識，多年工做經驗的梳理和總結，帶着你們全面、科學地創建本身的技術體系和技術認知！