Java高并發(fā)高性能分布式框架從無到有微服務(wù)架構(gòu)設(shè)計(jì)

1、Java 高并發(fā)高性能分布式框架從無到有微效勞架構(gòu)設(shè)計(jì)微效勞架構(gòu)模式( Microservice Architect Pattern )。 近兩年在效勞的瘋狂增長(zhǎng)與云計(jì)算技術(shù)的進(jìn)步，讓微效勞架 構(gòu)受到重點(diǎn)關(guān)注 微效勞架構(gòu)是一種架構(gòu)模式，它提倡將單 一應(yīng)用程序劃分成一組小的效勞，效勞之間互相協(xié)調(diào)、互相 配合，為用戶提供最終價(jià)值。每個(gè)效勞運(yùn)行在其獨(dú)立的進(jìn)程 中，效勞與效勞間采用輕量級(jí)的通信機(jī)制互相溝通(通常是 基于 的RESTful API )。每個(gè)效勞都圍繞著具體業(yè)務(wù)進(jìn) 行構(gòu)建， 并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、 類生產(chǎn)環(huán)境等。 另外，應(yīng)盡量防止統(tǒng)一的、集中式的效勞管理機(jī)制，對(duì)具體 的一個(gè)效勞而

2、言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇適宜的語言、工 具對(duì)其進(jìn)行構(gòu)建。微效勞架構(gòu)優(yōu)勢(shì) 首先簡(jiǎn)單介紹了微效勞 (Microservices )的內(nèi)涵及優(yōu)勢(shì)，微效勞架構(gòu)的本質(zhì)，是 用一些功能比擬明確、業(yè)務(wù)比擬精練的效勞去解決更大、更 實(shí)際的問題。微效勞架構(gòu)將效勞拆分，分別采用相對(duì)獨(dú)立的 效勞對(duì)各方面進(jìn)行管理，彼此之間使用統(tǒng)一的接口來進(jìn)行交 流，架構(gòu)變得復(fù)雜，優(yōu)勢(shì)也很明顯： 復(fù)雜度可控：在將應(yīng) 用分解的同時(shí)，躲避了原本復(fù)雜度無止境的積累。每一個(gè)微 效勞專注于單一功能，并通過定義良好的接口清晰表述效勞 邊界。由于體積小、復(fù)雜度低，每個(gè)微效勞可由一個(gè)小規(guī)模 開發(fā)團(tuán)隊(duì)完全掌控，易于保持高可維護(hù)性和開發(fā)效率。什么是微效

3、勞架構(gòu)微效勞架構(gòu)優(yōu)勢(shì) 獨(dú)立部署：由于微效勞具備 獨(dú)立的運(yùn)行進(jìn)程，所以每個(gè)微效勞也可以獨(dú)立部署。當(dāng)某個(gè) 微效勞發(fā)生變更時(shí)無需編譯、部署整個(gè)應(yīng)用。由微效勞組成 的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加 高效，同時(shí)降低對(duì)生產(chǎn)環(huán)境所造成的風(fēng)險(xiǎn)，最終縮短應(yīng)用交 付周期。 技術(shù)選型靈活：微效勞架構(gòu)下，技術(shù)選型是去中 心化的。每個(gè)團(tuán)隊(duì)可以根據(jù)自身效勞的需求和行業(yè)開展的現(xiàn) 狀，自由選擇最適合的技術(shù)棧。由于每個(gè)微效勞相對(duì)簡(jiǎn)單， 當(dāng)需要對(duì)技術(shù)棧進(jìn)行升級(jí)時(shí)所面臨的風(fēng)險(xiǎn)較低，甚至完全重 構(gòu)一個(gè)微效勞也是可行的。 容錯(cuò)：當(dāng)某一組建發(fā)生故障時(shí)， 在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴(kuò)散，形 成應(yīng)用全局

4、性的不可用。在微效勞架構(gòu)下，故障會(huì)被隔離在 單個(gè)效勞中。假設(shè)設(shè)計(jì)良好，其他效勞可通過重試、平穩(wěn)退化 等機(jī)制實(shí)現(xiàn)應(yīng)用層面的容錯(cuò)。 擴(kuò)展：?jiǎn)螇K架構(gòu)應(yīng)用也可以 實(shí)現(xiàn)橫向擴(kuò)展，就是將整個(gè)應(yīng)用完整的復(fù)制到不同的節(jié)點(diǎn)。 當(dāng)應(yīng)用的不同組件在擴(kuò)展需求上存在差異時(shí)，微效勞架構(gòu)便 表達(dá)出其靈活性，因?yàn)槊總€(gè)效勞可以根據(jù)實(shí)際需求獨(dú)立進(jìn)行 擴(kuò)展?；ヂ?lián)網(wǎng)高并發(fā)相關(guān)名詞頁面瀏覽數(shù)( page views ) 唯一身份瀏覽量( Unique PageViews )獨(dú)立訪問者數(shù)量 ( unique visitors )重復(fù)訪問者數(shù)量( repeat visitors)每個(gè)訪問者的頁面瀏覽數(shù)( Page Views per us

5、er )高并發(fā) 之前我將高并發(fā)的解決方法誤認(rèn)為是線程或者是隊(duì)列可以解決，因?yàn)楦卟l(fā)的時(shí)候是有很多用戶在訪問，導(dǎo)致出現(xiàn)系 統(tǒng)數(shù)據(jù)不正確、喪失數(shù)據(jù)現(xiàn)象，所以想到 的是用隊(duì)列解決， 其實(shí)隊(duì)列解決的方式也可以處理，比方我們?cè)诟?jìng)拍商品、轉(zhuǎn) 發(fā)評(píng)論微博或者是秒殺商品等，同一時(shí)間訪問量特別大，隊(duì) 列在此起到特別的作用，將 所有請(qǐng)求放入隊(duì)列，以毫秒計(jì) 時(shí)單位，有序的進(jìn)行，從而不會(huì)出現(xiàn)數(shù)據(jù)喪失系統(tǒng)數(shù)據(jù)不正 確的情況。 經(jīng)過查資料，高并發(fā)的解決方法有倆種，一種 是使用緩存、另一種是使用生成靜態(tài)頁面；還有就是從最基 礎(chǔ)的地方優(yōu)化我們寫代碼減少不必要的資源浪費(fèi)： 1. 不要 頻繁的new對(duì)象,對(duì)于在整個(gè)應(yīng)用中只需要存

