高可用和高并發(fā)概念討論和技術(shù)建議

3454862343QQ：成功后才能驕傲個性格言：男性別：

個人性格塑造：

沉穩(wěn)、細(xì)心、膽識、積極、大度、誠信、擔(dān)當(dāng)個人能力塑造：

觀察力

、思考力、決策力、組織力、影響力、執(zhí)行力編輯ppt討論內(nèi)容SOA、ESB、SAAS、微服務(wù)1：互聯(lián)網(wǎng)高并發(fā)系統(tǒng)-需要解決的問題3：SpringCloud和dubbo比較4：

JAVA互聯(lián)網(wǎng)技術(shù)選型5：互聯(lián)網(wǎng)高可用性（HA）系統(tǒng)-需要解決的問題2：

互聯(lián)話題：獨立訪問者數(shù)量（uniquevisitors）、重復(fù)訪問者數(shù)量（repeatvisitors）、頁面瀏覽數(shù)（pageviews）理解技術(shù)架構(gòu)建議6：編輯pptSOA(面向服務(wù)的架構(gòu))

面向服務(wù)的架構(gòu)（SOA）是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。接口是采用中立的方式進(jìn)行定義的，它應(yīng)該獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。對于一個SOA解決方案來說就需要能夠滿足這些場景的業(yè)務(wù)需求，能夠解決其中的各種技術(shù)問題。需要解決的基本問題包括：

服務(wù)的描述問題，描述服務(wù)提供哪些功能，適用服務(wù)有哪些要求

服務(wù)的注冊和查找問題，定義好的服務(wù)信息在哪發(fā)布，如何發(fā)布，到哪查找，如何查找

服務(wù)通訊方式，包括具體如何向服務(wù)發(fā)送請求，并獲取應(yīng)答，支持什么樣的交互方式。

服務(wù)流程問題，對服務(wù)流程的靈活定制，執(zhí)行監(jiān)控等提供管理

服務(wù)的管理問題，服務(wù)的提供，撤銷，改變這些情況如何進(jìn)行管理

服務(wù)質(zhì)量問題，如何保障安全性，通訊的可靠性，以及事務(wù)完整性如何保證

整個系統(tǒng)的效率問題，包括查找效率，通訊效率，服務(wù)運行處理效率等

系統(tǒng)能夠提供什么樣的開發(fā)工具，支持什么樣的開發(fā)模式，系統(tǒng)運行情況是否可以及時了解，是否可以及時獲取故障信息，是否可以提供運行狀態(tài)信息，以利于系統(tǒng)的優(yōu)化。編輯pptESB（企業(yè)服務(wù)總線）

ESB全稱為EnterpriseServiceBus，即企業(yè)服務(wù)總線。它是傳統(tǒng)中間件技術(shù)與XML、Web服務(wù)等技術(shù)結(jié)合的產(chǎn)物。ESB提供了網(wǎng)絡(luò)中最基本的連接中樞，是構(gòu)筑企業(yè)神經(jīng)系統(tǒng)的必要元素。

大規(guī)模分布式的企業(yè)應(yīng)用需要相對簡單而實用的中間件技術(shù)來簡化和統(tǒng)一越來越復(fù)雜、繁瑣的企業(yè)級信息系統(tǒng)平臺。面向服務(wù)體系架構(gòu)（SOA）是能夠?qū)?yīng)用程序的不同功能單元通過服務(wù)之間定義良好的接口和契約聯(lián)系起來。SOA使用戶可以不受限制地重復(fù)使用軟件、把各種資源互連起來，只要IT人員選用標(biāo)準(zhǔn)接口包裝舊的應(yīng)用程序、把新的應(yīng)用程序構(gòu)建成服務(wù)，那么其他應(yīng)用系統(tǒng)就可以很方便的使用這些功能服務(wù)。編輯pptSOA與ESB的區(qū)別

SOA是一種方式或架構(gòu)，用于具有自服務(wù)功能的應(yīng)用程序，應(yīng)用程序隨后通過用戶接口（UI）或經(jīng)過工作流將其聚合成用戶需要的功能。服務(wù)不僅是可復(fù)用代碼的組件，更是運行程序的一部分，客戶端可以不必合并它自己的代碼直接調(diào)用該程序。服務(wù)是與業(yè)務(wù)相關(guān)的一個定義。

ESB是用于調(diào)節(jié)SOA中的調(diào)用者及服務(wù)提供者的機制。它使得調(diào)用者在不知道提供者或提供者使用的地址的情況下調(diào)用該服務(wù)。ESB可在多個提供者、提供者的負(fù)載平衡及停止使用提供者（當(dāng)失效時）之間進(jìn)行選擇，并且基于調(diào)用者的需求在提供者之間進(jìn)行選擇，這些提供者提供了各種質(zhì)量級別的服務(wù)。ESB能夠調(diào)節(jié)同步或異步服務(wù)，事實上對于同一服務(wù)可以提供同步及異步的訪問。因此SOA和ESB是相對應(yīng)的。具備SOA的應(yīng)用程序應(yīng)當(dāng)使用ESB來調(diào)用它的服務(wù)。SOA和ESB不必用Web服務(wù)實現(xiàn)。然而，經(jīng)常需要ESB來調(diào)用服務(wù)，該服務(wù)提供自我描述及發(fā)現(xiàn)的能力，這由Web服務(wù)幫助完成。在SOA中經(jīng)常需要由一種技術(shù)實現(xiàn)的調(diào)用者，它們用于調(diào)用由其它技術(shù)實現(xiàn)的服務(wù)，這也由Web服務(wù)幫助完成。所以SOA、ESB和Web服務(wù)都集中于創(chuàng)建這樣的領(lǐng)域：一個應(yīng)用程序中的功能在其它應(yīng)用程序中也是可用的，本質(zhì)是復(fù)用性。編輯pptSAAS(軟件即服務(wù))

SaaS是Software-as-a-Service（軟件即服務(wù)）的簡稱,它與“on-demandsoftware”（按需軟件)，theapplicationserviceprovider(ASP，應(yīng)用服務(wù)提供商)，hostedsoftware(托管軟件)所具有相似的含義。它是一種通過Internet提供軟件的模式，廠商將應(yīng)用軟件統(tǒng)一部署在自己的服務(wù)器上，客戶可以根據(jù)自己實際需求，通過互聯(lián)網(wǎng)向廠商定購所需的應(yīng)用軟件服務(wù)，按定購的服務(wù)多少和時間長短向廠商支付費用，并通過互聯(lián)網(wǎng)獲得廠商提供的服務(wù)。

