默默在看新機會的你，是不是面試的時候，偶爾被問起“能不能簡單介紹一下專案的應用系統架構”？
沉迷于業務開發的你們，有沒有考慮過“用戶訪問到你開發的業務功能，到底經過了哪些環節”？
今天我將結合這些年的一些認知理解，開壇設法給大家講一講應用系統架構的從 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. 寫在最后
今天主要結合個人的理解，簡單聊了聊應用架構的部署演變歷程，希望你能夠有所識訓，好了，碼字不易，畫圖更不容易，如果感覺稍微有點意思，多多關注「一猿小講」，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/5992.html
標籤：架構設計
上一篇：搭建生產級的Netty專案
下一篇：安全架構模型應該怎么設計？