正確的業(yè)務(wù)架構(gòu)遠比正確的技術(shù)架構(gòu)重要
---- 斯沃.資基索德

經(jīng)驗尚淺顶捷，不敢妄議大神寫的《大型網(wǎng)站技術(shù)架構(gòu)》，所以前面寫成學(xué)習(xí)筆記的形式屎篱，后面會聊些思考服赎。希望能有所幫助。

作者在阿里當(dāng)過架構(gòu)師交播，現(xiàn)在就職英特爾重虑。寫這本書的時候正值12306剛出來，頻頻奔潰秦士。所以就寫了這本書缺厉，希望分享下相關(guān)經(jīng)驗。前半部分細講了網(wǎng)站架構(gòu)的要素和解決方案隧土，后半部分分析了淘寶維基百科等的具體案例芽死，并且分享了如何做架構(gòu)師的一些經(jīng)驗。對剛?cè)腴T后端開發(fā)或者想深入學(xué)習(xí)架構(gòu)設(shè)計次洼，進行系統(tǒng)優(yōu)化的同學(xué)都是不錯的學(xué)習(xí)書籍。

網(wǎng)站架構(gòu)的演化

1遇骑，原始時代卖毁，一臺服務(wù)器解決所有，經(jīng)典的LAMP落萎，廉價服務(wù)器+開源軟件亥啦，網(wǎng)站就建起來了。

→ 等到訪問量越來越大练链，數(shù)據(jù)存儲空間吃緊了翔脱，所以。媒鼓。届吁。

2，使用三臺服務(wù)器绿鸣，應(yīng)用疚沐，文件，數(shù)據(jù)庫分開潮模。應(yīng)用服務(wù)器加CPU亮蛔，文件服務(wù)器加大容量硬盤，數(shù)據(jù)庫服務(wù)器用更貴更快的硬盤擎厢。

→ 80%的訪問集中在20%的數(shù)據(jù)上究流，成為瓶頸

3辣吃，應(yīng)用服務(wù)器加本地緩存。

→ 本地緩存和應(yīng)用爭內(nèi)存

4芬探，加遠程獨立服務(wù)器放緩存神得，再不行上分布式緩存服務(wù)器，要多大有多大灯节。

→單臺應(yīng)用服務(wù)器應(yīng)對請求數(shù)量有限循头，限制了并發(fā)能力

5，使用應(yīng)用服務(wù)器集群炎疆，可伸縮性大大增強卡骂，再多用戶都不怕。

→用戶操作頻繁形入，高頻率的寫操作讓數(shù)據(jù)庫不堪重負

6全跨，數(shù)據(jù)庫讀寫分離，配置主從數(shù)據(jù)庫亿遂，讀從從庫讀浓若，寫就寫到主庫，利用主從復(fù)制讓數(shù)據(jù)一致

→網(wǎng)站內(nèi)容越來越豐富蛇数，響應(yīng)時間變長

7挪钓，上CDN服務(wù)，靜態(tài)數(shù)據(jù)或者不頻繁更新的數(shù)據(jù)都到CDN耳舅。再利用反向代理碌上，選擇距離用戶最近響應(yīng)最快的應(yīng)用服務(wù)器，大大加快響應(yīng)時間浦徊。

→寫數(shù)據(jù)操作量級上來了馏予，數(shù)據(jù)服務(wù)器真的又撐不住了

8.1，我錢多盔性，上分布式文件系統(tǒng)和分布式數(shù)據(jù)庫系統(tǒng)霞丧，還慢就繼續(xù)加機器，總有快的時候冕香。省心省力

8.2蛹尝，沒錢，花點心思暂筝，根據(jù)業(yè)務(wù)對數(shù)據(jù)庫進行拆分箩言，將不同細分業(yè)務(wù)數(shù)據(jù)放到不同的數(shù)據(jù)服務(wù)器上，重點數(shù)據(jù)用更好的服務(wù)器焕襟。

→數(shù)據(jù)量大陨收，檢索和生成報表巨慢

9，使用NoSQL放需要檢索的數(shù)據(jù)，減輕原來數(shù)據(jù)庫服務(wù)器壓力

→業(yè)務(wù)復(fù)雜务漩，技術(shù)開發(fā)難度提高

10拄衰，業(yè)務(wù)拆分，根據(jù)不同的產(chǎn)品線拆分技術(shù)開發(fā)饵骨，看起來是一個網(wǎng)站翘悉，其實是不同的應(yīng)用來共同提供數(shù)據(jù)的

→業(yè)務(wù)拆分粒度越來越小，服務(wù)部署維護困難

11居触，分布式服務(wù)妖混，統(tǒng)一運維

架構(gòu)模式