對企業(yè)來說，SaaS的優(yōu)點：⒈從技術(shù)方面來看：SaaS是簡單的部署，不需要購買任何硬件，剛開始只需要簡單注冊即可。企業(yè)無需再配備IT方面的專業(yè)技術(shù)人員，同時又能得到最新的技術(shù)應(yīng)用，滿足企業(yè)對信息管理的需求。⒉從投資方面來看：企業(yè)只以相對低廉的“月費”方式投資，不用一次性投資到位，不占用過多的營運資金，從而緩解企業(yè)資金不足的壓力；不用考慮成本折舊問題，并能及時獲得最新硬件平臺及最佳解決方案。⒊從維護(hù)和管理方面來看：由于企業(yè)采取租用的方式來進(jìn)行物流業(yè)務(wù)管理，不需要專門的維護(hù)和管理人員，也不需要為維護(hù)和管理人員支付額外費用。很大程度上緩解企業(yè)在人力、財力上的壓力，使其能夠集中資金對核心業(yè)務(wù)進(jìn)行有效的運營；SaaS能使用戶在世界上都是一個完全獨立的系統(tǒng)。如果您連接到網(wǎng)絡(luò)，就可以訪問系統(tǒng)。對企業(yè)來說，SaaS的缺點1.安全性：企業(yè)，尤其是大型企業(yè)，很不情愿使用SaaS正是因為安全問題，他們要保護(hù)他們的核心數(shù)據(jù)，不希望這些核心數(shù)據(jù)由第三方來負(fù)責(zé)。2.標(biāo)準(zhǔn)化：SaaS解決方案缺乏標(biāo)準(zhǔn)化。這個行業(yè)剛剛起步，沒有明確的解決辦法，一家公司可以設(shè)計建立一個解決方案。鑒于復(fù)雜和高度可定制的ERP產(chǎn)品，這是一個冒險的建議。編輯pptSOA和SaaS的區(qū)別1.SOA包括了關(guān)于軟件是如何被架構(gòu)起來的東西，而SaaS是關(guān)于軟件是如何被應(yīng)用的。2.在SaaS當(dāng)中，應(yīng)用程序可以像任何服務(wù)一樣被傳遞，就像你家中電話的語音一樣，看起來似乎就是為你的需求量體裁衣得到的。而SOA的定義和這個無絲毫的聯(lián)系。SOA支持的服務(wù)，都是些離散的可以再使用的事務(wù)處理，這些事務(wù)處理合起來就組成了一個業(yè)務(wù)流程，是從基本的系統(tǒng)中提取出來的抽象代碼。3.SOA是一個框架的方法，而SaaS是一種傳遞模型。4.通過SaaS傳遞Web服務(wù)并不需要SOA。5.SaaS主要是指一個軟件企業(yè)向其它企業(yè)提供軟件服務(wù)。而SOA一般是企業(yè)內(nèi)部搭建系統(tǒng)的基礎(chǔ)。SaaS注重的是提供服務(wù)的思維。而SOA注重的是實現(xiàn)服務(wù)的思維。編輯ppt什么是微服務(wù)架構(gòu)微服務(wù)架構(gòu)模式（MicroserviceArchitectPattern）。近兩年在服務(wù)的瘋狂增長與云計算技術(shù)的進(jìn)步，讓微服務(wù)架構(gòu)受到重點關(guān)注微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務(wù)運行在其獨立的進(jìn)程中，服務(wù)與服務(wù)間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTfulAPI）。每個服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機制，對具體的一個服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進(jìn)行構(gòu)建。微服務(wù)架構(gòu)優(yōu)勢首先簡單介紹了微服務(wù)（Microservices）的內(nèi)涵及優(yōu)勢，他表示，微服務(wù)架構(gòu)的本質(zhì)，是用一些功能比較明確、業(yè)務(wù)比較精練的服務(wù)去解決更大、更實際的問題。微服務(wù)架構(gòu)將服務(wù)拆分，分別采用相對獨立的服務(wù)對各方面進(jìn)行管理，彼此之間使用統(tǒng)一的接口來進(jìn)行交流，架構(gòu)變得復(fù)雜，優(yōu)勢也很明顯：復(fù)雜度可控：在將應(yīng)用分解的同時，規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能，并通過定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低，每個微服務(wù)可由一個小規(guī)模開發(fā)團(tuán)隊完全掌控，易于保持高可維護(hù)性和開發(fā)效率。編輯ppt什么是微服務(wù)架構(gòu)微服務(wù)架構(gòu)優(yōu)勢

獨立部署：由于微服務(wù)具備獨立的運行進(jìn)程，所以每個微服務(wù)也可以獨立部署。當(dāng)某個微服務(wù)發(fā)生變更時無需編譯、部署整個應(yīng)用。由微服務(wù)組成的應(yīng)用相當(dāng)于具備一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風(fēng)險，最終縮短應(yīng)用交付周期。技術(shù)選型靈活：微服務(wù)架構(gòu)下，技術(shù)選型是去中心化的。每個團(tuán)隊可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個微服務(wù)相對簡單，當(dāng)需要對技術(shù)棧進(jìn)行升級時所面臨的風(fēng)險較低，甚至完全重構(gòu)一個微服務(wù)也是可行的。容錯：當(dāng)某一組建發(fā)生故障時，在單一進(jìn)程的傳統(tǒng)架構(gòu)下，故障很有可能在進(jìn)程內(nèi)擴散，形成應(yīng)用全局性的不可用。在微服務(wù)架構(gòu)下，故障會被隔離在單個服務(wù)中。若設(shè)計良好，其他服務(wù)可通過重試、平穩(wěn)退化等機制實現(xiàn)應(yīng)用層面的容錯。擴展：單塊架構(gòu)應(yīng)用也可以實現(xiàn)橫向擴展，就是將整個應(yīng)用完整的復(fù)制到不同的節(jié)點。當(dāng)應(yīng)用的不同組件在擴展需求上存在差異時，微服務(wù)架構(gòu)便體現(xiàn)出其靈活性，因為每個服務(wù)可以根據(jù)實際需求獨立進(jìn)行擴展。編輯pptSOA和微服務(wù)架構(gòu)的區(qū)別如果一句話來談SOA和微服務(wù)的區(qū)別，即微服務(wù)不再強調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時SOA的思想進(jìn)入到單個業(yè)務(wù)系統(tǒng)內(nèi)部實現(xiàn)真正的組件化。微服務(wù)架構(gòu)強調(diào)的第一個重點就是業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化，原有的單個業(yè)務(wù)系統(tǒng)會拆分為多個可以獨立開發(fā)，設(shè)計，運行和運維的小應(yīng)用。這些小應(yīng)用之間通過服務(wù)完成交互和集成。每個小應(yīng)用從前端webui，到控制層，邏輯層，數(shù)據(jù)庫訪問，數(shù)據(jù)庫都完全是獨立的一套。在這里我們不用組件而用小應(yīng)用這個詞更加合適，每個小應(yīng)用除了完成自身本身的業(yè)務(wù)功能外，重點就是還需要消費外部其它應(yīng)用暴露的服務(wù)，同時自身也將自身的能力朝外部發(fā)布為服務(wù)。

