【面試精選】關於大型網站系統架構你不得不懂的10個問題

時間 2019-12-06

標籤面試精選關於大型網站系統架構不得不懂的問題欄目網站開發简体版

原文原文鏈接

該文已加入筆主的開源項目——JavaGuide（一份涵蓋大部分Java程序員所須要掌握的核心知識的文檔類項目),地址: https://github.com/Snailclimb/JavaGuide 。以爲不錯的話，記得點個Star。

下面這些問題都是一線大廠的真實面試問題，不管是對你面試仍是說拓寬知識面都頗有幫助。以前發過一篇8 張圖讀懂大型網站技術架構能夠做爲不太瞭解大型網站系統技術架構朋友的入門文章。html

git

面試

1. 你使用過哪些組件或者方法來提高網站性能,可用性以及併發量

提升硬件能力、增長系統服務器。（當服務器增長到某個程度的時候系統所能提供的併發訪問量幾乎不變，因此不能根本解決問題）
使用緩存（本地緩存：本地可使用JDK自帶的 Map、Guava Cache.分佈式緩存：Redis、Memcache.本地緩存不適用於提升系統併發量，通常是用處用在程序中。好比Spring是如何實現單例的呢？你們若是看過源碼的話，應該知道，Spiring把已經初始過的變量放在一個Map中，下次再要使用這個變量的時候，先判斷Map中有沒有，這也就是系統中常見的單例模式的實現。）
消息隊列 （解耦+削峯+異步）
採用分佈式開發 （不一樣的服務部署在不一樣的機器節點上，而且一個服務也能夠部署在多臺機器上，而後利用 Nginx 負載均衡訪問。這樣就解決了單點部署(All In)的缺點，大大提升的系統併發量）
數據庫分庫（讀寫分離）、分表（水平分表、垂直分表）
採用集羣 （多臺機器提供相同的服務）
CDN 加速 (將一些靜態資源好比圖片、視頻等等緩存到離用戶最近的網絡節點)
瀏覽器緩存
使用合適的鏈接池（數據庫鏈接池、線程池等等）
適當使用多線程進行開發。

2. 設計高可用系統的經常使用手段

降級： 服務降級是當服務器壓力劇增的狀況下，根據當前業務狀況及流量對一些服務和頁面有策略的降級，以此釋放服務器資源以保證核心任務的正常運行。降級每每會指定不一樣的級別，面臨不一樣的異常等級執行不一樣的處理。根據服務方式：能夠拒接服務，能夠延遲服務，也有時候能夠隨機服務。根據服務範圍：能夠砍掉某個功能，也能夠砍掉某些模塊。總之服務降級須要根據不一樣的業務需求採用不一樣的降級策略。主要的目的就是服務雖然有損可是總比沒有好；
限流： 防止惡意請求流量、惡意攻擊，或者防止流量超出系統峯值；
緩存： 避免大量請求直接落到數據庫，將數據庫擊垮；
超時和重試機制： 避免請求堆積形成雪崩；
回滾機制： 快速修復錯誤版本。

3. 現代互聯網應用系統一般具備哪些特色?

高併發，大流量；
高可用：系統7×24小時不間斷服務；
海量數據：須要存儲、管理海量數據，須要使用大量服務器；
用戶分佈普遍，網絡狀況複雜：許多大型互聯網都是爲全球用戶提供服務的，用戶分佈範圍廣，各地網絡狀況千差萬別；
安全環境惡劣：因爲互聯網的開放性，使得互聯網更容易受到攻擊，大型網站幾乎天天都會被黑客攻擊；
需求快速變動，發佈頻繁：和傳統軟件的版本發佈頻率不一樣，互聯網產品爲快速適應市場，知足用戶需求，其產品發佈頻率是極高的；
漸進式發展：與傳統軟件產品或企業應用系統一開始就規劃好所有的功能和非功能需求不一樣，幾乎全部的大型互聯網網站都是從一個小網站開始，漸進地發展起來。

4. 談談你對微服務領域的瞭解和認識

如今大公司都在用而且將來的趨勢都是 Spring Cloud，而阿里開源的 Spring Cloud Alibaba 也是 Spring Cloud 規範的實現。spring

