本文目錄：

1. Web / Application Servers
2. 負(fù)載均衡器: Load Balancer
3. 域名解析系統(tǒng)，DNS
4. HTTPS / SSL證書
5. 數(shù)據(jù)庫(kù)，Database
6. Blob / 文件存儲(chǔ)
7. 內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）
8. 緩存服務(wù)：Caching Service
9. 消息隊(duì)列：Message queue

1. Web / Application Servers

• Web Servers服務(wù)器：Web服務(wù)器，使用http協(xié)議向Web提供內(nèi)容。
• Application Servers：應(yīng)用程序服務(wù)器，托管并公開業(yè)務(wù)邏輯和進(jìn)程。

1.1 服務(wù)器端語(yǔ)言

[圖片上傳失敗...(image-43bcc6-1630575081610)]
可以使用不同的服務(wù)器端語(yǔ)言編寫代碼：

• 例如Node.js，Python，PHP，Java，C＃或Ruby。
• 每種語(yǔ)言都有自己的“Web框架”（例如基于 Java 的 Spring，基于 Ruby 的 Rails，基于C＃的ASP.NET MVC或基于Node.js的Express）。
• 這些框架使開發(fā)人員能夠編寫更少的代碼來(lái)處理數(shù)據(jù)請(qǐng)求。

1.2 后端語(yǔ)言選擇

而事實(shí)上，每個(gè)后端語(yǔ)言都有不一樣的特性，也都有各自的擁護(hù)者。哪一個(gè)語(yǔ)言最適合做為后端語(yǔ)言的入門一直都是沒有定論的問(wèn)題。但為了讓我們可以對(duì)各語(yǔ)言有一個(gè)很簡(jiǎn)單的概念，以下整理了各語(yǔ)言較常被提及的特色、在開發(fā)上比較被人詬病的點(diǎn)，以及有什么樣的網(wǎng)站是透過(guò)該語(yǔ)言開發(fā)的：

PHP：

• 使用者多，算是最普及的后端語(yǔ)言。
• 簡(jiǎn)單易學(xué)，但因一些古老的設(shè)計(jì)飽受批評(píng)。
• 網(wǎng)站范例：Facebook、Wordpress、新浪微博。

Java：

• 老牌語(yǔ)言，開發(fā)統(tǒng)治者。國(guó)內(nèi)外工作需求穩(wěn)定，應(yīng)用層面廣。
• 開發(fā)相較起來(lái)較慢，沒那麼適合新手。
• 網(wǎng)站范例：Linkedin、Amazon、淘寶。

Ruby：

• 開發(fā)快速，國(guó)內(nèi)外很多 bootcamp 都以此語(yǔ)言教后端。
• 適不適合新手學(xué)飽受爭(zhēng)議。
• 網(wǎng)站范例：Airbnb、Twitter。

Python:

• 語(yǔ)法簡(jiǎn)單易學(xué)，數(shù)據(jù)分析與資料探勘相關(guān)應(yīng)用多。
• 單獨(dú)使用 Python 相較起來(lái)運(yùn)行性能較差。
• 網(wǎng)站范例：Instagram、Reddit、知乎。

JavaScript (Node.js):

• 前端后端都可用 JS，高并發(fā)的情況執(zhí)行效率極高
• 不適合 CPU 密集的應(yīng)用
• 初創(chuàng)型企業(yè)首選
• 網(wǎng)站范例：Yahoo、Walmart

Go:

• Google力推，有很完善的標(biāo)準(zhǔn)庫(kù)，效能強(qiáng)大堪比C系列。
• 目前學(xué)習(xí)資源較少（感謝偉大B站的付出，真香）
• 網(wǎng)站范例：Google、Youtube、嗶哩嗶哩、頭條、騰訊云

1.2 Web服務(wù)器

[圖片上傳失敗...(image-558681-1630575081610)]
即Web Server，除了托管自定義應(yīng)用程序代碼之外，一些Web應(yīng)用程序體系結(jié)構(gòu)還使用“Web服務(wù)器進(jìn)程”，例如Apache HTTP Server或Nginx。這些服務(wù)器進(jìn)程將在訪問(wèn)后端代碼之前攔截客戶端請(qǐng)求。使用它們有以下幾個(gè)原因：

• 快速重定向某些請(qǐng)求而不必通過(guò)后端代碼執(zhí)行此操作（狀態(tài)碼404頁(yè)面）。
• 存儲(chǔ)在Web服務(wù)器的文件系統(tǒng)上的靜態(tài)內(nèi)容（例如圖像，CSS，JS）比通過(guò)后端代碼訪問(wèn)更快。
• 某些服務(wù)器端語(yǔ)言（例如PHP）沒有內(nèi)置的生產(chǎn)級(jí)Web服務(wù)器，因此需要通過(guò)專用的Web服務(wù)器進(jìn)程啟動(dòng)。