首先對于應(yīng)用本身暴露出來的服務(wù)，是和應(yīng)用一起部署的，即服務(wù)本身并不單獨部署，服務(wù)本身就是業(yè)務(wù)組件已有的接口能力發(fā)布和暴露出來的

其次微服務(wù)架構(gòu)本身來源于互聯(lián)網(wǎng)的思路，因此組件對外發(fā)布的服務(wù)強調(diào)了采用HTTPRestAPI的方式來進(jìn)行。

微服務(wù)的基本思想在于考慮圍繞著業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用，這些就應(yīng)用可獨立地進(jìn)行開發(fā)、管理和加速。在分散的組件中使用微服務(wù)云架構(gòu)和平臺使部署、管理和服務(wù)功能交付變得更加簡單。編輯ppt高可用什么是高可用性高可用性（HA）系統(tǒng)是目前企業(yè)防止核心計算機系統(tǒng)因故障停機的最有效手段。高可用性（HA）的功能1、軟件故障監(jiān)測與排除2、備份和數(shù)據(jù)保護(hù)3、管理站能夠監(jiān)視各站點的運行情況，能隨時或定時報告系統(tǒng)運行狀況，故障能及時報告和告警，并有必要的控制手段4、實現(xiàn)錯誤隔離以及主、備份服務(wù)器間的服務(wù)切換HA的工作方式：HA有主從方式和雙工方式兩種工作模式高可用性方案則利用更少的冗余部件同時由軟件檢測故障，一旦故障發(fā)生立即隔離損壞部件，通過提供故障恢復(fù)實現(xiàn)最大化系統(tǒng)和應(yīng)用的可用性。容錯技術(shù)隨著處理器速度的加快和價格的下跌而越來越多地轉(zhuǎn)移到軟件中。未來容錯技術(shù)將完全在軟件環(huán)境下完成，那時它和高可用性技術(shù)之間的差別也就隨之消失了。編輯ppt互聯(lián)網(wǎng)高可用性（HA）系統(tǒng)-需要解決的問題

一：負(fù)載均衡與反向代理二：隔離三：限流四：降級五：超時與重試六：回滾七：壓力測試與應(yīng)急預(yù)案編輯ppt高可用-負(fù)載均衡

負(fù)載均衡建立在現(xiàn)有網(wǎng)絡(luò)結(jié)構(gòu)之上，它提供了一種廉價有效透明的方法擴展網(wǎng)絡(luò)設(shè)備和服務(wù)器的帶寬、增加吞吐量、加強網(wǎng)絡(luò)數(shù)據(jù)處理能力、提高網(wǎng)絡(luò)的靈活性和可用性。

軟件負(fù)載均衡解決方案是指在一臺或多臺服務(wù)器相應(yīng)的操作系統(tǒng)上安裝一個或多個附加軟件來實現(xiàn)負(fù)載均衡，如DNSLoadBalance，CheckPointFirewall-1ConnectControl等，它的優(yōu)點是基于特定環(huán)境，配置簡單，使用靈活，成本低廉，可以滿足一般的負(fù)載均衡需求。軟件解決方案缺點也較多，因為每臺服務(wù)器上安裝額外的軟件運行會消耗系統(tǒng)不定量的資源，越是功能強大的模塊，消耗得越多，所以當(dāng)連接請求特別大的時候，軟件本身會成為服務(wù)器工作成敗的一個關(guān)鍵；軟件可擴展性并不是很好，受到操作系統(tǒng)的限制；由于操作系統(tǒng)本身的Bug，往往會引起安全問題。

硬件負(fù)載均衡解決方案是直接在服務(wù)器和外部網(wǎng)絡(luò)間安裝負(fù)載均衡設(shè)備，這種設(shè)備通常稱之為負(fù)載均衡器，由于專門的設(shè)備完成專門的任務(wù)，獨立于操作系統(tǒng)，整體性能得到大量提高，加上多樣化的負(fù)載均衡策略，智能化的流量管理，可達(dá)到最佳的負(fù)載均衡需求。編輯ppt高可用-反向代理

反向代理（ReverseProxy）方式是指以代理服務(wù)器來接受internet上的連接請求，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給internet上請求連接的客戶端，此時代理服務(wù)器對外就表現(xiàn)為一個反向代理服務(wù)器。代理服務(wù)器有三種：1．標(biāo)準(zhǔn)的代理緩沖服務(wù)器一個標(biāo)準(zhǔn)的代理緩沖服務(wù)被用于緩存靜態(tài)的網(wǎng)頁（例如：html文件和圖片文件等）到本地網(wǎng)絡(luò)上的一臺主機上（即代理服務(wù)器）。2．透明代理緩沖服務(wù)器透明代理緩沖服務(wù)和標(biāo)準(zhǔn)代理服務(wù)器的功能完全相同。但是，代理操作對客戶端的瀏覽器是透明的（即不需指明代理服務(wù)器的IP和端口）。3．反向代理緩沖服務(wù)器反向代理是和前兩種代理完全不同的一種代理服務(wù)。使用它可以降低原始WEB服務(wù)器的負(fù)載。反向代理服務(wù)器承擔(dān)了對原始WEB服務(wù)器的靜態(tài)頁面的請求，防止原始服務(wù)器過載。安全反向代理用途：可以提供從防火墻外部代理服務(wù)器到防火墻內(nèi)部安全內(nèi)容服務(wù)器的加密連接?？梢栽试S客戶機安全地連接到代理服務(wù)器，從而有利于安全地傳輸信息。安全反向代理會造成各安全連接加密數(shù)據(jù)所涉及的系統(tǒng)開銷而變慢。SSL提供了高速緩存機制，連接雙方重復(fù)使用先前協(xié)商的安全參數(shù)，大大降低后續(xù)連接的系統(tǒng)開銷。編輯ppt高可用-隔離術(shù)

