JavaWeb網站技術架構是怎樣的

這期內容當中小編將會給大家帶來有關JavaWeb網站技術架構是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

<p _hover-ignore="1" white-space:normal;background-color:#FFFFFF;">題記

　　工作也有幾多年了，無論是身邊遇到的還是耳間聞到的，多多少少也積攢了自己的一些經驗和思考，當然，博主并沒有太多接觸高大上的分布式架構實踐，相對比較零碎，隨時補充(附帶架構裝逼詞匯)。

　　俗話說的好，冰凍三尺非一日之寒，滴水穿石非一日之功，羅馬也不是一天就建成的，當然對于我們開發人員來說，一個好的架構也不是一蹴而就的。

　　初始搭建

　　開始的開始，就是各種框架一搭，然后扔到Tomcat容器中跑就是了，這時候我們的文件，數據庫，應用都在一個服務器上。

　　反向代理

　　基于以上Nginx反向代理，我們還可以實現動靜分離，靜態請求如html、css、js等請求交給Nginx處理，動態請求分發給后端Tomcat處理。

　　Nginx 升級到1.9.5+可以開啟HTTP/2.0時代，加速網站訪問。

　　當然，如果公司不差錢，CDN也是一個不錯的選擇。

　　服務拆分

　　在這分布式微服務已經普遍流行的年代，其實我們沒必要踩過多的坑，就很容易進行拆分。市面上已經有相對比較成熟的技術，比如阿里開源的Dubbo(官方明確表示已經開始維護了)，spring家族的spring cloud，當然具體如何去實施，無論是技術還是業務方面都要有很好的把控。

　　Dubbo

　　負載均衡實現

　　·DNS負載均衡，一般域名注冊商的dns服務器不支持，但博主用的阿里云解析已經支持

　　·四層負載均衡(F5、LVS)，工作在TCP協議下

　　·七層負載均衡(Nginx、haproxy)，工作在Http協議下

　　分布式session

　　大家都知道，服務一般分為有狀態和無狀態，而分布式sessoion就是針對有狀態的服務。

　　分布式Session的幾種實現方式

　　·基于數據庫的Session共享

　　·基于resin/tomcat web容器本身的session復制機制

　　·基于oscache/Redis/memcached 進行 session 共享。

　　·基于cookie 進行session共享

　　分布式Session的幾種管理方式

　　·Session Replication 方式管理 (即session復制) 簡介：將一臺機器上的Session數據廣播復制到集群中其余機器上 使用場景：機器較少，網絡流量較小 優點：實現簡單、配置較少、當網絡中有機器Down掉時不影響用戶訪問 缺點：廣播式復制到其余機器有一定廷時，帶來一定網絡開銷

　　·Session Sticky 方式管理 簡介：即粘性Session、當用戶訪問集群中某臺機器后，強制指定后續所有請求均落到此機器上 使用場景：機器數適中、對穩定性要求不是非常苛刻 優點：實現簡單、配置方便、沒有額外網絡開銷 缺點：網絡中有機器Down掉時、用戶Session會丟失、容易造成單點故障

　　·緩存集中式管理 簡介：將Session存入分布式緩存集群中的某臺機器上，當用戶訪問不同節點時先從緩存中拿Session信息 使用場景：集群中機器數多、網絡環境復雜 優點：可靠性好缺點：實現復雜、穩定性依賴于緩存的穩定性、Session信息放入緩存時要有合理的策略寫入

　　目前生產中使用到的

　　·基于tomcat配置實現的MemCache緩存管理session實現(麻煩)

　　·基于OsCache和shiro組播的方式實現(網絡影響)

　　·基于spring-session+redis實現的(最適合)

　　負載均衡策略

　　負載均衡策略的優劣及其實現的難易程度有兩個關鍵因素：一、負載均衡算法，二、對網絡系統狀況的檢測方式和能力。

　　1、rr 輪詢調度算法。顧名思義，輪詢分發請求。

　　優點：實現簡單

　　缺點：不考慮每臺服務器的處理能力

　　2、wrr 加權調度算法。我們給每個服務器設置權值weight，負載均衡調度器根據權值調度服務器，服務器被調用的次數跟權值成正比。

　　優點：考慮了服務器處理能力的不同

　　3、sh 原地址散列：提取用戶IP，根據散列函數得出一個key，再根據靜態映射表，查處對應的value，即目標服務器IP。過目標機器超負荷，則返回空。

　　4、dh 目標地址散列：同上，只是現在提取的是目標地址的IP來做哈希。

