默默在看新機會的你，是不是面試的時候，偶爾被問起“能不能簡單介紹一下項目的應用系統架構”？

沉迷於業務開發的你們，有沒有考慮過“用戶訪問到你開發的業務功能，到底經過了哪些環節”？

今天我將結合這些年的一些認知理解，開壇設法給大家講一講應用系統架構的從 0 到 1。

01.  如何造一個大泥球？

產品汪：緊急需求，2 天時間完成 x 網站的上線，包含知識問答頁面功能。

程式猿：時間短，任務緊。一切以上線為目標，那一切皆可是靜態，一切皆是硬編碼。花半天時間，讓前端妹子寫成靜態 HTML，打成 x.war 包，放到Web伺服器（Tomcat）就輕鬆搞定所有。

產品汪：上一版的需求功能實現不錯，領導很滿意。接下來要實現註冊、登錄功能。其中註冊功能包含開通三方賬戶，開通三方賬戶會存在超時現象，超時後需要繼續開通賬戶，前端頁面提示開戶處理中。

程式猿：註冊成功需要用 MySQL 做存儲；開通三方賬戶超時的需要繼續處理，那這個只能加個定時任務系統來重新跑批支持了。

產品汪：沒想到你們開發團隊挺給力啊，上期的功能又得到了領導的大力認可，不過我們想看看開通失敗的用戶有哪些，順帶著能修改部分信息？另外我們還想通過頁面添加知識問答的文章？

程式猿：沒問題，產品汪只要需求，我們猿就開擼。不就是再開發個運營管理平臺麽，代碼copy、粘貼，so easy！！

到此一個小而全的大泥球系統就產生了，或許你已經從事了 N 年的研發，也一直不停的再和這幾個系統打交道。

02. 如何使大泥球跑的更好？

起初產品需求簡單，開發的功能也簡單，網站系統架構也簡單。如上圖所示：網站架構用一臺Web伺服器就輕鬆搞定。

隨著業務推廣，如上圖所示：用戶量逐日增長，單台Web伺服器（Tomcat）肯定不能滿足網站的需求。

面對這個問題，不得不提提尼古拉斯趙四說過的一句話：世界上沒有什麼事，是一頓燒烤不能解決的，如果有，那就兩頓。這個問題不就是這種解決方案麽，一臺 Web 伺服器不夠，那就再加一臺唄。但是用戶卻鬱悶了，訪問地址變成了兩個，這用戶、產品汪們肯定都不能接受。

程式猿再三思考一二。如上圖所示：那就站在尼古拉斯趙四的肩膀上，再部署一個Nginx專門用來做分發，那問題不就解決了麽。Web 應用伺服器部署的問題是解決了，但是卻引入了另外一個問題，如果做分發的Nginx掛了，咋辦呢？

各位看官肯定也想到了尼古拉斯趙四的解決方案：那就再部署一份 Nginx。但是用戶也會很鬱悶，訪問地址又變成了兩個，這用戶、產品汪們肯定都不能接受。

程式猿往往會出其不意、未雨綢繆。天上飄來五個字“那都不是事”，加個 LVS 支撐一下問題不就迎刃而解啦。結合前面的步驟，你肯定也會有疑問“如果 LVS 掛了怎麼辦？”，若有此疑問，說明你的思考沒毛病。如上圖所示：LVS 是主備，並且主備之間進行通訊，如果 master 主的掛掉，備的會成為主節點繼續對外服務。

到目前為止你對應用架構集群的部署就瞭解差不多了，隨著業務的逐日增多，其中Nginx集群可以橫向擴展、Web伺服器也是可以橫向擴展，但是 MySQL 資料庫勢必會成為瓶頸，那該怎麼辦呢？

如上圖所示：面對MySQL成為瓶頸時，想到的便是分工明確、各司其職、進行資料庫讀寫分離。一般也會引入基於記憶體的資料庫 Redis，把經常讀的信息緩存一份。

如果數據量級特別大，那不得不用一下資料庫分庫分表，可用的技術有 MyCat、Sharding-Jdbc，今天就不再進行深入展開啦。

03. 帶你裝 B，帶你飛

另外在微服務發展盛行的今天，上述的應用架構（單體架構）確實也存在有不足點，就送給大家一張圖，大家自己搜一下微服務相關的知識，腦補一下空白吧。

再送給大家拋一個“Service Mesh”服務網格的概念，有時間也可以稍微瞭解一下，技多不壓身。

04. 寫在最後

今天主要結合個人的理解，簡單聊了聊應用架構的部署演變歷程，希望你能夠有所收穫。好了，碼字不易，畫圖更不容易。如果感覺稍微有點意思，多多關註「一猿小講」。