6、在一個(gè)實(shí)例的 類使用單例模式 . 對(duì)于 String 的連接操作 , 使用 StringBuffer 或者 StringBuilder. 對(duì)于 utility 類型的類 通過靜態(tài)方法來訪問。 2. 防止使用錯(cuò)誤的方式 , 如 Exception 可以控制方法推出 , 但是 Exception 要保存 stacktrace 消耗性能 , 除非必要不要使用 instanceof 做條 件判斷，盡量使用比的條件判斷方式.使用JAVA中效率高的 類, 比方 ArrayList 比 Vector 性能好。 高并發(fā) - 需要解決 的問題一：應(yīng)用緩存二： 緩存三：多級(jí)緩存四：池化五: 異步并發(fā)六：擴(kuò)容七：隊(duì)

7、列高并發(fā) - 應(yīng)用緩存堆緩存 使用 Java 堆內(nèi)存來存儲(chǔ)緩存對(duì)象。 使用堆緩存的好處是沒有序列 化/ 反序列化，是最快的緩存。缺點(diǎn)也很明顯，當(dāng)緩存的數(shù) 據(jù)量很大時(shí)，GC 垃圾回收暫停時(shí)間會(huì)變長(zhǎng)，存儲(chǔ)容量受限于堆空間大小。一般通過軟引用 / 弱引用來存儲(chǔ)緩存對(duì)象， 即當(dāng)堆內(nèi)存缺乏時(shí)，可以強(qiáng)制回收這局部?jī)?nèi)存釋放堆內(nèi)存空 間。一般使用堆緩存存儲(chǔ)較熱的數(shù)據(jù)。有Guava Cache： 緩存和 ConcurrentMap 是非常相像的， 但是它們也不完全一樣。 最根本的區(qū)別就是， ConcurrentMap 會(huì)持有所有添加的對(duì)象， 直到被顯示的移除。而緩存為了限制其內(nèi)存的使用，通常都 會(huì)配置成可以自動(dòng)

8、的將對(duì)象移除。在某些情況下即使不自動(dòng) 移除對(duì)象也是非常有用的，如 LoadingCache 它會(huì)自動(dòng)加載 緩存對(duì)象。 Ehcache 3.x ：是一種廣泛使用的開源 Java 分布 式緩存。主要面向通用緩存 Java EE和輕量級(jí)容器。它具有 內(nèi)存和磁盤存儲(chǔ)，緩存加載器 , 緩存擴(kuò)展 , 緩存異常處理程序 , 一個(gè)gzip緩存servlet 過濾器，支持REST和SOAP api等特 點(diǎn)。 MapDB： mapdb 是一個(gè)內(nèi)嵌的純 java 的數(shù)據(jù)庫，提供了 并發(fā)的HashMap TreeMap、Queue,可以基于堆外或者磁盤 來存儲(chǔ)數(shù)據(jù)高并發(fā) - 應(yīng)用緩存堆外緩存 即緩存數(shù)據(jù)存儲(chǔ)在 堆外內(nèi)

9、存，可以減少 GC暫停時(shí)間堆對(duì)象轉(zhuǎn)移到堆外，GC掃描和移動(dòng)的對(duì)象變少 ,但是,讀取數(shù)據(jù)時(shí)需要序列化 / 反 序列化,因此會(huì)比堆緩存要慢很多。有 Ehcache 3.x 、 MapDB 實(shí)現(xiàn)磁盤緩存即緩存數(shù)據(jù)存儲(chǔ)在磁道上，在JVM重啟時(shí)數(shù)據(jù)還存在的,而堆緩存 / 堆外緩存數(shù)據(jù)會(huì)喪失,需要重新加 載。有、MapDB實(shí)現(xiàn)分布式緩存 進(jìn)程內(nèi)緩存和 磁盤緩存，在多JVM實(shí)例的情況下，會(huì)存在兩個(gè)問題：1、 單機(jī)容量問題；2、數(shù)據(jù)一致性問題多臺(tái) JVM實(shí)例的緩存 數(shù)據(jù)不一致怎么辦？ ，這個(gè)問題不用糾結(jié)，既然數(shù)據(jù)允許 緩存，那么表示允許一定時(shí)間內(nèi)的不一致，因此可以設(shè)置緩存 數(shù)據(jù)的過期時(shí)間來定期更新數(shù)據(jù)； 3