線程隔離:

線程隔離主要是指線程池隔離，在實際使用時，我們會把請求分類，然后交給不同的線程池處理。當(dāng)一種業(yè)務(wù)的請求處理發(fā)生問題時，不會將故障擴散到其他線程池，從而保證其他服務(wù)可用。進(jìn)程隔離由于傳統(tǒng)的系統(tǒng)所有功能都集中在一個系統(tǒng)中，為了避免系統(tǒng)其中一個模塊功能出現(xiàn)問題導(dǎo)致整個系統(tǒng)無法使用的情況發(fā)生，將其該系統(tǒng)拆分成多子系統(tǒng)實現(xiàn)物理隔離，故通過進(jìn)程隔離使得某一個子系統(tǒng)出現(xiàn)問題時不影響到其他子系統(tǒng)。集群隔離隨著調(diào)用方的增多，當(dāng)秒殺（并發(fā)量特別大功能）類似的服務(wù)被刷新會影響到其他服務(wù)的穩(wěn)定性時，應(yīng)該考慮為秒殺（并發(fā)量特別大功能）類似的服務(wù)提供單獨的服務(wù)集群，即分服務(wù)分組，這樣當(dāng)某一個分組出現(xiàn)問題時，不會影響到其他分組，從而實現(xiàn)了故障隔離愿景。機房隔離

隨著對系統(tǒng)可用性的要求，會進(jìn)行多機房部署，每一個機房的服務(wù)都有自己的服務(wù)分組，本機房的服務(wù)應(yīng)該只調(diào)用本機房的服務(wù)，不進(jìn)行跨機房調(diào)用。其中，一個機房服務(wù)發(fā)生問題時，可以通過DNS/負(fù)載均衡將請求全部切到另一個機房，或者考慮服務(wù)能自動重試其他機房的服務(wù)，從而提升系統(tǒng)可用性。編輯ppt高可用-隔離術(shù)

讀寫隔離

為了提高數(shù)據(jù)訪問，一般采用redis主從模式將讀和寫進(jìn)群分離，在正常情況下，當(dāng)主redis集群出現(xiàn)問題時，從redis集群還是可以用的，從而不影響用戶的訪問。動靜隔離例如當(dāng)用戶訪問如結(jié)算頁時，如果JS/CSS等靜態(tài)資源也在結(jié)算頁系統(tǒng)中時，很可能因為訪問量太大導(dǎo)致帶寬被打滿導(dǎo)致出現(xiàn)不可用。

為了不影響結(jié)算等用戶操作的功能，將其JS/CSS等靜態(tài)資源靜態(tài)化與用戶操作功能分開部署。資源隔離最常見的資源如磁盤、CPU、網(wǎng)絡(luò)；對于寶貴的資源都會存在競爭問題。我們可以使用JIMDB數(shù)據(jù)同步時要dump數(shù)據(jù)，SSD盤容量用了50%以上，dump到同一塊磁盤時遇到了容量不足的問題，我們通過單獨掛一塊SAS盤來專門同步數(shù)據(jù)。還有如使用Docker容器時，有的容器寫磁盤非常頻繁，因此要考慮為不同的容器掛載不同的磁盤。編輯ppt高可用-限流在開發(fā)高并發(fā)系統(tǒng)時有三把利器用來保護(hù)系統(tǒng)：緩存、降級和限流。緩存的目的是提升系統(tǒng)訪問速度和增大系統(tǒng)能處理的容量，可謂是抗高并發(fā)流量的銀彈；而降級是當(dāng)服務(wù)出問題或者影響到核心流程的性能則需要暫時屏蔽掉，待高峰或者問題解決后再打開；而有些場景并不能用緩存和降級來解決，比如稀缺資源（秒殺、搶購）、寫服務(wù)（如評論、下單）、頻繁的復(fù)雜查詢（評論的最后幾頁），因此需有一種手段來限制這些場景的并發(fā)/請求量，即限流。

限流的目的是通過對并發(fā)訪問/請求進(jìn)行限速或者一個時間窗口內(nèi)的的請求進(jìn)行限速來保護(hù)系統(tǒng)，一旦達(dá)到限制速率則可以拒絕服務(wù)（定向到錯誤頁或告知資源沒有了）、排隊或等待（比如秒殺、評論、下單）、降級（返回兜底數(shù)據(jù)或默認(rèn)數(shù)據(jù)，如商品詳情頁庫存默認(rèn)有貨）。

一般開發(fā)高并發(fā)系統(tǒng)常見的限流有：限制總并發(fā)數(shù)（比如數(shù)據(jù)庫連接池、線程池）、限制瞬時并發(fā)數(shù)（如nginx的limit_conn模塊，用來限制瞬時并發(fā)連接數(shù)）、限制時間窗口內(nèi)的平均速率（如Guava的RateLimiter、nginx的limit_req模塊，限制每秒的平均速率）；其他還有如限制遠(yuǎn)程接口調(diào)用速率、限制MQ的消費速率。另外還可以根據(jù)網(wǎng)絡(luò)連接數(shù)、網(wǎng)絡(luò)流量、CPU或內(nèi)存負(fù)載等來限流。編輯ppt高可用-降級降級的最終目的是保證核心服務(wù)可用，即使是有損的。而且有些服務(wù)是無法降級的（如加入購物車、結(jié)算）。

降級預(yù)案在進(jìn)行降級之前要對系統(tǒng)進(jìn)行梳理，看看系統(tǒng)是不是可以丟卒保帥；從而梳理出哪些必須誓死保護(hù)，哪些可降級；比如可以參考日志級別設(shè)置預(yù)案：

一般：比如有些服務(wù)偶爾因為網(wǎng)絡(luò)抖動或者服務(wù)正在上線而超時，可以自動降級；

警告：有些服務(wù)在一段時間內(nèi)成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發(fā)送告警；

錯誤：比如可用率低于90%，或者數(shù)據(jù)庫連接池被打爆了，或者訪問量突然猛增到系統(tǒng)能承受的最大閥值，此時可以根據(jù)情況自動降級或者人工降級；

