2.1 從一個故事說起

2.2 訪問量驅動架構
2.3 單機架構
2.4 多機架構-三分天下
2.5 叢集架構-負載均衡
2.6 分散式架構-MySQL分表分庫分片
2.7 小張講解
2.8 課後作業

2.1 從一個故事說起

7月7日，晴，外面下起了小雨，屋裡女朋友盯著手機，各種淘寶，各種衣服...  目不轉睛的看著手機螢幕。

而我呢，盯著沒有訊號的電視發呆...思緒一下子就回到了好多年前。

2006年7月7日，路上，熙熙攘攘的人群，好多妹紙在逛街，女人天生就喜歡買衣服，你去到步行街的only, 優衣庫的品牌店看看，

大把的妹紙好像等著你一樣！

2009年7月7日，網際網路一下子火爆起來，搶車位、偷菜這些社交遊戲十分火爆，有的妹紙為了偷好友的菜，竟然晚上一直守到了

凌晨3點，除了買衣服還有什麼事情可以讓妹紙熬夜到這麼晚呢。

2012年7月7日，隨著社交遊戲的褪去，妹紙們依舊是回到了購物買衣服這件事情上面來了，只是這次不是逛街，而是網上逛淘寶，想想那會

女朋友偶爾開啟電腦開個把小時網頁，看看衣服購物，因為當時物流還不是非常的發達，不是經常網上購物，很多時候還是會去步行街逛逛。

2016年7月7日，晃了一下神，整個人回到了現在，旁邊，女朋友還在看著手機，逛著唯品會，雨也還在下著，可想而知，如今移動網際網路的

發達，已經沒有多少妹紙願意去逛街了，東門步行街人少了，華強北沒落了，波司登、利郎、百麗、佐丹奴、安踏、九牧王、七匹狼這些傳統

知名品牌接連關店了。

這到底是好事還是壞事呢，網際網路帶給我們很多方便和快捷，但是似乎讓我們少了很多購物的樂趣和麵對面的溝通。

世界上最遙遠的距離是我和你在一起，而你卻在玩手機。

親愛的，洗洗睡了吧。。

2.2 訪問量驅動架構

為什麼說是訪問量驅動架構的變革呢？

技術的發展離不開業務的需求，如果我們網站一天的訪問量只有幾百人，我們還需要做分散式架構嗎，我肯定的說：不需要。

當使用者訪問量達到了幾萬或者幾十萬的PV訪問，單機架構肯定是支撐不了的，這個時候就需要新的架構，但不一定是分散式，

這個就是 “量（訪問量）變到質（架構）變”。一定的訪問量以後，需要新的架構來支撐整套系統，不然系統就崩潰了。

為什麼會有如今這麼複雜的各種架構呢，得益於電商的發展，得益於中國勞動人民的人群基數，我代表。。額，代表我自己

感謝大家了 ：）.

架構是一直在發展的，除了分散式，現在比較流行的 微服務架構也正在快速的發展。

上一節通過不同時期的生活場景，讓大家感受到網際網路的發展，以及各個階段所用的架構是怎麼樣的，下面就介紹各個時期所用的架構。

2.3 單機架構

每個開發者都會經歷一遍這個架構，現在來看，他實在是太簡單了，讓很多人都以為他不是一種架構，小張想說的就是，

這是最簡單的單機架構，現在物資生活豐富了，大家一個人會有很多部手機，如果你有廢棄的手機不妨拿來做個伺服器，

手機做伺服器，這也是單機架構的一種實踐。

小張推薦一款Android 下面的APP ksweb ，下載安裝十分簡單，安裝好了以後就可以啟動一個網站伺服器，通過

http://ip:8080 網頁就可以訪問了。

KSWEB

ksweb 裡面包含 php應用伺服器，Mysql的資料庫，以及檔案系統。

單機架構圖如下：

單機架構圖

應用伺服器，資料庫，檔案系統全部放在一臺物理伺服器上面。

誰有膽量的把地址發到朋友圈，叫上你朋友圈裡所有人，來訪問你的手機，看看能不能像三星手機有種爆炸的效果.

2.4 多機架構-三分天下