至此，會(huì)引出一個(gè)疑問(wèn)：Apache、Nginx、Tomcat和Node.js四者的區(qū)別是什么？

引用：apache、node.js、nginx、tomcat誰(shuí)能幫我捋一捋關(guān)系？

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

[圖片上傳失敗...(image-db7fed-1630575081610)]
首先它們都能創(chuàng)建 Web服務(wù)器，但是他們關(guān)注的點(diǎn)不一樣。

• Tomcat 只能跟 Java配合，Node.js只能跟JavaScript。
• Apache 能和其他語(yǔ)言配合（通常跟 PHP 配合居多），但需要借助不同的模塊。
• Nginx則是通過(guò)端口轉(zhuǎn)發(fā)，所以Apache和Nginx可以和各種編程語(yǔ)言一起使用
• Nginx和Apache是純web服務(wù)器，不具備解析動(dòng)態(tài)語(yǔ)言（比如php文件和js文件）的能力.
• Tomcat和Node.js 能夠解析這些腳本語(yǔ)言，提供應(yīng)用服務(wù)，Web Server算是附加的功能。

1.3 web服務(wù)器的形式（載體）

安裝這些工具和后端項(xiàng)目的Web服務(wù)器計(jì)算機(jī)，本身可以采用以下幾種形式：

• 一臺(tái)物理機(jī)器
• 虛擬專用服務(wù)器，即我們通常所說(shuō)的VPS（例如華為云，阿里云等）

VPS實(shí)際上是被劃分為幾個(gè)部分的獨(dú)立服務(wù)器，每個(gè)部分作為單獨(dú)的VPS服務(wù)器進(jìn)行銷售和使用。也就是說(shuō)，它是一臺(tái)可運(yùn)行多個(gè)Web應(yīng)用程序(網(wǎng)站、軟件等)的相對(duì)獨(dú)立的機(jī)器，每個(gè)用戶擁有部分資源。

• 托管虛擬機(jī)實(shí)例（例如AWS EC2，Google Compute Engine）
• 平臺(tái)即服務(wù)（PaaS）主機(jī)，云服務(wù)提供商（例如Heroku，AWS Elastic Beanstalk）

[圖片上傳失敗...(image-b2b7da-1630575081610)]

VPS是基于軟件層的虛擬化技術(shù),具體來(lái)說(shuō)就是操作系統(tǒng)的虛擬化,VM是基于硬件層的虛擬化技術(shù),VM主機(jī)使用vmware server搭建。

1.4 Dokcer，虛擬機(jī)與物理機(jī)

docker容器與虛擬機(jī)有什么區(qū)別？

用個(gè)類比來(lái)極簡(jiǎn)說(shuō)明一下：

1. 物理機(jī)是這樣的：

2. 虛擬機(jī)是這樣的：

3. Dokcer是這樣的：

2. 負(fù)載均衡器: Load Balancer

負(fù)載均衡是高可用網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的的一個(gè)關(guān)鍵組成部分，有了負(fù)載均衡，我們通?？梢詫⑽覀兊膽?yīng)用服務(wù)器部署多臺(tái)，然后通過(guò)負(fù)載均衡將用戶的請(qǐng)求分發(fā)到不同的服務(wù)器用來(lái)提高網(wǎng)站、應(yīng)用、數(shù)據(jù)庫(kù)或其他服務(wù)的性能以及可靠性。

負(fù)載平衡器模型通常分為兩類：第4層（傳輸層）和第7層（應(yīng)用層）。

第4層（傳輸層）：：

• 根據(jù)網(wǎng)絡(luò)和傳輸層協(xié)議（IP，TCP，F(xiàn)TP，UDP）中的數(shù)據(jù)進(jìn)行操作。
• 不認(rèn)識(shí)http協(xié)議，對(duì)應(yīng)其他TCP應(yīng)用，例如基于C/S開發(fā)的ERP等系統(tǒng)。

第7層（應(yīng)用層）：：

• 根據(jù)應(yīng)用層協(xié)議（如HTTP）中的數(shù)據(jù)分發(fā)請(qǐng)求。
• 認(rèn)識(shí)http協(xié)議，所以其應(yīng)用范圍主要是眾多的網(wǎng)站或者內(nèi)部信息平臺(tái)等基于B/S開發(fā)的系統(tǒng)。

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

• 硬件負(fù)載均衡： 對(duì)應(yīng)第四層，如F5負(fù)載均衡器
• 軟件負(fù)載均衡： 對(duì)應(yīng)第七層，如LVS、Nginx和HAproxy