咱們一般把 Spring Cloud 理解爲一系列開源組件的集合，可是 Spring Cloud並非等同於 Spring Cloud Netflix 的 Ribbon、Feign、Eureka（中止更新）、Hystrix 這一套組件，而是抽象了一套通用的開發模式。它的目的是經過抽象出這套通用的模式，讓開發者更快更好地開發業務。可是這套開發模式運行時的實際載體，仍是依賴於 RPC、網關、服務發現、配置管理、限流熔斷、分佈式鏈路跟蹤等組件的具體實現。數據庫

Spring Cloud Alibaba 是官方認證的新一套 Spring Cloud 規範的實現,Spring Cloud Alibaba 是一套國產開源產品集合，後續還會有中文 reference 和一些原理分析文章，因此，這對於國內的開發者是很是棒的一件事。阿里的這一舉動勢必會推進國內微服務技術的發展，由於在沒有 Spring Cloud Alibaba 以前，咱們的第一選擇是 Spring Cloud Netflix，可是它們的文檔都是英文的，出問題後排查也比較困難，在國內並非有特別多的人精通。Spring Cloud Alibaba 由阿里開源組件和阿里雲產品組件兩部分組成，其致力於提供微服務一站式解決方案，方便開發者經過 Spring Cloud 編程模型輕鬆開發微服務應用。apache

另外，Apache Dubbo Ecosystem 是圍繞 Apache Dubbo 打造的微服務生態，是通過生產驗證的微服務的最佳實踐組合。在阿里巴巴的微服務解決方案中，Dubbo、Nacos 和 Sentinel，以及後續將開源的微服務組件，都是 Dubbo EcoSystem 的一部分。阿里後續也會將 Dubbo EcoSystem 集成到 Spring Cloud 的生態中。編程

5. 談談你對 Dubbo 和 Spring Cloud 的認識(二者關係)

具體能夠看公衆號-阿里巴巴中間件的這篇文章:獨家解讀：Dubbo Ecosystem - 從微服務框架到微服務生態後端

Dubbo 與 Spring Cloud 並非競爭關係，Dubbo 做爲成熟的 RPC 框架，其易用性、擴展性和健壯性已獲得業界的承認。將來 Dubbo 將會做爲 Spring Cloud Alibaba 的 RPC 組件，並與 Spring Cloud 原生的 Feign 以及 RestTemplate 進行無縫整合，實現「零」成本遷移。

在阿里巴巴的微服務解決方案中，Dubbo、Nacos 和 Sentinel，以及後續將開源的微服務組件，都是 Dubbo EcoSystem 的一部分。咱們後續也會將 Dubbo EcoSystem 集成到 Spring Cloud 的生態中。

6. 性能測試瞭解嗎?說說你知道的性能測試工具?

性能測試指經過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。性能測試是總稱，一般細分爲：

基準測試： 在給系統施加較低壓力時，查看系統的運行情況並記錄相關數作爲基礎參考
負載測試：是指對系統不斷地增長壓力或增長必定壓力下的持續時間，直到系統的某項或多項性能指標達到安全臨界值，例如某種資源已經達到飽和狀態等。此時繼續加壓，系統處理能力會降低。
壓力測試： 超過安全負載狀況下，不斷施加壓力（增長併發請求），直到系統崩潰或沒法處理任何請求，依此得到系統最大壓力承受能力。
穩定性測試： 被測試系統在特定硬件、軟件、網絡環境下，加載必定業務壓力（模擬生產環境不一樣時間點、不均勻請求，呈波浪特性）運行一段較長時間，以此檢測系統是否穩定。

後端程序員或者測試日常比較經常使用的測試工具是 JMeter（官網：https://jmeter.apache.org/）。Apache JMeter 是一款基於Java的壓力測試工具(100％純Java應用程序)，旨在加載測試功能行爲和測量性能。它最初被設計用於 Web 應用測試但後來擴展到其餘測試領域。

7. 對於一個單體應用系統,隨着產品使用的用戶愈來愈多,網站的流量會增長,最終單臺服務器沒法處理那麼大的流量怎麼辦?

