大型網站技術架構(四)--核心架構要素 開啓mac上印象筆記的代碼塊 大型網站技術架構(三)--架構模式 JDK8 stream toMap() java.lang.IllegalStateExcep

大型網站技術架構(四)--核心架構要素

 

做者:13
GitHub:https://github.com/ZHENFENG13
版權聲明:本文爲原創文章,未經容許不得轉載。
此篇已收錄至《大型網站技術架構:核心原理與案例分析》讀書筆記系列,點擊訪問該目錄獲取完整內容。php

前言

所謂架構,一種通俗的說法就是「最高層次的規劃,難以改變的決定」,這些規劃和決定奠基了事物將來發展的方向和最終的藍圖。html

而軟件架構即「有關軟件總體結構與組件的抽象描述,用於指導大型軟件系統各方面的設計」。java

通常來講軟件架構須要關注性能、可用性、伸縮性、擴展性和安全性這5個架構要素。git

1

性能

性能是網站架構設計的一個重要方面,任何軟件架構設計方案都必須考慮可能帶來的性能問題,也正由於性能問題幾乎無處不在,因此優化網站性能的手段也很是多。github

  • 瀏覽器端:能夠經過瀏覽器緩存、頁面壓縮傳輸、合理佈局頁面、減小Cookie傳輸等手段,甚至可使用CDN加速功能。
  • 應用服務器端:可使用服務器本地緩存和分佈式緩存,也能夠經過異步操做方式來加快響應,在高併發請求的狀況下,能夠將多臺應用服務器組成一個集羣共同對外服務,提升總體處理能力,改善性能。
  • 數據庫服務器端:可用使用索引、緩存、SQL性能優化等手段,還可使用NoSQL數據庫來優化數據模型、存儲結構等。

衡量網站性能有一系列指標,重要的有響應時間、TPS、系統性能計數器等,經過這些指標以肯定系統設計是否達到目標。數據庫

2

可用性

可用性即可以不間斷提供服務的時間。幾乎全部網站都承諾7×24小時可用,但事實上任何網站都不可能達到徹底的7×24,總會有一些故障時間,扣除這些故障時間,就是網站的可用時間。一些大型網站能夠作到4個9以上的可用性,也就是99.99%。瀏覽器

網站高可用的主要手段就是冗餘,應用部署在多臺服務器上同時提供服務,數據存儲在多臺服務器上相互備份,任何一臺服務器都不會影響應用的總體能夠,一般的實現手段即把多臺服務器經過負載均衡設備組成一個集羣。緩存

衡量一個系統架構設計是否知足高可用的目標,就是假設系統中任何一臺或者多臺服務器宕機時,以及出現各類不可預期的問題時,系統總體是否依然可用。安全

3

伸縮性

大型網站須要面對大量用戶的高併發訪問和存儲海量數據,網站經過集羣的方式將多臺服務器組成一個總體共同提供服務。所謂伸縮性是指經過不斷向集羣中加入服務器的手段來緩解不斷總體上市用戶併發訪問壓力和不斷增加的數據存儲需求。性能優化

衡量架構伸縮性的主要標準就是是否可用多臺服務器構建集羣,是否容易向集羣中添加新的服務器。加入新的服務器後是否能夠提供和原來的服務器無差異的服務。集羣中可容納的總服務器數量是否有限制。

4

擴展性

不一樣於其餘架構要素主要關注非功能性需求,網站的擴展性架構直接關注網站的功能需求。網站快速發展,功能不斷擴展,如何設計網站的架構使其可以快速響應需求變化,是網站可擴展架構的主要目標。

衡量網站架構擴展性好壞的主要標準就是在網站增長新的業務產品時,是否能夠實現對現有產品透明無影響,不一樣產品之間是否不多耦合等。

