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

時間 2019-11-05

標籤之路 web 前端開發後端指南欄目 HTML 简体版

原文原文鏈接

前言

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

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

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

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

不管你的動機是什麼，這個體系裏都有你想要了解或學習的東西：vue

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

本文目錄：node

1. `Web / Application Servers`

Web Servers服務器：Web服務器，使用http協議向Web提供內容。
Application Servers：應用程序服務器，託管並公開業務邏輯和進程。

1.1 服務器端語言

可使用不一樣的服務器端語言編寫代碼：

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

1.2 後端語言選擇

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

PHP：nginx

使用者多，算是最普及的後端語言。
簡單易學，但因一些古老的設計飽受批評。
網站範例：Facebook、Wordpress、新浪微博。

Java：git

老牌語言，開發統治者。國內外工做需求穩定，應用層面廣。
開發相較起來較慢，沒那麼適合新手。
網站範例：Linkedin、Amazon、淘寶。

Ruby：github

開發快速，國內外不少 bootcamp 都以此語言教後端。
適不適合新手學飽受爭議。
網站範例：Airbnb、Twitter。

Python:web

語法簡單易學，數據分析與資料探勘相關應用多。
單獨使用 Python 相較起來運行性能較差。
網站範例：Instagram、Reddit、知乎。

JavaScript (Node.js):

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

Go:

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

1.2 Web服務器

即 Web Server，除了託管自定義應用程序代碼以外，一些Web應用程序體系結構還使用「Web服務器進程」，例如 Apache HTTP Server或 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 可以解析這些腳本語言，提供應用服務，Web Server算是附加的功能。

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. 負載均衡器: `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服務器不會被全部請求淹沒，來幫助維持一致的響應時間，所以處理每一個請求的速度會相對慢些。
它保持高可用性。若是服務器崩潰，全部後續客戶端請求仍將成功，由於它們將路由到健康的服務器，而且用戶不會發現任何問題。

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免費生成證書。
若是你使用的是雲基礎架構，則可使用託管服務，例如AWS Certificate Manager。這容許你建立並自動續訂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. 一主一從的架構(主從式)

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

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

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

互爲主從的架構是指兩臺機器本身都是主機，而且也都是做爲對方的從機。兩臺機器都提供完整的讀寫服務，所以無需切換，客戶機在調用的時候隨機挑選一臺便可，當其中一臺宕機了，另一臺還能夠繼續服務。

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

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

6. `Blob` / 文件存儲

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

前端網站資源，如圖像，Javascript，CSS，字體，音頻，視頻文件。
用戶經過表單上傳的各種文件。

雲服務供應商不是將這些存儲在數據庫中，而是提供專用服務來存儲這些服務，例如AWS Simple Storage Service（S3），Azure，Google Cloud Storage和阿里雲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. 緩存服務：`Caching Service`

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

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

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

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

常見的緩存服務是Redis和Memcached。AWS經過其Elasticache服務提供這二者的託管版本。

8.1 `Redis`和`Memcached`對比

Redis和Memcached是都是主流的開源內存數據存儲。雖然它們既易於使用又提供高性能，但在選擇引擎時須要考慮重要的差別。Memcached是爲簡單而設計的，而Redis提供了豐富的功能，使其可以普遍用於各類用例。

	Memcached	Redis
亞毫秒級延遲	是	是
開發人員易用性	是	是
數據分區	是	是
多語言支持	是	是
高級數據結構	-	是
多線程架構	是	-
快照	-	是
複製	-	是
發佈/訂閱	-	是
Lua腳本	-	是
地理空間支持	-	是

亞毫秒級延遲:

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

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

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

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

而後，你將擁有一個能夠執行如下操做的工做任務流：

從隊列中讀取消息。
開始處理視頻。
完成後，保存視頻的編碼副本。
向用戶發送通知電子郵件（消息）。
從隊列中刪除消息。

這裏有2個架構組件：

您能夠經過如下幾種方式實現worker任務：

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

9.1 Message queue 簡介

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

如今經常使用的MQ組件有activeMQ、rabbitMQ、rocketMQ、zeroMQ 還有近年來火熱的kafka,從某些場景來講也是MQ，固然kafka的功能更增強大，雖然不一樣的MQ都有本身的特色和優點，可是，無論是哪一種MQ，都有MQ自己自帶的一些特色。

9.2 MQ主要特性

特性	說明
推送或拉取傳送	拉取是指不斷查詢隊列以獲取新消息。推送是指系統在有可用消息時通知用戶 (也稱爲發佈/訂閱消息收發)。您還可使用長輪詢讓拉取等待指定的時間，以便新消息在完成以前到達。
定時或延遲傳送	支持爲消息設置特定的傳送時間。若是須要爲全部消息設置相同延遲，能夠設置一個延遲隊列。
至少一次傳送	消息隊列能夠存儲多個消息副本以實現冗餘和高可用性，並在發生通訊故障或錯誤的狀況下從新發送消息，以確保它們至少通過一次傳送。
確切一次傳送	在不允許重複的狀況下，FIFO (先進先出) 消息隊列會經過自動篩選重複來確保每一個消息均精確地傳輸了一次 (且只有一次)。
FIFO (先進先出) 隊列	在這些隊列中，首先接受處理的是最先的 (或第一個) 條目，有時稱爲「隊首」。
消息優先級	一般狀況下，您能夠爲消息分配優先級，以肯定要在隊列中添加該消息的位置，從而確保優先級較高的消息位於隊列前端並獲得優先處理。