兩種類型的負(fù)載平衡器都會(huì)收到請(qǐng)求，并根據(jù)配置的算法將這些請(qǐng)求分發(fā)到特定的服務(wù)器。一些行業(yè)標(biāo)準(zhǔn)算法是：

• 輪詢調(diào)度，Round robin，RR
• 加權(quán)輪詢，Weighted round robin，WRB
• 最少連接數(shù)，Least connections
• 最短的響應(yīng)時(shí)間，Least response time

[圖片上傳失敗...(image-e28b62-1630575081610)]

在Web應(yīng)用程序中使用負(fù)載均衡器有兩個(gè)主要好處：

• 它通過(guò)確保單個(gè)Web服務(wù)器不會(huì)被所有請(qǐng)求淹沒，來(lái)幫助維持一致的響應(yīng)時(shí)間，因此處理每個(gè)請(qǐng)求的速度會(huì)相對(duì)慢些。
• 它保持高可用性。如果服務(wù)器崩潰，所有后續(xù)客戶端請(qǐng)求仍將成功，因?yàn)樗鼈儗⒙酚傻浇】档姆?wù)器，并且用戶不會(huì)發(fā)現(xiàn)任何問(wèn)題。

3. 域名解析系統(tǒng)，DNS

當(dāng)用戶在其地址欄中輸入URL時(shí)，瀏覽器將獲取URL的域部分（例如www.google.com）并調(diào)用DNS 。DNS解析發(fā)回該網(wǎng)站服務(wù)器的IP地址位置（例如172.217.23.4）。一旦它具有IP地址，它就可以發(fā)送對(duì)網(wǎng)頁(yè)的實(shí)際請(qǐng)求。

• 如果你的Web應(yīng)用程序使用負(fù)載均衡器，則應(yīng)將域名配置為指向負(fù)載均衡器的域名或IP地址。
• 如果您沒有使用負(fù)載均衡器，那么您可以將域名直接指向應(yīng)用程序服務(wù)器的域名/ IP地址。

大多數(shù)互聯(lián)網(wǎng)域名注冊(cè)服務(wù)（例如GoDaddy，萬(wàn)網(wǎng)等）都提供DNS管理控制臺(tái)。這些允許你配置域名（和子域）以指向應(yīng)用程序的位置。

如果你愿意，還可以將您的域名服務(wù)器轉(zhuǎn)移到阿里云、騰訊云等云提供商，并從那里進(jìn)行管理。這樣做的好處是可以將所有應(yīng)用程序環(huán)境配置保存在一個(gè)位置，并使其更易于自動(dòng)化。

4. HTTPS / SSL證書

如果你正在構(gòu)建Web應(yīng)用程序（或靜態(tài)網(wǎng)站），則需要通過(guò)HTTPS提供服務(wù)，以確保用戶與服務(wù)器之間的安全通信。現(xiàn)在使用HTTPS 也有SEO的好處，所以沒有理由不使用它。

這意味著需要在后端安裝SSL證書。具體來(lái)說(shuō)，需要在任何服務(wù)器上安裝它們，這是客戶端請(qǐng)求的第一個(gè)聯(lián)系點(diǎn)。這通常意味著負(fù)載均衡器和CDN服務(wù)器，但如果你沒有使用負(fù)載均衡器，也可能是應(yīng)用程序服務(wù)器。

[圖片上傳失敗...(image-42c15b-1630575081610)]

• 你可以使用LetsEncrypt免費(fèi)生成證書。
• 如果你使用的是云基礎(chǔ)架構(gòu)，則可以使用托管服務(wù)，例如AWS Certificate Manager。這允許你創(chuàng)建并自動(dòng)續(xù)訂SSL證書并將其分發(fā)到應(yīng)用程序服務(wù)器，負(fù)載平衡器和CDN服務(wù)器。
• 只有中大型的HTTPS證書授權(quán)中心才會(huì)被瀏覽器承認(rèn)，否則會(huì)顯示為不安全，需要手動(dòng)信任。

目前SSL證書根據(jù)驗(yàn)證級(jí)別分為三種類型

• 域名型SSL證書，簡(jiǎn)稱DV SSL
• 企業(yè)型SSL證書，簡(jiǎn)稱OV SSL
• 增強(qiáng)型SSL證書，簡(jiǎn)稱EV SSL。
• 它們之間都有一定的區(qū)別，認(rèn)證級(jí)別也都不同，各自適合不同規(guī)模類型的網(wǎng)站安裝。

[圖片上傳失敗...(image-e24d54-1630575081610)]
一般情況下，企業(yè)類網(wǎng)站使用的OV SSL證書比較多，而且價(jià)格也適中，在大眾用戶可接受范圍內(nèi)。

