架構師之路 — 部署架構 — Overview（架構師之路 沈劍）

目錄

文章目錄

目錄

部署架構 5 大要素

1、性能

2、可用性

3、伸縮性

4、擴展性

5、安全性

部署架構技術手段

分布式系統架構

橫向分層

縱向分割

分布式

集群

緩存

CDN 靜態化數據

異步

冗余

自動化

安全

部署架構 5 大要素

一般說來，除了功能需求外，軟件架構還需要關注性能、可用性、伸縮性、擴展性和安全性這 5 個要素。

1、性能

性能是網站的一個重要指標，任何軟件架構設計方案都必須考慮可能會帶來的性能問題。也正是因為性能問題幾乎無處不在，所以優化網站性能的手段也非常多，主要的方式可以總結如下：

瀏覽器：瀏覽器緩存、使用頁面壓縮、合理布局頁面、減少 Cookie 傳輸等。

CDN 和反向代理。

本地緩存和分布式緩存。

異步消息隊列。

應用層：服務器集群。

代碼層：多線程、改善內存管理等。

數據層：索引、緩存、SQL 優化等，以及合理使用 NoSQL 數據庫。

2、可用性

網站高可用的主要手段是冗余，應用部署在多臺服務器上同時提供訪問，數據存儲在多臺服務器上互相備份，任何一臺服務器宕機都不會影響應用的整體可用，也不會導致數據丟失。

對于應用服務器而言，多臺應用服務器通過負載均衡設備組成一個集群共同對外提供服務，任何一臺服務器宕機，只需把請求切換到其他服務器即可，但是一個前提條件是應用服務器上不能保存請求的會話信息。

對于存儲服務器，需要對數據進行實時備份，當服務器宕機時需要將數據訪問轉移到可用的服務器上，并進行數據恢復以保證繼續有服務器宕機的時候數據依然可用。

除了運行環境，網站的高可用還需要軟件開發過程的質量保證。通過預發布驗證、自動化測試、自動化發布、灰度發布等手段，減少將故障引入線上環境的可能。

3、伸縮性

衡量架構伸縮性的主要標準有：是否可以用多臺服務器構建集群，是否容易向集群中添加新的服務器，加入新的服務器后是否可以提供和原來的服務器無差別的服務，集群中可容納的總的服務器數量是否有限制。

對于應用服務器集群，通過使用合適的負載均衡設備就可以向集群中不斷加入服務器。

對于緩存服務器集群，需要使用高效的緩存路由算法，避免加入新服務器導致路由大面積失效。

關系數據庫很難做到大規模集群的可伸縮性，因此關系數據庫的集群伸縮性方案必須在數據庫之外實現，通過路由分區等手段將部署有多個數據庫的服務器組成一個集群。

至于大部分 NoSQL 數據庫產品，由于其先天就是為海量數據而生，因此其對伸縮性的支持通常都非常好。

4、擴展性

衡量架構擴展性的主要標準就是不同產品之間是否很少耦合。在網站增加新的業務產品時，是否可以實現對現有產品透明無影響，不需要任何改動或者很少改動既有業務功能就可以上線新產品。

網站可伸縮架構的主要手段是事件驅動架構和分布式服務。

事件驅動架構在網站通常利用消息隊列實現，將用戶請求和其他業務事件構造成消息發布到消息隊列，消息的處理者作為消費者從消息隊列中獲取消息進行處理。通過這種方式將消息產生和消息處理分離開來，可以透明地增加新的消息生產者任務或者新的消息消費者任務。

分布式服務則是將業務和可復用服務分離開來，通過分布式服務框架調用。新增產品可以通過調用可復用的服務實現自身的業務邏輯，而對現有產品沒有任何影響。可復用服務升級變更的時候，也可以通過提供多版本服務對應用實現透明升級，不需要強制應用同步變更。

5、安全性

網站的安全架構就是保護網站不受惡意訪問和攻擊，保護網站的重要數據不被竊取。衡量網站安全架構的標準就是針對現存和潛在的各種攻擊與竊密手段，是否有可靠的應對策略。

部署架構技術手段

分布式系統架構

大型網站要很好支撐高并發，需要長期的規劃設計。在初期就需要把系統進行分層，在發展過程中把核心業務進行拆分成模塊單元，根據需求進行分布式部署，可以進行獨立團隊維護開發。

橫向分層

將系統在橫向維度上切分成幾個部分，每個部門負責一部分相對簡單并比較單一的職責，然后通過上層對下層的依賴和調度組成一個完整的系統。

通過分層，可以更好地將一個龐大的軟件系統切分成不同的部分，便于分工合作開發和維護。各層之間具有一定的獨立性，只要維持調用接口不變，各層可以根據具體問題獨立演化發展而不需要其他層必須做出相應調整。

但是分層架構也有一些挑戰，就是必須合理規劃層次邊界和接口，在開發過程中，嚴格遵循分層架構的約束，禁止跨層調用及逆向調用。在實踐中，大的分層結構內部還可以繼續分層。