嚴(yán)重錯誤：比如因為特殊原因數(shù)據(jù)錯誤了，此時需要緊急人工降級。降級按照是否自動化可分為：自動開關(guān)降級和人工開關(guān)降級。降級按照功能可分為：讀服務(wù)降級、寫服務(wù)降級。降級按照處于的系統(tǒng)層次可分為：多級降級。降級的功能點主要從服務(wù)端鏈路考慮，即根據(jù)用戶訪問的服務(wù)調(diào)用鏈路來梳理哪里需要降級：頁面降級、頁面片段降級、頁面異步請求降級、服務(wù)功能降級、讀降級、寫降級自動開關(guān)降級：超時降級、統(tǒng)計失敗次數(shù)降級、故障降級、限流降級人工開關(guān)降級：讀服務(wù)降級、寫服務(wù)降級編輯ppt高可用-超時與重試

在實際開發(fā)過程中，我們見過太多故障時因為沒有設(shè)置超時或者設(shè)置得不對而造成的，而這些故障都是因為沒有意識到超時設(shè)置的重要性而造成的。如果應(yīng)用不設(shè)置超時，則可能會導(dǎo)致請求響應(yīng)慢，慢請求積累導(dǎo)致連鎖反應(yīng)，甚至造成應(yīng)用雪塌。而有些中間件或者框架在超時后進(jìn)行重試（例如dubbo默認(rèn)重試兩次），讀服務(wù)天然適合重試，但寫服務(wù)大多不能重試（如寫訂單、支付等），重試次數(shù)太多會導(dǎo)致多倍請求流量。

例如模擬了Ddos攻擊（分布式拒絕服務(wù)(DDoS:DistributedDenialofService)攻擊指借助于客戶/服務(wù)器技術(shù)，將多個計算機聯(lián)合起來作為攻擊平臺，對一個或多個目標(biāo)發(fā)動DDoS，通常，攻擊者使用一個偷竊帳號將DDoS主控程序安裝在一個計算機上，在一個設(shè)定的時間主控程序?qū)⑴c大量代理程序通訊，代理程序已經(jīng)被安裝在網(wǎng)絡(luò)上的許多計算機上。代理程序收到指令時就發(fā)動攻擊。利用客戶/服務(wù)器技術(shù)，主控程序能在幾秒鐘內(nèi)激活成百上千次代理程序的運行。），后果可能是災(zāi)難，因此，務(wù)必設(shè)置合理的重試機制，并且應(yīng)該和熔斷、快速失敗機制配合。所以在進(jìn)行代碼Review時，一定記得Review超時與重試機制。編輯ppt高可用-回滾

事務(wù)回滾

在執(zhí)行數(shù)據(jù)庫SQL時，如果我們檢測到哦事務(wù)提交沖突，那么事務(wù)中所有執(zhí)行的SQL要進(jìn)行回滾，目的是防止數(shù)據(jù)庫出現(xiàn)數(shù)據(jù)不一致。代碼庫回滾

在開發(fā)項目時一定要將代碼維護(hù)到代碼倉庫，從而進(jìn)行版本管理。有了版本控制系統(tǒng)后可記錄代碼的歷史版本，在出現(xiàn)問題時候可以方便回滾。部署版本回滾

代碼測試完成后，接下來要進(jìn)行系統(tǒng)部署，在部署時要考慮當(dāng)代碼邏輯出現(xiàn)錯誤后如何快速恢復(fù)數(shù)據(jù)版本回滾

在設(shè)計消息隊列時，重要業(yè)務(wù)會對消息隊列進(jìn)行副本處理，以便萬一業(yè)務(wù)邏輯出現(xiàn)問題能進(jìn)行歷史數(shù)據(jù)回滾，從而修復(fù)問題。靜態(tài)資源版本回滾

靜態(tài)化頁面資源后，每次內(nèi)容變更時我們都會生成一個全量新版本放到項目的文件目錄中，從而保證版本可追溯，出現(xiàn)問題時能及時回滾。編輯ppt高可用-壓力測試

線下壓力測試

通過如Jmeter，Apac，heab壓力測試系統(tǒng)的某一個接口等（如登錄、查詢訂單）或者某一個組件（例如數(shù)據(jù)庫連接池），然后進(jìn)行調(diào)優(yōu)（如調(diào)優(yōu)JVM參數(shù)，優(yōu)化代碼等），實現(xiàn)單個接口或者組件的性能最優(yōu)。線上壓力測試

線上壓力測試份方式非常多，按讀分為讀壓、寫壓測和混合壓測，按照數(shù)據(jù)仿真度分為仿真壓力測試和引流壓力測試，按照給用戶提供服務(wù)分為隔離集群壓力測試和線上集群壓力測試。系統(tǒng)優(yōu)化和容災(zāi)

拿到全面的壓力測試報告后，接下來就是分析報告，然后進(jìn)行一些有這對性的優(yōu)化，如硬件升級、系統(tǒng)擴容、參數(shù)調(diào)優(yōu)、代碼優(yōu)化（代碼同步改異步）、架構(gòu)優(yōu)化（如加緩存、讀寫分離、歷史數(shù)據(jù)歸檔）等。在擴容時也需要考慮容災(zāi)，比如分組部署、跨機房部署。容災(zāi)是通過部署多組（單機房或多機房）相同系統(tǒng)，當(dāng)其中一組出現(xiàn)問題時，可以切換到另一個分組，保證系統(tǒng)可用編輯ppt高可用-應(yīng)急預(yù)案

在系統(tǒng)壓力測試之后發(fā)現(xiàn)一些系統(tǒng)瓶頸，在系統(tǒng)優(yōu)化之后會提升系統(tǒng)吐吞量并降低響應(yīng)時間，容災(zāi)之后的系統(tǒng)可用性得以保障，但還是會存在一些風(fēng)險，如網(wǎng)絡(luò)抖動、某臺機器負(fù)載過高、某個服務(wù)變慢、數(shù)據(jù)庫Load值過高，為了防止因為這些問題而出現(xiàn)系統(tǒng)雪崩，需要針對這些情況制定應(yīng)急預(yù)案，從而在出現(xiàn)突發(fā)情況時，有響應(yīng)的措施來解決掉這些問題。

應(yīng)急預(yù)案可按照如下幾步進(jìn)行：首先進(jìn)行系統(tǒng)分級，然后進(jìn)行全鏈路分析、配置監(jiān)控，最后制定應(yīng)急預(yù)案。編輯ppt互聯(lián)網(wǎng)高并發(fā)系統(tǒng)-需要解決的問題

一：應(yīng)用緩存二：HTTP緩存三：多級緩存四：池化五：異步并發(fā)六：擴容七：隊列編輯ppt高并發(fā)-應(yīng)用緩存堆緩存

