漫談高併發與高可用

高併發與高可用

大型網站系統應有的特色

高併發，大流量

高併發，大流量：須要面對高併發用戶，大流量訪問。舉個例子，去往迪拜的飛機有200張票，可是有100w人都擠進系統買票，如何讓這100w人可以看到票務的實時更新，以及順利的買到一張票，都是一個網站架構師應該考慮的問題。這也許對於淘寶的「雙十一」1000w的一分鐘獨立訪問用戶量來講，是個微不足道的數字，可是對於用戶的體驗以及網站的口碑來講，都是一項不小的挑戰。

高可用

高可用：相對於高併發來講，高可用並非一個比較有規律的參數，7*24 是每一個網站的夢想，可是你並不知道，在某一刻，他就沒理由的宕機了。

海量數據

海量數據：存儲，管理海量的數據，須要使用大量的服務器。FaceBook每週上傳的照片接近10億，沒有一個大型的存儲服務器的支撐，相信用戶量不會一直飆升。

用戶分佈普遍，網絡狀況複雜

用戶分佈普遍，網絡狀況複雜：許多大型的互聯網都是爲全球用戶提供服務的，用戶分佈範圍廣，各地網絡狀況千差萬別。各個運行商之間的互通，各個國家的數據鏈接等等。

安全環境惡劣

安全環境惡劣：因爲互聯網的開放性，使得互聯網更容易受到攻擊，包括各類省份證信息被竊取等事件家常便飯。

漸進式發展

漸進式發展：幾乎全部的大型互聯網網站都是從一個小網站開始，漸進發展起來的，好的互聯網產品都是慢慢運營出來的。

網站架構演變過程

傳統架構

傳統項目分爲三層架構，將業務邏輯層、數據庫訪問層、控制層放入在一個項目中 使用SSH或者SSM技術。

優勢:適合於我的或者小團隊開發，不適合大團隊開發。

分佈式架構

根據業務需求進行拆分紅N個子系統，多個子系統相互協做才能完成業務流程子系統之間通信使用RPC遠程通信技術。

優勢:

1.把模塊拆分，使用接口通訊，下降模塊之間的耦合度。

2.把項目拆分紅若干個子項目，不一樣的團隊負責不一樣的子項目。

3.增長功能時只須要再增長一個子項目，調用其它系統的接口就能夠。

4.能夠靈活的進行分佈式部署。

有優勢就有缺點，缺點以下：

1.系統之間交互須要使用遠程通訊，接口開發增長工做量。

2.各個模塊有一些通用的業務邏輯沒法共用。

爲了解決上面分佈式架構的缺點，咱們引入了soa架構，SOA：Service Oriented Architecture面向服務的架構。也就是把工程拆分紅服務層、表現層兩個工程。服務層中包含業務邏輯，只須要對外提供服務便可。表現層只須要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。

SOA架構

SOA是一種軟件架構模式，將共同的業務邏輯抽取出來，封裝成單獨的服務

業務系統分解爲多個組件，讓每一個組件都獨立提供離散，自治，可複用的服務能力

經過服務的組合和編排來實現上層的業務流程

做用：簡化維護,下降總體風險,伸縮靈活

 

微服務架構

微服務是指開發一個單個、小型的但有業務的服務，每一個服務都有本身的處理和輕通信機制，能夠部署在單個服務器上，讓專業的人作專業的事情。

微服務與SOA相比，更加輕量級。

SOA與微服務架構區別

OA架構主要針對企業級、採用ESB服務（ESB企業服務總線），很是重，須要序列化和反序列化，採用XML格式傳輸。

微服務架構主要互聯網公司，輕量級、小巧，獨立運行，基於Http+Rest+JSON格式傳輸。

ESB也能夠說是傳統中間件技術與XML、Web服務等技術相互結合的產物。

 

1.在微服務中，與SOA不一樣，服務能夠獨立於其餘服務進行操做和部署，所以更容易常常部署新版本的服務和獨立擴張服務，讓專業的人作專業的事情，快速迭代新的產品。

2.在SOA中服務可能共享數據存儲，而微服務中每一個服務都具備獨立的數據存儲。

3.SOA與微服務主要區別在於規模和範圍，SOA是一種思想，是面向服務架構體系，微服務繼承 了SOA的優勢，去除傳統的ESB消息總線，採用Http+json格式通信方式，更加輕量級。

 

高併發設計原則

系統設計不只須要考慮實現業務功能，還要保證系統高併發、高可用、高可靠等。同時還應考慮系統容量規劃（流量、容量等）、SLA指定（吞吐量、響應時間、可用性、降級方案等）、監控報警（機器負載、響應時間、可用率等）、應急預案（容災、降級、限流、隔離、切流量、可回滾等）。

 

緩存

異步併發

鏈接池

線程池

擴容

消息隊列

分佈式任務

拆分系統

在咱們從零開始作一個新系統的時候，會首先進行系統功能模塊架構設計，那麼是直接作一個大而全的垂直的MVC系統，使用一個war包進行發佈管理，仍是須要按一些規則進行模塊拆分，設計成SOA或者微服務系統比較好呢？這個筆者認爲須要依據項目具備什麼樣的人力物力條件以及項目須要支撐多少用戶量和交易量爲基礎。一個好的系統設計應該可以知足解決當前的需求和問題，把控實現和進度風險，預測和規劃將來，避免過分設計，在上線一個基礎核心版本以後，再進行不斷迭代和完善。

 

