聊聊應用系統架構的0到1

默默在看新機會的你，是否是面試的時候，偶爾被問起「能不能簡單介紹一下項目的應用系統架構」？沉迷於業務開發的大家，有沒有考慮過「用戶訪問到你開發的業務功能，到底通過了哪些環節」？

關注"一猿小講"公衆號的粉絲們今天有福了，由於今天我將結合這些年的一些認知理解，開壇設法給你們講一講應用系統架構的從 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. 寫在最後

今天主要結合我的的理解，簡單聊了聊應用架構的部署演變歷程，但願你可以有所收穫。好了，碼字不易，畫圖更不容易。若是感受稍微有點意思，不用讚揚，就點擊右下角的「在看」，或者多多分享給你的朋友就很感激。