網站可擴展架構的主要手段是事件驅動架構和分佈式服務。

  • 事件驅動一般利用消息隊列實現,經過這種方式將消息生產和處理邏輯分隔開。
  • 服務器服務則是將業務和可複用服務分離開來,經過分佈式服務框架調用。新增長產品可用經過調用可複用的服務來實現自身的業務邏輯,而對現有產品沒有任何影響。

5

安全性

互聯網是開發的,任何人在任何地方均可以訪問網站。網站的安全架構就是保護網站不受惡意訪問和攻擊,保護網站的重要數據不被竊取。

衡量網站安全架構的標準就是針對現存和潛在的各類攻擊和竊密手段,是否有可靠的應對策略。

security

這個世界沒有絕對的安全,正如沒有絕對的自由同樣,很遺憾,這個世界上沒有固若金湯的網站安全架構,咱們只能天天打起百分百的精神,預防可能的漏洞或者攻擊。

首發於個人我的博客,2017年5月18日。

我曾七次鄙視本身的靈魂:
第一次,當它本可進取時,卻故做謙卑;
第二次,當它空虛時,用愛慾來填充;
第三次,在困難和容易之間,它選擇了容易;
第四次,它犯了錯,卻藉由別人也會犯錯來寬慰本身;
第五次,它自由軟弱,卻把它認爲是生命的堅韌;
第六次,當它鄙夷一張醜惡的嘴臉時,殊不知那正是本身面具中的一副;
第七次,它側身於生活的污泥中雖不甘心,卻又畏首畏尾。
 
 
 

開啓mac上印象筆記的代碼塊

 

Mac 印象筆記左上角菜單欄:偏好設置-->軟件更新-->開啓代碼塊

(Preferences -> Software Update -> Enable code block)

如圖:

Evernote

我曾七次鄙視本身的靈魂:
第一次,當它本可進取時,卻故做謙卑;
第二次,當它空虛時,用愛慾來填充;
第三次,在困難和容易之間,它選擇了容易;
第四次,它犯了錯,卻藉由別人也會犯錯來寬慰本身;
第五次,它自由軟弱,卻把它認爲是生命的堅韌;
第六次,當它鄙夷一張醜惡的嘴臉時,殊不知那正是本身面具中的一副;
第七次,它側身於生活的污泥中雖不甘心,卻又畏首畏尾。
 
 
 

大型網站技術架構(三)--架構模式

 

做者:13
GitHub:https://github.com/ZHENFENG13
版權聲明:本文爲原創文章,未經容許不得轉載。
此篇已收錄至《大型網站技術架構:核心原理與案例分析》讀書筆記系列,點擊訪問該目錄獲取完整內容。

前言

模式:每個模式描述了一個在咱們周圍不斷重複發生的問題及該問題解決方案的核心。這樣,你就能一次又一次地使用該方案而沒必要作重複工做。

網站架構模式:大型互聯網公司在實踐中提出了許多解決方案,以實現網站高性能、高可用、易伸縮、可擴展、安全等各類技術框架目標。這些解決方案又被更多網站重複使用,從而逐漸造成大型網站架構模式。

所謂網站架構模式即爲了解決大型網站面臨的高併發訪問、海量數據、高可靠運行燈一系列問題與挑戰,爲此,在實踐中提出了許多解決方案,以實現網站高性能、高可靠性、易伸縮、可擴展、安全等各類技術架構目標。

分層

分層是企業應用系統中最多見的一種架構模式,將系統在橫向維度上切分紅幾個部分,每一個部分負責一部分相對簡單並比較單一的職責,而後經過上層對下層的依賴和調度組成一個完整的系統。
ssm-demo結構圖:

在網站的分層架構中,常見的爲3層,即應用層、服務層、數據層。
應用層具體負責業務和視圖的展現;服務層爲應用層提供服務支持;數據庫提供數據存儲訪問服務,如數據庫、緩存、文件、搜索引擎等。
分層架構是邏輯上的,在物理部署上,三層架構能夠部署在同一個物理機器上,可是隨着網站業務的發展,必然須要對已經分層的模塊分離部署,即三層結構分別部署在不一樣的服務器上,是網站擁有更多的計算資源以應對愈來愈多的用戶訪問。