比如把電商系統分成：應用層，服務層，數據層等，具體分多少個層次根據自己的業務場景。分層架構是邏輯上的，在物理部署上可以部署在同一臺物理機器上，但是隨著網站業務的發展，必然需要對已經分層的模塊分離部署，分別部署在不同的服務器上，使網站可以支撐更多用戶訪問。

應用層：網站首頁，用戶中心，商品中心，購物車，紅包業務，活動中心等，負責具體業務和視圖展示。

服務層：訂單服務，用戶管理服務，紅包服務，商品服務等，為應用層提供服務支持。

數據層：關系數據庫，NoSQL 數據庫等，提供數據存儲查詢服務。

分層架構是邏輯上的，三層結構可以部署在同一個物理機器上。但是隨著網站業務的發展，必然需要對已經分層的模塊分離部署，使網站擁有更多的計算資源以應對越來越多的用戶訪問。

縱向分割

分層是將軟件在橫向方面進行切分，分割則是在縱向方面對軟件進行切分。

網站越大，功能越復雜，服務和數據處理的種類也越多。將這些不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元，一方面有助于軟件的開發和維護；另一方面，便于不同模塊的分布式部署，提高網站的并發處理能力和功能擴展能力。比如用戶中心可以分割成：賬戶信息模塊，訂單模塊，充值模塊，提現模塊，優惠券模塊等

分布式

分層和分割的一個主要目的是為了切分后的模塊便于分布式部署，即將不同模塊部署在不同的服務器上，通過遠程調用協同工作。

將分層或者分割后的業務分布式部署，獨立的應用服務器，數據庫，緩存服務器。當業務達到一定用戶量的時候，再進行服務器均衡負載，數據庫，緩存主從集群。

分布式靜態資源，比如：靜態資源上傳 CDN。

分布式計算，比如：使用 Hadoop 進行大數據的分布式計算。

分布式數據和存儲，比如：各分布節點根據哈希算法或其他算法分散存儲數據。

但分布式在解決網站高并發問題的同時也帶來了其他問題。典型的有下面幾點：

意味著服務調用必須通過網絡，這可能會對性能造成比較嚴重的影響。

服務器越多，宕機的概率也就越大，造成的服務不可用可能會導致很多應用不可訪問，使網站可用性降低。

數據在分布式的環境中保持數據一致性非常困難，分布式事務也難以保證。

系統依賴錯綜復雜，開發管理維護困難。

因此分布式設計要根據具體情況量力而行。常用的分布式方案有：

分布式服務

分布式數據庫和存儲

分布式計算

分布式配置

分布式鎖

分布式文件系統

分布式靜態資源

等。

集群

使用分布式雖然已經將分層和分割后的模塊獨立部署，但是對于用戶訪問集中的模塊，還需要將獨立部署的服務器集群化，即多臺服務器部署相同應用構成一個集群，通過負載均衡設備共同對外提供服務。例如：應用服務器，數據庫，NoSQL 數據庫。

核心業務基本上需要搭建集群，通過負載均衡設備共同對外提供服務， 服務器集群能夠為相同的服務提供更多的并發支持，因此當有更多的用戶訪問時，只需要向集群中加入新的機器即可。另外可以實現當其中的某臺服務器發生故障時，可以通過負載均衡的失效轉移機制將請求轉移至集群中其他的服務器上，因此可以提高系統的可用性。

應用服務器集群：

Nginx 反向代理

SLB

等

數據庫集群：

主從分離，從庫集群

等

緩存

緩存是改善軟件性能的第一手段，在復雜的軟件設計中，緩存幾乎無處不在。

使用緩存有兩個前提條件：

數據訪問熱點不均衡，某些數據會被更頻繁的訪問，這些數據應該放在緩存中；

數據在某個時間段內有效，不會很快過期，否則緩存的數據就會因已經失效而產生臟讀，影響結果的正確性。

緩存除了可以加快數據訪問速度，還可以減輕后端應用和數據存儲的負載壓力，網站數據庫幾乎都是按照有緩存的前提進行負載能力設計的。例如：高并發業務接口多數都是進行業務數據的查詢，包括：商品列表，商品信息，用戶信息，紅包信息等，這些數據都是不會經常變化，并且持久化在數據庫中。

高并發的情況下直接連接從庫做查詢操作，多臺從庫服務器也抗不住這么大量的連接請求數，單臺數據庫服務器允許的最大連接數量是有限的。

這種高并發的業務接口要考慮緩存設計。數據不經常變化，我們可以把數據進行緩存，緩存的方式有很多種，一般的：應用服務器直接 Cache 內存，主流的：存儲在 Memcached、Redis 內存數據庫。其中，Cache 是直接存儲在應用服務器中，讀取速度快。內存數據庫服務器允許連接數可以支撐到很大，而且數據存儲在內存，讀取速度快，再加上主從集群，可以支撐很大的并發查詢。

這樣不僅可以提高接口響應速度，也可以節約服務器帶寬，雖然有些服務器帶寬是按流量計費，但是也不是絕對無限的，在高并發的時候服務器帶寬也可能導致請求響應慢的問題。

CDN 靜態化數據