這個時候就要考慮擴容了。《億級流量網站架構核心技術》這本書上面介紹到咱們能夠考慮下面幾步來解決這個問題：

第一步，能夠考慮簡單的擴容來解決問題。好比增長系統的服務器，提升硬件能力等等。
第二步，若是簡單擴容搞不定，就須要水平拆分和垂直拆分數據／應用來提高系統的伸縮性，即經過擴容提高系統負載能力。
第三步，若是經過水平拆分／垂直拆分仍是搞不定，那就須要根據現有系統特性，架構層面進行重構甚至是從新設計，即推倒重來。

對於系統設計，理想的狀況下應支持線性擴容和彈性擴容，即在系統瓶頸時，只須要增長機器就能夠解決系統瓶頸，如下降延遲提高吞吐量，從而實現擴容需求。

若是你想擴容，則支持水平/垂直伸縮是前提。在進行拆分時，必定要清楚知道本身的目的是什麼，拆分後帶來的問題如何解決，拆分後若是沒有獲得任何收益就不要爲了
拆而拆，即不要過分拆分，要適合本身的業務。

8. 大表優化的常見手段

當MySQL單表記錄數過大時，數據庫的CRUD性能會明顯降低，一些常見的優化措施以下：

限定數據的範圍： 務必禁止不帶任何限制數據範圍條件的查詢語句。好比：咱們當用戶在查詢訂單歷史的時候，咱們能夠控制在一個月的範圍內。；
讀/寫分離： 經典的數據庫拆分方案，主庫負責寫，從庫負責讀；
垂直分區： 根據數據庫裏面數據表的相關性進行拆分。 例如，用戶表中既有用戶的登陸信息又有用戶的基本信息，能夠將用戶表拆分紅兩個單獨的表，甚至放到單獨的庫作分庫。簡單來講垂直拆分是指數據表列的拆分，把一張列比較多的表拆分爲多張表。 以下圖所示，這樣來講你們應該就更容易理解了。垂直拆分的優勢： 可使得行數據變小，在查詢時減小讀取的Block數，減小I/O次數。此外，垂直分區能夠簡化表的結構，易於維護。垂直拆分的缺點： 主鍵會出現冗餘，須要管理冗餘列，並會引發Join操做，能夠經過在應用層進行Join來解決。此外，垂直分區會讓事務變得更加複雜；
水平分區： 保持數據表結構不變，經過某種策略存儲數據分片。這樣每一片數據分散到不一樣的表或者庫中，達到了分佈式的目的。水平拆分能夠支撐很是大的數據量。水平拆分是指數據錶行的拆分，表的行數超過200萬行時，就會變慢，這時能夠把一張的表的數據拆成多張表來存放。舉個例子：咱們能夠將用戶信息表拆分紅多個用戶信息表，這樣就能夠避免單一表數據量過大對性能形成影響。水平拆分能夠支持很是大的數據量。須要注意的一點是:分表僅僅是解決了單一表數據過大的問題，但因爲表的數據仍是在同一臺機器上，其實對於提高MySQL併發能力沒有什麼意義，因此 水平拆分最好分庫 。水平拆分可以 支持很是大的數據量存儲，應用端改造也少，但 分片事務難以解決 ，跨界點Join性能較差，邏輯複雜。《Java工程師修煉之道》的做者推薦 儘可能不要對數據進行分片，由於拆分會帶來邏輯、部署、運維的各類複雜度 ，通常的數據表在優化得當的狀況下支撐千萬如下的數據量是沒有太大問題的。若是實在要分片，儘可能選擇客戶端分片架構，這樣能夠減小一次和中間件的網絡I/O。

下面補充一下數據庫分片的兩種常見方案：

客戶端代理： 分片邏輯在應用端，封裝在jar包中，經過修改或者封裝JDBC層來實現。 噹噹網的 Sharding-JDBC 、阿里的TDDL是兩種比較經常使用的實現。
中間件代理： 在應用和數據中間加了一個代理層。分片邏輯統一維護在中間件服務中。 咱們如今談的 Mycat 、360的Atlas、網易的DDB等等都是這種架構的實現。