　　優點：以上兩種算法的都能實現同一個用戶訪問同一個服務器。

　　5、lc 最少連接。優先把請求轉發給連接數少的服務器。

　　優點：使得集群中各個服務器的負載更加均勻。

　　6、wlc 加權最少連接。在lc的基礎上，為每臺服務器加上權值。算法為：(活動連接數*256+非活動連接數)÷權重 ，計算出來的值小的服務器優先被選擇。

　　優點：可以根據服務器的能力分配請求。

　　7、sed 最短期望延遲。其實sed跟wlc類似，區別是不考慮非活動連接數。算法為：(活動連接數+1)*256÷權重，同樣計算出來的值小的服務器優先被選擇。

　　8、nq 永不排隊。改進的sed算法。我們想一下什么情況下才能“永不排隊”，那就是服務器的連接數為0的時候，那么假如有服務器連接數為0，均衡器直接把請求轉發給它，無需經過sed的計算。

　　9、LBLC 基于局部性的最少連接。均衡器根據請求的目的IP地址，找出該IP地址最近被使用的服務器，把請求轉發之，若該服務器超載，最采用最少連接數算法。

　　10、LBLCR 帶復制的基于局部性的最少連接。均衡器根據請求的目的IP地址，找出該IP地址最近使用的“服務器組”，注意，并不是具體某個服務器，然后采用最少連接數從該組中挑出具體的某臺服務器出來，把請求轉發之。若該服務器超載，那么根據最少連接數算法，在集群的非本服務器組的服務器中，找出一臺服務器出來，加入本服務器組，然后把請求轉發之。

　　讀寫分離

　　MySql主從配置，讀寫分離并引入中間件，開源的MyCat，阿里的DRDS都是不錯的選擇。

　　如果是對高可用要求比較高，但是又沒有相應的技術保障，建議使用阿里云的RDS或者Redis相關數據庫，省事省力又省錢。

　　全文檢索

　　如果有搜索業務需求，引入solr或者elasticsearch也是一個不錯的選擇，不要什么都塞進關系型數據庫。

　　緩存優化

　　引入緩存無非是為了減輕后端數據庫服務的壓力，防止其"罷工"。

　　常見的緩存服務有，Ehcache、OsCache、MemCache、Redis，當然這些都是主流經得起考驗的緩存技術實現，特別是Redis已大規模運用于分布式集群服務中，并證明了自己優越的性能。

　　消息隊列

　　異步通知：比如短信驗證，郵件驗證這些非實時反饋性的邏輯操作。

　　流量削鋒：應該是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。

　　日志處理：系統中日志是必不可少的，但是如何去處理高并發下的日志確是一個技術活，一不小心可能會壓垮整個服務。工作中我們常用到的開源日志ELK，為嘛中間會加一個Kafka或者redis就是這么一個道理(一群人涌入和排隊進的區別)。

　　消息通訊：點對點通信(個人對個人)或發布訂閱模式(聊天室)。

　　日志服務

　　消息隊列中提到的ELK開源日志組間對于中小型創業供公司是一個不錯的選擇。

　　隊列

　　·任務隊列

　　·消息隊列

　　·請求隊列

　　擴容

　　·單體垂直擴容

　　·單體水平擴容

　　·應用拆分

　　·數據庫拆分

　　·數據庫分庫分表

　　·數據異構

　　·分布式任務

　　網絡安全

　　·SQL注入

　　·XSS攻擊

　　·CSRF攻擊

　　·拒絕服務(DoS，Denial of Service)攻擊

　　架構裝逼必備工具

　　操作系統

　　Linux(必備)、某軟的

　　負載均衡

　　DNS、F5、LVS、Nginx、OpenResty、HAproxy、負載均衡SLB(阿里云)

　　分布式框架

　　Dubbo、Motan、Spring-Could

　　數據庫中間件

　　DRDS (阿里云)、Mycat、360 Atlas、Cobar (不維護了)

　　消息隊列

　　RabbitMQ、ZeroMQ、Redis、ActiveMQ、Kafka

　　注冊中心

　　Zookeeper、Redis

　　緩存

　　Redis、Oscache、Memcache、Ehcache

　　集成部署

　　Docker、Jenkins、Git、Maven

　　存儲

　　OSS、NFS、FastDFS、MogileFS

　　數據庫

　　MySql、Redis、MongoDB、PostgreSQL、Memcache、HBase

　　網絡

　　專用網絡VPC、彈性公網IP、CDN

上述就是小編為大家分享的JavaWeb網站技術架構是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。