正文之前先和大家閒扯一下。作爲一個程序員，我們還是需要思考未來的出路，但感覺一直做技術也不是個頭。我不像其他博主那麼牛叉，差不多都是百度，阿里，騰訊的大神級人物。但是歸結於一點，不管你身在何處，總歸還是想有自己的一番事業，有一家屬於自己或者合夥的公司！這段時間我一直在思考自己未來的出路在哪裏？面對家庭壓力，事業瓶頸該怎麼去突破，一直很困擾！如果有相似境遇的人大家可以一起交個朋友私下聊聊！
心裏的話說出來也算好受一點，話不多說，下面切入正題
一、傳統項目架構
定義：傳統項目其實就是一個Web工程，裏面包含所有組件(數據庫連接組件，數據持久層組件，業務邏輯層，控制器，頁面資源) + 單機數據庫，同時如果有資源需要上傳的 話，也是上傳到本地工程服務器！
優點：適合小型項目，能夠快速開發，不需要針對環境做太多複雜的部署，靈活性強，增添功能，文件相對容易
缺點：項目需求增多項目的會繼續增大，不能靈活的拆分模塊，隨着業務的增大拆分極度困難，耦合高！用戶量增大更加的容易導致單機瓶頸，響應慢，或者系統崩潰。
二、傳統項目架構 + web負載均衡
隨着 "一" 中用戶訪問量的增加單機性能達到瓶頸那麼我們可以通過添加web服務器的方式來提高訪問量，可以進一步緩解大用戶量的訪問需求。這或許對經驗不足的朋友看來有點難理解，下面我畫一幅草圖大家可以大致明白。
這裏引入一個新的概念就是負載均衡服務器，apache服務器本身也有負載均衡的作用，但是這裏不是很常用因爲其併發性和穩定性不是特別高，因此不推薦。再有就是市面上比較流行Nginx，各大互聯網公司應該都在使用，其性能極高，大家可以百度一下Nginx的各方面性能，極力推薦。如果公司預算充足的話，可以買硬件資源來做負載均衡器，比如H5服務器等，但是價格會比較高！
補充(負載均衡器的定義)：負載均衡機就好比一個汽車調度中心，所有的汽車到來都先經過調度中心，然後告知每輛車停哪個車位，最後在停到具體車位上去，車位就相當於(Web服務器)
三、傳統項目架構 + web負載均衡 + 數據庫集羣
“二“ 中服務器架構可以進一步增大系訪問量，但是隨着時間的推移，發覺數據庫的數據量越來越大，有點跑不動了，那麼這個時候又需要針對系統做另一部改進了。大家看如下圖。
相對於二中我們增加了一臺數據庫服務器，這裏只是一個例子，如果數據庫還不夠用，可以考慮多增加一些寫入數據庫和讀取數據庫，博主在這裏，只舉一個典型的例子，能夠起到拋磚引玉，舉一反三的作用。
架構難點詳解：1：寫入數據庫和讀取數據庫之間如何進行數據同步呢。2：怎麼通過web服務實現讀寫分離呢？請大家帶着問題細細的往下看。
問題一數據庫同步的問題相對來說比較容易解決網上有很多解決方案,MySql數據同步，搜索就一大把這裏就不多做解釋。
問題二可能相對來說有點難：其實這裏有兩種解決方案，一是引入數據中間件，二是在Web運用層開啓AOP，通過切面的方式動態切換數據源，前提是需要自己制定好切面的規則。
四、傳統項目架構 + web負載均衡 + 數據庫集羣 + 數據庫垂直拆分
備註：數據庫集羣也叫數據庫的水平擴展
繼續隨着用戶訪問量增加，以及單表數據達到上限(數據庫達到幾千萬，甚至上億條數據)，這個時候應該考慮針對每張表做水平切分，切分的規則由自己制定！
因此架構的整體難度又將大大增加，如果繼續在Web層面做一些改進會導致耦合性增加，而且不利於再擴展，因此需要對“三”中架構做相對改造，引入數據中間件，先看如下圖
架構越來越龐大，大家一定要細心的讀取和看博文，下面我解釋一下大概思路：
我們不能夠繼續沿用三中的架構方式，不能夠在Web層面開啓AOP做一個讀寫分離了(原因上面已經說過)，這裏需要引入數據中間件服務器。每當有數據訪問的時候，我們先訪問中間件，在通過規則引擎分配到切片上，如果有寫入操作直接走分片的寫數據庫，讀操作直接走讀服務器，這樣把原本一張表的的數據可以分別分配到兩個不同的數據庫中，大大的緩解了數據訪問的壓力。
五、傳統項目架構 + web負載均衡 + 數據庫集羣 + 數據庫垂直拆分 + 緩存技術
但是隨着數據量再次增多，還是發覺系統可能會響應較慢，這個時候，我們可以通過緩存技術來提升訪問銷量，目前常用的緩存技術：ehcache，memcached，redis,Mongo...
這些技術也是普遍常用的,各個技術的優劣大家可以下來百度查找一下。