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

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

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

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

存儲和服務如何結合在一起？

什么時候（或為什么）我需要用到這個？

全棧之路該怎么走？

各技術的主流框架選擇

本文目錄：

Web / Application Servers

負載均衡器: Load Balancer

域名解析系統，DNS

HTTPS / SSL證書

數據庫，Database

Blob / 文件存儲

內容分發網絡（CDN）

緩存服務：Caching Service

消息隊列：Message queue

Web Servers服務器：Web服務器，使用http協議向Web提供內容。

Application Servers：應用程序服務器，托管并公開業務邏輯和進程。

例如Node.js，Python，PHP，Java，C＃或Ruby。

每種語言都有自己的“Web框架”（例如基于 Java 的 Spring，基于 Ruby 的 Rails，基于C＃的ASP.NET MVC或基于Node.js的Express）。

這些框架使開發人員能夠編寫更少的代碼來處理數據請求。

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

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、嗶哩嗶哩、頭條、騰訊云

快速重定向某些請求而不必通過后端代碼執行此操作（狀態碼404頁面）。

存儲在Web服務器的文件系統上的靜態內容（例如圖像，CSS，JS）比通過后端代碼訪問更快。

某些服務器端語言（例如PHP）沒有內置的生產級Web服務器，因此需要通過專用的Web服務器進程啟動。

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

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

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

Tomcat 只能跟 Java配合，Node.js只能跟JavaScript。

Apache 能和其他語言配合（通常跟 PHP 配合居多），但需要借助不同的模塊。

Nginx則是通過端口轉發，所以Apache和Nginx可以和各種編程語言一起使用

Nginx和Apache是純web服務器，不具備解析動態語言（比如php文件和js文件）的能力.

Tomcat和Node.js 能夠解析這些腳本語言，提供應用服務，Web Server算是附加的功能。

安裝這些工具和后端項目的Web服務器計算機，本身可以采用以下幾種形式：

一臺物理機器

虛擬專用服務器，即我們通常所說的VPS（例如華為云，阿里云等）

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

托管虛擬機實例（例如AWS EC2，Google Compute Engine）

平臺即服務（PaaS）主機，云服務提供商（例如Heroku，AWS Elastic Beanstalk）

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

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

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

1. 物理機是這樣的：

2. 虛擬機是這樣的：

3. Dokcer是這樣的：

2. 負載均衡器: Load Balancer

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

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

第4層（傳輸層）：：

根據網絡和傳輸層協議（IP，TCP，FTP，UDP）中的數據進行操作。

不認識http協議，對應其他TCP應用，例如基于C/S開發的ERP等系統。

第7層（應用層）：：

根據應用層協議（如HTTP）中的數據分發請求。

認識http協議，所以其應用范圍主要是眾多的網站或者內部信息平臺等基于B/S開發的系統。

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

硬件負載均衡： 對應第四層，如F5負載均衡器

軟件負載均衡： 對應第七層，如LVS、Nginx和HAproxy

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

輪詢調度，Round robin，RR

加權輪詢，Weighted round robin，WRB

最少連接數，Least connections

最短的響應時間，Least response time

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

它通過確保單個Web服務器不會被所有請求淹沒，來幫助維持一致的響應時間，因此處理每個請求的速度會相對慢些。

它保持高可用性。如果服務器崩潰，所有后續客戶端請求仍將成功，因為它們將路由到健康的服務器，并且用戶不會發現任何問題。

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

如果你的Web應用程序使用負載均衡器，則應將域名配置為指向負載均衡器的域名或IP地址。

如果您沒有使用負載均衡器，那么您可以將域名直接指向應用程序服務器的域名/ IP地址。

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

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

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

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

你可以使用LetsEncrypt免費生成證書。

如果你使用的是云基礎架構，則可以使用托管服務，例如AWS Certificate Manager。這允許你創建并自動續訂SSL證書并將其分發到應用程序服務器，負載平衡器和CDN服務器。

只有中大型的HTTPS證書授權中心才會被瀏覽器承認，否則會顯示為不安全，需要手動信任。

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

域名型SSL證書，簡稱DV SSL

企業型SSL證書，簡稱OV SSL

增強型SSL證書，簡稱EV SSL。

它們之間都有一定的區別，認證級別也都不同，各自適合不同規模類型的網站安裝。

5. 數據庫，Database

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

早期比較流行的數據庫模型有三種，分別為層次式數據庫、網絡式數據庫和關系型數據庫。

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

關系數據庫（例如MySql，Postgres，SQLServer，Oracle，SQLite）已經存在了40多年，并且一直是大多數Web應用程序的支柱。

而在過去十年左右的時間里，NoSQL數據庫（例如MongoDB，Cassandra，CouchDB，DynamoDB）在Web應用程序中變得越來越普遍，主要是因為它們具有可擴展性優勢和數據結構靈活性。

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

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

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

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

數據庫服務器的基礎方案分為三種：

一主一備的架構（主備式）

一主一從的架構（主從式）

互為主從的架構（主主式）

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

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

其思路也特別的簡單：

將數據庫部署到兩臺機器，其中一臺機器(代號A)作為日常提供數據讀寫服務的機器，稱為「主機」。

另外一臺機器(代號B)并不提供線上服務，但會實時的將「主機」的數據同步過來，稱為「備機」。

一旦「主機」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續提供服務。

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

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

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

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

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

主從式架構中的「從機」雖然也在隨時隨刻提供服務，但是它只提供「讀」服務，并不提供「寫」服務。

