本文目錄：

1. Web / Application Servers
2. 負(fù)載均衡器: Load Balancer
3. 域名解析系統(tǒng)，DNS
4. HTTPS / SSL證書
5. 數(shù)據(jù)庫，Database
6. Blob / 文件存儲
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ù)器端語言

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

• 例如Node.js憾朴，Python，PHP，Java乐设，C＃或Ruby讼庇。
• 每種語言都有自己的“Web框架”（例如基于 Java 的 Spring，基于 Ruby 的 Rails近尚，基于C＃的ASP.NET MVC或基于Node.js的Express）蠕啄。
• 這些框架使開發(fā)人員能夠編寫更少的代碼來處理數(shù)據(jù)請求。

1.2 后端語言選擇

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

PHP：

• 使用者多，算是最普及的后端語言撼港。
• 簡單易學(xué)坪它，但因一些古老的設(shè)計飽受批評。
• 網(wǎng)站范例：Facebook帝牡、Wordpress往毡、新浪微博。

Java：

• 老牌語言靶溜，開發(fā)統(tǒng)治者开瞭。國內(nèi)外工作需求穩(wěn)定，應(yīng)用層面廣罩息。
• 開發(fā)相較起來較慢嗤详，沒那麼適合新手。
• 網(wǎng)站范例：Linkedin瓷炮、Amazon葱色、淘寶。

Ruby：

• 開發(fā)快速娘香，國內(nèi)外很多 bootcamp 都以此語言教后端苍狰。
• 適不適合新手學(xué)飽受爭議。
• 網(wǎng)站范例：Airbnb烘绽、Twitter淋昭。

Python:

• 語法簡單易學(xué)，數(shù)據(jù)分析與資料探勘相關(guān)應(yīng)用多安接。
• 單獨(dú)使用 Python 相較起來運(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)庫撩银，效能強(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)程將在訪問后端代碼之前攔截客戶端請求胆屿。使用它們有以下幾個原因：

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

至此冷离，會引出一個疑問：Apache、Nginx纯命、Tomcat和Node.js四者的區(qū)別是什么酒朵？

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

是一類東西留夜，又不是一類東西匙铡。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. Dokcer是這樣的：

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

負(fù)載均衡是高可用網(wǎng)絡(luò)基礎(chǔ)架構(gòu)的的一個關(guān)鍵組成部分筏餐，有了負(fù)載均衡，我們通衬的矗可以將我們的應(yīng)用服務(wù)器部署多臺魁瞪，然后通過負(fù)載均衡將用戶的請求分發(fā)到不同的服務(wù)器用來提高網(wǎng)站、應(yīng)用惠呼、數(shù)據(jù)庫或其他服務(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)識http協(xié)議少梁，對應(yīng)其他TCP應(yīng)用，例如基于C/S開發(fā)的ERP等系統(tǒng)矫付。

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

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

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

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

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

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

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

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

• 它通過確保單個Web服務(wù)器不會被所有請求淹沒文搂，來幫助維持一致的響應(yīng)時間适刀，因此處理每個請求的速度會相對慢些。
• 它保持高可用性煤蹭。如果服務(wù)器崩潰笔喉，所有后續(xù)客戶端請求仍將成功，因?yàn)樗鼈儗⒙酚傻浇】档姆?wù)器硝皂，并且用戶不會發(fā)現(xiàn)任何問題常挚。

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

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

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

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

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

4. HTTPS / SSL證書

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

這意味著需要在后端安裝SSL證書囊蓝。具體來說，需要在任何服務(wù)器上安裝它們令蛉，這是客戶端請求的第一個聯(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)建并自動續(xù)訂SSL證書并將其分發(fā)到應(yīng)用程序服務(wù)器汇鞭，負(fù)載平衡器和CDN服務(wù)器凉唐。
• 只有中大型的HTTPS證書授權(quán)中心才會被瀏覽器承認(rèn)，否則會顯示為不安全霍骄，需要手動信任台囱。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

無論底層是關(guān)系型數(shù)據(jù)庫谅河，還是NoSQL數(shù)據(jù)庫咱旱，無論是 Mysql 還是 Redis、MongoDB绷耍，在架構(gòu)設(shè)計上都是相通的吐限。

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

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

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

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

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

其思路也特別的簡單：

• 將數(shù)據(jù)庫部署到兩臺機(jī)器诸典，其中一臺機(jī)器(代號A)作為日常提供數(shù)據(jù)讀寫服務(wù)的機(jī)器，稱為「主機(jī)」崎苗。
• 另外一臺機(jī)器(代號B)并不提供線上服務(wù)狐粱，但會實(shí)時的將「主機(jī)」的數(shù)據(jù)同步過來赘阀，稱為「備機(jī)」。
• 一旦「主機(jī)」出了故障脑奠，通過人工的方式基公，手動的將「主機(jī)」踢下線，將「備機(jī)」改為「主機(jī)」來繼續(xù)提供服務(wù)宋欺。

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

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

為了解決這個資源浪費(fèi)問題磕潮，我們就得想一個把「備機(jī)」也用起來的方案：主從式架構(gòu)。

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

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

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

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

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

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

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

至于數(shù)據(jù)庫集群方案封断，我暫時沒看懂斯辰，就不寫了。坡疼。彬呻。

6. Blob / 文件存儲

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

• 前端網(wǎng)站資源，如圖像蒲跨，Javascript译断，CSS，字體或悲，音頻镐作，視頻文件。
• 用戶通過表單上傳的各類文件隆箩。

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

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

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

Blob 存儲用于：

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

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

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

但是屋摔，假設(shè)我的用戶位于中國烁设，我的S3存儲位于美國西部 - 數(shù)據(jù)傳輸距離數(shù)千英里，因此我的用戶會看到延遲钓试。

CDN是什么装黑？使用CDN有什么優(yōu)勢？

• CDN是云供應(yīng)商提供的服務(wù)弓熏，它們在全球范圍內(nèi)分布有“邊緣服務(wù)器”恋谭。
• 這些邊緣服務(wù)器從“原點(diǎn)”（例如，blob /文件存儲位置）獲取文件的副本硝烂。你的前端Web應(yīng)用程序?qū)⒅赶?其CDN URL箕别，而不是指向靜態(tài)資產(chǎn)的Blob存儲URL铜幽。
• 現(xiàn)在滞谢，客戶端和“邊緣”之間的距離遠(yuǎn)不是幾千英里的往返串稀，而是更少，因此文件的獲取速度更快狮杨。

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

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

7.1 CDN工作流

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

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

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

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

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

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

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

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

8.1 Redis和Memcached對比

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

亞毫秒級延遲:

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

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

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

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

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

支持廣泛的編程語言:

Redis和Memcached都有許多面向開發(fā)人員的開源客戶端淆游。支持的語言包括Java，Python，PHP犹菱，C拾稳，C ++，C＃腊脱，JavaScript访得，Node.js，Ruby陕凹，Go等等悍抑。

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

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

多線程架構(gòu)：

由于Memcached是多線程的店茶，因此它可以使用多個處理核心蜕便。這意味著您可以通過擴(kuò)展計算容量來處理更多操作。

快照:

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

復(fù)制:

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

發(fā)布/訂閱:

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

Lua腳本:

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

地理空間支持:

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

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

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

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

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

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

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

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

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

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

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

9.1 Message queue 簡介

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

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

9.2 MQ主要特性

9.3 MQ應(yīng)用示例

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

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

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

1. 注冊后的初始化

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

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

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

后臺發(fā)布商品的時候:

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

3.支付超時取消

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

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

4. 支付完成后通知

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