「全棧之路」Web前端開發的後端指南

• 2019 年 10 月 4 日
• 筆記

前言

在若干次前的一場面試，面試官看我做過 python爬蟲/後端 的工作，順帶問了我些後端相關的問題：你覺得什麼是後端？

送命題。當時腦瓦特了，答曰：邏輯處理和數據增刪改查。。。

當場被懟得體無完膚，羞愧難當。事後再反思這問題，結合資料總結了一下。發現自己學過的 Redis、 Elasticsearch和 DNS等其實都屬於後端知識體系範疇。

在本文中，我將嘗試總結前端須知的後端體系入門。

無論你的動機是什麼，這個體系里都有你想要了解或學習的東西：

• 存儲和服務如何結合在一起？
• 什麼時候（或為什麼）我需要用到這個？
• 全棧之路該怎麼走？
• 各技術的主流框架選擇

本文目錄：

1. Web / Application Servers
2. 負載均衡器: Load Balancer
3. 域名解析系統，DNS
4. HTTPS / SSL證書
5. 資料庫，Database
6. Blob / 文件存儲
7. 內容分發網路（CDN）
8. 快取服務：Caching Service
9. 消息隊列：Message queue

1. Web/ApplicationServers

• WebServers伺服器：Web伺服器，使用 http協議向Web提供內容。
• ApplicationServers：應用程式伺服器，託管並公開業務邏輯和進程。

1.1 伺服器端語言

可以使用不同的伺服器端語言編寫程式碼：

• 例如 Node.js，Python，PHP，Java，C＃或 Ruby。
• 每種語言都有自己的「Web框架」（例如基於 Java 的 Spring，基於 Ruby 的 Rails，基於C＃的ASP.NET MVC或基於Node.js的Express）。
• 這些框架使開發人員能夠編寫更少的程式碼來處理數據請求。

1.2 後端語言選擇

而事實上，每個後端語言都有不一樣的特性，也都有各自的擁護者。哪一個語言最適合做為後端語言的入門一直都是沒有定論的問題。但為了讓我們可以對各語言有一個很簡單的概念，以下整理了各語言較常被提及的特色、在開發上比較被人詬病的點，以及有什麼樣的網站是透過該語言開發的：

PHP：

• 使用者多，算是最普及的後端語言。
• 簡單易學，但因一些古老的設計飽受批評。
• 網站範例：Facebook、 WordPress、新浪微博。 Java：
• 老牌語言，開發統治者。中國外工作需求穩定，應用層面廣。
• 開發相較起來較慢，沒那麽適合新手。
• 網站範例：Linkedin、 Amazon、淘寶。 Ruby：
• 開發快速，中國外很多 bootcamp 都以此語言教後端。
• 適不適合新手學飽受爭議。
• 網站範例：Airbnb、 Twitter。 Python:
• 語法簡單易學，數據分析與資料探勘相關應用多。
• 單獨使用 Python 相較起來運行性能較差。
• 網站範例：Instagram、 Reddit、知乎。

JavaScript(Node.js):

• 前端後端都可用 JS，高並發的情況執行效率極高
• 不適合 CPU 密集的應用
• 初創型企業首選
• 網站範例：Yahoo、 Walmart

Go:

• Google力推，有很完善的標準庫，效能強大堪比C系列。
• 目前學習資源較少（感謝偉大B站的付出，真香）
• 網站範例：Google、 Youtube、嗶哩嗶哩、頭條、騰訊雲

1.2 Web伺服器

即 WebServer，除了託管自定義應用程式程式碼之外，一些Web應用程式體系結構還使用「Web伺服器進程」，例如 ApacheHTTPServer或 Nginx。這些伺服器進程將在訪問後端程式碼之前攔截客戶端請求。使用它們有以下幾個原因：

• 快速重定向某些請求而不必通過後端程式碼執行此操作（狀態碼404頁面）。
• 存儲在Web伺服器的文件系統上的靜態內容（例如影像， CSS， JS）比通過後端程式碼訪問更快。
• 某些伺服器端語言（例如 PHP）沒有內置的生產級 Web伺服器，因此需要通過專用的 Web伺服器進程啟動。

