【寫(xiě)在最前】
我們?cè)谄綍r(shí)的編程學(xué)習(xí)中，經(jīng)常會(huì)接觸到“ 系統(tǒng)架構(gòu)設(shè)計(jì) ”這個(gè)概念；
但是很多小白并不能準(zhǔn)確理解這個(gè)概念，以及常用系統(tǒng)的架構(gòu)演進(jìn)過(guò)程，甚至是在查閱了很多資料之后仍然是云山霧罩。
通過(guò)本文知識(shí)，讓我們花5分鐘時(shí)間徹底搞懂它，相信聰明的你，看完一定會(huì)有收獲！
【正文開(kāi)始】
什么是架構(gòu)設(shè)計(jì)模式?
我想這個(gè)問(wèn)題，如果有5個(gè)人回答，估計(jì)能得出6個(gè)答案，因?yàn)?strong>第6個(gè)就是大家互相討論（妥協(xié)）的結(jié)果（^_^）。
在我看來(lái)，設(shè)計(jì)模式就是設(shè)計(jì)經(jīng)驗(yàn)，只有具備了足夠多的經(jīng)驗(yàn)，才能夠根據(jù)業(yè)務(wù)自身的具體情況，組合出最適合當(dāng)前業(yè)務(wù)的架構(gòu)設(shè)計(jì)，從而控制投入成本，提高工作效率。
筆者在IT行業(yè)深耕十余年，經(jīng)歷過(guò)的架構(gòu)設(shè)計(jì)（演進(jìn)）可以說(shuō)數(shù)以百計(jì)，今天把一些架構(gòu)設(shè)計(jì)模式的一些經(jīng)驗(yàn)分享給大家，以饗讀者。
當(dāng)前業(yè)界的架構(gòu)設(shè)計(jì)，大體上可以分為 6種：
1. 單庫(kù)單應(yīng)用模式
這種模式一般只有一個(gè)數(shù)據(jù)庫(kù)，一個(gè)后臺(tái)管理系統(tǒng)（當(dāng)然也可以有前臺(tái)應(yīng)用）。
這是最簡(jiǎn)單的架構(gòu)設(shè)計(jì)模式，也是所有IT初學(xué)者最先（必須）接觸到的模式。
說(shuō)一下該模式的優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)：結(jié)構(gòu)簡(jiǎn)單、開(kāi)發(fā)速度快、實(shí)現(xiàn)簡(jiǎn)單，可用于產(chǎn)品的第一版原型驗(yàn)證需求、用戶(hù)少的設(shè)計(jì)。
缺點(diǎn)：性能差、沒(méi)有解決“高并發(fā)，高可用、大數(shù)據(jù)、易擴(kuò)展“的問(wèn)題（所以不能用于正式業(yè)務(wù)的生產(chǎn)環(huán)境）
注1：該架構(gòu)是其他架構(gòu)設(shè)計(jì)模式的基礎(chǔ)（再?gòu)?fù)雜的架構(gòu)，也都是在這個(gè)模式上不斷演進(jìn)的）
注2：目前流行的前后端分離模式，只是將前端工程化，但本質(zhì)上并沒(méi)有改變應(yīng)用架構(gòu)的本質(zhì)，所以在本文中仍然歸類(lèi)為這一種。
2、內(nèi)容分發(fā)模式
這種模式主要解決”靜態(tài)資源（網(wǎng)頁(yè)，圖片，js,css等）的訪問(wèn)性能問(wèn)題”
與單庫(kù)單應(yīng)用模式相比：多了一個(gè)OSS云存儲(chǔ)（阿里云，七牛云等）和一個(gè)CDN加速網(wǎng)絡(luò)
CDN加速原理：
1）程序通過(guò)調(diào)用OSS上傳接口，得到圖片訪問(wèn)地址U，并把U地址入庫(kù)
2）CDN網(wǎng)絡(luò)會(huì)將真實(shí)圖片資源，在各個(gè)CND節(jié)點(diǎn)緩存一份；
3）用戶(hù)訪問(wèn)地址U時(shí)，CDN先拿到用戶(hù)端IP，然后再通過(guò)一個(gè)DNS智能查詢(xún)算法，找出與該用戶(hù)距離最近（或通訊時(shí)間最短）的CDN節(jié)點(diǎn)服務(wù)器，將該服務(wù)器的緩存圖片下發(fā)給用戶(hù)。
說(shuō)一下該模式的優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)：資源下載快、無(wú)需過(guò)多的開(kāi)發(fā)與配置，同時(shí)也減輕了后端服務(wù)器對(duì)資源的存儲(chǔ)壓力，減少帶寬的使用。
缺點(diǎn)：目前來(lái)說(shuō)OSS，CDN的價(jià)格還是稍微有些貴，只適用于中小規(guī)模的應(yīng)用，另外由于網(wǎng)絡(luò)傳輸?shù)难舆t、CDN同步策略等，會(huì)有數(shù)據(jù)不一致的問(wèn)題。
3、查詢(xún)分離模式
這種模式主要解決“查詢(xún)性能問(wèn)題”.
這個(gè)可以說(shuō)是單庫(kù)單應(yīng)用模式的升級(jí)版本，也是架構(gòu)迭代演進(jìn)過(guò)程中的必經(jīng)之路。
與單庫(kù)單應(yīng)用模式相比：進(jìn)行了業(yè)務(wù)數(shù)據(jù)庫(kù)的主從分離，并引入了ES搜索引擎
為什么要這樣做呢？下面結(jié)合兩個(gè)業(yè)務(wù)需求場(chǎng)景進(jìn)行敘述。
場(chǎng)景一：業(yè)務(wù)讀多寫(xiě)少
有統(tǒng)計(jì)數(shù)據(jù)表明，一般的業(yè)務(wù)系統(tǒng)，讀（查詢(xún)）場(chǎng)景跟寫(xiě)（保存）場(chǎng)景的比例在7；3（甚至8：2）以上
這就決定了我們的系統(tǒng)中會(huì)有大量的查詢(xún)請(qǐng)求。
如果僅僅是因?yàn)閿?shù)據(jù)庫(kù)的寫(xiě)性能遇到了問(wèn)題，而導(dǎo)致我們的系統(tǒng)80%的讀場(chǎng)景不可用，這顯然是不能夠接受的。
針對(duì)此問(wèn)題，業(yè)界較為成熟的方案就是對(duì)數(shù)據(jù)庫(kù)進(jìn)行”讀寫(xiě)分離“，即寫(xiě)的時(shí)候入主庫(kù)，讀的時(shí)候讀從庫(kù)。
這樣就把壓力分散到不同的數(shù)據(jù)庫(kù)了，如果一個(gè)讀庫(kù)性能不行，扛不住的話，可以一主多從，橫向擴(kuò)展。
一般的業(yè)務(wù)流程是這樣的：
1）服務(wù)端把一條業(yè)務(wù)數(shù)據(jù)，寫(xiě)到主數(shù)據(jù)庫(kù)（master）
2）主數(shù)據(jù)庫(kù)通過(guò)”同步策略“將該數(shù)據(jù)同步到從庫(kù)中（slave）
3）需要數(shù)據(jù)查詢(xún)時(shí)，直接去從庫(kù)（slave）讀相應(yīng)的數(shù)據(jù)
一些聰明的、愛(ài)思考、想上進(jìn)的同學(xué)可能發(fā)現(xiàn)問(wèn)題了：就是數(shù)據(jù)的延遲問(wèn)題，
比如：數(shù)據(jù)還沒(méi)有同步到從庫(kù)，我就馬上讀，那么肯定是讀不到的。
對(duì)于這個(gè)問(wèn)題，各家公司解決的思路不一樣，方法也就不盡相同。
比如其中一個(gè)解決方案是：先嘗試讀從庫(kù)，如果讀不到就再?lài)L試讀主庫(kù)。
場(chǎng)景二：關(guān)鍵詞全文檢索
業(yè)務(wù)系統(tǒng)都會(huì)有關(guān)鍵字搜索的需求，如果使用傳統(tǒng)的數(shù)據(jù)庫(kù)技術(shù)，基本都會(huì)使用like這種SQL語(yǔ)句。
眾所周知：當(dāng)數(shù)據(jù)量達(dá)到一定級(jí)別，SQL全表掃描會(huì)有嚴(yán)重的性能問(wèn)題。
解決辦法就是全文檢索場(chǎng)景直接走ES搜索引擎（ES不僅可以替代數(shù)據(jù)庫(kù)完成全文檢索功能，還可以實(shí)現(xiàn)諸如分頁(yè)、排序、分組等功能）
ES搜索引擎的一般使用流程為，
1）服務(wù)端把一條業(yè)務(wù)數(shù)據(jù)落業(yè)務(wù)庫(kù)，同時(shí)異步發(fā)送給ES
2）ES把該條記錄按照預(yù)定規(guī)則、配置放入自己的索引庫(kù)
3）客戶(hù)端查詢(xún)時(shí)，由服務(wù)端把這個(gè)請(qǐng)求發(fā)送到ES，ES根據(jù)需求拼裝、組合數(shù)據(jù)，返回給客戶(hù)端
說(shuō)完了兩個(gè)場(chǎng)景，該總結(jié)一下這種設(shè)計(jì)模式的優(yōu)缺點(diǎn)的了：
優(yōu)點(diǎn)：減少數(shù)據(jù)庫(kù)的壓力，理論上提供無(wú)限高的讀性能，間接提高業(yè)務(wù)(寫(xiě))的性能，專(zhuān)用的查詢(xún)、索引、全文(分詞)解決方案。
缺點(diǎn)：數(shù)據(jù)延遲，數(shù)據(jù)一致性的保證和解決。
4、分庫(kù)分表模式
這種模式主要解決"單表寫(xiě)入壓力過(guò)大的問(wèn)題"，這個(gè)模式也是架構(gòu)迭代演進(jìn)過(guò)程中的必經(jīng)之路。
對(duì)于單個(gè)業(yè)務(wù)表，一般有水平切分和垂直切分兩種，這里主要介紹水平切分。
理論上：一臺(tái)主機(jī)可以有多個(gè)實(shí)例，一個(gè)實(shí)例中可以有多個(gè)庫(kù)，一個(gè)庫(kù)可以有多個(gè)表。
實(shí)踐中：一臺(tái)主機(jī)上只有一個(gè)實(shí)例，一個(gè)實(shí)例中只有一個(gè)庫(kù)，庫(kù)==實(shí)例==主機(jī)，所以才有了分庫(kù)分表這個(gè)簡(jiǎn)稱(chēng)。
接下來(lái)以一個(gè)例子來(lái)講解一下分表流程：
假設(shè)用戶(hù)表(user)，數(shù)據(jù)量有1億用戶(hù)，查詢(xún)、插入、存儲(chǔ)都出現(xiàn)了問(wèn)題，怎么分呢？
首先，分析問(wèn)題，這個(gè)明顯是由于數(shù)據(jù)量太大了而導(dǎo)致的問(wèn)題。
其次，設(shè)計(jì)方案，可以分為10個(gè)庫(kù)，這樣每個(gè)庫(kù)的數(shù)據(jù)量就降到了1KW，單表1KW數(shù)據(jù)量還是有些大，而且不利于以后量的增長(zhǎng)，所以每個(gè)庫(kù)再分100個(gè)表，這個(gè)每個(gè)單表數(shù)據(jù)量就為10W了，對(duì)于查詢(xún)、索引更新、單表文件大小、打開(kāi)速度，都有益處。
再次，給IT運(yùn)維部門(mén)打電話，要10臺(tái)物理機(jī)，擴(kuò)展數(shù)據(jù)庫(kù)...... 最后，邏輯實(shí)現(xiàn)，這里是最有學(xué)問(wèn)的地方。首先是寫(xiě)入數(shù)據(jù)，需要知道寫(xiě)到哪個(gè)分庫(kù)分表中，讀也是一樣的，所以，需要有個(gè)請(qǐng)求路由層，負(fù)責(zé)把請(qǐng)求分發(fā)、轉(zhuǎn)換到不同的庫(kù)表中，
說(shuō)說(shuō)這個(gè)模式的問(wèn)題：
1）事務(wù)問(wèn)題
因?yàn)榉謳?kù)分表，傳統(tǒng)事務(wù)完成不了，而分布式事務(wù)又太笨太重，所以這里需要有一定的策略，保證在這種情況下事務(wù)能夠完成。常用的策略如：最終一致性、復(fù)制、特殊設(shè)計(jì)等。
2）關(guān)聯(lián)和分組查詢(xún)改造
該模式下，傳統(tǒng)的 join, orderby,grouby 都不能再用了，需要在業(yè)務(wù)代碼層進(jìn)行改造。(如何解決這些副作用不是一句兩句能說(shuō)清楚的，以后會(huì)單獨(dú)開(kāi)篇，敬請(qǐng)及時(shí)關(guān)注作者）
該總結(jié)一下這種模式的優(yōu)缺點(diǎn)的了，如下：
優(yōu)點(diǎn)：減少數(shù)據(jù)庫(kù)單表的讀寫(xiě)壓力。
缺點(diǎn)：事務(wù)保證困難、業(yè)務(wù)邏輯需要做大量改造。
5、微服務(wù)架構(gòu)模式
上面的模式看似不錯(cuò)，但也只是解決了部分性能問(wèn)題。但是軟件系統(tǒng)天生的復(fù)雜性，決定了還有其他諸如”高可用、健壯性、易擴(kuò)展“等大量問(wèn)題等待我們?nèi)ソ鉀Q.
微服務(wù)模式 可以說(shuō)是最近的熱點(diǎn)，花花綠綠、大大小小、國(guó)內(nèi)國(guó)外的公司都在鼓吹，實(shí)踐這個(gè)模式，可是大部分都沒(méi)有弄清楚為什么要這么做，也并不知道這么做有什么好處、壞處，
在這里，我以自己的親身實(shí)踐說(shuō)一下我對(duì)這個(gè)模式的看法，也請(qǐng)大家在評(píng)論區(qū)踴躍留言！
隨著項(xiàng)目發(fā)展，業(yè)務(wù)與人員的規(guī)模會(huì)不斷增加，從而會(huì)陸續(xù)遇到了如下問(wèn)題：
1）數(shù)據(jù)庫(kù)寫(xiě)壓力大量增加，導(dǎo)致數(shù)據(jù)庫(kù)不堪重負(fù)， 數(shù)據(jù)庫(kù)一旦掛了，那么整個(gè)系統(tǒng)業(yè)務(wù)都掛了
2）業(yè)務(wù)代碼越來(lái)越多，全都放在一個(gè)GIT里，越來(lái)越難以維護(hù)
3）上線要求越來(lái)越頻繁，經(jīng)常是一個(gè)小功能的修改，就要整個(gè)大項(xiàng)目要重新編譯
4）其他一些外圍系統(tǒng)直接連接數(shù)據(jù)庫(kù)，導(dǎo)致一旦數(shù)據(jù)庫(kù)結(jié)構(gòu)發(fā)生變化，所有的相關(guān)系統(tǒng)都要通知，甚至對(duì)修改不敏感的系統(tǒng)也要通知
5）每個(gè)應(yīng)用服務(wù)器需要開(kāi)通所有的、相同的、訪問(wèn)權(quán)限和網(wǎng)絡(luò)權(quán)限，因?yàn)槊總€(gè)服務(wù)器部署的應(yīng)用都是一樣的
慢慢的，所有人，都已經(jīng)失去了對(duì)這個(gè)系統(tǒng)的把控......
微服務(wù)架構(gòu)，就是為了解決上述這些問(wèn)題，這種模式的一般設(shè)計(jì)見(jiàn)下圖：
如上圖所示，我們把業(yè)務(wù)分塊做了垂直切分，切成一個(gè)個(gè)獨(dú)立的業(yè)務(wù)系統(tǒng)，每個(gè)系統(tǒng)各自衍化，有自己的業(yè)務(wù)庫(kù)、緩存庫(kù)等，
系統(tǒng)之間的實(shí)時(shí)交互通過(guò)RPC遠(yuǎn)程調(diào)用，異步交互通過(guò)MQ消息隊(duì)列
通過(guò)這種組合，共同完成整個(gè)系統(tǒng)功能。
這樣，對(duì)于上面的5個(gè)問(wèn)題，我們就都有了解決方案：
對(duì)于問(wèn)題1：由于拆分成了多個(gè)子系統(tǒng)，系統(tǒng)的壓力被分散了，而各個(gè)子系統(tǒng)都有自己的數(shù)據(jù)庫(kù)實(shí)例，所以數(shù)據(jù)庫(kù)的壓力變小。
一個(gè)子系統(tǒng)A的數(shù)據(jù)庫(kù)掛了，只是影響到系統(tǒng)A和使用系統(tǒng)A的那些功能，不會(huì)所有的功能不可用，從而可以解決一個(gè)數(shù)據(jù)庫(kù)掛了，導(dǎo)致所有功能不可用的問(wèn)題。
對(duì)于問(wèn)題2：各個(gè)子系統(tǒng)有自己獨(dú)立的GIT代碼庫(kù)，不會(huì)相互影響。通用的模塊可通過(guò)庫(kù)、服務(wù)、平臺(tái)的形式解決。
對(duì)于問(wèn)題3：子系統(tǒng)A發(fā)生改變，需要上線，那么我只需要編譯A，然后只上線部署A就可以了，不需要其他系統(tǒng)做同樣的事情。
對(duì)于問(wèn)題4：所有需要訪問(wèn)的業(yè)務(wù)數(shù)據(jù)，都通過(guò)接口的形式發(fā)布出去，客戶(hù)通過(guò)接口獲取數(shù)據(jù)，從而屏蔽了底層數(shù)據(jù)庫(kù)結(jié)構(gòu)。我們只需保證接口契約沒(méi)有發(fā)生變化即可，新的需求增加新的接口
對(duì)于問(wèn)題5： 不同的子系統(tǒng)需要不同的權(quán)限，這個(gè)問(wèn)題也優(yōu)雅的解決了。
目前來(lái)看，所有問(wèn)題都得到了解決？？？
注意：采用該架構(gòu)，會(huì)有許多其他副作用隨之產(chǎn)生，如RPC、MQ的超高穩(wěn)定性、超高性能，網(wǎng)絡(luò)延遲，數(shù)據(jù)一致性等問(wèn)題，這里就不展開(kāi)來(lái)講了，太多了，一本書(shū)都講不完。
另外：對(duì)于這個(gè)模式來(lái)說(shuō)，最難把握的是拆分的維度，細(xì)粒度
一個(gè)較為可行的拆分指導(dǎo)原則是：能不分就不分，除非有非常必要的理由！
該總結(jié)一下這種模式的優(yōu)缺點(diǎn)的了，如下：
優(yōu)點(diǎn)：相對(duì)高性能，可擴(kuò)展性強(qiáng)，高可用，適合于中等以上規(guī)模公司架構(gòu)。
缺點(diǎn)：復(fù)雜、粒度不好把握。不僅需要一個(gè)能在高層把控大方向、大流程、總體技術(shù)的人，還需要能夠針對(duì)各個(gè)子系統(tǒng)有針對(duì)性的開(kāi)發(fā)。把握不好度或者濫用的話，投入產(chǎn)出會(huì)適得其反！
6、彈性伸縮模式
這種模式主要解決流量高并發(fā)（流量突發(fā)）的問(wèn)題。
比如：天貓雙11或京東618，會(huì)在特定的時(shí)間帶來(lái)巨大流量，但是傳統(tǒng)橫向擴(kuò)展方案實(shí)施又比較慢，如果設(shè)計(jì)處理不好就會(huì)影響業(yè)務(wù)，甚至全站崩潰。
這個(gè)模式是一種相對(duì)來(lái)說(shuō)比較高級(jí)的技術(shù)，也是各個(gè)大公司目前都正在研究、試用的技術(shù)。
時(shí)至今日，有這種思想的架構(gòu)師就已經(jīng)是算是很不錯(cuò)了，更別提那些已經(jīng)動(dòng)手實(shí)踐過(guò)的，所以，你懂得......
與微服務(wù)模式相比，這種架構(gòu)會(huì)多出一個(gè)“彈性伸縮服務(wù)”，用來(lái)動(dòng)態(tài)的增加、減少實(shí)例。
具體實(shí)現(xiàn)上，比較成熟的兩種資源池方案是VM、Docker，每個(gè)產(chǎn)品目前都有著自己強(qiáng)大的生態(tài)。監(jiān)控的點(diǎn)有CPU、內(nèi)存、硬盤(pán)、網(wǎng)絡(luò)IO、服務(wù)質(zhì)量等，根據(jù)這些，在配合一些預(yù)留、擴(kuò)張、收縮策略，就可以簡(jiǎn)單的實(shí)現(xiàn)自動(dòng)伸縮。
該總結(jié)一下這種模式的優(yōu)缺點(diǎn)的了，如下：
優(yōu)點(diǎn)：彈性、隨需計(jì)算，充分優(yōu)化企業(yè)計(jì)算資源。
缺點(diǎn)：應(yīng)用要從架構(gòu)層做到可動(dòng)態(tài)配置的橫向擴(kuò)展，彈性伸縮改造、依賴(lài)的底層配套比較多，對(duì)團(tuán)隊(duì)的技術(shù)水平、運(yùn)維實(shí)力、應(yīng)用規(guī)模要求都非常高。
【全文完】
