大型網站架構特征：

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架構更加適合與互聯網公司敏捷開發、快速叠代版本，因為粒度非常精細。

更多知識查看螞蟻課堂

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