至此，會引出一個疑問： Apache、 Nginx、 Tomcat和 Node.js四者的區別是什麼？

引用：apache、node.js、nginx、tomcat誰能幫我捋一捋關係？

是一類東西，又不是一類東西。

首先它們都能創建 Web伺服器，但是他們關注的點不一樣。

• Tomcat 只能跟 Java配合， Node.js只能跟 JavaScript。
• Apache 能和其他語言配合（通常跟 PHP 配合居多），但需要藉助不同的模組。
• Nginx則是通過埠轉發，所以 Apache和 Nginx可以和各種程式語言一起使用
• Nginx和 Apache是純 web伺服器，不具備解析動態語言（比如php文件和js文件）的能力.
• Tomcat和 Node.js 能夠解析這些腳本語言，提供應用服務， WebServer算是附加的功能。

1.3 web伺服器的形式（載體）

安裝這些工具和後端項目的 Web伺服器電腦，本身可以採用以下幾種形式：

• 一台物理機器
• 虛擬專用伺服器，即我們通常所說的VPS（例如華為雲，阿里雲等）

VPS實際上是被劃分為幾個部分的獨立伺服器，每個部分作為單獨的VPS伺服器進行銷售和使用。也就是說，它是一台可運行多個Web應用程式(網站、軟體等)的相對獨立的機器，每個用戶擁有部分資源。

• 託管虛擬機實例（例如AWS EC2，Google Compute Engine）
• 平台即服務（PaaS）主機，雲服務提供商（例如Heroku，AWS Elastic Beanstalk）

VPS是基於軟體層的虛擬化技術,具體來說就是作業系統的虛擬化, VM是基於硬體層的虛擬化技術, VM主機使用 vmware server搭建。

1.4 Dokcer，虛擬機與物理機

docker容器與虛擬機有什麼區別？

用個類比來極簡說明一下：

1. 物理機是這樣的：

2. 虛擬機是這樣的：

3. Dokcer是這樣的：

2. 負載均衡器: LoadBalancer

負載均衡是高可用網路基礎架構的的一個關鍵組成部分，有了負載均衡，我們通常可以將我們的應用伺服器部署多台，然後通過負載均衡將用戶的請求分發到不同的伺服器用來提高網站、應用、資料庫或其他服務的性能以及可靠性。

負載平衡器模型通常分為兩類：第4層（傳輸層）和第7層（應用層）。

第4層（傳輸層）：：

• 根據網路和傳輸層協議（IP，TCP，FTP，UDP）中的數據進行操作。
• 不認識http協議，對應其他TCP應用，例如基於C/S開發的ERP等系統。

第7層（傳輸層）：：

• 根據應用層協議（如HTTP）中的數據分發請求。
• 認識http協議，所以其應用範圍主要是眾多的網站或者內部資訊平台等基於B/S開發的系統。

負載均衡器主要分為硬體負載均衡和軟體負載均衡兩大類。

• 硬體負載均衡：對應第四層，如F5負載均衡器
• 軟體負載均衡：對應第七層，如 LVS、 Nginx和 HAproxy

兩種類型的負載平衡器都會收到請求，並根據配置的演算法將這些請求分發到特定的伺服器。一些行業標準演算法是：

• 輪詢調度， Roundrobin，RR
• 加權輪詢， Weightedround robin，WRB
• 最少連接數， Leastconnections
• 最短的響應時間， Leastresponse time

在 Web應用程式中使用負載均衡器有兩個主要好處：

• 它通過確保單個 Web伺服器不會被所有請求淹沒，來幫助維持一致的響應時間，因此處理每個請求的速度會相對慢些。
• 它保持高可用性。如果伺服器崩潰，所有後續客戶端請求仍將成功，因為它們將路由到健康的伺服器，並且用戶不會發現任何問題。

3. 域名解析系統， DNS

當用戶在其地址欄中輸入 URL時，瀏覽器將獲取 URL的域部分（例如 www.google.com）並調用DNS 。DNS解析發回該網站伺服器的IP地址位置（例如172.217.23.4）。一旦它具有IP地址，它就可以發送對網頁的實際請求。

