記一次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網站技術架構總結
題記 工作也有幾多年了,無論是身邊遇到的還是耳間聞到的,多多少少也積攢了自己的一些經驗和思考,當然,博主並沒有太多接觸高大上的分散式架構實踐,相對比較零碎,隨時補充(附帶架構裝逼詞彙)。 俗話說的好,冰凍三尺非一日之寒,滴水穿石非一日之功,羅馬也不是一天就建成的,當然對於我們開發人員來說,一個好的架構也不是一
JavaWeb網站技術架構
加權 replicat 工作 分布式框架 安全策略 small jsp last 版本 JavaWeb網站技術架構總結 題記 工作也有幾多年了,無論是身邊遇到的還是耳間聞到的,多多少少也積攢了自己的一些經驗和思考,當然,博主並沒有太多接觸高大上的分布式架構實踐,相對
記一次http網站換成https的處理
tomcat nginx https今天對原來的網站做證書加密處理,就是http轉換成https。配置好nginx後發現網頁打開有部分頁面卻還是http協議,這樣將導致https網頁無法加載http的內容。嘗試了網上各種配置,都不行。最後的解決辦法是修改程序代碼。原來代碼:<c:set var=&quo
JavaWeb專案技術架構總結
題記 工作也有幾多年了,無論是身邊遇到的還是耳間聞到的,多多少少也積攢了自己的一些經驗和思考,當然,博主並沒有太多接觸高大上的分散式架構實踐,相對比較零碎,隨時補充(附帶架構裝逼詞彙)。 俗話說的好,冰凍三尺非一日之寒,滴水穿石非一日之功,羅馬也不是一天就建成的,當然對於我們開發人員來說,一
《記一次意外的技術討論收穫—策略模式》
最近公司有和第三方合作的專案,於是想到了使用策略模式去實現,到時候有別的第三方來走他自己的策略去完成相關的業務流程就行了。 1)類載入的問題--名稱空間 但是我們在做的過程中遇到的第一個問題就是名稱空間的問題,因為公司老的框架是不支援也沒有使用名稱
什麼是魔法函式?記一次“產臉”後的總結
XX:“你覺得你Python掌握程度如何?瞭解,熟悉,還是精通”。 我: “我覺得我自動化測試和工具開發應用的還不少,應該算熟悉吧”。 XX:”那你給我講講什麼是魔法函式?” 我:“…………………………….(感覺像吃了陀翔般難受,明明知道肯定
記一次線上mysql主從架構異常的恢復經歷
fault ase 主從數據庫 sta start 1-1 href show color 前提:之前一位同事負責的一位客戶,因後期轉到devops小組。所以將此用戶交接給我,在後期發現有一套數據庫主從環境,從庫已經無法正常使用。查看slave 狀態為: 其中:Master
記一次介面效能優化實踐總結:優化介面效能的八個建議
### 前言 最近對外介面偶現504超時問題,原因是程式碼執行時間過長,超過nginx配置的15秒,然後真槍實彈搞了一次介面效能優化。在這裡結合優化過程,總結了介面優化的八個要點,希望對大家有幫助呀~ - 資料量比較大,批量操作資料入庫 - 耗時操作考慮非同步處理 - 恰當使用快取 - 優化程式邏輯、程式碼
架構設計的指導思想——總結《大型網站技術架構:核心原理與案例分析》一書
本文的思維導圖如下: 本文分為三大部分,9個架構模式、8個架構要素和架構要素的提升手段。9個架構模式分別是分層,分割,分散式,叢集,快取,非同步,冗餘,自動化,安全。8個架構要素分別是效能,可用性,可伸縮,可擴充套件,安全,成本,可維護,可移植。 在展開闡述之前,先談談架
記一次完整的安全技術解決方案遭遇成本考驗後的“退步與博弈”
架構師 互聯網 解決方案 防火墻 高可用 寫在前面,出於保護客戶隱私和堅守網工的職業道德素養,本文不得出現的所有完整ip、客戶名稱、信息、以及詳細的業務模型闡述。最近確實走心的在分享案例,2017年5月21日在家裏寫了近四小時,女票已經暴走,請大家掩護我!!!!!
軟件架構設計學習總結(13):大型網站技術架構(七)網站的可擴展性架構
開放 擴展 修改 restfu 消息發送 封裝 nts 進行 可擴展性 擴展性是指對現有系統影響最小的情況下,系統功能可持續擴展或提升的能力。 設計網站可擴展架構的核心思想是模塊化,並在此基礎上,降低模塊間的耦合性,提供模塊的復用性。模塊通過分布式部署,獨立
軟件架構設計學習總結(14):大型網站技術架構(八)網站的安全架構
根據 知情 提交 pac 請求參數 用途 text 避免 信息加密 從互聯網誕生起,安全威脅就一直伴隨著網站的發展,各種Web攻擊和信息泄露也從未停止。常見的攻擊手段有XSS攻擊、SQL註入、CSRF、Session劫持等。 1、XSS攻擊 XSS攻擊即跨站點腳本攻擊(C
軟件架構設計學習總結(12):大型網站技術架構(六)網站的伸縮性架構
可用性 name 偶數 發送 得到 合並 linux vi 可謂 性能 網站系統的伸縮性架構最重要的技術手段就是使用服務器集群功能,通過不斷地向集群中添加服務器來增強整個集群的處理能力。“伸”即網站的規模和服務器的規模總是在不斷擴大。 1、網站架構的伸縮性設計 網站的伸縮性
記一次Linux下JavaWeb環境的搭建
上傳 部署 x64 blog 兩個 family cif 解壓 啟動 今天重裝了騰訊雲VPS的系統,那麽幾乎所有運行環境都要重新部署了。過程不難懂,但是也比較繁瑣,這次就寫下來,方便他人也方便自己日後參考參考。 我采用的是JDK+Tomcat的形式來進行Java
《大型網站技術架構》讀書筆記一:大型網站架構演化
硬件 解決方案 更新 獨立 流量 操作 大型網站技術架構 負責 思維導圖 一、大型網站系統特點 (1)高並發、大流量:PV量巨大 (2)高可用:7*24小時不間斷服務 (3)海量數據:文件數目分分鐘xxTB (4)用戶分布廣泛,網絡情況復雜:網絡運營
記一次真實的網站被黑經歷
明顯 AR 也說 用戶 -o HP 靜態 lis 圖片 前言 距離上次被DDOS×××已經有10天左右的時間,距離上上次已經記不起具體那一天了,每一次都這麽不了了只。然而近期一次相對持久的×××,我覺得有必要靜下心來,分享一下被黑的那段經歷。 在敘述經歷之前,先簡單的介紹
記一次負載均衡+NFS博客站點搭建的總結
共存 AI 遠程 id號 base system32 water fst http 起因 原本是打算搭建個小博客站點做實驗,突然想起之前遇到的一次負載均衡失效的經歷,便打算做一次實驗重現當初的情況並記錄下來,防止日後再遇到類似的情況懵逼。
記一次前端服務端客戶端三方聯調的總結
由於負責專案的原因第一次與客戶端服務端三方聯調,感覺有必要總結一下,雖然內容不復雜 技術也不難,總結總是好的。 就是要求使用者去關注公眾號,成功之後給予金幣獎勵。 和服務端的互動:進入頁面,反覆輪循去請求介面,服務端輪循去查詢資料庫,當得到返回結果是成功的時候銷燬該頁面。30s後停止請求。 和客戶端的互
一張圖讀懂大型網站技術架構
軟體架構師最大的價值不在於掌握多少先進的技術,而在於具有將一個大系統切分成N個低耦合的子模組的能力,這些子模組包含橫向的業務模組,也包含縱向的基礎技術模組。這種能力一部分源自專業的技術和經驗,還有一部分源自架構師對業務場景的理解、對人性的把握、甚至對世界的認知。 ----李智慧 以下為李
記一次大三秋季成都某公司Java電話面試經歷和總結
簡歷是在一個招聘app上投的。感興趣的童鞋也可以試試~ 本來HR是準備直接過去面試的,但是由於本人不在本地原因,所以直接約了時間面試 面試官是技術部的Leader,總共面試時間是40分鐘左右吧! 好的,下面就直接進入正題吧! 面試官問:之前看到過你做的筆試