5. 數(shù)據(jù)庫(kù)，Database

幾乎所有Web應(yīng)用程序都需要在某處保留數(shù)據(jù)。在大多數(shù)情況下，某處即某種形式的數(shù)據(jù)庫(kù)。
數(shù)據(jù)庫(kù)的主要工作是將數(shù)據(jù)可靠地保存到永久存儲(chǔ)器中，并允許通過(guò)查詢檢索數(shù)據(jù)。它還可以圍繞它存儲(chǔ)的數(shù)據(jù)結(jié)構(gòu)強(qiáng)制執(zhí)行一些規(guī)則約束。

5.1 數(shù)據(jù)庫(kù)的種類

早期比較流行的數(shù)據(jù)庫(kù)模型有三種，分別為層次式數(shù)據(jù)庫(kù)、網(wǎng)絡(luò)式數(shù)據(jù)庫(kù)和關(guān)系型數(shù)據(jù)庫(kù)。

而在當(dāng)今的互聯(lián)網(wǎng)中，最常用的數(shù)據(jù)庫(kù)模型主要是兩種，即關(guān)系型（SQL）數(shù)據(jù)庫(kù)和非關(guān)系型（NoSQL）數(shù)據(jù)庫(kù)。

• 關(guān)系數(shù)據(jù)庫(kù)（例如MySql，Postgres，SQLServer，Oracle，SQLite）已經(jīng)存在了40多年，并且一直是大多數(shù)Web應(yīng)用程序的支柱。
• 而在過(guò)去十年左右的時(shí)間里，NoSQL數(shù)據(jù)庫(kù)（例如MongoDB，Cassandra，CouchDB，DynamoDB）在Web應(yīng)用程序中變得越來(lái)越普遍，主要是因?yàn)樗鼈兙哂锌蓴U(kuò)展性優(yōu)勢(shì)和數(shù)據(jù)結(jié)構(gòu)靈活性。

5.2 數(shù)據(jù)庫(kù)部署

你可以在一臺(tái)服務(wù)器上托管數(shù)據(jù)庫(kù)，但在生產(chǎn)方案中更常見的是將其托管在某種形式的集群2臺(tái)或更多服務(wù)器上。這可確保數(shù)據(jù)庫(kù)具有高可用性并降低數(shù)據(jù)丟失的風(fēng)險(xiǎn)，例如，如果一臺(tái)服務(wù)器的存儲(chǔ)損壞。

近年來(lái)，少數(shù)云托管的“無(wú)服務(wù)器數(shù)據(jù)庫(kù)”已經(jīng)可用。這些是可以通過(guò)API調(diào)用的數(shù)據(jù)庫(kù)，但你無(wú)需設(shè)置服務(wù)器來(lái)托管它們。除了處理諸如自動(dòng)備份之類的事情之外，云供應(yīng)商還為您無(wú)形地執(zhí)行此操作。這些示例包括DynamoDB（NoSQL），Firebase實(shí)時(shí)數(shù)據(jù)庫(kù)（NoSQL）和Aurora無(wú)服務(wù)器（關(guān)系）。

5.3 數(shù)據(jù)庫(kù)基礎(chǔ)方案

來(lái)源：架構(gòu)設(shè)計(jì)之「數(shù)據(jù)庫(kù)從主備到主主的高可用方案」

無(wú)論底層是關(guān)系型數(shù)據(jù)庫(kù)，還是NoSQL數(shù)據(jù)庫(kù)，無(wú)論是 Mysql 還是 Redis、MongoDB，在架構(gòu)設(shè)計(jì)上都是相通的。

數(shù)據(jù)庫(kù)服務(wù)器的基礎(chǔ)方案分為三種：

• 一主一備的架構(gòu)（主備式）
• 一主一從的架構(gòu)（主從式）
• 互為主從的架構(gòu)（主主式）

1. 一主一備的架構(gòu)(主備式)

主備式架構(gòu)是雙機(jī)部署中最簡(jiǎn)單的一種架構(gòu)，幾乎市面上所有的數(shù)據(jù)庫(kù)系統(tǒng)都會(huì)自帶這個(gè)主備功能。

[圖片上傳失敗...(image-84c29a-1630575081610)]

其思路也特別的簡(jiǎn)單：

• 將數(shù)據(jù)庫(kù)部署到兩臺(tái)機(jī)器，其中一臺(tái)機(jī)器(代號(hào)A)作為日常提供數(shù)據(jù)讀寫服務(wù)的機(jī)器，稱為「主機(jī)」。
• 另外一臺(tái)機(jī)器(代號(hào)B)并不提供線上服務(wù)，但會(huì)實(shí)時(shí)的將「主機(jī)」的數(shù)據(jù)同步過(guò)來(lái)，稱為「?jìng)錂C(jī)」。
• 一旦「主機(jī)」出了故障，通過(guò)人工的方式，手動(dòng)的將「主機(jī)」踢下線，將「?jìng)錂C(jī)」改為「主機(jī)」來(lái)繼續(xù)提供服務(wù)。