• 如果你的Web應用程式使用負載均衡器，則應將域名配置為指向負載均衡器的域名或IP地址。
• 如果您沒有使用負載均衡器，那麼您可以將域名直接指嚮應用程式伺服器的域名/ IP地址。

大多數互聯網域名註冊服務（例如 GoDaddy，萬網等）都提供DNS管理控制台。這些允許你配置域名（和子域）以指嚮應用程式的位置。

如果你願意，還可以將您的域名伺服器轉移到阿里雲、騰訊雲等雲提供商，並從那裡進行管理。這樣做的好處是可以將所有應用程式環境配置保存在一個位置，並使其更易於自動化。

4. HTTPS/SSL證書

如果你正在構建Web應用程式（或靜態網站），則需要通過HTTPS提供服務，以確保用戶與伺服器之間的安全通訊。現在使用 HTTPS 也有 SEO的好處，所以沒有理由不使用它。

這意味著需要在後端安裝SSL證書。具體來說，需要在任何伺服器上安裝它們，這是客戶端請求的第一個聯繫點。這通常意味著負載均衡器和CDN伺服器，但如果你沒有使用負載均衡器，也可能是應用程式伺服器。

• 你可以使用 LetsEncrypt免費生成證書。
• 如果你使用的是雲基礎架構，則可以使用託管服務，例如 AWSCertificateManager。這允許你創建並自動續訂SSL證書並將其分發到應用程式伺服器，負載平衡器和CDN伺服器。
• 只有中大型的 HTTPS證書授權中心才會被瀏覽器承認，否則會顯示為不安全，需要手動信任。

目前SSL證書根據驗證級別分為三種類型

• 域名型SSL證書，簡稱DV SSL
• 企業型SSL證書，簡稱OV SSL
• 增強型SSL證書，簡稱EV SSL。
• 它們之間都有一定的區別，認證級別也都不同，各自適合不同規模類型的網站安裝。

一般情況下，企業類網站使用的OV SSL證書比較多，而且價格也適中，在大眾用戶可接受範圍內。

5. 資料庫，Database

幾乎所有Web應用程式都需要在某處保留數據。在大多數情況下，某處即某種形式的資料庫。資料庫的主要工作是將數據可靠地保存到永久存儲器中，並允許通過查詢檢索數據。它還可以圍繞它存儲的數據結構強制執行一些規則約束。

5.1 資料庫的種類

早期比較流行的資料庫模型有三種，分別為層次式資料庫、網路式資料庫和關係型資料庫。

而在當今的互聯網中，最常用的資料庫模型主要是兩種，即關係型（SQL）資料庫和非關係型（NoSQL）資料庫。

• 關係資料庫（例如 MySql，Postgres，SQLServer，Oracle，SQLite）已經存在了40多年，並且一直是大多數Web應用程式的支柱。
• 而在過去十年左右的時間裡，NoSQL資料庫（例如MongoDB，Cassandra，CouchDB，DynamoDB）在Web應用程式中變得越來越普遍，主要是因為它們具有可擴展性優勢和數據結構靈活性。

5.2 資料庫部署

你可以在一台伺服器上託管資料庫，但在生產方案中更常見的是將其託管在某種形式的集群2台或更多伺服器上。這可確保資料庫具有高可用性並降低數據丟失的風險，例如，如果一台伺服器的存儲損壞。

近年來，少數雲託管的「無伺服器資料庫」已經可用。這些是可以通過API調用的資料庫，但你無需設置伺服器來託管它們。除了處理諸如自動備份之類的事情之外，雲供應商還為您無形地執行此操作。這些示例包括 DynamoDB（NoSQL）， Firebase實時資料庫（ NoSQL）和 Aurora無伺服器（關係）。

5.3 資料庫基礎方案

來源：架構設計之「資料庫從主備到主主的高可用方案」

無論底層是關係型資料庫，還是NoSQL資料庫，無論是 Mysql 還是 Redis、MongoDB，在架構設計上都是相通的。

資料庫伺服器的基礎方案分為三種：

• 一主一備的架構（主備式）
• 一主一從的架構（主從式）
• 互為主從的架構（主主式）

1. 一主一備的架構(主備式)

