譯者： 讀完這篇部落格，你就可以回答一個經典的面試題：當你訪問Google時，到底發生了什麼？

• 原文：Web Architecture 101
• 譯者：Fundebug

為了保證可讀性，本文采用意譯而非直譯。另外，本文版權歸原作者所有，翻譯僅用於學習。

當我還是小白的時候，如果知道Web應用架構就好了！

上圖展示了我們Storyblocks的架構，對於初學者來說，似乎有些複雜。

下面我通過使用者訪問Strong Beautiful Fog And Sunbeams In The Forest頁面的處理過程來簡單說明各個架構要素的作用：

• 當用戶點選
  Strong Beautiful Fog And Sunbeams In The Forest訪問我們的圖片服務時，瀏覽器會先給DNS(域名解析服務)伺服器傳送請求，獲取IP地址，然後再給Storyblocks伺服器傳送請求。
• 使用者的請求會到達我們的Load Balancer(負載均衡服務)，Load Balancer會隨機選擇我們10個Web Application Server(網頁應用服務)中的一個來處理這個請求。
• Web Application Server會先在Caching Service(快取服務)讀取圖片資訊，然後再從Database(資料庫)中讀取其他資料。
• 當Web Application Server發現圖片的color profile(顏色分析)還沒有計算時，會給Job Queue(任務佇列)
  傳送一個color profile任務。
• Job Server(任務服務)會從Job Queue中獲取corlor profile任務進行非同步計算，計算結束之後再更新資料庫。
• Web Application Server會給search service(搜尋服務)傳送搜尋請求，以圖片的名字作為關鍵詞，來查詢類似的圖片。
• 如果使用者恰好是登入狀態，Web Application Server會去訪問Account Service(賬號伺服器)來獲取賬號資訊。
• Web Application Server會給data firehose(資料載入服務)傳送一個Page View(網頁瀏覽)
  事件，並把它記錄到我們的Cloud Storage System(儲存雲)，最終載入到我們的Data Warehouse(資料倉庫)中。資料分析師會通過Data Warehouse中的資料來分析我們的執行情況，輔助我們的商業決策。
• Web Application Server會渲染出HTML，並把它通過Load Balancer傳送給使用者的瀏覽器。頁面中的JavaScript和CSS檔案儲存在我們的Cloud Storage System(儲存雲)中，並通過CDN進行分發。因此，使用者的瀏覽器會直接訪問CDN來獲取JavaScript和CSS檔案。
• 最後，瀏覽器再渲染整個頁面給使用者看。

我們的Strong Beautiful Fog And Sunbeams In The Forest頁面有一張非常漂亮的森林圖片，網頁截圖如下：

接下來，我會依次介紹每一個要素。

1. DNS

DNS全稱為Domain Name Server，即域名解析服務，它是網際網路的基礎。提供域名(比如google.com)，DNS可以返回其IP地址(比如85.129.83.120)。有了IP地址，使用者的計算機才知道應該訪問哪個伺服器。這一點類似於手機號碼，域名與IP的區別等價於”給馬雲打電話”和”給201-867–5309打電話”。以前你需要通過電話本查詢馬雲的手機號碼，那DNS就類似於網際網路的電話本，你需要它來查詢某個域名的IP。

2. Load Balancer

圖片來源

Load Balancer(負載均衡伺服器)是我們對應用進行橫向擴充套件的關鍵。它會把請求分發到多個Web Application Server(網頁應用服務)中的一個，這些Application Server執行的程式是一樣的，對同一個請求的處理方式完全相同，它們會把請求返回給客戶端。Load Balancer的作用就是分發請求，這樣，當某個伺服器宕機時，仍然可以保證服務。

目前，業界最受歡迎的Load Balancer是Nginx，Fundebug用的也是Nginx。

3. Web Application Servers

圖片來源

Web Application Server，即網頁應用服務，理解起來相對簡單一些。它們負責執行核心的業務邏輯，處理使用者的請求，並返回HTML給使用者瀏覽器。為了完成工作，它們通常需要訪問多種後端服務，比如資料庫、快取、任務佇列、搜尋服務等。在Load Balancer中提到過了，Web Application Server通常有多個副本，它們從Load Balancer獲取使用者請求。