使用Java堆內(nèi)存來存儲緩存對象。使用堆緩存的好處是沒有序列化/反序列化，是最快的緩存。缺點也很明顯，當(dāng)緩存的數(shù)據(jù)量很大時，GC（垃圾回收）暫停時間會變長，存儲容量受限于堆空間大小。一般通過軟引用/弱引用來存儲緩存對象，即當(dāng)堆內(nèi)存不足時，可以強制回收這部分內(nèi)存釋放堆內(nèi)存空間。一般使用堆緩存存儲較熱的數(shù)據(jù)。有GuavaCache、Ehcache3.x、MapDB實現(xiàn)堆外緩存即緩存數(shù)據(jù)存儲在堆外內(nèi)存，可以減少GC暫停時間（堆對象轉(zhuǎn)移到堆外，GC掃描和移動的對象變少），但是，讀取數(shù)據(jù)時需要序列化/反序列化，因此會比堆緩存要慢很多。有Ehcache3.x、MapDB實現(xiàn)磁盤緩存即緩存數(shù)據(jù)存儲在磁道上，在JVM重啟時數(shù)據(jù)還存在的，而堆緩存/堆外緩存數(shù)據(jù)會丟失，需要重新加載。有Ehcache3.x、MapDB實現(xiàn)編輯ppt高并發(fā)-應(yīng)用緩存分布式緩存

之前緩存提到是進(jìn)程內(nèi)緩存和磁盤緩存，在多JVM實例的情況下，會存在兩個問題：1、單機容量問題；2、數(shù)據(jù)一致性問題（多臺JVM實例的緩存數(shù)據(jù)不一致怎么辦？），這個問題不用糾結(jié)，既然數(shù)據(jù)允許緩存，則表示允許一定時間內(nèi)的不一致，因此可以設(shè)置緩存數(shù)據(jù)的過期時間來定期更新數(shù)據(jù)；3、緩存不命中時，需要回源到DB/服務(wù)請求多變問題：每個實例在緩存不命中的情況下都會回源到DB加載數(shù)據(jù)，因此多實例后DB整體的訪問量變多了解決辦法是可以使用如一致性哈希分片算法。因此，這些情況可以考慮使用分布式緩存來解決。

可以使用ehcache–clustered(配合Terracottaserver)實現(xiàn)JAVA進(jìn)程間分布式緩存。最好的辦法是使用redis實現(xiàn)分布式緩存。編輯ppt高并發(fā)-HTTP緩存瀏覽器緩存是指當(dāng)我們使用瀏覽器訪問一些網(wǎng)站頁面或者h(yuǎn)ttp服務(wù)時，根據(jù)服務(wù)端返回的緩存設(shè)置響應(yīng)頭將響應(yīng)內(nèi)容緩存到瀏覽器，下次可以直接使用緩存內(nèi)容或者僅需要去服務(wù)端驗證內(nèi)容是否過期即可。這樣的好處可以減少瀏覽器和服務(wù)端之間來回傳輸?shù)臄?shù)據(jù)量，節(jié)省帶寬提升性能。

解決辦法：內(nèi)容不需要動態(tài)（計算、渲染等）速度更快，內(nèi)容越接近于用戶速度越快。像apachetrafficserver、squid、varnish、nginx等技術(shù)都可以來進(jìn)行內(nèi)容緩存。還有CDN就是用來加速用戶訪問的：即用戶首先訪問到全國各地的CDN節(jié)點（使用如ATS、Squid實現(xiàn)），如果CDN沒命中，會回源到中央nginx集群，該集群如果沒有命中緩存（該集群的緩存不是必須的，要根據(jù)實際命中情況等決定），最后回源到后端應(yīng)用集群。編輯ppt高并發(fā)-多級緩存（分布式緩存）編輯ppt高并發(fā)-池化在應(yīng)用系統(tǒng)開發(fā)過程中，我們經(jīng)常會用到池化技術(shù)，如對象池、連接池、線程池等，通過池化來減少一些消耗，以提升性能。對象池通過復(fù)用對象從而減少創(chuàng)建對象、垃圾回收的開銷。但是，池化不能太大，太大會影響GC時的掃描時間。連接池如數(shù)據(jù)庫連接池、Redis連接池、Http連接池，通過復(fù)用TCP連接減少創(chuàng)建和釋放連接的時間來提升性能。線程池也是類似的，通過復(fù)用線程提升性能。也就是說池化的目的就是通過復(fù)用技術(shù)提升性能。編輯ppt高并發(fā)-擴容1、讀寫分離：當(dāng)數(shù)據(jù)庫訪問量還不是很大的時候，我們可以適當(dāng)增加服務(wù)器，數(shù)據(jù)庫主從復(fù)制的方式將讀寫分離2、垂直分區(qū)：當(dāng)寫入操作一旦增加的時候，那么主從數(shù)據(jù)庫將花更多的時間的放在數(shù)據(jù)同步上，這個時候服務(wù)器也是不堪重負(fù)的；那么就有了數(shù)據(jù)的垂直分區(qū)，數(shù)據(jù)的垂直分區(qū)思路是將寫入操作比較頻繁的數(shù)據(jù)表，如用戶表_user,或者訂單表_orders,那么我們就可以把這個兩個表分離出來，放在不同的服務(wù)器，如果這兩個表和其他表存在聯(lián)表查詢，那么就只能把原來的sql語句給拆分了，先查詢一個表，在查詢另一個，雖然說這個會消耗更過性能，但比起那種大量數(shù)據(jù)同步，負(fù)擔(dān)還是減輕了不少；3、水平分區(qū)：但是往往事情不盡人意，可能采取垂直分區(qū)能撐一段時間，由于網(wǎng)站太火了，訪問量又每日100w,一下子蹦到了1000w,這個時候可以采取數(shù)據(jù)的進(jìn)行分離，我們可以根據(jù)user的Id不同進(jìn)行分配，如采取%2的形式，或者%10的形式，當(dāng)然這種形式對以后的擴展有了很大的限制，當(dāng)我由10個分區(qū)增加到20個的時候，所有的數(shù)據(jù)都得重新分區(qū)，那么將是一個的很龐大的計算量；以下提供幾種常見的算法：

哈希算法：就是采用user_id%的方式;

范圍：可以根據(jù)user_id字符值范圍分區(qū)，如1-1000為一區(qū)，1001-2000則是另一個區(qū)等；

