記一次JavaWeb網(wǎng)站技術(shù)架構(gòu)總結(jié)
時間：2023-08-15 13:54:01 | 來源：網(wǎng)站運營
時間：2023-08-15 13:54:01 來源：網(wǎng)站運營
記一次JavaWeb網(wǎng)站技術(shù)架構(gòu)總結(jié)：
題記
工作也有幾多年了，無論是身邊遇到的還是耳間聞到的，多多少少也積攢了自己的一些經(jīng)驗和思考，當然，博主并沒有太多接觸高大上的分布式架構(gòu)實踐，相對比較零碎，隨時補充(附帶架構(gòu)裝逼詞匯)。
俗話說的好，冰凍三尺非一日之寒，滴水穿石非一日之功，羅馬也不是一天就建成的，當然對于我們開發(fā)人員來說，一個好的架構(gòu)也不是一蹴而就的。
初始搭建
開始的開始，就是各種框架一搭，然后扔到Tomcat容器中跑就是了，這時候我們的文件，數(shù)據(jù)庫，應用都在一個服務器上。
服務分離
隨著系統(tǒng)的的上線，用戶量也會逐步上升，很明顯一臺服務器已經(jīng)滿足不了系統(tǒng)的負載，這時候，我們就要在服務器還沒有超載的時候，提前做好準備。
由于我們是單體架構(gòu)，優(yōu)化架構(gòu)在短時間內(nèi)是不現(xiàn)實的，增加機器是一個不錯的選擇。這時候，我們可能要把應用和數(shù)據(jù)庫服務單獨部署，如果有條件也可以把文件服務器單獨部署。
反向代理
為了提升服務處理能力，我們在Tomcat容器前加一個代理服務器，我一般使用Nginx，當然你如果更熟悉apache也未嘗不可。
用戶的請求發(fā)送給反向代理，然后反向代理把請求轉(zhuǎn)發(fā)到后端的服務器。
嚴格意義上來說，Nginx是屬于web服務器，一般處理靜態(tài)html、css、js請求，而Tomcat屬于web容器，專門處理JSP請求，當然Tomcat也是支持html的，只是效果沒Nginx好而已。
反向代理的優(yōu)勢，如下：
- 隱藏真實后端服務
- 負載均衡集群
- 高可用集群
- 緩存靜態(tài)內(nèi)容實現(xiàn)動靜分離
- 安全限流
- 靜態(tài)文件壓縮
- 解決多個服務跨域問題
- 合并靜態(tài)請求(HTTP/2.0后已經(jīng)被弱化)
- 防火墻
- SSL以及http2
動靜分離
基于以上Nginx反向代理，我們還可以實現(xiàn)動靜分離，靜態(tài)請求如html、css、js等請求交給Nginx處理，動態(tài)請求分發(fā)給后端Tomcat處理。
Nginx 升級到1.9.5+可以開啟HTTP/2.0時代，加速網(wǎng)站訪問。
當然，如果公司不差錢，
CDN也是一個不錯的選擇。
服務拆分
在這分布式微服務已經(jīng)普遍流行的年代，其實我們沒必要踩過多的坑，就很容易進行拆分。市面上已經(jīng)有相對比較成熟的技術(shù)，比如阿里開源的Dubbo(官方明確表示已經(jīng)開始維護了)，spring家族的spring cloud，當然具體如何去實施，無論是技術(shù)還是業(yè)務方面都要有很好的把控。
DubboSpringCloud- 服務發(fā)現(xiàn)——Netflix Eureka
- 客服端負載均衡——Netflix Ribbon
- 斷路器——Netflix Hystrix
- 服務網(wǎng)關(guān)——Netflix Zuul
- 分布式配置——Spring Cloud Config
微服務與輕量級通信- 同步通信和異步通信
- 遠程調(diào)用RPC
- REST
- 消息隊列
持續(xù)集成部署
服務拆分以后，隨著而來的就是持續(xù)集成部署，你可能會用到以下工具。
Docker、Jenkins、Git、Maven
圖片源于網(wǎng)絡(luò)，基本拓撲結(jié)構(gòu)如下所示：
整個持續(xù)集成平臺架構(gòu)演進到如下圖所示：
服務集群
Linux集群主要分成三大類( 高可用集群， 負載均衡集群，科學計算集群)。其實，我們最常見的也是生產(chǎn)中最常接觸到的就是負載均衡集群。
負載均衡實現(xiàn)- DNS負載均衡，一般域名注冊商的dns服務器不支持，但博主用的阿里云解析已經(jīng)支持
- 四層負載均衡(F5、LVS)，工作在TCP協(xié)議下
- 七層負載均衡(Nginx、haproxy)，工作在Http協(xié)議下
分布式session大家都知道，服務一般分為有狀態(tài)和無狀態(tài)，而分布式sessoion就是針對有狀態(tài)的服務。
分布式Session的幾種實現(xiàn)方式- 基于數(shù)據(jù)庫的Session共享
- 基于resin/tomcat web容器本身的session復制機制
- 基于oscache/Redis/memcached 進行 session 共享。
- 基于cookie 進行session共享
分布式Session的幾種管理方式- Session Replication 方式管理 (即session復制)
簡介：將一臺機器上的Session數(shù)據(jù)廣播復制到集群中其余機器上
使用場景：機器較少，網(wǎng)絡(luò)流量較小
優(yōu)點：實現(xiàn)簡單、配置較少、當網(wǎng)絡(luò)中有機器Down掉時不影響用戶訪問
缺點：廣播式復制到其余機器有一定廷時，帶來一定網(wǎng)絡(luò)開銷 - Session Sticky 方式管理
簡介：即粘性Session、當用戶訪問集群中某臺機器后，強制指定后續(xù)所有請求均落到此機器上
使用場景：機器數(shù)適中、對穩(wěn)定性要求不是非?？量?br>優(yōu)點：實現(xiàn)簡單、配置方便、沒有額外網(wǎng)絡(luò)開銷
缺點：網(wǎng)絡(luò)中有機器Down掉時、用戶Session會丟失、容易造成單點故障 - 緩存集中式管理
簡介：將Session存入分布式緩存集群中的某臺機器上，當用戶訪問不同節(jié)點時先從緩存中拿Session信息
使用場景：集群中機器數(shù)多、網(wǎng)絡(luò)環(huán)境復雜
優(yōu)點：可靠性好
缺點：實現(xiàn)復雜、穩(wěn)定性依賴于緩存的穩(wěn)定性、Session信息放入緩存時要有合理的策略寫入
目前生產(chǎn)中使用到的- 基于tomcat配置實現(xiàn)的MemCache緩存管理session實現(xiàn)(麻煩)
- 基于OsCache和shiro組播的方式實現(xiàn)(網(wǎng)絡(luò)影響)
- 基于spring-session+redis實現(xiàn)的(最適合)
負載均衡策略負載均衡策略的優(yōu)劣及其實現(xiàn)的難易程度有兩個關(guān)鍵因素：一、負載均衡算法，二、對網(wǎng)絡(luò)系統(tǒng)狀況的檢測方式和能力。
1、rr 輪詢調(diào)度算法。顧名思義，輪詢分發(fā)請求。
優(yōu)點：實現(xiàn)簡單
缺點：不考慮每臺服務器的處理能力
2、wrr 加權(quán)調(diào)度算法。我們給每個服務器設(shè)置權(quán)值weight，負載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務器，服務器被調(diào)用的次數(shù)跟權(quán)值成正比。
優(yōu)點：考慮了服務器處理能力的不同
3、sh 原地址散列：提取用戶IP，根據(jù)散列函數(shù)得出一個key，再根據(jù)靜態(tài)映射表，查處對應的value，即目標服務器IP。過目標機器超負荷，則返回空。
4、dh 目標地址散列：同上，只是現(xiàn)在提取的是目標地址的IP來做哈希。
優(yōu)點：以上兩種算法的都能實現(xiàn)同一個用戶訪問同一個服務器。
5、lc 最少連接。優(yōu)先把請求轉(zhuǎn)發(fā)給連接數(shù)少的服務器。
優(yōu)點：使得集群中各個服務器的負載更加均勻。
6、wlc 加權(quán)最少連接。在lc的基礎(chǔ)上，為每臺服務器加上權(quán)值。算法為：（活動連接數(shù)*256+非活動連接數(shù)）÷權(quán)重 ，計算出來的值小的服務器優(yōu)先被選擇。
優(yōu)點：可以根據(jù)服務器的能力分配請求。
7、sed 最短期望延遲。其實sed跟wlc類似，區(qū)別是不考慮非活動連接數(shù)。算法為：（活動連接數(shù)+1)*256÷權(quán)重，同樣計算出來的值小的服務器優(yōu)先被選擇。
8、nq 永不排隊。改進的sed算法。我們想一下什么情況下才能“永不排隊”，那就是服務器的連接數(shù)為0的時候，那么假如有服務器連接數(shù)為0，均衡器直接把請求轉(zhuǎn)發(fā)給它，無需經(jīng)過sed的計算。
9、LBLC 基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近被使用的服務器，把請求轉(zhuǎn)發(fā)之，若該服務器超載，最采用最少連接數(shù)算法。
10、LBLCR 帶復制的基于局部性的最少連接。均衡器根據(jù)請求的目的IP地址，找出該IP地址最近使用的“服務器組”，注意，并不是具體某個服務器，然后采用最少連接數(shù)從該組中挑出具體的某臺服務器出來，把請求轉(zhuǎn)發(fā)之。若該服務器超載，那么根據(jù)最少連接數(shù)算法，在集群的非本服務器組的服務器中，找出一臺服務器出來，加入本服務器組，然后把請求轉(zhuǎn)發(fā)之。
讀寫分離
MySql主從配置，讀寫分離并引入中間件，開源的MyCat，阿里的DRDS都是不錯的選擇。
如果是對高可用要求比較高，但是又沒有相應的技術(shù)保障，建議使用阿里云的RDS或者Redis相關(guān)數(shù)據(jù)庫，省事省力又省錢。
全文檢索
如果有搜索業(yè)務需求，引入solr或者elasticsearch也是一個不錯的選擇，不要什么都塞進關(guān)系型數(shù)據(jù)庫。
緩存優(yōu)化
引入緩存無非是為了減輕后端數(shù)據(jù)庫服務的壓力，防止其"罷工"。
常見的緩存服務有，Ehcache、OsCache、MemCache、Redis，當然這些都是主流經(jīng)得起考驗的緩存技術(shù)實現(xiàn)，特別是Redis已大規(guī)模運用于分布式集群服務中，并證明了自己優(yōu)越的性能。
消息隊列
異步通知：比如短信驗證，郵件驗證這些非實時反饋性的邏輯操作。
流量削鋒：應該是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。
日志處理：系統(tǒng)中日志是必不可少的，但是如何去處理高并發(fā)下的日志確是一個技術(shù)活，一不小心可能會壓垮整個服務。工作中我們常用到的開源日志ELK，為嘛中間會加一個Kafka或者redis就是這么一個道理(一群人涌入和排隊進的區(qū)別)。
消息通訊：點對點通信(個人對個人)或發(fā)布訂閱模式(聊天室)。
日志服務
消息隊列中提到的ELK開源日志組間對于中小型創(chuàng)業(yè)供公司是一個不錯的選擇。
安全優(yōu)化
以上種種，沒有安全做保證可能都會歸于零。
- 阿里云的VPN虛擬專有網(wǎng)絡(luò)以及安全組配置
- 自建機房的話，要自行配置防火墻安全策略
- 相關(guān)服務訪問，比如Mysql、Redis、Solr等如果沒有特殊需求盡量使用內(nèi)網(wǎng)訪問并設(shè)置鑒權(quán)
- 盡量使用代理服務器，不要對外開放過多的端口
- https配合HTTP/2.0也是個不錯的選擇
架構(gòu)裝逼必備詞匯
高可用- 負載均衡（負載均衡算法）
- 反向代理
- 服務隔離
- 服務限流
- 服務降級（自動優(yōu)雅降級）
- 失效轉(zhuǎn)移
- 超時重試（代理超時、容器超時、前端超時、中間件超時、數(shù)據(jù)庫超時、NoSql超時）
- 回滾機制（上線回滾、數(shù)據(jù)庫版本回滾、事務回滾）
高并發(fā)- 應用緩存
- HTTP緩存
- 多級緩存
- 分布式緩存
- 連接池
- 異步并發(fā)
分布式事務- 二階段提交(強一致)
- 三階段提交(強一致)
- 消息中間件(最終一致性)，推薦阿里的RocketMQ
隊列擴容- 單體垂直擴容
- 單體水平擴容
- 應用拆分
- 數(shù)據(jù)庫拆分
- 數(shù)據(jù)庫分庫分表
- 數(shù)據(jù)異構(gòu)
- 分布式任務
網(wǎng)絡(luò)安全- SQL注入
- XSS攻擊
- CSRF攻擊
- 拒絕服務（DoS，Denial of Service）攻擊
架構(gòu)裝逼必備工具
操作系統(tǒng)Linux（必備）、某軟的
負載均衡DNS、F5、LVS、Nginx、OpenResty、HAproxy、負載均衡SLB（阿里云）
分布式框架Dubbo、Motan、Spring-Could
數(shù)據(jù)庫中間件DRDS （阿里云）、Mycat、360 Atlas、Cobar (不維護了)
消息隊列RabbitMQ、ZeroMQ、Redis、ActiveMQ、Kafka
注冊中心Zookeeper、Redis
緩存Redis、Oscache、Memcache、Ehcache
集成部署Docker、Jenkins、Git、Maven
存儲OSS、NFS、FastDFS、MogileFS
數(shù)據(jù)庫MySql、Redis、MongoDB、PostgreSQL、Memcache、HBase
網(wǎng)絡(luò)專用網(wǎng)絡(luò)VPC、彈性公網(wǎng)IP、CDN
轉(zhuǎn)自：記一次JavaWeb網(wǎng)站技術(shù)架構(gòu)總結(jié) - 小柒2012 - 博客園
關(guān)鍵詞：技術(shù),總結(jié)
在線咨詢