大型Java项目架构演进
為什么80%的碼農(nóng)都做不了架構(gòu)師？>>> ??
大型Java項目架構(gòu)演進過程
1. All-In-One （所有服務(wù)在一臺服務(wù)器上）：
? ?也就是所有的服務(wù)都在同一個服務(wù)器上，包括應(yīng)用服務(wù)器、文件服務(wù)器和數(shù)據(jù)庫
2. 各服務(wù)分別部署在不同的服務(wù)器上
? ? 隨著用戶越來越多，訪問量越來越大，硬盤、CPU、內(nèi)存等硬件開始吃緊，一臺服務(wù)器已經(jīng)無法滿足需求，這個時候就需要將不同的服務(wù)部署在多個服務(wù)器上，給應(yīng)用服務(wù)（Application server）配置更好的內(nèi)存和cpu，給數(shù)據(jù)庫服務(wù)器配置更好，更大，更快的硬盤。
3. 添加緩存服務(wù)器：
? ? 隨著訪問的并發(fā)越來越高，為了縮短接口的訪問時間，提高訪問性能。
????同時發(fā)現(xiàn)，我們的很多業(yè)務(wù)數(shù)據(jù)不需要每次都從數(shù)據(jù)庫中獲取，于是我們使用緩存來進行數(shù)據(jù)緩存，提高訪問速度。
? ? （80%的業(yè)務(wù)集中在20%的數(shù)據(jù)上，即2--8原則）
? ? 在這里緩存又可以分為? 本地緩存 和 遠程緩存。 同時，遠程緩存又有兩種情形：單機緩存 和 分布式集群緩存
? ? 使用該架構(gòu)需要思考和解決的問題：
????? ? 1. 哪種業(yè)務(wù)特點的數(shù)據(jù)需要進行緩存
????? ? 2. 哪些數(shù)據(jù)適合進行本地緩存，哪些數(shù)據(jù)適合進行遠程緩存
????? ? 3. 分布式緩存在擴容時會遇到什么問題，如果解決
????? ? 4. 分布式緩存的算法都有哪幾種，各有什么優(yōu)缺點
?
4. 增加負載均衡器，服務(wù)器均衡：
? ? 隨著訪問的QPS(每秒查詢率)不斷的提高，服務(wù)器的處理能力（例如Tomcat）可能就會出現(xiàn)瓶頸，雖然也可以購買更加強大的硬件，但總會有上限，而且這個成本到了后期會出現(xiàn)指數(shù)級的增長，這個時候就需要做一個服務(wù)器的集群，通過負責均衡服務(wù)器來實現(xiàn)服務(wù)集群訪問。
? ? 這個時候需要考慮的問題：
????? ? 1. 負責均衡的調(diào)度策略都有哪些，各有什么優(yōu)缺點，各適合什么場景。
?????????調(diào)度策略： 輪訓、權(quán)重、地址散列（包含：源ip散列 和 目的ip散列）、最少連接、加權(quán)最少連接
????? ? 2. session的管理問題
????????? ? 同一用戶可能第一次登陸的是A服務(wù)器，那么session信息是保存在A服務(wù)器上的，第二次可能訪問的是B服務(wù)器，這個時候B服務(wù)器上并沒有該用戶的session信息，這時就涉及到了session管理的問題問題。
????? ? 方式1.?可以使用 Session?Sticky（粘滯會話）
????????????
????????????實現(xiàn)原理：對于同一連接中的數(shù)據(jù)包，負載均衡會將其進行一個轉(zhuǎn)化，然后轉(zhuǎn)發(fā)至后端固定的服務(wù)器上進行處理。也就像上圖所示，Browser1每次都會訪問Application1這個服務(wù)器。這個方案解決了session的共享問題。但是同時又有缺點：1. 如果Application1進行了重啟，那么保存在其上的信息將會全部消失，2. 負載均衡器成為了一個有狀態(tài)的服務(wù)器，要實現(xiàn)容災(zāi)會有麻煩。
????????? ? 方式2.? Session Copy
? ? 實現(xiàn)原理：Application之間會copy自身保存的session到其他服務(wù)器上，使得用戶通過負載均衡不論將請求發(fā)送至哪個Application，該Application都有該用戶的session信息。缺點：1. 由于Application之間要不斷的同步session信息，可能造成帶寬不夠的問題。2. 當大量用戶在線的時候，Application會占用大量的內(nèi)存，不適合做大規(guī)模集群。
方式3. 基于cookie
????? ? 實現(xiàn)原理：用戶攜帶含有session信息的cookie去訪問Application。缺點：1. cookie的長度是有限制的? 2. cookie保存在瀏覽器上，安全性是一個問題。
????方式4. 使用session服務(wù)器
? ? 實現(xiàn)原理：所有用戶的session信息都統(tǒng)一保存在session server中。缺點：1. session server是個單點的，如何解決該server的單點，保證其高可用性 ?
5. 數(shù)據(jù)庫的讀寫分離：
? ? 當用戶量達到一定量的時候，數(shù)據(jù)庫的讀寫操作的都是同一個數(shù)據(jù)庫，這個時候數(shù)據(jù)庫就成為了一個瓶頸，這個時候就可以進行數(shù)據(jù)庫的讀寫分離
????? ? 包含主庫和從庫，同時應(yīng)用要接入多數(shù)據(jù)源，并且通過統(tǒng)一的數(shù)據(jù)訪問模型進行數(shù)據(jù)訪問，數(shù)據(jù)庫讀寫分離將所有的讀操作全部引入到Slave這個數(shù)據(jù)庫中，將所有的寫操作全部引入到Master這個數(shù)據(jù)庫中，同時由于進行了讀寫數(shù)據(jù)分離，我們在應(yīng)用中實現(xiàn)了數(shù)據(jù)訪問模塊，使得上層寫代碼的人不知道數(shù)據(jù)讀寫分離的情況，這樣我們多數(shù)據(jù)源的讀寫對業(yè)務(wù)代碼就沒有了侵入。
????? ? 這個時候引申的問題就有：1. 如何支持多數(shù)據(jù)源，2.?如何封裝對業(yè)務(wù)沒有侵入，3. 如何使用目前項目使用的ORM框架完成底層的讀寫分離，4. 是否需要更換ORM，又各有什么優(yōu)缺點，如何取舍。
????? ? 當數(shù)據(jù)量非常大的時候，數(shù)據(jù)庫的讀寫分離又會遇到一下問題：1. 主庫和從庫在同步的時候，有沒有延時；如果我們將主庫和從庫進行了夸機房部署，那么在跨機房數(shù)據(jù)傳輸?shù)臅r候，延時更是一個問題。2. 應(yīng)用對數(shù)據(jù)源的路由問題
?6. 曾加了CDN和反向代理服務(wù)器：
? ? 為了提高服務(wù)器，又增加了CDN 和反向代理服務(wù)器。使用CDN可以很好的解決不同地區(qū)訪問速度的問題；反向代理則可以緩存用戶的資源
?
?7. 文件服務(wù)器改為了分布式文件服務(wù)器：
? ? 需要考慮的問題：1. 如何不影響已部署在線上的業(yè)務(wù)訪問（不能出現(xiàn)某個圖片不能訪問了），2. 是否需要業(yè)務(wù)部門幫忙清洗數(shù)據(jù) 3. 是否需要備份服務(wù)器 4. 是否需要重新做域名解析等等。
8. 數(shù)據(jù)庫分表：
? ? 數(shù)據(jù)量大的時候，數(shù)據(jù)的增刪改查又出現(xiàn)了瓶頸，這個時候我們選擇使用專庫專用的方式，進行數(shù)據(jù)的垂直拆分，相關(guān)的業(yè)務(wù)都使用自己專有的庫。
? ? 需要考慮的問題：1. 跨業(yè)務(wù)的事物，夸庫的事物 （可以考慮分布式事物，或者去掉事物，或者不追求強事物），2. 夸庫的join怎么實現(xiàn)
9. 數(shù)據(jù)庫分表
? ? 隨著訪問量過大，業(yè)務(wù)量過大，可能出現(xiàn)某個業(yè)務(wù)的數(shù)據(jù)庫的數(shù)據(jù)達到了單個數(shù)據(jù)庫的瓶頸，這個時候就要考慮進行數(shù)據(jù)庫的水平拆分（將同一個表的數(shù)據(jù)拆分到兩個數(shù)據(jù)庫中）
????? ? 需要考慮的問題：1. sql路由的問題（假設(shè)查詢某個用戶，如何確定用戶在哪個數(shù)據(jù)庫中）2. 主見的策略會有所不同 3 分頁的問題
10.?添加了搜索引擎和NoSql服務(wù)器
? ? ? ? 假如發(fā)現(xiàn)我們應(yīng)用服務(wù)器上的搜索量飆升，或者因為我們對外做了一個推廣，這個時候我們將Application中的搜索功能單獨拆分出來，做了一個搜索引擎，同時部分場景可以使用NoSql提高性能，同時我們開發(fā)一個統(tǒng)一的數(shù)據(jù)訪問模塊，這個某塊下面連著數(shù)據(jù)庫集群、搜索引擎、還有NoSql，解決上層應(yīng)用開發(fā)的數(shù)據(jù)源問題。
?
?
轉(zhuǎn)載于:https://my.oschina.net/Declan/blog/2222455
總結(jié)
以上是生活随笔為你收集整理的大型Java项目架构演进的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MYSQL timestamp NOT
- 下一篇： PostgreSQL 10.1 手册_部