這個(gè)架構(gòu)的優(yōu)缺點(diǎn)都很明顯，優(yōu)點(diǎn)就是幾乎不需要做什么開發(fā)改造，各類數(shù)據(jù)庫(kù)就支持這種模式，部署維護(hù)起來(lái)也簡(jiǎn)單，并沒有引入額外的系統(tǒng)復(fù)雜度和瓶頸。

但是缺點(diǎn)呢，就是當(dāng)「主機(jī)」出現(xiàn)故障的時(shí)候，需要人工去干預(yù)啊，運(yùn)維同學(xué)很辛苦的，而且處理還不一定及時(shí)。再還有一個(gè)缺點(diǎn)就是，主備架構(gòu)會(huì)造成嚴(yán)重浪費(fèi)資源，畢竟需要一臺(tái)與「主機(jī)」同等配置的「?jìng)錂C(jī)」長(zhǎng)期備著，但又不作為線上服務(wù)來(lái)使用，你說(shuō)浪費(fèi)不浪費(fèi)。

為了解決這個(gè)資源浪費(fèi)問(wèn)題，我們就得想一個(gè)把「?jìng)錂C(jī)」也用起來(lái)的方案：主從式架構(gòu)。

2. 一主一從的架構(gòu)(主從式)

主從式架構(gòu)大體上與上述的主備式架構(gòu)差不多。區(qū)別就是主備式的「?jìng)錂C(jī)」平時(shí)是不干活的的，主要起到備份的作用。而主從式的「?jìng)錂C(jī)」改為了「從機(jī)」，平時(shí)也要提供服務(wù)，跟「主機(jī)」一樣隨時(shí)隨刻的在干活的。

[圖片上傳失敗...(image-10b3fc-1630575081610)]

1. 主從式架構(gòu)中的「從機(jī)」雖然也在隨時(shí)隨刻提供服務(wù)，但是它只提供「讀」服務(wù)，并不提供「寫」服務(wù)。
2. 「主機(jī)」會(huì)實(shí)時(shí)的將線上數(shù)據(jù)同步到「從機(jī)」，以保證「從機(jī)」能夠正常的提供讀操作。
3. 這種架構(gòu)相比較主備式，對(duì)資源是一種節(jié)約，畢竟「從機(jī)」也在提供服務(wù)，沒有白白的浪費(fèi)。并且在「主機(jī)」出現(xiàn)故障時(shí)，在人工介入之前，好歹「從機(jī)」也是能夠提供數(shù)據(jù)的「讀」操作的，畢竟大多數(shù)業(yè)務(wù)都是「讀」多「寫」少，因此對(duì)穩(wěn)定性又提高了一個(gè)層次。
4. 缺點(diǎn)就是架構(gòu)稍微復(fù)雜了一點(diǎn)，畢竟「主機(jī)」和「從機(jī)」都有「讀」服務(wù)，那么前端業(yè)務(wù)系統(tǒng)就需要用一定策略去判斷該路由到哪一臺(tái)去讀取數(shù)據(jù)。還有就是，延遲問(wèn)題，「主機(jī)」的數(shù)據(jù)同步到「從機(jī)」難免會(huì)有一定程度的延遲，這個(gè)延遲可能會(huì)對(duì)數(shù)據(jù)實(shí)時(shí)性要求較高的業(yè)務(wù)有一定影響。

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

互為主從的架構(gòu)是指兩臺(tái)機(jī)器自己都是主機(jī)，并且也都是作為對(duì)方的從機(jī)。兩臺(tái)機(jī)器都提供完整的讀寫服務(wù)，因此無(wú)需切換，客戶機(jī)在調(diào)用的時(shí)候隨機(jī)挑選一臺(tái)即可，當(dāng)其中一臺(tái)宕機(jī)了，另外一臺(tái)還可以繼續(xù)服務(wù)。
[圖片上傳失敗...(image-4c22b1-1630575081610)]

