高併發與高可用實戰之基礎知識大型網站架構特徵（一）

大型網站架構特徵：

1.高併發？（用戶訪問量比較大）

解決方案:拆分系統、服務化、消息中間件、緩存、併發化

高併發設計原則

系統設計不只須要考慮實現業務功能，還要保證系統高併發、高可用、高可靠等。同時還應考慮系統容量規劃（流量、容量等）、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)緩存

接入層緩存

應用層緩存

分佈式緩存

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

併發化

改串行爲並行。

 

2.高可用？（在高併發 保證系統不被宕機）

解決方案:降級、限流、切流量、可回滾

高可用設計原則

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

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

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

經過隔離實現故障隔離。

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

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

降級

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

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

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

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

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

 

限流

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

實踐：

惡意請求流量只訪問到 Cache

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

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

 

切流量

目的：屏蔽故障機器

實踐:

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

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

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

 

可回滾

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

 

3.網站演變過程

單體架構 ->分佈式架構 ->SOA(面向服務架構-面向於業務邏輯層) ->微服務

單體架構

SSH、SSM 分層結構開發 (傳統項目)

分佈式架構

將一個項目進行拆分，拆分紅n多個子項目 (根據業務邏輯拆分)
好比電商系統。拆分爲優惠券系統、訂單系統、支付系統、消息系統、交易系統，最終要將全部拆分的子項目整成一個流程，經過域名跳轉訪問。

SOA

面向服務架構 ，業務邏輯和試圖展現層分離。
涉及到RPC遠程調用技術（Dubbo、SpringCloud）
將業務邏輯層抽取出來，封裝成服務(接口)，給其餘的子系統調用。
SOAP=http+xml格式
ESB （消息總線）

微服務

基於SOA演變過來，繼承了SOA優勢，去除了SOA層ESB消息總線，採用http+json(restful)

微服務架構與SOA區別

1微服務架構基於SOA演變過來，繼承SOA優勢微服務架構中去除SOA架構中的ESB消息總線，採用http+json（restful）。
2.微服務架構比SOA架構粒度會更加精細，讓專業的人去作專業的事情（專一），目的提升效率，每一個服務於服務之間互不影響，微服務架構中，每一個服務必須獨立部署，互不影響，微服務架構更加輕巧，輕量級。
3.SOA架構中可能數據庫存儲會發生共享，微服務強調獨每一個服務都是單獨數據庫，保證每一個服務於服務之間互不影響。
4.體現項目特徵：微服務架構比SOA架構更加適合與互聯網公司敏捷開發、快速迭代版本，由於粒度很是精細。

 

更多知識查看螞蟻課堂