六種常見系統(tǒng)架構(gòu) - 基礎(chǔ)篇
常見的幾種系統(tǒng)架構(gòu)設(shè)計，本文先講前三個：
1. 單庫單應(yīng)用架構(gòu)：最簡單的，可能大家都見過
2. 內(nèi)容分發(fā)架構(gòu)：目前用的比較多
3. 讀寫分離架構(gòu)：對于大并發(fā)的查詢、業(yè)務(wù)
4. 微服務(wù)架構(gòu)：適用于復(fù)雜的業(yè)務(wù)模式的拆解
5. 多級緩存架構(gòu)：可以把緩存玩的很好
6. 分庫分表架構(gòu)：解決單體數(shù)據(jù)庫瓶頸
一、單庫單應(yīng)用架構(gòu)
這是最簡單的一種設(shè)計模式，我們的大部分本科畢業(yè)設(shè)計、一些小的應(yīng)用，基本上都是這種模式，這種模式的一般設(shè)計見下圖：
如上圖所示，這種模式一般只有一個數(shù)據(jù)庫，一個業(yè)務(wù)應(yīng)用層，一個后臺管理系統(tǒng)，所有的業(yè)務(wù)都是用業(yè)務(wù)層完成的，所有的數(shù)據(jù)也都是存儲在一個數(shù)據(jù)庫中，好一點會由數(shù)據(jù)庫的同步，雖然簡單，但是也并不是一無是處。
優(yōu)點：結(jié)構(gòu)簡單、開發(fā)速度快、實現(xiàn)簡單，可用于產(chǎn)品的第一版等有原型驗證需求。
缺點：性能差、基本沒有高可用、擴(kuò)展性差，不適合用于大規(guī)模部署、應(yīng)用等生產(chǎn)環(huán)境。
二、內(nèi)容分發(fā)架構(gòu)
基本上所有的大型的網(wǎng)站都有或多或少的采用這一種設(shè)計模式，常見的應(yīng)用場景是采用CDN技術(shù)把網(wǎng)頁、圖片、CSS、JS等這些靜態(tài)資源分發(fā)到離用戶最近的服務(wù)器，這種模式的一般設(shè)計見下圖：
如上圖所示，這種模式較單庫單應(yīng)用的模式多了一個CDN、一個云存儲OSS（七牛、又拍等雷同）。一個經(jīng)典的應(yīng)用流程（以用戶上傳、查看圖片需求為例如下：）
1、上傳的時候，用戶選擇本地機器上的一個圖片進(jìn)行上傳
2、程序會把這個圖片上傳到云存儲OSS上，并返回該圖片的一個URL
3、程序把這個URL字符串存儲在業(yè)務(wù)數(shù)據(jù)庫中，上傳完成
4、查看的時候，程序從業(yè)務(wù)數(shù)據(jù)庫得到該圖片的URL
5、程序通過DNS查詢到這個URL的圖片服務(wù)器
6、智能DNS會解析這個URL，得到用戶最近的服務(wù)器（或集群）的地址A
7、然后把服務(wù)器A上的圖片返回給程序
8、程序顯示該圖片，查看完成
由上可知，這個模式的關(guān)鍵是智能DNS，他能夠解析出離用戶最近的服務(wù)器，運行原理大致是：根據(jù)請求者的IP得到請求地點B，然后通過計算或者配置得到與B最近或通訊時間最短的服務(wù)器C，然后把C的IP地址返回給請求者。這種模式的優(yōu)缺點如下：
優(yōu)點：資源下載快，無需過多的開發(fā)與配置，同時也減輕了后端服務(wù)器對資源的存儲壓力，減少帶寬的使用。
缺點：目前來說OSS、CDN的價格還是稍微有點貴的，只適用于中小規(guī)模的應(yīng)用，另外由于網(wǎng)絡(luò)傳輸延遲、CDN的同步策略等，會有一些一致性、更新慢方面的問題。
三、讀寫分離架構(gòu)
這種模式主要解決單體數(shù)據(jù)庫壓力過大，從而導(dǎo)致業(yè)務(wù)緩慢甚至超時，查詢影響時間變長的問題，也包括需要大量數(shù)據(jù)庫服務(wù)器計算資源的查詢請求，這個可以說是單庫應(yīng)用模式的升級版本，也是技術(shù)架構(gòu)迭代演進(jìn)過程中的必經(jīng)之路。
這種模式的一般設(shè)計如下圖：
如上圖所示，這種模式較單庫但應(yīng)用模式與內(nèi)容分發(fā)模式多了幾個部分，一個是業(yè)務(wù)數(shù)據(jù)庫的主從分離，一個是引入ES，為什么要這樣？都解決的哪些痛點，下面具體結(jié)合業(yè)務(wù)需求場景進(jìn)行敘述。
場景一：全文關(guān)鍵詞檢索
我想這個需求，絕大多數(shù)應(yīng)用都會有，如果使用傳統(tǒng)的數(shù)據(jù)庫技術(shù)，大部分可能會使用like這種sql語句，高級一點的是先分詞，然后通分詞index相關(guān)的記錄。sql語句的性能問題與全表掃描機制導(dǎo)致了非常嚴(yán)重的性能問題，現(xiàn)在基本上很少見到。
ES較Solr配置簡單、使用方便，所以這里選用了他。另外，ES支持橫向擴(kuò)展，理論上沒有性能的瓶頸。同時，還支持各種插件、自定義分詞器等，可擴(kuò)展性較強。在這里，使用ES不僅可以替代數(shù)據(jù)庫完成全檢索功能，還可以實現(xiàn)諸如分頁、排序、分組、分面等功能。具體的，請同學(xué)們自行學(xué)習(xí)之，那怎么使用呢？一個一般的流程是這樣的：
1、服務(wù)端把一條業(yè)務(wù)數(shù)據(jù)落庫
2、服務(wù)器異步把該條數(shù)據(jù)發(fā)送到ES
3、ES把該條記錄按照規(guī)則、配置放入自己的索引庫
4、客戶端查詢的時候，由服務(wù)端把這個請求發(fā)送到ES，得到數(shù)據(jù)后，根據(jù)需求拼裝、組合數(shù)據(jù)，返回給客戶端
實際中怎么用，還請同學(xué)們根據(jù)實際情況做組合、取舍
場景二：大量的普通查詢
這個場景是指我們的業(yè)務(wù)中的大部分輔助性的查詢，如：取錢的時候先查詢一下余額，根據(jù)用戶的ID查詢用戶的記錄，取得該用戶最新的一條取錢記錄等，我們肯定是要天天用到的，而且用的還非常多。同時呢，我們的寫入請求也是非常多的，導(dǎo)致大量的寫入、查詢操作壓向同一數(shù)據(jù)庫，然后，數(shù)據(jù)庫掛了，系統(tǒng)掛了，領(lǐng)導(dǎo)生氣了，被開除了，還不起房貸了，露宿街頭了，老婆跟別人跑了……
不敢想，所以要求我們必須分散數(shù)據(jù)庫的壓力，一個業(yè)界較成熟的方案就是數(shù)據(jù)庫的讀寫分離，寫的時候入主庫，讀的時候讀分庫。這樣就把壓力分散到不同的數(shù)據(jù)庫了，如果一個讀庫性能不行，扛不住的話，可以一主多從，橫向擴(kuò)展，可謂是一劑良藥啊！那么怎么使用呢？一個一般的流程是這樣的：
1、服務(wù)端把一條數(shù)據(jù)落庫
2、數(shù)據(jù)庫同步或異步或半同步把這條數(shù)據(jù)復(fù)制到從庫
3、服務(wù)端讀取數(shù)據(jù)的時候直接去從庫讀相應(yīng)的數(shù)據(jù)
比較簡單吧，一些聰明的、愛思考的、上進(jìn)的同學(xué)可能發(fā)現(xiàn)問題了，也包括上面介紹的場景一，就是延遲問題，如：數(shù)據(jù)還沒到從庫，我就馬上讀，那么是讀不到的，會發(fā)生問題的。對于這個問題，各家公司解決的思路也是不一樣的，方法不盡相同，一個普遍的解決方案是：讀不到就讀主庫，當(dāng)然這么說也是有前提條件的，但具體的方案就不在這里一一展開了，我可能會在接下來的分享中詳解各種方案。
另外，關(guān)于數(shù)據(jù)庫復(fù)制模式，還請同學(xué)們自行學(xué)習(xí)，太多了，這里說不清，該總結(jié)一下這種模式的優(yōu)缺點了，如下：
優(yōu)點：減少數(shù)據(jù)庫的壓力，理論上提供無限高的讀性能，間接提高業(yè)務(wù)（寫）的性能，專用的查詢、索引、全文（分詞）解決方案。
缺點：數(shù)據(jù)延遲，數(shù)據(jù)一致性的保證。
有收獲，點個在看?