映射關(guān)系：就是將user_id存在的所對應(yīng)的分區(qū)放在數(shù)據(jù)庫中保存，當(dāng)用戶操作時先去查詢所在分區(qū)，再進(jìn)行操作；編輯ppt高并發(fā)-擴容分布式數(shù)據(jù)庫4、分布式數(shù)據(jù)庫（終極方案）：TDSQL架構(gòu)采用自動擴容機制、分表邏輯、擴容流程、容災(zāi)機制、強同步方案解決分布式數(shù)據(jù)庫擴容方案編輯ppt高并發(fā)-擴容分布式數(shù)據(jù)庫系統(tǒng)由三個模塊組成：Scheduler、Agent、網(wǎng)關(guān)，三個模塊的交互都是通過ZooKeeper完成，極大簡化了各個節(jié)點之間的通信機制，相對于第二代HOLD的開發(fā)簡單了很多。Scheduler作為集群的管理調(diào)度中心，主要功能包括：1、管理set，提供創(chuàng)建、刪除set、set內(nèi)節(jié)點替換等工作；2、所有的DDL操作統(tǒng)一下發(fā)和調(diào)度；3、監(jiān)控set內(nèi)各個節(jié)點的存活狀態(tài)，當(dāng)set內(nèi)主節(jié)點故障，發(fā)起高一致性主備切換流程；4、監(jiān)控各個set的CPU、磁盤容量、各個表的資源消耗情況，必要的時候自動發(fā)起擴容流程；5、Scheduler自身的容災(zāi)通過ZooKeqzer的選舉機制完成，保證中心控制節(jié)點無單點。Agent模塊負(fù)責(zé)監(jiān)控本機MySQL實例的運行情況，主要功能包括：1、用短連接的方式周期性訪問本機的MySQL實例，檢測是否可讀、可寫，若發(fā)生異常，會將異常信息上報到ZooKeeper，最終會由上面描述的Scheduler模塊檢測到這個異常情況，從而發(fā)起容災(zāi)切換；2、檢測主備復(fù)制的執(zhí)行情況，會定期上報主備復(fù)制的延時和延遲的事務(wù)數(shù)，若發(fā)生了主備切換，自動向新主機重建主備，因此MySQL的主備不需要DBA干預(yù)，對于新增的實例會自動采用xtrabackup通過主機自動重建數(shù)據(jù)；編輯ppt高并發(fā)-擴容分布式數(shù)據(jù)庫3、檢測MySQL實例的CPU利用率和各個表的請求量、數(shù)據(jù)量、CPU利用率，上報到ZooKeeper，ZooKeeper通過全局的資源情況抉擇如何擴容、縮容；監(jiān)控是否有下發(fā)到自身的擴容任務(wù)，如有則會執(zhí)行擴容流程（下面會有描述）；監(jiān)控是否要發(fā)生容災(zāi)切換，并按計劃執(zhí)行主備切換流程。網(wǎng)關(guān)基于MySQLProxy開發(fā)，在網(wǎng)絡(luò)層、連接管理、SQL解析、路由等方面做了大量優(yōu)化，主要特點和功能如下：1、解析SQL，將識別出的DDL語句直接存到ZooKeeper，讓Keeper來統(tǒng)一調(diào)度；2、WatchZooKeeper的路由信息，拉取最新的路由表保存到本地文件和內(nèi)存；3、將SQL請求路由到對應(yīng)的set，支持讀寫分離；4、對接入的IP、用戶名、密碼進(jìn)行鑒權(quán)；5、記錄完整的SQL執(zhí)行信息，與秒級監(jiān)控平臺對接完成實時的SQL請求的時耗，成功率等指標(biāo)監(jiān)控分析；6、對count、distinct、sum、avg、max、min、orderby、groupby等聚合類SQL一般需要訪問后端的多個set，網(wǎng)關(guān)會分析結(jié)果并做合并再返回，暫不支持跨setjoin和分布式事務(wù)；7、網(wǎng)關(guān)無狀態(tài)，既支持與業(yè)務(wù)部署到一起，也可以獨立部署（可通過TGW或者LVS做容災(zāi)）。編輯ppt高并發(fā)-擴容（Canal分布式數(shù)據(jù)庫同步系統(tǒng)）1.基于Canal開源產(chǎn)品，獲取數(shù)據(jù)庫增量日志數(shù)據(jù)。2.典型管理系統(tǒng)架構(gòu)，manager(web管理)+node(工作節(jié)點)a.manager運行時推送同步配置到node節(jié)點b.node節(jié)點將同步狀態(tài)反饋到manager上3.基于zookeeper，解決分布式狀態(tài)調(diào)度的，允許多node節(jié)點之間協(xié)同工作.編輯ppt高并發(fā)-隊列應(yīng)用場景1、異步處理：使用隊列的一個主要原因是進(jìn)行異步處理，比如用戶注冊完成后，需要發(fā)送注冊成功郵件/新用戶積分/優(yōu)惠卷等；緩存過期時，先返回過期數(shù)據(jù)，然后異步更新緩存、異步寫日志等。2、系統(tǒng)解耦：比如用戶支付完成訂單后，需要通知生產(chǎn)配貨系統(tǒng)、發(fā)票系統(tǒng)、庫存系統(tǒng)、推薦系統(tǒng)、搜索系統(tǒng)等進(jìn)行業(yè)務(wù)處理。3、數(shù)據(jù)同步：比如想把mysql變更的數(shù)據(jù)同步到Redis，或者將mysql數(shù)據(jù)同步到mongodb,或者讓機房之間的數(shù)據(jù)同步，或者主從數(shù)據(jù)同步等，有相關(guān)軟件：databus、canal、otter等。使用數(shù)據(jù)總線隊列進(jìn)行數(shù)據(jù)同步的好處是可以保證數(shù)據(jù)修改的有序。4、流量削峰：系統(tǒng)的瓶頸一般在數(shù)據(jù)庫上，比如扣減庫存、下單等，此時可以考慮使用隊列將變更請求暫時放入隊列，通過緩存+隊列暫存的方式將數(shù)據(jù)庫流量削峰。同樣，對于秒殺系統(tǒng)，下單服務(wù)會是該系統(tǒng)的瓶頸，此時可以使用隊列進(jìn)行排隊和限流，從而保護(hù)下單服務(wù)，通過隊列暫存或者隊列限流進(jìn)行流量削峰編輯ppt高并發(fā)-隊列（Canal）1、Canal同步緩存2、Canal下發(fā)任務(wù)給消息隊列編輯pptDubbo