10、、緩存不命中時(shí)，需要 回源到DB/效勞請(qǐng)求多變問題：每個(gè)實(shí)例在緩存不命中的情 況下都會(huì)回源到 DB加載數(shù)據(jù)，因此多實(shí)例后 DB整體的訪問 量變多了解決方法是可以使用如一致性哈希分片算法。因 此，這些情況可以考慮使用分布式緩存來解決。 可以使用 ehcache clustered 配合 Terracotta server 實(shí)現(xiàn) JAVA 進(jìn)程間分布式緩存。最好的方法是使用 redis 實(shí)現(xiàn)分布式緩 存。高并發(fā)- 緩存瀏覽器緩存是指當(dāng)我們使用瀏覽器訪 問一些網(wǎng)站頁面或者 效勞時(shí)，根據(jù)效勞端返回的緩存 設(shè)置響應(yīng)頭將響應(yīng)內(nèi)容緩存到瀏覽器，下次可以直接使用緩 存內(nèi)容或者僅需要去效勞端驗(yàn)證內(nèi)容是否過期即可

11、。這樣的 好處可以減少瀏覽器和效勞端之間來回傳輸?shù)臄?shù)據(jù)量，節(jié)省 帶寬提升性能。 解決方法：內(nèi)容不需要?jiǎng)討B(tài)計(jì)算、渲染 等速度更快，內(nèi)容越接近于用戶速度越快。像 apache traffic server 、 squid 、 varnish 、 nginx 等技術(shù)都可以來 進(jìn)行內(nèi)容緩存。還有 CDN就是用來加速用戶訪問的：即用戶 首先訪問到全國(guó)各地的 CDN節(jié)點(diǎn)使用如ATS Squid實(shí)現(xiàn)， 如果CDN沒命中，會(huì)回源到中央 nginx集群，該集群如果沒 有命中緩存該集群的緩存不是必須的，要根據(jù)實(shí)際命中情況等決定，最后回源到后端應(yīng)用集群。高并發(fā) - 多級(jí)緩存 分布式緩存高并發(fā) - 池化在應(yīng)用系統(tǒng)開發(fā)

12、過程中，我們 經(jīng)常會(huì)用到池化技術(shù)，如對(duì)象池、連接池、線程池等，通過 池化來減少一些消耗，以提升性能。 對(duì)象池通過復(fù)用對(duì)象 從而減少創(chuàng)立對(duì)象、垃圾回收 的開銷。但是，池化不能太 大，太大會(huì)影響GC時(shí)的掃描時(shí)間。 連接池如數(shù)據(jù)庫連接池、 Redis連接池、 連接池，通過復(fù)用 TCP連接減少創(chuàng)立和 釋放連接的時(shí)間來提升性能。 線程池也是類似的，通過復(fù) 用線程提升性能。也就是說池化的目的就是通過復(fù)用技術(shù)提 升性能。高并發(fā) - 擴(kuò)容 1、讀寫別離：當(dāng)數(shù)據(jù)庫訪問量還不是 很大的時(shí)候，我們可以適當(dāng)增加效勞器，數(shù)據(jù)庫主從復(fù)制的 方式將讀寫別離 2、垂直分區(qū)： 當(dāng)寫入操作一旦增加的時(shí)候， 那么主從數(shù)據(jù)庫將花更多

13、的時(shí)間的放在數(shù)據(jù)同步上，這個(gè)時(shí) 候效勞器也是不堪重負(fù)的；那么就有了數(shù)據(jù)的垂直分區(qū)，數(shù) 據(jù)的垂直分區(qū)思路是將寫入操作比擬頻繁的數(shù)據(jù)表，如用戶 表_user,或者訂單表_orders,那么我們就可以把這個(gè)兩個(gè) 表別離出來，放在不同的效勞器，如果這兩個(gè)表和其他表存 在聯(lián)表查詢，那么就只能把原來的 sql 語句給拆分了，先查 詢一個(gè)表，在查詢另一個(gè)，雖然說這個(gè)會(huì)消耗更過性能，但 比起那種大量數(shù)據(jù)同步，負(fù)擔(dān)還是減輕了不少； 3、水平分 區(qū)：但是往往事情不盡人意，可能采取垂直分區(qū)能撐一段時(shí) 間，由于網(wǎng)站太火了，訪問量又每日100w, 下子蹦到了1000w,這個(gè)時(shí)候可以采取數(shù)據(jù)的進(jìn)行別離，我們可以根據(jù)user 的 Id 不同進(jìn)行分配，如采取 %2、 %10 形式，當(dāng)然這種 形式對(duì)以后的擴(kuò)展有了很