單機已經被我們玩壞了，這個時候自然有人要出來解決問題了，如何解決呢

最容易想到的方法就是，把應用伺服器、資料庫、檔案系統分開，把他們三，三分天下

於是，架構圖就演化成下面這樣：

多機架構圖

這個很簡單，是吧，把應用伺服器、資料庫、檔案系統分別放到三臺不同的物理機上，來分攤壓力。

但是你不能小看中國妹紙們的力量，電商的爆發，讓她們的購物的慾望得到了釋放，

簡單的多機架構已經撐不住了，也是妹紙們的慾望成就了我們，能讓我們做出更好的架構。

2.5 叢集架構-負載均衡

因為我們現在已經將應用伺服器、檔案系統、資料庫分離到三個不同物理機上了，

我們可以針對每臺物理機上面的系統做優化，訪問量爆增以後，併發量大，最先撐不住的就是應用伺服器了，

這個時候我們對應用伺服器這部分做一個叢集的架構，然後對這個叢集做負載均衡，

簡單來說，現在應用伺服器是一臺物理機，我們用多臺物理機來對應用伺服器做叢集，然後訪問量來了以後

利用負載均衡的技術將訪問量分攤到不同的物理機上，這樣訪問量被分攤了，每臺機承受的壓力就小了，

並且這種架構還有很強的擴充套件性，如果碰到雙11 訪問量徒增，我們可以通過增加叢集機器的方式來進行擴充套件。

這種叢集架構的架構圖如下：

叢集架構圖

2.6 分散式架構-Mysql分表分庫分片

但是如果真的是雙11 ，上面的架構就真的可以滿足一天十幾億次的訪問量嗎，當然是不可能的，

這裡先介紹一個木桶效應：

木桶效應

木桶是有很多豎著的板子圍起來了的，整個木桶能裝多少水並不是高的那塊板決定的，而是由最短的那塊板決定，

這就是木桶效應，而木桶效應同樣的適用於架構設計

叢集架構只是解決了整個系統中應用伺服器這一塊的效能，而瓶頸（短板）在資料庫這一塊，所以整個系統效能的提高

還得提高資料庫這一塊的效能。

但是資料庫這一塊可不可以像應用伺服器那樣做個叢集，來提高效能呢，這個就要從應用伺服器和資料庫在整個系統中的定位來分析了，

應用伺服器 只是對 使用者的訪問請求作處理

資料庫是對業務的資料做儲存、查詢，還有事務處理等，涉及到資料的操作，會有多表查詢，資料一致性的考慮。

所以從這方面來看，資料庫這一塊似乎要複雜很多，應用伺服器的每個請求都是獨立的，所以可以任意分佈到叢集的任何物理機上。

如果將資料也任意分佈到資料庫叢集的任意物理機上，那麼等你查詢的時候，就完全不知道如何來查了。

這樣，拿Mysql 為例，我們要他的效能作提升，就需要 利用一定的 分庫分表策略 來進行，而這部分的工作就交由 Mysql資料庫中介軟體Mycat  來做。

這種架構我們稱之為分散式架構，如圖：

分散式架構圖

理解了Mycat 在整個系統中的定位 ，有利於接下來我們對他的學習， 學習Mycat之前，我們還將進行一些Mysql資料庫的知識預備。

2.7 小張講解

> 關於架構的衍生

用叢集架構來說，如果使用者訪問量併發量剛剛上來，我們不用急於改變整體架構，因為這樣重新架構一個正在生產的系統，代價是

非常大的，我們可以通過快取的機制，來提高效能，提高整個系統效能的方法在於找到那個短板，影響效能的短板，然後進行優化，

系統的短板在於資料庫，資料庫的短板在於IO，所以通過快取可以降低IO的讀寫，有利於系統效能的提升。

> Mysql 讀寫分離

在不使用分表分庫，資料分片之前，我們還可以對 Mysql資料庫進行 讀寫分離，具體如何在實際專案中來做，我們在後面會利用

阿里雲來進行實戰操作。

2.8 課後作業

1. 架構發展路線圖

2. 如何優化系統效能的思路

3. 何為木桶效應

4.如何運用快取技術提高系統效能

本文原創小張，轉載請註明來源地址小張部落格