模式，描述了一個不斷重復(fù)發(fā)生的問題和該問題解決方案的核心轮洋。這樣制市，你就能一次次的使用該方案而不必做重復(fù)工作。

網(wǎng)站架構(gòu)要解決的問題弊予，就這幾種:

1. 高性能祥楣。就是要快！
2. 高可用汉柒。7*24在線可用误褪，掛了就不好了。
3. 易伸縮碾褂。能隨訪問量兽间，數(shù)據(jù)處理量的大小。進行擴容降容正塌，不再門庭若市時候奔潰渡八，不在人去樓空時浪費錢。
4. 可擴展传货。師傅師傅大師兄又加需求了！好的架構(gòu)宏娄，要隨業(yè)務(wù)的發(fā)展问裕，無痛加功能加服務(wù)。
5. 安全孵坚。不安全粮宛，以上都是白搭。

以上這些問題重復(fù)的出現(xiàn)卖宠，也就形成了解決的模式巍杈。常見的模式:

1. 分層。橫向切割扛伍。應(yīng)用層靠近用戶筷畦，負責(zé)具體業(yè)務(wù)和頁面展示，也就是常說的后臺和前端那部分，現(xiàn)在都是前后端分離了鳖宾，也是分層的一種方法吼砂。服務(wù)器提供具體服務(wù)支持，比如訂單結(jié)算鼎文，購物車服務(wù)等渔肩，我現(xiàn)在工作大概就是在這一層，所以不要再問我后臺后端差別了啊啊啊拇惋。數(shù)據(jù)層周偎，最后面，提供數(shù)據(jù)存儲的撑帖。
2. 分割蓉坎。縱向切割磷仰。將不同業(yè)務(wù)進行分割袍嬉，例如淘寶，購物車灶平，搜索伺通，廣告分割成不同的應(yīng)用，由獨立團隊進行負責(zé)逢享。
3. 分布式罐监。不同應(yīng)用放不同物理機子，分布式部署可以對不同的應(yīng)用服務(wù)做到資源的有效分配瞒爬。
4. 集群弓柱。多臺服務(wù)器部署相同的應(yīng)用，通過負載均衡對外提供服務(wù)侧但，集群再提高更好的并發(fā)特性的同時矢空，也能提供系統(tǒng)的可用性，一臺掛了還有一臺嘛禀横。
5. 緩存屁药。CDN，redis等等柏锄。緩存主要是兩個難點酿箭，怎樣提供緩存命中率和設(shè)置過期時間避免臟讀。
6. 異步趾娃。這一塊是重點缭嫡，異步架構(gòu)是典型的生產(chǎn)者消費者模式，應(yīng)用使用隊列進行消息傳遞而不直接互相調(diào)用抬闷。好處有二妇蛀，可用性提高，如果后面的應(yīng)用掛了，前面的應(yīng)用還能繼續(xù)接收用戶請求讥耗，數(shù)據(jù)堆入隊列有勾，等掛了的應(yīng)用重啟繼續(xù)消費隊列就可以了。消除訪問波峰古程，突然的一波訪問蔼卡，如果沒有異步處理，后端壓力會驟增挣磨，很可能就崩了雇逞，異步處理能將消息放進消息隊列，后端依次處理茁裙，就不會有太大問題塘砸。
7. 冗余。服務(wù)器隨時會掛晤锥，多備一臺服務(wù)器掉蔬，數(shù)據(jù)多做一份備份，總是好事矾瘾。雖然有點費錢女轿。
8. 自動化。發(fā)布過程自動化壕翩，人為操作很容易出錯蛉迹，當(dāng)然，需要自動發(fā)布系統(tǒng)足夠好用放妈。
9. 安全北救。加密，驗證碼芜抒，風(fēng)險控制珍策。

這本書主要就是圍繞以上內(nèi)容進行講解，涉及的具體技術(shù)細節(jié)這里就不詳述了宅倒，技術(shù)棧一直在變膛壹，書里介紹的有些也有可能已經(jīng)過時了，但萬變不離其宗唉堪，應(yīng)當(dāng)朝著正確的方向，不斷學(xué)習(xí)肩民。下面簡單聊一些個人書后的思考唠亚。

異步的問題

和人不同的是，網(wǎng)站系統(tǒng)持痰，任何可以晚點再做的事情都應(yīng)該晚點再做灶搜。

一般就是使用消息隊列將調(diào)用異步化，一個應(yīng)用接一個應(yīng)用的處理數(shù)據(jù)，上游處理完了丟到下游割卖，上游無需下游立即甚至壓根不用下游進行反饋前酿。