今天咱們來談一談進行SOA、微服務系統架構設計時模塊拆分的一些維度和原則。

系統維度：按照系統功能、業務拆分，如、優惠券、購物車，結算，訂單等系統。

功能維度：對系統功能在作細粒度拆分，優惠券系統分爲 優惠券後臺系統、領券系統、發券系統。

讀寫維度：好比商品系統中，若是查詢量比較大，能夠單獨分爲兩個服務，分別爲查詢服務和寫服務,

讀寫比例特徵拆分；讀多，可考慮多級緩存；寫多，可考慮分庫分表.

AOP 維度： 根據訪問特徵，按照 AOP 進行拆分，好比商品詳情頁可分爲 CDN、頁面渲染系統，CDN 就是一個 AOP 系統

模塊維度：對總體代碼結構劃分 Web、Service、DAO

 

 

服務化

在分佈式系統中，將業務邏輯層封裝成接口形式，暴露給其餘系統調用，那麼這個接口咱們能夠理解爲叫作服務。

當服務愈來愈多的時候，就會須要用到服務治理，那麼會用到Dubbo、SpringCloud服務治理框架

後續在深刻Dubbo和SpringCloud中會詳細講到。

 

服務化演進: 進程內服務-單機遠程服務-集羣手動註冊服務-自動註冊和發現服務-服務的分組、隔離、路由-服務治理

考慮服務分組、隔離、限流、黑白名單、超時、重試機制、路由、故障補償等

實踐：利用 Nginx、HaProxy、LVS 等實現負載均衡，ZooKeeper、Consul 等實現自動註冊和發現服務

消息隊列

消息中間件是一個客戶端與服務器異步通信框架，消息中間件中分爲點對點與發佈訂閱通信方式，生產者發送消息後，消費者能夠無需等待， 異步接受生產者發送消息。

在電商系統中，會使用消息隊列異步推送消息，注意消息失敗重試冪等性問題。

冪等性問題解決方案，使用持久化日誌+全局id記錄。

緩存技術

瀏覽器端緩存

APP客戶端緩存

CDN(Content Delivery Network)緩存

接入層緩存

應用層緩存

分佈式緩存

對於兜底數據或者異常數據，不該該讓其緩存，不然用戶會在很長一段時間裏看到這些數據。

併發化

改串行爲並行。

高可用設計原則

 

經過負載均衡和反向代理實現分流。

經過限流保護服務免受雪崩之災。

經過降級實現部分可用、有損服務。

經過隔離實現故障隔離。

經過合理設置的超時與重試機制避免請求堆積形成雪崩。

經過回滾機制快速修復錯誤版本。

降級

對於高可用服務，很重要的一個設計就是降級開關，在設計降級開關時，主要依據以下思路：

1.開關集中化管理：經過推送機制把開關推送到各個應用。

2.可降級的多級讀服務：好比服務調用降級爲只讀本地緩存、只讀分佈式緩存、只讀默認降級數據（如庫存狀態默認有貨）。

3.開關前置化：如架構是Nginx–>tomcat，能夠將開關前置到Nginx接入層，在Nginx層作開關，請求流量回源後端應用或者只是一小部分流量回源。

4.業務降級：當高併發流量來襲，在電商系統大促設計時保障用戶能下單、能支付是核心要求，並保障數據最終一致性便可。這樣就能夠把一些同步調用改爲異步調用，優先處理高優先級數據或特殊特徵的數據，合理分配進入系統的流量，以保障系統可用。

 

限流

目的: 防止惡意請求攻擊或超出系統峯值

實踐：

惡意請求流量只訪問到 Cache

穿透後端應用的流量使用 Nginx 的 limit 處理

惡意 IP 使用 Nginx Deny 策略或者 iptables 拒絕

 

切流量

目的：屏蔽故障機器

實踐:

DNS: 更改域名解析入口，如 DNSPOD 能夠添加備用 IP，正常 IP 故障時，會自主切換到備用地址; 生效實踐較慢

HttpDNS: 爲了繞過運營商 LocalDNS 實現的精準流量調度

LVS/HaProxy/Nginx: 摘除故障節點

 

可回滾

發佈版本失敗時可隨時快速回退到上一個穩定版本

 

業務設計原則

防重設計

頁面請求防止重複提交，能夠採用防重key、放重表、Token等

採用圖形驗證，防止機器攻擊。

冪等設計

消息中間件:消息中間件中應該注意因網絡延遲的緣由，致使消息重複消費

第三方支付接口:在回調接口中，應該注意網絡延遲，沒有及時返回給第三方支付平臺，注意回調冪等性問題。

分佈式系統中，保證生成的訂單號惟一性，定時Job執行的冪等性問題等。

 

流程定義

複用流程系統，提供個性化的流程服務。

狀態與狀態機

複用流程系統，提供個性化的流程服務。

後臺系統操做可反饋

設計後臺系統時，考慮效果的可預覽、可反饋。

後臺系統審批化

對於有些重要的後臺功能須要設計審批流，好比調整價格，並對操做進行日誌記錄，從而保證操做可追溯、可審計。

文檔註釋

系統發展的最初階段就應該有文檔庫（設計架構、設計思想、數據字典/業務流程、現有問題），業務代碼合特殊需求都要有註釋。

備份

包括代碼和人員的備份。代碼主要提交到代碼倉庫進行管理和備份，代碼倉庫至少應該具有多版本的功能。人員備份指的是一個系統至少應該有兩名開發人員是瞭解的。