Web Application Server需要使用特定的程式語言(Java, Node.js, Ruby, PHP, Scala, Java, C# .NET等) 和MVC框架(Node.js有Express, Ruby有Rails, Scala有Play, PHP有Laravel等)來實現。Fundebug後端語言用的是Node.js，框架用的是Express。

4. Database

圖片來源

現代應用基本上都需要使用1個或者多個Dabase(資料庫)來儲存資料。利用資料庫，我們可以方便地對資料進行各種處理，比如定義資料結構、插入資料、查詢資料、更新資料、刪除資料、對資料進行計算等。一般來說，Web Application Servers會直接訪問資料庫，Job Server也一樣。另外，每一種後端服務都有可能會需要獨立的資料庫。

目前，業界最受歡迎的開源資料庫技術有MySQL、MongoDB等。Fundebug用的是MongoDB。

5. Caching Service

圖片來源

Caching Service，即快取服務，提供簡單的鍵值對儲存和讀取服務，它可以讓資料的儲存和讀取的時間複雜度接近於O(1)。對於複雜的計算，我們會將計算結果儲存到快取中，這樣下次需要結果時，就不需要重新計算了，可以從快取中直接讀取結果。Web Application Servers會將資料庫查詢、外部呼叫結果、某個URL對應的HTML檔案等儲存到快取中。

下面是一些真實的快取例項：

• Google會快取常見查詢的結果，比如”dog”或者”Taylor Swift”，而不是每次去重新計算。
• Facebook會快取你登陸時看到的資料，比如動態、朋友等，細節可以閱讀Scaling Memcache at Facebook。
• 我們Storyblocks會快取React服務端渲染的HTML，搜尋結果等。

目前，業界最受歡迎的快取技術是Redis和Memcache。Fundebug用的是Redis。

如何你希望實時監控線上應用的BUG，歡迎免費試用Fundebug!

6. Job Queue & Servers

圖片來源

大多數網頁應用都需要在後臺進行一些非同步計算，這些計算並非直接與響應使用者請求有關。比如，Google需要爬取整個網際網路的網頁，併為其建立索引，這個計算不是在你搜索的時候進行，而是非同步進行，他們一直在更新網頁索引。

非同步計算有多種不同的方式，最普遍的方式就是Job Queue，即任務佇列。它由兩部分組成，一個儲存任務的佇列，以及一個或者多個執行任務的服務。

Job Queue中儲存了需要進行非同步計算的任務。最簡單的任務佇列是first-in-first-out (FIFO)，即先進先出，而更為複雜的佇列會有優先順序機制。對於 Web Application Servers來說，當需要計算某個任務時，將這個任務加入佇列就可以了。

在Storyblocks，我們利用Job Queue執行非常多的後臺任務，比如編碼視訊和圖片、為CSV加標籤、統計使用者資料、傳送密碼重置的郵件等。剛開始我們用的是FIFO佇列，後來我們增加了優先順序機制來保證響應時間要求高的任務(比如傳送密碼重置郵件)可以儘快處理。

Job server(任務服務)負責執行任務，它們不斷從佇列中獲取任務然後執行。Job Server也可以使用各種後端語言編寫，Fundebug用的是Node.js。

目前，業界流行的Job Queue技術有RabbitMQ、ActiveMQ、Kafka等，Fundebug用的是RabbitMQ。

7. Full-text Search Service

大多Web應用都會支援搜尋功能，使用者輸入關鍵詞，應用返回相關結果。搜尋技術也被稱作full-text search，即全文檢索，是通過inverted index(倒排索引)來是的。如下圖所示：

事實上，資料庫比如MySQL會支援全文檢索功能，但是一般來說我們會採用獨立的Search Service(搜尋服務)來計算和儲存倒排索引，並提供搜尋介面。目前最受歡迎的全文檢索技術是Elasticsearch，當然還有其他選擇，比如 Sphinx和Apache Solr，Fundebug用的是Elasticsearch。

8. Services

當應用規模足夠大時，很可能需要將一些服務拆分出來。這些服務並不向外部提供，而是提供給Web Application Servers以及其他內部服務。在Storyblocks，我們有很多這樣的服務：

• Account service(賬號服務)：管理我們所有站點的使用者賬號資料，提供統一的賬號系統。
• Content service(內容服務)：管理我們所有視訊、音訊和圖片的元資料，它會提供下載內容和檢視歷史的介面。
• Payment service(支付服務)：提供介面來結算使用者的信用卡。
• HTML → PDF service(HTML轉PDF服務)：提供HTML轉PDF的介面。

Services也可以使用各種後端語言編寫，Fundebug用的是Node.js。

9. Data

圖片來源

AI時代，一個公司的成敗取決於它如何利用資料。一個典型的資料處理處理流程有3個主要步驟：

• Web Application Servers負責收集資料，通常是一些使用者行為記錄，將資料傳送給Data Firhose(資料載入服務)，Data Firhose負責將流資料可靠地載入到資料儲存和分析工具。AWS Kinesis和Kafka可以作為Data Firhose。
• Data Firhose將收集的原始資料以及初步處理過的資料儲存到資料雲中。AWS Kinesis Data Firehose可以方便地將資料儲存到AWS 雲端儲存(S3)中。
• 初步處理過的資料可以載入到Data Warehouse(資料倉庫)進行處理。我們使用的是AWS Redshift，大型公司有些使用Oracle的Data Warehouse。如果資料非常大的話，可能需要使用Hadoop。

還有，我們Storyblocks會每天晚上將Web Application Servers和各種Services的執行資料載入到Redshift中。這樣，我們的資料分析師可以結合所有資料進行綜合分析。

Fundebug使用Kafka作為Data Firhose，使用阿里雲的物件儲存 OSS作為資料倉庫，使用Hadoop進行離線資料分析。

10. Cloud storage

Cloud storage即資料儲存雲，可以通過安全、可擴充套件的資料儲存服務，可以儲存任意資料，並可以通過HTTP介面進行操作和管理。亞馬遜的AWS 雲端儲存(S3)是當前最受歡迎的資料儲存雲，我們Storyblocks依賴它來儲存視訊、音訊、圖片、JavaScript、CSS以及前文提到過的使用者行為資料等。

Fundebug使用阿里雲的物件儲存 OSS以及騰訊雲的物件儲存 COS作為資料儲存雲。

11. CDN

CDN，全稱為Content Delivery Network，即內容分發網路，它可以利用更靠近使用者的伺服器分發HTML、CSS、JavaScript和圖片等靜態資源，有效降低頁面載入時間。不再使用單個源伺服器提供服務，而是利用全球各地的伺服器作為快取伺服器分發靜態資源，使用者可以直接從更加靠近他們的快取伺服器下載資源，而不需要去訪問源伺服器。

如下圖所示，當西班牙的使用者給紐約的網站請求某個頁面時，靜態資源可以從英國的快取伺服器直接下載，而不再需要進行速度很慢的跨大西洋訪問：

圖片來源

這篇部落格詳細介紹了CDN技術。一般來說，網頁應用會使用CDN來分發CSS，JavaScript，圖片以及視訊等靜態資源。Fundebug使用騰訊雲以及七牛雲的CDN服務。

參考

• RabbitMQ入門教程
• 不要爭了！技術選擇沒那麼重要
• MongoDB之compact操作詳解
• MongoDB複合索引詳解
• 當Node.js遇見Docker

關於Fundebug

Fundebug專注於JavaScript、微信小程式、微信小遊戲、支付寶小程式、React Native、Node.js和Java實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了6億+錯誤事件，得到了Google、360、金山軟體等眾多知名使用者的認可。歡迎免費試用！

版權宣告:
轉載時請註明作者Fundebug以及本文地址：
https://blog.fundebug.com/2018/08/20/11-element-of-web-application/