9. 在系統中使用消息隊列能帶來什麼好處?

《大型網站技術架構》第四章和第七章均有提到消息隊列對應用性能及擴展性的提高。

1) 經過異步處理提升系統性能

如上圖，在不使用消息隊列服務器的時候，用戶的請求數據直接寫入數據庫，在高併發的狀況下數據庫壓力劇增，使得響應速度變慢。可是在使用消息隊列以後，用戶的請求數據發送給消息隊列以後當即返回，再由消息隊列的消費者進程從消息隊列中獲取數據，異步寫入數據庫。因爲消息隊列服務器處理速度快於數據庫（消息隊列也比數據庫有更好的伸縮性），所以響應速度獲得大幅改善。

經過以上分析咱們能夠得出消息隊列具備很好的削峯做用的功能——即經過異步處理，將短期高併發產生的事務消息存儲在消息隊列中，從而削平高峯期的併發事務。 舉例：在電子商務一些秒殺、促銷活動中，合理使用消息隊列能夠有效抵禦促銷活動剛開始大量訂單涌入對系統的衝擊。以下圖所示：

由於用戶請求數據寫入消息隊列以後就當即返回給用戶了，可是請求數據在後續的業務校驗、寫數據庫等操做中可能失敗。所以使用消息隊列進行異步處理以後，須要適當修改業務流程進行配合，好比用戶在提交訂單以後，訂單數據寫入消息隊列，不能當即返回用戶訂單提交成功，須要在消息隊列的訂單消費者進程真正處理完該訂單以後，甚至出庫後，再經過電子郵件或短信通知用戶訂單成功，以避免交易糾紛。這就相似咱們平時手機訂火車票和電影票。

2) 下降系統耦合性

咱們知道模塊分佈式部署之後聚合方式一般有兩種：1.分佈式消息隊列和2.分佈式服務。

先來簡單說一下分佈式服務：

目前使用比較多的用來構建SOA（Service Oriented Architecture面向服務體系結構）的分佈式服務框架是阿里巴巴開源的Dubbo.若是想深刻了解Dubbo的能夠看我寫的關於Dubbo的這一篇文章：《高性能優秀的服務框架-dubbo介紹》：http://www.javashuo.com/article/p-elojngof-dp.html

再來談咱們的分佈式消息隊列：

咱們知道若是模塊之間不存在直接調用，那麼新增模塊或者修改模塊就對其餘模塊影響較小，這樣系統的可擴展性無疑更好一些。

咱們最多見的事件驅動架構相似生產者消費者模式，在大型網站中一般用利用消息隊列實現事件驅動結構。以下圖所示：

消息隊列使利用發佈-訂閱模式工做，消息發送者（生產者）發佈消息，一個或多個消息接受者（消費者）訂閱消息。 從上圖能夠看到消息發送者（生產者）和消息接受者（消費者）之間沒有直接耦合，消息發送者將消息發送至分佈式消息隊列即結束對消息的處理，消息接受者從分佈式消息隊列獲取該消息後進行後續處理，並不須要知道該消息從何而來。對新增業務，只要對該類消息感興趣，便可訂閱該消息，對原有系統和業務沒有任何影響，從而實現網站業務的可擴展性設計。

消息接受者對消息進行過濾、處理、包裝後，構形成一個新的消息類型，將消息繼續發送出去，等待其餘消息接受者訂閱該消息。所以基於事件（消息對象）驅動的業務架構能夠是一系列流程。

另外爲了不消息隊列服務器宕機形成消息丟失，會將成功發送到消息隊列的消息存儲在消息生產者服務器上，等消息真正被消費者服務器處理後才刪除消息。在消息隊列服務器宕機後，生產者服務器會選擇分佈式消息隊列服務器集羣中的其餘服務器發佈消息。

備註： 不要認爲消息隊列只能利用發佈-訂閱模式工做，只不過在解耦這個特定業務環境下是使用發佈-訂閱模式的，好比在咱們的ActiveMQ消息隊列中還有點對點工做模式，具體的會在後面的文章給你們詳細介紹，這一篇文章主要仍是讓你們對消息隊列有一個更透徹的瞭解。