• 采用 互為主從架構(gòu) 有個(gè)復(fù)雜點(diǎn)就是，因?yàn)閮膳_(tái)主機(jī)都接受寫數(shù)據(jù)，那就需要將寫的最新數(shù)據(jù)實(shí)時(shí)的同步給對(duì)方，需要將數(shù)據(jù)進(jìn)行兩臺(tái)主機(jī)的雙向復(fù)制。
• 而雙向復(fù)制不可避免的會(huì)在一定程度上帶來(lái)數(shù)據(jù)延遲、極端情況下甚至有數(shù)據(jù)丟失等問(wèn)題。
• 在實(shí)際業(yè)務(wù)中，有些業(yè)務(wù)數(shù)據(jù)對(duì)一致性要求是非常高的，并不能接受數(shù)據(jù)的延遲、丟失，因此這類業(yè)務(wù)也不適合互為主從的模式，比如金融業(yè)務(wù)。
• 但是我們互聯(lián)網(wǎng)業(yè)務(wù)中大多數(shù)場(chǎng)景還是沒有這么高要求的，所以這種模式對(duì)于一般場(chǎng)景還是用的蠻多。

至于數(shù)據(jù)庫(kù)集群方案，我暫時(shí)沒看懂，就不寫了。。。

6. Blob / 文件存儲(chǔ)

雖然數(shù)據(jù)庫(kù)通常用于存儲(chǔ)動(dòng)態(tài)數(shù)據(jù)（例如，由最終用戶或API客戶端生成），但是存在某些類別的數(shù)據(jù)（ 非結(jié)構(gòu)化數(shù)據(jù)），這些數(shù)據(jù)不能由用戶改變或者基于文件而不適合數(shù)據(jù)庫(kù)存儲(chǔ)，例如：

• 前端網(wǎng)站資源，如圖像，Javascript，CSS，字體，音頻，視頻文件。
• 用戶通過(guò)表單上傳的各類文件。

云服務(wù)供應(yīng)商不是將這些存儲(chǔ)在數(shù)據(jù)庫(kù)中，而是提供專用服務(wù)來(lái)存儲(chǔ)這些服務(wù)，例如AWS Simple Storage Service（S3），Azure，Google Cloud Storage和阿里云OSS等。

這樣做的好處是云供應(yīng)商可以安全地存儲(chǔ)文件，并可以為其制作冗余副本，以最大限度地降低數(shù)據(jù)丟失的風(fēng)險(xiǎn)。

6.1 關(guān)于 Blob 存儲(chǔ):

Blob 存儲(chǔ)用于：

• 直接向?yàn)g覽器提供圖像或文檔。
• 存儲(chǔ)文件以供分布式訪問(wèn)。
• 對(duì)視頻和音頻進(jìn)行流式處理。
• 向日志文件進(jìn)行寫入。
• 存儲(chǔ)用于備份和還原、災(zāi)難恢復(fù)及存檔的數(shù)據(jù)。
• 存儲(chǔ)數(shù)據(jù)以供本地或 Azure 托管服務(wù)執(zhí)行分析

7. 內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）

Blob /文件存儲(chǔ)服務(wù)允許客戶端通過(guò)HTTP端點(diǎn)訪問(wèn)文件。例如，您的Web應(yīng)用程序的HTML標(biāo)記可以簡(jiǎn)單地鏈接到AWS S3中存儲(chǔ)的圖像和CSS文件的URL。
傳統(tǒng)網(wǎng)絡(luò)訪問(wèn)：
[圖片上傳失敗...(image-1f8428-1630575081610)]

但是，假設(shè)我的用戶位于中國(guó)，我的S3存儲(chǔ)位于美國(guó)西部 - 數(shù)據(jù)傳輸距離數(shù)千英里，因此我的用戶會(huì)看到延遲。

CDN是什么？使用CDN有什么優(yōu)勢(shì)？

• CDN是云供應(yīng)商提供的服務(wù)，它們?cè)谌蚍秶鷥?nèi)分布有“邊緣服務(wù)器”。
• 這些邊緣服務(wù)器從“原點(diǎn)”（例如，blob /文件存儲(chǔ)位置）獲取文件的副本。你的前端Web應(yīng)用程序?qū)⒅赶?其CDN URL，而不是指向靜態(tài)資產(chǎn)的Blob存儲(chǔ)URL。
• 現(xiàn)在，客戶端和“邊緣”之間的距離遠(yuǎn)不是幾千英里的往返，而是更少，因此文件的獲取速度更快。

使用了CDN的網(wǎng)站訪問(wèn)：

[圖片上傳失敗...(image-b89edb-1630575081610)][圖片上傳中...(111.jpg-e1a32b-1630631316755-0)]

7.1 CDN工作流

[圖片上傳失敗...(image-5cdee7-1630575081610)]

通過(guò)權(quán)威DNS服務(wù)器來(lái)實(shí)現(xiàn)最優(yōu)節(jié)點(diǎn)的選擇，通過(guò)緩存來(lái)減少源站的壓力。

8. 緩存服務(wù)：Caching Service

雖然CDN是靜態(tài)文件的一種緩存形式，但Web應(yīng)用程序可能需要臨時(shí)緩存動(dòng)態(tài)數(shù)據(jù)。