「主機」會實時的將線上數據同步到「從機」，以保證「從機」能夠正常的提供讀操作。

這種架構相比較主備式，對資源是一種節約，畢竟「從機」也在提供服務，沒有白白的浪費。并且在「主機」出現故障時，在人工介入之前，好歹「從機」也是能夠提供數據的「讀」操作的，畢竟大多數業務都是「讀」多「寫」少，因此對穩定性又提高了一個層次。

缺點就是架構稍微復雜了一點，畢竟「主機」和「從機」都有「讀」服務，那么前端業務系統就需要用一定策略去判斷該路由到哪一臺去讀取數據。還有就是，延遲問題，「主機」的數據同步到「從機」難免會有一定程度的延遲，這個延遲可能會對數據實時性要求較高的業務有一定影響。

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

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

采用 互為主從架構 有個復雜點就是，因為兩臺主機都接受寫數據，那就需要將寫的最新數據實時的同步給對方，需要將數據進行兩臺主機的雙向復制。

而雙向復制不可避免的會在一定程度上帶來數據延遲、極端情況下甚至有數據丟失等問題。

在實際業務中，有些業務數據對一致性要求是非常高的，并不能接受數據的延遲、丟失，因此這類業務也不適合互為主從的模式，比如金融業務。

但是我們互聯網業務中大多數場景還是沒有這么高要求的，所以這種模式對于一般場景還是用的蠻多。

至于數據庫集群方案，我暫時沒看懂，就不寫了。。。

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

前端網站資源，如圖像，Javascript，CSS，字體，音頻，視頻文件。

用戶通過表單上傳的各類文件。

云服務供應商不是將這些存儲在數據庫中，而是提供專用服務來存儲這些服務，例如AWS Simple Storage Service（S3），Azure，Google Cloud Storage和阿里云OSS等。

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

Blob 存儲用于：

直接向瀏覽器提供圖像或文檔。

存儲文件以供分布式訪問。

對視頻和音頻進行流式處理。

向日志文件進行寫入。

存儲用于備份和還原、災難恢復及存檔的數據。

存儲數據以供本地或 Azure 托管服務執行分析

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

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

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

CDN是云供應商提供的服務，它們在全球范圍內分布有“邊緣服務器”。

這些邊緣服務器從“原點”（例如，blob /文件存儲位置）獲取文件的副本。你的前端Web應用程序將指向 其CDN URL，而不是指向靜態資產的Blob存儲URL。

現在，客戶端和“邊緣”之間的距離遠不是幾千英里的往返，而是更少，因此文件的獲取速度更快。

使用了CDN的網站訪問：

7.1 CDN工作流

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

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

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

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

緩存服務本質上是一種特殊類型的數據庫。 緩存采用鍵值存儲的形式，其中鍵是應用程序代碼用于查詢數據的字符串（例如DailySiteStats_2018-10-17），值是緩存的實際數據。緩存的數據通常完全保存在內存中，這使得從緩存中檢索數據的速度非常快。

常見的緩存服務是Redis和Memcached。AWS通過其Elasticache服務提供這兩者的托管版本。

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

適用于批處理任務和分離應用程序的異步消息收發

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

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

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

從隊列中讀取消息。

開始處理視頻。

完成后，保存視頻的編碼副本。

向用戶發送通知電子郵件（消息）。

從隊列中刪除消息。

這里有2個架構組件：

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

調度CRON作業以觸發應用程序服務器上安裝的指定代碼，以便按特定計劃從隊列中讀取。

將消息添加到隊列時，使用FaaS平臺調用工作器代碼。

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

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

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

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

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

1. 注冊后的初始化

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

調用郵件服務器發送郵件、調用促銷服務贈送優惠劵、下發用戶數據到客戶關系系統等。

那么這時候我們將這些操作去監聽MQ，當用戶注冊成功過后，通過MQ通知其他業務進行操作。確保注冊用戶的性能。

2. 后臺發布商品

后臺發布商品的時候:

商品數據需要從數據庫中轉換成搜索引擎數據（基于elasticsearch）

那么我們應該將商品寫入數據庫后，再寫入到MQ，然后通過監聽MQ來生成elasticsearch對應的數據。

3.支付超時取消

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

以前我們可能是定時任務循環查詢，然后取消訂單。

實際上，我更推薦類似延遲MQ的方式，避免了很多無效的數據庫查詢，將一個MQ設置為24小時后才讓消費者消費掉，這樣很大程度上能減輕服務器壓力。

4. 支付完成后通知

支付完成后，需要及時的通知子系統（進銷存系統發貨，用戶服務積分，發送短信）進行下一步操作。

但是，支付回調我們都是需要保證高性能的，所以，應該直接修改數據庫狀態，存入MQ，讓MQ通知子系統做其他非實時的業務操作。這樣能保證核心業務的高效及時。

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

只是覺得好玩，就按其大綱，重寫總結一下，有說錯的地方多擔待。

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

好了，又水完一篇，入正題：

微信：huab119

郵箱：454274033@qq.com

需要轉載到公眾號的喊我加下白名單就行了。

「Vue實踐」5分鐘擼一個Vue CLI 插件

「Vue實踐」武裝你的前端項目

「中高級前端面試」JavaScript手寫代碼無敵秘籍

「從源碼中學習」面試官都不知道的Vue題目答案

「從源碼中學習」Vue源碼中的JS騷操作

「從源碼中學習」徹底理解Vue選項Props

「Vue實踐」項目升級vue-cli3的正確姿勢

為何你始終理解不了JavaScript作用域鏈？