Web網站技術架構總結

記一次JavaWeb網站技術架構總結

作者:小柒

出處:https://blog.52itstyle.com

 

題記

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

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

 

初始搭建

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


 

服務分離

随着系統的的上線,用戶量也會逐步上升,很明顯一台服務器已經滿足不了系統的負載,這時候,我們就要在服務器還沒有超載的時候,提前做好準備。

由于我們是單體架構,優化架構在短時間内是不現實的,增加機器是一個不錯的選擇。這時候,我們可能要把應用和數據庫服務單獨部署,如果有條件也可以把文件服務器單獨部署。

 

反向代理

   

 

為了提升服務處理能力,我們在Tomcat容器前加一個代理服務器,我一般使用Nginx,當然你如果更熟悉apache也未嘗不可。

用戶的請求發送給反向代理,然後反向代理把請求轉發到後端的服務器。

嚴格意義上來說,Nginx是屬于web服務器,一般處理靜态htmlcssjs請求,而Tomcat屬于web容器,專門處理JSP請求,當然Tomcat也是支持html的,隻是效果沒Nginx好而已。

 

反向代理的優勢,如下:

隐藏真實後端服務

負載均衡集群

高可用集群

緩存靜态内容實現動靜分離

安全限流

靜态文件壓縮

解決多個服務跨域問題

合并靜态請求(HTTP/2.0後已經被弱化)

防火牆

SSL以及http2

 

動靜分離

 

 

基于以上Nginx反向代理,我們還可以實現動靜分離,靜态請求如htmlcssjs等請求交給Nginx處理,動态請求分發給後端Tomcat處理。

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

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

 

服務拆分

 

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

Dubbo

   

 

SpringCloud

 

服務發現——Netflix Eureka

客服端負載均衡——Netflix Ribbon

斷路器——Netflix Hystrix

服務網關——Netflix Zuul

分布式配置——Spring Cloud Config

微服務與輕量級通信

 

同步通信和異步通信

遠程調用RPC

REST

消息隊列

持續集成部署

 

服務拆分以後,随着而來的就是持續集成部署,你可能會用到以下工具。

DockerJenkinsGitMaven

圖片源于網絡,基本拓撲結構如下所示:

   

 

整個持續集成平台架構演進到如下圖所示:

   

 

 

服務集群

 

Linux集群主要分成三大類( 高可用集群, 負載均衡集群,科學計算集群)。其實,我們最常見的也是生産中最常接觸到的就是負載均衡集群。

   

 

 

負載均衡實現

 

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

四層負載均衡(F5LVS),工作在TCP協議下

七層負載均衡(Nginxhaproxy),工作在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實現(麻煩)

基于OsCacheshiro組播的方式實現(網絡影響)

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

 

負載均衡策略

 

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

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

優點:實現簡單

缺點:不考慮每台服務器的處理能力

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

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

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

4dh 目标地址散列:同上,隻是現在提取的是目标地址的IP來做哈希。

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

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

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

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

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

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

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

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

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

 

讀寫分離

 

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

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

 

全文檢索

 

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

 

緩存優化

 

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

 

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

 

消息隊列

 

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

   

 

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

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

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

 

日志服務

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


   

安全優化

 

以上種種,沒有安全做保證可能都會歸于零。

 

阿裡雲的VPN虛拟專有網絡以及安全組配置

自建機房的話,要自行配置防火牆安全策略

相關服務訪問,比如MysqlRedisSolr等如果沒有特殊需求盡量使用内網訪問并設置鑒權

盡量使用代理服務器,不要對外開放過多的端口

https配合HTTP/2.0也是個不錯的選擇

 

文章發布:Lv-weigann時間:2017-10-02

一个人在线观看的www视频日本_两个人看的www高清免费中文