隨著業務不斷發展，用戶規模越來越大，不同地區的用戶訪問網站時，速度差別也極大。為了提供更好的用戶體驗，網站需要加速網站訪問速度。主要手段有使用 CDN 和反向代理。

高并發請求數據不變化的情況下如果可以不請求自己的服務器獲取數據那就可以減少服務器的資源壓力。對于更新頻繁度不高，并且數據允許短時間內的延遲，可以通過數據靜態化成 JSON，XML，HTML等數據文件上傳 CDN，在拉取數據的時候優先到 CDN 拉取，如果沒有獲取到數據再從緩存，數據庫中獲取，當管理人員操作后臺編輯數據再重新生成靜態文件上傳同步到 CDN，這樣在高并發的時候可以使數據的獲取命中在 CDN 服務器上。

CDN 和反向代理的基本原理都是緩存，區別在于 CDN 部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據；而反向代理則部署在網站的中心機房，當用戶請求到達中心機房后，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存著用戶請求的資源，就將其直接返回給用戶。

CDN 節點同步有一定的延遲性，所以找一個靠譜的 CDN 服務器商也很重要。

異步

應用系統的一個重要目標是降低耦合性。系統解耦的手段除了前面提到的分層、分割、分布式等，還有一個重要手段是異步，業務之間的消息傳遞不是同步調用，而是將一個業務操作分成多個階段，每個階段之間通過共享數據的方式異步執行進行協作。

異步架構是典型的生產者消費者模式，兩者不存在直接調用，只要保持數據結構不變，彼此功能實現可以隨意變化而不互相影響，這對網站擴展新功能非常便利。除此之外，使用異步消息隊列還有如下優點：

提高系統可用性：消費者服務器發生故障，數據會在消息隊列服務器中存儲堆積，生產者服務器可以繼續處理業務請求，系統整體表現無故障。消費者服務器恢復正常后，繼續處理消息隊列中的數據。

加快網站響應速度：處在業務處理前端的生產者服務器在處理完業務請求后，將數據寫入消息隊列，不需要等待消費者服務器處理就可以返回，響應延遲減少。

消除并發訪問高峰：用戶訪問網站是隨機的，存在訪問高峰和低谷。使用消息隊列將突然增加的訪問請求數據放入消息隊列中，等待消費者服務器依次處理，就不會對整個網站負載造成太大壓力。

例如：在高并發業務中如果涉及到數據庫操作，主要壓力都是在數據庫服務器上面，雖然使用主從分離，但是數據庫操作都是在主庫上操作，單臺數據庫服務器連接池允許的最大連接數量是有限的。當連接數量達到最大值的時候，其他需要連接數據操作的請求就需要等待有空閑的連接，這樣高并發的時候很多請求就會出現 connection time out 的情況。

像這種涉及數據庫操作的高并發的業務，就要考慮使用異步了。客戶端發起接口請求，服務端快速響應，客戶端展示結果給用戶，數據庫操作通過異步同步。

使用消息隊列，將入庫的內容 enqueue 到消息隊列中，業務接口快速響應給用戶結果。

然后再寫個獨立程序從消息隊列 dequeue 數據出來進行入庫操作，入庫成功后刷新用戶相關緩存，如果入庫失敗記錄日志，方便反饋查詢和重新持久化。

這樣一來數據庫操作就只有一個程序（多線程）來完成，不會給數據帶來壓力。但需要注意的是，使用異步方式處理業務可能會對用戶體驗、業務流程造成影響，需要網站產品設計方面的支持。

冗余

網站需要7×24小時連續運行，但是服務器隨時可能出現故障，特別是服務器規模比較大時，出現某臺服務器宕機是必然事件。

要想保證在服務器宕機的情況下網站依然可以繼續服務，不丟失數據，就需要一定程度的服務器冗余運行，數據冗余備份，這樣當某臺服務器宕機時，可以將其上的服務和數據訪問轉移到其他機器上。

訪問和負載很小的服務也必須部署至少兩臺服務器構成一個集群，其目的就是通過冗余實現服務高可用。數據庫除了定期存檔進行冷備份外，還需要對數據庫進行主從分離，實時同步實現熱備份。

自動化

目前應用系統的自動化架構設計主要集中在發布運維方面，通過自動化可以減少人工的操作的成本，而且可以快速操作，避免人為操作上面的失誤。包括：

自動化發布

自動化代碼管理

自動化測試

自動化安全監測

自動化部署

自動化監控

自動化告警

自動化失效轉移與恢復

自動化降級和自動化分配資源

等

安全

系統在安全架構方面也積累了許多模式：

通過密碼和手機校驗碼進行身份認證；

登錄、交易等操作需要對網絡通信進行加密，網站服務器上存儲的敏感數據如用戶信息等也進行加密處理；

為了防止機器人程序濫用網絡資源攻擊網站，網站使用驗證碼進行識別；

對于常見的用于攻擊網站的 XSS 攻擊、SQL 注入、進行編碼轉換等相應處理；

對于垃圾信息、敏感信息進行過濾；

對交易轉賬等重要操作根據交易模式和交易信息進行風險控制。

分布式 網站

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。