主備式架構是雙機部署中最簡單的一種架構，幾乎市面上所有的資料庫系統都會自帶這個主備功能。

其思路也特別的簡單：

• 將資料庫部署到兩台機器，其中一台機器(代號A)作為日常提供數據讀寫服務的機器，稱為「主機」。
• 另外一台機器(代號B)並不提供線上服務，但會實時的將「主機」的數據同步過來，稱為「備機」。
• 一旦「主機」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。

這個架構的優缺點都很明顯，優點就是幾乎不需要做什麼開發改造，各類資料庫就支援這種模式，部署維護起來也簡單，並沒有引入額外的系統複雜度和瓶頸。

但是缺點呢，就是當「主機」出現故障的時候，需要人工去干預啊，運維同學很辛苦的，而且處理還不一定及時。再還有一個缺點就是，主備架構會造成嚴重浪費資源，畢竟需要一台與「主機」同等配置的「備機」長期備著，但又不作為線上服務來使用，你說浪費不浪費。

為了解決這個資源浪費問題，我們就得想一個把「備機」也用起來的方案：主從式架構。

2. 一主一從的架構(主從式)

主從式架構大體上與上述的主備式架構差不多。區別就是主備式的「備機」平時是不幹活的的，主要起到備份的作用。而主從式的「備機」改為了「從機」，平時也要提供服務，跟「主機」一樣隨時隨刻的在幹活的。

1. 主從式架構中的「從機」雖然也在隨時隨刻提供服務，但是它只提供「讀」服務，並不提供「寫」服務。
2. 「主機」會實時的將線上數據同步到「從機」，以保證「從機」能夠正常的提供讀操作。
3. 這種架構相比較主備式，對資源是一種節約，畢竟「從機」也在提供服務，沒有白白的浪費。並且在「主機」出現故障時，在人工介入之前，好歹「從機」也是能夠提供數據的「讀」操作的，畢竟大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。
4. 缺點就是架構稍微複雜了一點，畢竟「主機」和「從機」都有「讀」服務，那麼前端業務系統就需要用一定策略去判斷該路由到哪一台去讀取數據。還有就是，延遲問題，「主機」的數據同步到「從機」難免會有一定程度的延遲，這個延遲可能會對數據實時性要求較高的業務有一定影響。

3. 互為主從的架構(主主式)

互為主從的架構是指兩台機器自己都是主機，並且也都是作為對方的從機。兩台機器都提供完整的讀寫服務，因此無需切換，客戶機在調用的時候隨機挑選一台即可，當其中一台宕機了，另外一台還可以繼續服務。

• 採用 互為主從架構 有個複雜點就是，因為兩台主機都接受寫數據，那就需要將寫的最新數據實時的同步給對方，需要將數據進行兩台主機的雙向複製。
• 而雙向複製不可避免的會在一定程度上帶來數據延遲、極端情況下甚至有數據丟失等問題。
• 在實際業務中，有些業務數據對一致性要求是非常高的，並不能接受數據的延遲、丟失，因此這類業務也不適合互為主從的模式，比如金融業務。
• 但是我們互聯網業務中大多數場景還是沒有這麼高要求的，所以這種模式對於一般場景還是用的蠻多。

至於資料庫集群方案，我暫時沒看懂，就不寫了。。。

6. Blob / 文件存儲

雖然資料庫通常用於存儲動態數據（例如，由最終用戶或API客戶端生成），但是存在某些類別的數據（ 非結構化數據），這些數據不能由用戶改變或者基於文件而不適合資料庫存儲，例如：

• 前端網站資源，如影像， Javascript， CSS，字體，音頻，影片文件。
• 用戶通過表單上傳的各類文件。

雲服務供應商不是將這些存儲在資料庫中，而是提供專用服務來存儲這些服務，例如 AWSSimpleStorageService（S3）， Azure， GoogleCloudStorage和阿里雲 OSS等。

這樣做的好處是雲供應商可以安全地存儲文件，並可以為其製作冗餘副本，以最大限度地降低數據丟失的風險。

6.1 關於 Blob 存儲:

Blob 存儲用於：