消息隊列的應(yīng)用，使系統(tǒng)的靈活性大大提高鹏溯，起到很好的削峰作用罢维。前面的應(yīng)用將短時間內(nèi)大量的請求存入消息隊列，推遲處理時間丙挽，使到后面吃大量內(nèi)存CPU的應(yīng)用不至于被壓垮肺孵。固定的消費速率也使數(shù)據(jù)庫服務(wù)器的并發(fā)數(shù)得到控制。

但是颜阐，異步也會帶來很多麻煩的事情平窘。

從前，有一個程序員凳怨，他有一個問題瑰艘，他想用異步來解決，現(xiàn)在兩個他問題了有肤舞。

由于數(shù)據(jù)操作被異步化了紫新，所以很難確定數(shù)據(jù)究竟處理完了沒有，也很難保障數(shù)據(jù)的一致性萨赁，前端應(yīng)用認為處理完了弊琴，后端其實還沒好，就會出現(xiàn)很多問題杖爽，導(dǎo)致數(shù)據(jù)不一致敲董，處理結(jié)果出現(xiàn)異常。這經(jīng)常需要額外的同步操作來進行核實數(shù)據(jù)慰安，帶來額外的開銷腋寨。

另一個問題是，異步會導(dǎo)致數(shù)據(jù)的更新不及時化焕，當(dāng)然萄窜，這是異步的目的，同樣也是缺點撒桨，看不同的場合查刻。比如每日賣家報表，推遲個幾分鐘再統(tǒng)計出來沒有任何問題凤类，但是像秒殺系統(tǒng)穗泵，推廣限額系統(tǒng)，就不能容忍數(shù)據(jù)統(tǒng)計延遲谜疤。在應(yīng)用了異步處理的架構(gòu)里佃延，這些需求也就都需要額外處理现诀，提供系統(tǒng)的復(fù)雜性。

所以履肃，不要迷信技術(shù)仔沿，不是任何網(wǎng)站都需要異步化的，也不是異步架構(gòu)里每個環(huán)節(jié)都需要異步化的尺棋。技術(shù)用到正確的地方才是好的技術(shù)封锉。

應(yīng)用服務(wù)無狀態(tài)化的價值

墨菲定律，如果一個服務(wù)有幾率會掛陡鹃，那它終有一天一定會掛給你看烘浦。

無狀態(tài)應(yīng)用服務(wù)，就是此應(yīng)用不保存業(yè)務(wù)的上下文信息萍鲸，而僅根據(jù)每次請求提交的數(shù)據(jù)進行相應(yīng)的業(yè)務(wù)邏輯處理闷叉。部署兩臺服務(wù)器，請求無論被哪臺處理了脊阴，結(jié)果都是一樣的握侧。這里可以聯(lián)想對比下函數(shù)式編程，道理有點類似嘿期。

無狀態(tài)的應(yīng)用品擎，對整體的架構(gòu)設(shè)計有非常大的幫助。不用考慮宕機時會影響到業(yè)務(wù)數(shù)據(jù)處理和業(yè)務(wù)數(shù)據(jù)丟失备徐。掛了萄传，排查問題后重啟直接繼續(xù)干活，不用做任何額外的數(shù)據(jù)糾正蜜猾，這讓和它配合的應(yīng)用都省心很多秀菱。

微服務(wù)做到無狀態(tài)，需要編程經(jīng)驗蹭睡，和對業(yè)務(wù)流程有清晰的認識衍菱，這些還要繼續(xù)研究。

不要企圖用技術(shù)解決所有問題

網(wǎng)站的價值肩豁，在于能為用戶做什么脊串，而不在于它是怎么做的。業(yè)務(wù)成就技術(shù)清钥，而不是相反琼锋，一個快速發(fā)展的網(wǎng)站，才能驅(qū)動技術(shù)架構(gòu)不斷改進祟昭。

正確的業(yè)務(wù)架構(gòu)缕坎，遠比正確的技術(shù)架構(gòu)重要。產(chǎn)品認識到位从橘，業(yè)務(wù)邏輯清楚念赶，對技術(shù)的開發(fā)往往起到事半功倍的作用。

前面提到的分層分隔恰力，怎樣分叉谜，和業(yè)務(wù)是密切相關(guān)的。都說程序員需要嚴密的邏輯思考能力踩萎，其實停局，產(chǎn)品或者業(yè)務(wù)人員同樣需要嚴密的邏輯能力。將具體但繁雜的業(yè)務(wù)需求香府，發(fā)展方向董栽，梳理清楚，1234拆分出層次分明企孩，輕重緩急的細分業(yè)務(wù)锭碳，組成清晰的業(yè)務(wù)架構(gòu)。

愿天下沒有難寫的代碼勿璃，只有賺錢的業(yè)務(wù)擒抛，阿門。