因此雖然分層架構模式最初的目的是規劃軟件清晰的邏輯結構以便於開發維護,但在網站的發展過程當中,分層結構對網站支持高併發向分佈式方向的發展相當重要。

分隔

若是說分層是將軟件在橫向方面進行切分,那麼分隔就是在縱向方面對軟件進行切分。
網站越大,功能越複雜,服務和數據處理的種類也越多,將這些不一樣的功能和服務分隔開來,包裝成高內聚低耦合的模塊單元,不只有助於軟件的開發維護也便於不一樣模塊的分佈式部署,提升網站的併發處理能力和功能擴展能力。
大型網站分隔的粒度可能會很小。好比在應用層,將不一樣業務進行分隔,例如將購物、論壇、搜索、廣告分隔成不一樣的應用,有對立的團隊負責,部署在不一樣的服務器上。

分佈式

對於大型網站,分層和分隔的一個主要目的是爲了切分後的模塊便於分佈式部署,即將不一樣模塊部署在不一樣的服務器上,經過遠程調用協同工做。分佈式意味着可使用更多的計算機完一樣的工做,計算機越多,CPU、內存、存儲資源就越多,能過處理的併發訪問和數據量就越大,進而可以爲更多的用戶提供服務。
在網站應用中,經常使用的分佈式方案有一下幾種:

  • 分佈式應用和服務:將分層和分隔後的應用和服務模塊分佈式部署,能夠改善網站性能和併發性、加快開發和發佈速度、減小數據庫鏈接資源消耗。

  • 分佈式靜態資源:網站的靜態資源如JS、CSS、Logo圖片等資源對立分佈式部署,並採用獨立的域名,即人們常說的動靜分離。靜態資源分佈式部署能夠減輕應用服務器的負載壓力;經過使用獨立域名加快瀏覽器併發加載的速度。

  • 分佈式數據和存儲:大型網站須要處理以P爲單位的海量數據,單臺計算機沒法提供如此大的存儲空間,這些數據庫須要分佈式存儲。

  • 分佈式計算:目前網站廣泛使用Hadoop和MapReduce分佈式計算框架進行此類批處理計算,其特色是移動計算而不是移動數據,將計算程序分發到數據所在的位置以加速計算和分佈式計算。

集羣

對於用戶訪問集中的模塊須要將獨立部署的服務器集羣化,即多臺服務器部署相同的應用構成一個集羣,經過負載均衡設備共同對外提供服務。
服務器集羣可以爲相同的服務提供更多的併發支持,所以當有更多的用戶訪問時,只須要向集羣中加入新的機器便可;
另外能夠實現當其中的某臺服務器發生故障時,能夠經過負載均衡的失效轉移機制將請求轉移至集羣中其餘的服務器上,所以能夠提升系統的可用性。

緩存

緩存目的就是減輕服務器的計算,使數據直接返回給用戶。
在如今的軟件設計中,緩存已經無處不在。
具體實現有CDN、反向代理、本地緩存、分佈式緩存等。

使用緩存有兩個條件:訪問數據熱點不均衡,即某些頻繁訪問的數據須要放在緩存中;
數據在某個時間段內有效,不過很快過時,否在會由於數據過時而髒讀,影響數據的正確性。

異步

使用異步,業務之間的消息傳遞不是同步調用,而是將一個業務操做分紅多個階段,每一個階段之間經過共享數據的方法異步執行進行協做。
具體實現則在單一服務器內部可用經過多線程共享內存對了的方式處理;在分佈式系統中可用經過分佈式消息隊列來實現異步。
異步架構的典型就是生產者消費者方式,二者不存在直接調用。

冗餘