這個問題通常會在上一個問題問完以後，緊接着被問到。「使用消息隊列會帶來什麼問題？」這個問題要引發重視，通常咱們都會考慮使用消息隊列會帶來的好處而忽略它帶來的問題！

10. 說說本身對 CAP 定理,BASE 理論的瞭解

CAP 定理

在理論計算機科學中，CAP定理（CAP theorem），又被稱做布魯爾定理（Brewer's theorem），它指出對於一個分佈式計算系統來講，不可能同時知足如下三點：

一致性（Consistence） :全部節點訪問同一份最新的數據副本
可用性（Availability）:每次請求都能獲取到非錯的響應——可是不保證獲取的數據爲最新數據
分區容錯性（Partition tolerance） : 分佈式系統在遇到某節點或網絡分區故障的時候，仍然可以對外提供知足一致性和可用性的服務。

CAP僅適用於原子讀寫的NOSQL場景中，並不適合數據庫系統。如今的分佈式系統具備更多特性好比擴展性、可用性等等，在進行系統設計和開發時，咱們不該該僅僅侷限在CAP問題上。

注意：不是所謂的3選2（不要被網上大多數文章誤導了）:

大部分人解釋這必定律時，經常簡單的表述爲：「一致性、可用性、分區容忍性三者你只能同時達到其中兩個，不可能同時達到」。實際上這是一個很是具備誤導性質的說法，並且在CAP理論誕生12年以後，CAP之父也在2012年重寫了以前的論文。

當發生網絡分區的時候，若是咱們要繼續服務，那麼強一致性和可用性只能2選1。也就是說當網絡分區以後P是前提，決定了P以後纔有C和A的選擇。也就是說分區容錯性（Partition tolerance）咱們是必需要實現的。

我在網上找了不少文章想看一下有沒有文章提到這個不是所謂的3選2，用百度半天沒找到了一篇，用谷歌搜索找到一篇比較不錯的，若是想深刻學習一下CAP就看這篇文章把，我這裏就很少BB了：《分佈式系統之CAP理論》： http://www.cnblogs.com/hxsyl/p/4381980.html

BASE 理論

BASE 是 Basically Available（基本可用） 、Soft-state（軟狀態） 和 Eventually Consistent（最終一致性） 三個短語的縮寫。BASE理論是對CAP中一致性和可用性權衡的結果，其來源於對大規模互聯網系統分佈式實踐的總結，是基於CAP定理逐步演化而來的，它大大下降了咱們對系統的要求。

BASE理論的核心思想： 即便沒法作到強一致性，但每一個應用均可以根據自身業務特色，採用適當的方式來使系統達到最終一致性。也就是犧牲數據的一致性來知足系統的高可用性，系統中一部分數據不可用或者不一致時，仍須要保持系統總體「主要可用」。

BASE理論三要素：

基本可用： 基本可用是指分佈式系統在出現不可預知故障的時候，容許損失部分可用性。可是，這毫不等價於系統不可用。好比： ①響應時間上的損失:正常狀況下，一個在線搜索引擎須要在0.5秒以內返回給用戶相應的查詢結果，但因爲出現故障，查詢結果的響應時間增長了1~2秒；②系統功能上的損失：正常狀況下，在一個電子商務網站上進行購物的時候，消費者幾乎可以順利完成每一筆訂單，可是在一些節日大促購物高峯的時候，因爲消費者的購物行爲激增，爲了保護購物系統的穩定性，部分消費者可能會被引導到一個降級頁面；
軟狀態： 軟狀態指容許系統中的數據存在中間狀態，並認爲該中間狀態的存在不會影響系統的總體可用性，即容許系統在不一樣節點的數據副本之間進行數據同步的過程存在延時；
最終一致性： 最終一致性強調的是系統中全部的數據副本，在通過一段時間的同步後，最終可以達到一個一致的狀態。所以，最終一致性的本質是須要系統保證最終數據可以達到一致，而不須要實時保證系統數據的強一致性。