1. 程式人生 > >JavaWeb網站技術架構

JavaWeb網站技術架構

加權 replicat 工作 分布式框架 安全策略 small jsp last 版本

JavaWeb網站技術架構總結

題記

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

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

初始搭建

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

服務分離

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

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

反向代理

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

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

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

反向代理的優勢,如下:

  • 隱藏真實後端服務
  • 負載均衡集群
  • 高可用集群
  • 緩存靜態內容實現動靜分離
  • 安全限流
  • 靜態文件壓縮
  • 解決多個服務跨域問題
  • 合並靜態請求(HTTP/2.0後已經被弱化)
  • 防火墻
  • SSL以及http2

動靜分離

基於以上Nginx反向代理,我們還可以實現動靜分離,靜態請求如html、css、js等請求交給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
  • 消息隊列

持續集成部署

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

Docker、Jenkins、Git、Maven

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

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

服務集群

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

負載均衡實現

  • 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開源日誌組間對於中小型創業供公司是一個不錯的選擇。

安全優化

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

  • 阿裏雲的VPN虛擬專有網絡以及安全組配置
  • 自建機房的話,要自行配置防火墻安全策略
  • 相關服務訪問,比如Mysql、Redis、Solr等如果沒有特殊需求盡量使用內網訪問並設置鑒權
  • 盡量使用代理服務器,不要對外開放過多的端口
  • https配合HTTP/2.0也是個不錯的選擇

架構裝逼必備詞匯

高可用

  • 負載均衡(負載均衡算法)
  • 反向代理
  • 服務隔離
  • 服務限流
  • 服務降級(自動優雅降級)
  • 失效轉移
  • 超時重試(代理超時、容器超時、前端超時、中間件超時、數據庫超時、NoSql超時)
  • 回滾機制(上線回滾、數據庫版本回滾、事務回滾)

高並發

  • 應用緩存
  • HTTP緩存
  • 多級緩存
  • 分布式緩存
  • 連接池
  • 異步並發

分布式事務

  • 二階段提交(強一致)
  • 三階段提交(強一致)
  • 消息中間件(最終一致性),推薦阿裏的RocketMQ

隊列

  • 任務隊列
  • 消息隊列
  • 請求隊列

擴容

  • 單體垂直擴容
  • 單體水平擴容
  • 應用拆分
  • 數據庫拆分
  • 數據庫分庫分表
  • 數據異構
  • 分布式任務

網絡安全

  • 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網站技術架構