網站須要7×24小時連續運行,那麼就得有相應的冗餘機制,以防某臺機器宕掉時沒法訪問,而冗餘則能夠經過部署至少兩臺服務器構成一個集羣實現服務高可用。
數據庫除了按期備份還須要實現冷熱備份,甚至能夠在全球範圍內部署災備數據中心。

水至清則無魚嘛。

自動化

具體有自動化發佈過程,自動化代碼管理、自動化測試、自動化安全檢測、自動化部署、自動化監控、自動化報警、自動化失效轉移、自動化失效恢復等。

安全

網站在安全架構方面有許多模式:

  • 經過密碼和手機校驗碼進行身份認證;
  • 登陸、交易須要對網絡通訊進行加密;
  • 爲了防止機器人程序濫用資源,須要使用驗證碼進行識別;
  • 對常見的XSS攻擊、SQL注入須要編碼轉換;垃圾信息須要過濾等。

個人小網站從上線之初到如今也被攻擊了好幾回了,真的是無奈,就是一個爲初學者演示的demo,你皮這一下以後頗有成就感嗎?

結語

首發於個人我的博客.

之前嘛,看書基本都是看看熱鬧,如今的話,就會有更多本身的思考了,吃一塹長一智,雖然前人已經經過各類方式告知咱們一些事情,可是不少錯依然會犯,只有痛了才知道。

end

我曾七次鄙視本身的靈魂:
第一次,當它本可進取時,卻故做謙卑;
第二次,當它空虛時,用愛慾來填充;
第三次,在困難和容易之間,它選擇了容易;
第四次,它犯了錯,卻藉由別人也會犯錯來寬慰本身;
第五次,它自由軟弱,卻把它認爲是生命的堅韌;
第六次,當它鄙夷一張醜惡的嘴臉時,殊不知那正是本身面具中的一副;
第七次,它側身於生活的污泥中雖不甘心,卻又畏首畏尾。
 
 
 

JDK8 stream toMap() java.lang.IllegalStateException: Duplicate key異常解決(key重複)

 

測試又報bug啦

接到測試小夥伴的問題,說是一個接口不返回數據了,好吧,雖然不是我寫的接口任務落到頭上也得解決,本地調試了一下,好傢伙,直接拋了個異常出來,這又是哪位大哥喝醉了寫的代碼...

Exception in thread "main" java.lang.IllegalStateException: Duplicate key at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) at java.util.HashMap.merge(HashMap.java:1254) at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320) at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) 

key重複異常解決

報錯的那行代碼以下:

Map<Long, Entity> entityMap= entityList.stream().collect(Collectors.toMap(Entity::getType, (entity) -> entity));

這行代碼的目的就是將一個list對象轉爲map對象,以type爲key,以entity對象爲value。
可是與日常用的方法不一樣,而是直接使用java8的stream方式,報錯也很清楚,就是key重複,也就是說在使用toMap方法時,有重複的type值致使了這個報錯,最終解決方式以下:

Map<Long, Entity> entityMap= entityList.stream().collect(Collectors.toMap(Entity::getType, Function.identity(),(entity1,entity2) -> entity1));

使用toMap()的重載方法,若是已經存在則再也不修改來避免重複key的問題。

順便吐槽一下,這已是多久前的代碼了,怎麼今天才報出這個錯,也是醉了。

我曾七次鄙視本身的靈魂: 第一次,當它本可進取時,卻故做謙卑; 第二次,當它空虛時,用愛慾來填充; 第三次,在困難和容易之間,它選擇了容易; 第四次,它犯了錯,卻藉由別人也會犯錯來寬慰本身; 第五次,它自由軟弱,卻把它認爲是生命的堅韌; 第六次,當它鄙夷一張醜惡的嘴臉時,殊不知那正是本身面具中的一副; 第七次,它側身於生活的污泥中雖不甘心,卻又畏首畏尾。
相關文章
相關標籤/搜索