例如，假設(shè)存在一個(gè)數(shù)據(jù)庫(kù)查詢，該查詢對(duì)昨天的數(shù)據(jù)執(zhí)行計(jì)算，其結(jié)果每天經(jīng)常被成千上萬(wàn)的用戶訪問(wèn)。每次用戶請(qǐng)求此數(shù)據(jù)時(shí)聯(lián)系數(shù)據(jù)庫(kù)就沒有任何意義。

對(duì)此的解決方案是使用高速緩存服務(wù)在第一個(gè)用戶請(qǐng)求之后將結(jié)果存儲(chǔ)一段時(shí)間。通過(guò)緩存將更快地提供對(duì)該數(shù)據(jù)的后續(xù)請(qǐng)求。

緩存服務(wù)本質(zhì)上是一種特殊類型的數(shù)據(jù)庫(kù)。
緩存采用鍵值存儲(chǔ)的形式，其中鍵是應(yīng)用程序代碼用于查詢數(shù)據(jù)的字符串（例如DailySiteStats_2018-10-17），值是緩存的實(shí)際數(shù)據(jù)。緩存的數(shù)據(jù)通常完全保存在內(nèi)存中，這使得從緩存中檢索數(shù)據(jù)的速度非?？?。

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

8.1 Redis和Memcached對(duì)比

Redis和Memcached是都是主流的開源內(nèi)存數(shù)據(jù)存儲(chǔ)。雖然它們既易于使用又提供高性能，但在選擇引擎時(shí)需要考慮重要的差異。Memcached是為簡(jiǎn)單而設(shè)計(jì)的，而Redis提供了豐富的功能，使其能夠廣泛用于各種用例。

亞毫秒級(jí)延遲:

Redis和Memcached都支持亞毫秒的響應(yīng)時(shí)間。通過(guò)將數(shù)據(jù)存儲(chǔ)在內(nèi)存中，它們可以比基于磁盤的數(shù)據(jù)庫(kù)更快地讀取數(shù)據(jù)。

開發(fā)人員易用性:

Redis和Memcached在語(yǔ)法上都很容易使用，并且需要最少量的代碼才能集成到您的應(yīng)用程序中。

數(shù)據(jù)分區(qū):