• 直接向瀏覽器提供影像或文檔。
• 存儲文件以供分散式訪問。
• 對影片和音頻進行流式處理。
• 向日誌文件進行寫入。
• 存儲用於備份和還原、災難恢復及存檔的數據。
• 存儲數據以供本地或 Azure 託管服務執行分析

7. 內容分發網路（CDN）

Blob /文件存儲服務允許客戶端通過 HTTP端點訪問文件。例如，您的Web應用程式的HTML標記可以簡單地鏈接到AWS S3中存儲的影像和CSS文件的URL。傳統網路訪問：

但是，假設我的用戶位於中國，我的S3存儲位於美國西部 – 數據傳輸距離數千英里，因此我的用戶會看到延遲。

CDN是什麼？使用CDN有什麼優勢？

• CDN是雲供應商提供的服務，它們在全球範圍內分布有「邊緣伺服器」。
• 這些邊緣伺服器從「原點」（例如，blob /文件存儲位置）獲取文件的副本。你的前端Web應用程式將指向 其CDN URL，而不是指向靜態資產的Blob存儲URL。
• 現在，客戶端和「邊緣」之間的距離遠不是幾千英里的往返，而是更少，因此文件的獲取速度更快。

使用了CDN的網站訪問：

7.1 CDN工作流

通過權威DNS伺服器來實現最優節點的選擇，通過快取來減少源站的壓力。

8. 快取服務：CachingService

雖然 CDN是靜態文件的一種快取形式，但 Web應用程式可能需要臨時快取動態數據。

例如，假設存在一個資料庫查詢，該查詢對昨天的數據執行計算，其結果每天經常被成千上萬的用戶訪問。每次用戶請求此數據時聯繫資料庫就沒有任何意義。

對此的解決方案是使用高速快取服務在第一個用戶請求之後將結果存儲一段時間。通過快取將更快地提供對該數據的後續請求。

快取服務本質上是一種特殊類型的資料庫。 快取採用鍵值存儲的形式，其中鍵是應用程式程式碼用於查詢數據的字元串（例如DailySiteStats_2018-10-17），值是快取的實際數據。快取的數據通常完全保存在記憶體中，這使得從快取中檢索數據的速度非常快。

常見的快取服務是 Redis和 Memcached。AWS通過其 Elasticache服務提供這兩者的託管版本。

8.1 Redis和 Memcached對比

Redis和 Memcached是都是主流的開源記憶體數據存儲。雖然它們既易於使用又提供高性能，但在選擇引擎時需要考慮重要的差異。Memcached是為簡單而設計的，而 Redis提供了豐富的功能，使其能夠廣泛用於各種用例。

亞毫秒級延遲:

Redis和 Memcached都支援亞毫秒的響應時間。通過將數據存儲在記憶體中，它們可以比基於磁碟的資料庫更快地讀取數據。

開發人員易用性:

Redis和 Memcached在語法上都很容易使用，並且需要最少量的程式碼才能集成到您的應用程式中。

數據分區:

