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