Redis和Memcached`都允許您在多個(gè)節(jié)點(diǎn)之間分發(fā)數(shù)據(jù)。這允許您在需求增長(zhǎng)時(shí)向外擴(kuò)展以更好地處理更多數(shù)據(jù)。

支持廣泛的編程語(yǔ)言:

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

高級(jí)數(shù)據(jù)結(jié)構(gòu):

除了字符串，Redis還支持列表，集合，有序集，哈希，位數(shù)組等。應(yīng)用程序可以使用這些更高級(jí)的數(shù)據(jù)結(jié)構(gòu)來(lái)支持各種用例。例如，你可以使用Redis排序集輕松實(shí)現(xiàn)游戲排行榜，該排行榜保持按其排名排序的玩家列表。

多線程架構(gòu)：

由于Memcached是多線程的，因此它可以使用多個(gè)處理核心。這意味著您可以通過(guò)擴(kuò)展計(jì)算容量來(lái)處理更多操作。

快照:

使用Redis，您可以使用即時(shí)快照將數(shù)據(jù)保存在磁盤上，該快照可用于存檔或恢復(fù)。

復(fù)制:

Redis允許您創(chuàng)建Redis主數(shù)據(jù)庫(kù)的多個(gè)副本。這允許您擴(kuò)展數(shù)據(jù)庫(kù)讀取并具有高可用性集群。

發(fā)布/訂閱:

Redis支持使用模式匹配的Pub /Sub消息傳遞，您可以將其用于高性能聊天室，實(shí)時(shí)評(píng)論流，社交媒體源和服務(wù)器互通。

Lua腳本:

Redis允許您執(zhí)行事務(wù)性Lua腳本。腳本可以幫助您提高性能并簡(jiǎn)化應(yīng)用程序。

地理空間支持:

Redis具有專門用于大規(guī)模處理實(shí)時(shí)地理空間數(shù)據(jù)的命令。您可以執(zhí)行諸如查找兩個(gè)元素（例如人或地點(diǎn)）之間的距離以及查找點(diǎn)的給定距離內(nèi)的所有元素之類的操作。

9. 消息隊(duì)列：Message queue

[圖片上傳失敗...(image-55217b-1630575081610)]

適用于批處理任務(wù)和分離應(yīng)用程序的異步消息收發(fā)

有時(shí)，你程序需要執(zhí)行的任務(wù)與響應(yīng)用戶請(qǐng)求沒有直接關(guān)系。

例如，假設(shè)用戶上傳了需要編碼和水印的視頻。但這是一項(xiàng)長(zhǎng)期運(yùn)行的任務(wù)，因此讓用戶在完成時(shí)等待是沒有意義的。更好的方法是異步執(zhí)行此操作。您的網(wǎng)絡(luò)應(yīng)用程序代碼會(huì)在隊(duì)列中創(chuàng)建一條作業(yè)消息，并通知您的用戶，當(dāng)水印視頻準(zhǔn)備就緒時(shí)，他們將收到一封電子郵件（消息）。

然后，你將擁有一個(gè)可以執(zhí)行以下操作的工作任務(wù)流：

1. 從隊(duì)列中讀取消息。
2. 開始處理視頻。
3. 完成后，保存視頻的編碼副本。
4. 向用戶發(fā)送通知電子郵件（消息）。
5. 從隊(duì)列中刪除消息。

這里有2個(gè)架構(gòu)組件：

您可以通過(guò)以下幾種方式實(shí)現(xiàn)worker任務(wù)：

• 調(diào)度CRON作業(yè)以觸發(fā)應(yīng)用程序服務(wù)器上安裝的指定代碼，以便按特定計(jì)劃從隊(duì)列中讀取。
• 將消息添加到隊(duì)列時(shí)，使用FaaS平臺(tái)調(diào)用工作器代碼。

9.1 Message queue 簡(jiǎn)介

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

現(xiàn)在常用的MQ組件有activeMQ、rabbitMQ、rocketMQ、zeroMQ 還有近年來(lái)火熱的kafka,從某些場(chǎng)景來(lái)說(shuō)也是MQ，當(dāng)然kafka的功能更加強(qiáng)大，雖然不同的MQ都有自己的特點(diǎn)和優(yōu)勢(shì)，但是，不管是哪種MQ，都有MQ本身自帶的一些特點(diǎn)。

9.2 MQ主要特性

9.3 MQ應(yīng)用示例

來(lái)源：MQ(消息隊(duì)列)常見的應(yīng)用場(chǎng)景解析

我們的實(shí)際場(chǎng)景大概是一個(gè)基于微服務(wù)架構(gòu)的電商系統(tǒng)，分為用戶微服務(wù)、商品微服務(wù)、訂單微服務(wù)、促銷微服務(wù)等。

基于微服務(wù)模式開發(fā)的系統(tǒng)，MQ的使用場(chǎng)景更多。這里我們就列舉一下常見的應(yīng)用示例。

1. 注冊(cè)后的初始化

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

• 調(diào)用郵件服務(wù)器發(fā)送郵件、調(diào)用促銷服務(wù)贈(zèng)送優(yōu)惠劵、下發(fā)用戶數(shù)據(jù)到客戶關(guān)系系統(tǒng)等。
• 那么這時(shí)候我們將這些操作去監(jiān)聽MQ，當(dāng)用戶注冊(cè)成功過(guò)后，通過(guò)MQ通知其他業(yè)務(wù)進(jìn)行操作。確保注冊(cè)用戶的性能。

2. 后臺(tái)發(fā)布商品

后臺(tái)發(fā)布商品的時(shí)候:

• 商品數(shù)據(jù)需要從數(shù)據(jù)庫(kù)中轉(zhuǎn)換成搜索引擎數(shù)據(jù)（基于elasticsearch）
• 那么我們應(yīng)該將商品寫入數(shù)據(jù)庫(kù)后，再寫入到MQ，然后通過(guò)監(jiān)聽MQ來(lái)生成elasticsearch對(duì)應(yīng)的數(shù)據(jù)。

3.支付超時(shí)取消

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

• 以前我們可能是定時(shí)任務(wù)循環(huán)查詢，然后取消訂單。
• 實(shí)際上，我更推薦類似延遲MQ的方式，避免了很多無(wú)效的數(shù)據(jù)庫(kù)查詢，將一個(gè)MQ設(shè)置為24小時(shí)后才讓消費(fèi)者消費(fèi)掉，這樣很大程度上能減輕服務(wù)器壓力。

4. 支付完成后通知

• 支付完成后，需要及時(shí)的通知子系統(tǒng)（進(jìn)銷存系統(tǒng)發(fā)貨，用戶服務(wù)積分，發(fā)送短信）進(jìn)行下一步操作。
• 但是，支付回調(diào)我們都是需要保證高性能的，所以，應(yīng)該直接修改數(shù)據(jù)庫(kù)狀態(tài)，存入MQ，讓MQ通知子系統(tǒng)做其他非實(shí)時(shí)的業(yè)務(wù)操作。這樣能保證核心業(yè)務(wù)的高效及時(shí)。