Redis和Memcached`都允許您在多個節點之間分發數據。這允許您在需求增長時向外擴展以更好地處理更多數據。

支援廣泛的程式語言:

Redis和 Memcached都有許多面向開發人員的開源客戶端。支援的語言包括 Java，Python，PHP，C，C++，C＃，JavaScript，Node.js，Ruby，Go等等。

高級數據結構:

除了字元串， Redis還支援列表，集合，有序集，哈希，位數組等。應用程式可以使用這些更高級的數據結構來支援各種用例。例如，你可以使用Redis排序集輕鬆實現遊戲排行榜，該排行榜保持按其排名排序的玩家列表。

多執行緒架構：

由於 Memcached是多執行緒的，因此它可以使用多個處理核心。這意味著您可以通過擴展計算容量來處理更多操作。

快照:

使用 Redis，您可以使用即時快照將數據保存在磁碟上，該快照可用於存檔或恢復。

複製:

Redis允許您創建 Redis主資料庫的多個副本。這允許您擴展資料庫讀取並具有高可用性集群。

發布/訂閱:

Redis支援使用模式匹配的 Pub/Sub消息傳遞，您可以將其用於高性能聊天室，實時評論流，社交媒體源和伺服器互通。

Lua腳本:

Redis允許您執行事務性 Lua腳本。腳本可以幫助您提高性能並簡化應用程式。

地理空間支援:

Redis具有專門用於大規模處理實時地理空間數據的命令。您可以執行諸如查找兩個元素（例如人或地點）之間的距離以及查找點的給定距離內的所有元素之類的操作。

9. 消息隊列：Message queue

適用於批處理任務和分離應用程式的非同步消息收發

有時，你程式需要執行的任務與響應用戶請求沒有直接關係。

例如，假設用戶上傳了需要編碼和水印的影片。但這是一項長期運行的任務，因此讓用戶在完成時等待是沒有意義的。更好的方法是非同步執行此操作。您的網路應用程式程式碼會在隊列中創建一條作業消息，並通知您的用戶，當水印影片準備就緒時，他們將收到一封電子郵件（消息）。

然後，你將擁有一個可以執行以下操作的工作任務流：

1. 從隊列中讀取消息。
2. 開始處理影片。
3. 完成後，保存影片的編碼副本。
4. 向用戶發送通知電子郵件（消息）。
5. 從隊列中刪除消息。

這裡有2個架構組件：

您可以通過以下幾種方式實現 worker任務：

• 調度 CRON作業以觸發應用程式伺服器上安裝的指定程式碼，以便按特定計劃從隊列中讀取。
• 將消息添加到隊列時，使用 FaaS平台調用工作器程式碼。

9.1 Message queue 簡介

消息隊列是一種非同步的服務間通訊方式，適用於無伺服器和微服務架構。消息在被處理和刪除之前一直存儲在隊列上。每條消息僅可被一位用戶處理一次。消息隊列可被用於分離重量級處理、緩衝或批處理工作以及緩解高峰期工作負載。

現在常用的MQ組件有 activeMQ、 rabbitMQ、 rocketMQ、 zeroMQ 還有近年來火熱的 kafka,從某些場景來說也是MQ，當然kafka的功能更加強大，雖然不同的MQ都有自己的特點和優勢，但是，不管是哪種MQ，都有MQ本身自帶的一些特點。

9.2 MQ主要特性

9.3 MQ應用示例

來源：MQ(消息隊列)常見的應用場景解析

我們的實際場景大概是一個基於微服務架構的電商系統，分為用戶微服務、商品微服務、訂單微服務、促銷微服務等。

基於微服務模式開發的系統，MQ的使用場景更多。這裡我們就列舉一下常見的應用示例。

1. 註冊後的初始化

註冊後我們可能需要做很多初始化的操作，如：

• 調用郵件伺服器發送郵件、調用促銷服務贈送優惠劵、下發用戶數據到客戶關係系統等。
• 那麼這時候我們將這些操作去監聽MQ，當用戶註冊成功過後，通過MQ通知其他業務進行操作。確保註冊用戶的性能。

2. 後台發布商品

後台發布商品的時候:

• 商品數據需要從資料庫中轉換成搜索引擎數據（基於 elasticsearch）
• 那麼我們應該將商品寫入資料庫後，再寫入到 MQ，然後通過監聽 MQ來生成 elasticsearch對應的數據。

3.支付超時取消

用戶下單後，24小時未支付，需要取消訂單。

• 以前我們可能是定時任務循環查詢，然後取消訂單。
• 實際上，我更推薦類似延遲MQ的方式，避免了很多無效的資料庫查詢，將一個MQ設置為24小時後才讓消費者消費掉，這樣很大程度上能減輕伺服器壓力。

4. 支付完成後通知

• 支付完成後，需要及時的通知子系統（進銷存系統發貨，用戶服務積分，發送簡訊）進行下一步操作。
• 但是，支付回調我們都是需要保證高性能的，所以，應該直接修改資料庫狀態，存入MQ，讓MQ通知子系統做其他非實時的業務操作。這樣能保證核心業務的高效及時。

免責聲明

逛國外社區看到這篇，覺得體系大綱挺簡潔明了的。

只是就重寫總結一下，有說錯的地方多擔待。

~~意思就是寫得略粗糙，別噴我。。。~~