詳細(xì)介紹

Dubbo是阿里巴巴公司開源的一個高性能優(yōu)秀的服務(wù)框架，使得應(yīng)用可通過高性能的RPC實現(xiàn)服務(wù)的輸出和輸入功能，可以和Spring框架無縫集成。主要核心部件：

Remoting:網(wǎng)絡(luò)通信框架，實現(xiàn)了sync-over-async和request-response消息機制.

RPC:一個遠(yuǎn)程過程調(diào)用的抽象，支持負(fù)載均衡、容災(zāi)和集群功能

Registry:服務(wù)目錄框架用于服務(wù)的注冊和服務(wù)事件發(fā)布和訂閱編輯pptDubbo服務(wù)集群-集群容錯模式編輯pptDubbo服務(wù)提供者集群與負(fù)載均衡編輯pptSpringCloud19個技術(shù)SpringCloud工具框架1、SpringCloudConfig配置中心，利用git集中管理程序的配置。2、SpringCloudNetflix集成眾多Netflix的開源軟件3、SpringCloudBus消息總線，利用分布式消息將服務(wù)和服務(wù)實例連接在一起，用于在一個集群中傳播狀態(tài)的變化4、SpringCloudforCloudFoundry利用PivotalCloudfoundry集成你的應(yīng)用程序5、SpringCloudCloudFoundryServiceBroker為建立管理云托管服務(wù)的服務(wù)代理提供了一個起點。6、SpringCloudCluster基于Zookeeper,Redis,Hazelcast,Consul實現(xiàn)的領(lǐng)導(dǎo)選舉和平民狀態(tài)模式的抽象和實現(xiàn)。7、SpringCloudConsul基于HashicorpConsul實現(xiàn)的服務(wù)發(fā)現(xiàn)和配置管理。8、SpringCloudSecurity在Zuul代理中為OAuth2rest客戶端和認(rèn)證頭轉(zhuǎn)發(fā)提供負(fù)載均衡9、SpringCloudSleuthSpringCloud應(yīng)用的分布式追蹤系統(tǒng)，和Zipkin，HTrace，ELK兼容。10、SpringCloudDataFlow一個云本地程序和操作模型，組成數(shù)據(jù)微服務(wù)在一個結(jié)構(gòu)化的平臺上。編輯pptDubbo架構(gòu)高并發(fā)高可用選型技術(shù)編輯pptSpringCloud19個技術(shù)11、SpringCloudStream基于Redis,Rabbit,Kafka實現(xiàn)的消息微服務(wù)，簡單聲明模型用以在SpringCloud應(yīng)用中收發(fā)消息。12、SpringCloudStreamAppStarters基于SpringBoot為外部系統(tǒng)提供spring的集成13、SpringCloudTask短生命周期的微服務(wù)，為SpringBooot應(yīng)用簡單聲明添加功能和非功能特性。14、SpringCloudTaskAppStarters15、SpringCloudZookeeper服務(wù)發(fā)現(xiàn)和配置管理基于ApacheZookeeper。16、SpringCloudforAmazonWebServices快速和亞馬遜網(wǎng)絡(luò)服務(wù)集成。17、SpringCloudConnectors便于PaaS應(yīng)用在各種平臺上連接到后端像數(shù)據(jù)庫和消息經(jīng)紀(jì)服務(wù)。18、SpringCloudStarters（項目已經(jīng)終止并且在Angel.SR2后的版本和其他項目合并）19、SpringCloudCLI插件用Groovy快速的創(chuàng)建SpringCloud組件應(yīng)用。SpringCloud共集成了19個子項目，里面都包含一個或者多個第三方的組件或者框架！編輯pptSpringCloud和dubbo比較-背景Dubbo，是阿里巴巴服務(wù)化治理的核心框架，并被廣泛應(yīng)用于阿里巴巴集團(tuán)的各成員站點(阿里巴巴現(xiàn)在使用架構(gòu)為HSF)。于2012-10-24最后版本2.5.3成為最后一版本，由當(dāng)當(dāng)接手維護(hù)，命名為dubboxSpringCloud，從命名我們就可以知道，它是SpringSource的產(chǎn)物，Spring社區(qū)的強大背書可以說是Java企業(yè)界最有影響力的組織了，除了SpringSource之外，還有Pivotal和Netfix是其強大的后盾與技術(shù)輸出。其中Netflix開源的整套微服務(wù)架構(gòu)套件是SpringCloud的核心。

如果拿Dubbo與Netflix套件做對比，前者在國內(nèi)影響力較大，后者在國外影響力較大，在背景上可以打個平手；但是若要與SpringCloud做對比，由于SpringSource的加入，在背書上，SpringCloud略勝一籌，但是在高并發(fā)上dubbo曾經(jīng)在阿里的運營中實際承載過過億用戶同時在線的，而Netflix并沒有實際的上線應(yīng)用中體現(xiàn)過。

SpringCloud下面有19個子項目（可能還會新增）分別覆蓋了微服務(wù)架構(gòu)下的方方面面，服務(wù)治理只是其中的一個方面，一定程度來說，Dubbo只是SpringCloudNetflix中的一個子集。但是在選擇框架上，方案完整度恰恰是一個需要重點關(guān)注的內(nèi)容，當(dāng)然從高可用和高并發(fā)一起考慮，SpringCloud無疑是最佳選擇。編輯pptSpringSource架構(gòu)高并發(fā)高可用選型技術(shù)編輯pptSpringCloud和dubbo比較-對比DubboSpringCloud服務(wù)注冊中心ZookeeperSpringCloudNetflixEureka服務(wù)調(diào)用方式RPCRESTAPI服務(wù)網(wǎng)關(guān)無SpringCloudNetflixZuul斷路器不完善SpringCloudNetflixHystrix分布式配置無SpringCloudConfig服務(wù)跟蹤無SpringCloudSleuth消息總線無SpringCloudBus數(shù)據(jù)流無SpringCloudStream批量任務(wù)無SpringCloudTask………………編輯ppt互聯(lián)網(wǎng)高可用的需要技術(shù)對比DubboSpringCloud負(fù)載均衡消息服務(wù)端有(后置服務(wù))

RESTfulweb

沒有SpringCloudNetflixEurekaEureka服務(wù)器和Eureka客戶端均可集群方向代理沒有（須第三方支持）SpringCloudSecurity隔離沒有（須第三方支持）SpringC