互聯(lián)網(wǎng)金融微服務(wù)架構(gòu)設(shè)計課件_第1頁
互聯(lián)網(wǎng)金融微服務(wù)架構(gòu)設(shè)計課件_第2頁
互聯(lián)網(wǎng)金融微服務(wù)架構(gòu)設(shè)計課件_第3頁
互聯(lián)網(wǎng)金融微服務(wù)架構(gòu)設(shè)計課件_第4頁
互聯(lián)網(wǎng)金融微服務(wù)架構(gòu)設(shè)計課件_第5頁
已閱讀5頁,還剩141頁未讀 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

討論內(nèi)容SOA、ESB、SAAS、PAAS

、IaaS

、微服務(wù)1:互聯(lián)網(wǎng)高可用性(HA)3:SpringCloud和dubbo比較4:

SpringCloud架構(gòu)技術(shù)描述5:互聯(lián)網(wǎng)高并發(fā)2:

互聯(lián)話題:獨立訪問者數(shù)量(uniquevisitors)、重復(fù)訪問者數(shù)量(repeatvisitors)、頁面瀏覽數(shù)(pageviews)理解

SpringCloud架構(gòu)實現(xiàn)計劃6:討論內(nèi)容SOA、ESB、SAAS、PAAS、IaaSOA(面向服務(wù)的架構(gòu))

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

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

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

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

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

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

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

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

系統(tǒng)能夠提供什么樣的開發(fā)工具,支持什么樣的開發(fā)模式,系統(tǒng)運行情況是否可以及時了解,是否可以及時獲取故障信息,是否可以提供運行狀態(tài)信息,以利于系統(tǒng)的優(yōu)化。SOA(面向服務(wù)的架構(gòu))ESB(企業(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ù)。ESB(企業(yè)服務(wù)總線)SOA與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可在多個提供者、提供者的負載平衡及停止使用提供者(當(dāng)失效時)之間進行選擇,并且基于調(diào)用者的需求在提供者之間進行選擇,這些提供者提供了各種質(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ù)用性。SOA與ESB的區(qū)別SAAS(軟件即服務(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è)資金不足的壓力;不用考慮成本折舊問題,并能及時獲得最新硬件平臺及最佳解決方案。⒊從維護和管理方面來看:由于企業(yè)采取租用的方式來進行物流業(yè)務(wù)管理,不需要專門的維護和管理人員,也不需要為維護和管理人員支付額外費用。很大程度上緩解企業(yè)在人力、財力上的壓力,使其能夠集中資金對核心業(yè)務(wù)進行有效的運營;SaaS能使用戶在世界上都是一個完全獨立的系統(tǒng)。如果您連接到網(wǎng)絡(luò),就可以訪問系統(tǒng)。對企業(yè)來說,SaaS的缺點1.安全性:企業(yè),尤其是大型企業(yè),很不情愿使用SaaS正是因為安全問題,他們要保護他們的核心數(shù)據(jù),不希望這些核心數(shù)據(jù)由第三方來負責(zé)。2.標(biāo)準(zhǔn)化:SaaS解決方案缺乏標(biāo)準(zhǔn)化。這個行業(yè)剛剛起步,沒有明確的解決辦法,一家公司可以設(shè)計建立一個解決方案。鑒于復(fù)雜和高度可定制的ERP產(chǎn)品,這是一個冒險的建議。SAAS(軟件即服務(wù))SaaS是SoftwarePAAS(平臺即服務(wù))

PaaS是Platform-as-a-Service的縮寫,意思是平臺即服務(wù)。把服務(wù)器平臺作為一種服務(wù)提供的商業(yè)模式。通過網(wǎng)絡(luò)進行程序提供的服務(wù)稱之為SaaS(SoftwareasaService),而云計算時代相應(yīng)的服務(wù)器平臺或者開發(fā)環(huán)境作為服務(wù)進行提供就成為了PaaS(PlatformasaService)。所謂PaaS實際上是指將軟件研發(fā)的平臺(計世資訊定義為業(yè)務(wù)基礎(chǔ)平臺)作為一種服務(wù),以SaaS的模式提交給用戶。因此,PaaS也是SaaS模式的一種應(yīng)用。但是,PaaS的出現(xiàn)可以加快SaaS的發(fā)展,尤其是加快SaaS應(yīng)用的開發(fā)速度。在2007年國內(nèi)外SaaS廠商先后推出自己的PAAS平臺。

PaaS區(qū)別簡單地說,PaaS平臺就是指云環(huán)境中的應(yīng)用基礎(chǔ)設(shè)施服務(wù),也可以說是中間件即服務(wù)。PaaS平臺在云架構(gòu)中位于中間層,其上層是SaaS,其下層是IaaS[3]。在傳統(tǒng)On-Premise部署方式下,應(yīng)用基礎(chǔ)設(shè)施即中間件的種類非常多,有應(yīng)用服務(wù)器,數(shù)據(jù)庫,ESBs,BPM,Portal,消息中間件,遠程對象調(diào)用中間件等等。對于PaaS平臺,Gartner把它們分為兩類,一類是應(yīng)用部署和運行平臺APaaS(applicationplatformasaservice),另一類是集成平臺IPaaS(integrationasaservice)。人們經(jīng)常說的PaaS平臺基本上是指APaaS,如Force和GoogleAppEngine。國內(nèi)日前上線的中國云應(yīng)用平臺,能夠為軟件廠商提供領(lǐng)先的IaaS基礎(chǔ)平臺,使得軟件廠商能夠?qū)⒆⒁饬性谄鋺?yīng)用產(chǎn)品的云化之上,而將對基礎(chǔ)資源的需求,包括云服務(wù)器、云存儲、云監(jiān)控等完全依托在理念領(lǐng)先、技術(shù)成熟、安全可靠的IaaS平臺上。PAAS(平臺即服務(wù))PaaS是Platform-IaaS(基礎(chǔ)設(shè)施即服務(wù))

IaaS(InfrastructureasaService),即基礎(chǔ)設(shè)施即服務(wù)。消費者通過Internet可以從完善的計算機基礎(chǔ)設(shè)施獲得服務(wù)。這類服務(wù)稱為基礎(chǔ)設(shè)施即服務(wù)?;贗nternet的服務(wù)(如存儲和數(shù)據(jù)庫)是IaaS的一部分。Internet上其他類型的服務(wù)包括平臺即服務(wù)(PlatformasaService,PaaS)和軟件即服務(wù)(SoftwareasaService,SaaS)。PaaS提供了用戶可以訪問的完整或部分的應(yīng)用程序開發(fā),SaaS則提供了完整的可直接使用的應(yīng)用程序,比如通過Internet管理企業(yè)資源。

根據(jù)NIST(NationalInstituteofStandardsandTechnology,美國國家標(biāo)準(zhǔn)與技術(shù)研究院)的權(quán)威定義,云計算的服務(wù)模式有SPI(即SaaS、PaaS和IaaS)這三個大類或?qū)哟?。這是目前被業(yè)界最廣泛認同的劃分。PaaS和IaaS源于SaaS理念。PaaS和IaaS可以直接通過SOA/WebServices向平臺用戶提供服務(wù),也可以作為SaaS模式的支撐平臺間接向最終用戶服務(wù)IaaS中間件(包括HPC/Gri中間件,PVM/MPI,機群/集群,Beowulf,DRS作業(yè)調(diào)度,并行文件系統(tǒng)等)

云系統(tǒng)(效用計算機SaaSBI/BPM,BSS/OSS,WS/SOA/API)PaaS中間件(包括應(yīng)用服務(wù)器MQ/ESB/SOA,多層次多租戶SaaS模式支撐,Hypervisor,OSGI等)IaaS(基礎(chǔ)設(shè)施即服務(wù))IaaS(InfrasIaaS

、

PaaS、SaaS1.SaaS:提供給客戶的服務(wù)是運營商運行在云計算基礎(chǔ)設(shè)施上的應(yīng)用程序,用戶可以在各種設(shè)備上通過客戶端界面訪問,如瀏覽器。消費者不需要管理或控制任何云計算基礎(chǔ)設(shè)施,包括網(wǎng)絡(luò)、服務(wù)器、操作系統(tǒng)、存儲等等;2.PaaS:提供給消費者的服務(wù)是把客戶采用提供的開發(fā)語言和工具(例如Java,python,.Net等)開發(fā)的或收購的應(yīng)用程序部署到供應(yīng)商的云計算基礎(chǔ)設(shè)施上去??蛻舨恍枰芾砘蚩刂频讓拥脑苹A(chǔ)設(shè)施,包括網(wǎng)絡(luò)、服務(wù)器、操作系統(tǒng)、存儲等,但客戶能控制部署的應(yīng)用程序,也可能控制運行應(yīng)用程序的托管環(huán)境配置;3.IaaS:提供給消費者的服務(wù)是對所有計算基礎(chǔ)設(shè)施的利用,包括處理CPU、內(nèi)存、存儲、網(wǎng)絡(luò)和其它基本的計算資源,用戶能夠部署和運行任意軟件,包括操作系統(tǒng)和應(yīng)用程序。消費者不管理或控制任何云計算基礎(chǔ)設(shè)施,但能控制操作系統(tǒng)的選擇、存儲空間、部署的應(yīng)用,也有可能獲得有限制的網(wǎng)絡(luò)組件(例如路由器、,防火墻,、負載均衡器等)的控制。IaaS、PaaS、SaaS1.SaaS:提供給客戶SOA和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ù)的思維。SOA和SaaS的區(qū)別1.SOA包括了關(guān)于軟什么是微服務(wù)架構(gòu)微服務(wù)架構(gòu)模式(MicroserviceArchitectPattern)。近兩年在服務(wù)的瘋狂增長與云計算技術(shù)的進步,讓微服務(wù)架構(gòu)受到重點關(guān)注微服務(wù)架構(gòu)是一種架構(gòu)模式,它提倡將單一應(yīng)用程序劃分成一組小的服務(wù),服務(wù)之間互相協(xié)調(diào)、互相配合,為用戶提供最終價值。每個服務(wù)運行在其獨立的進程中,服務(wù)與服務(wù)間采用輕量級的通信機制互相溝通(通常是基于HTTP的RESTfulAPI)。每個服務(wù)都圍繞著具體業(yè)務(wù)進行構(gòu)建,并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外,應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機制,對具體的一個服務(wù)而言,應(yīng)根據(jù)業(yè)務(wù)上下文,選擇合適的語言、工具對其進行構(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ù)對各方面進行管理,彼此之間使用統(tǒng)一的接口來進行交流,架構(gòu)變得復(fù)雜,優(yōu)勢也很明顯:復(fù)雜度可控:在將應(yīng)用分解的同時,規(guī)避了原本復(fù)雜度無止境的積累。每一個微服務(wù)專注于單一功能,并通過定義良好的接口清晰表述服務(wù)邊界。由于體積小、復(fù)雜度低,每個微服務(wù)可由一個小規(guī)模開發(fā)團隊完全掌控,易于保持高可維護性和開發(fā)效率。什么是微服務(wù)架構(gòu)微服務(wù)架構(gòu)模式(Micros什么是微服務(wù)架構(gòu)微服務(wù)架構(gòu)優(yōu)勢

獨立部署:由于微服務(wù)具備獨立的運行進程,所以每個微服務(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ù)選型是去中心化的。每個團隊可以根據(jù)自身服務(wù)的需求和行業(yè)發(fā)展的現(xiàn)狀,自由選擇最適合的技術(shù)棧。由于每個微服務(wù)相對簡單,當(dāng)需要對技術(shù)棧進行升級時所面臨的風(fēng)險較低,甚至完全重構(gòu)一個微服務(wù)也是可行的。容錯:當(dāng)某一組建發(fā)生故障時,在單一進程的傳統(tǒng)架構(gòu)下,故障很有可能在進程內(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ù)實際需求獨立進行擴展。什么是微服務(wù)架構(gòu)微服務(wù)架構(gòu)優(yōu)勢SOA和微服務(wù)架構(gòu)的區(qū)別如果一句話來談SOA和微服務(wù)的區(qū)別,即微服務(wù)不再強調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線,同時SOA的思想進入到單個業(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的方式來進行。

微服務(wù)的基本思想在于考慮圍繞著業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用,這些就應(yīng)用可獨立地進行開發(fā)、管理和加速。在分散的組件中使用微服務(wù)云架構(gòu)和平臺使部署、管理和服務(wù)功能交付變得更加簡單。SOA和微服務(wù)架構(gòu)的區(qū)別如果一句話來談SOA互聯(lián)網(wǎng)高并發(fā)相關(guān)名詞頁面瀏覽數(shù)(pageviews)獨立訪問者數(shù)量(uniquevisitors)重復(fù)訪問者數(shù)量(repeatvisitors)每個訪問者的頁面瀏覽數(shù)(PageViewsperuser)唯一身份瀏覽量(UniquePageViews)互聯(lián)網(wǎng)高并發(fā)相關(guān)名詞頁面瀏覽數(shù)(pageviews)獨高并發(fā)

之前我將高并發(fā)的解決方法誤認為是線程或者是隊列可以解決,因為高并發(fā)的時候是有很多用戶在訪問,導(dǎo)致出現(xiàn)系統(tǒng)數(shù)據(jù)不正確、丟失數(shù)據(jù)現(xiàn)象,所以想到的是用隊列解決,其實隊列解決的方式也可以處理,比如我們在競拍商品、轉(zhuǎn)發(fā)評論微博或者是秒殺商品等,同一時間訪問量特別大,隊列在此起到特別的作用,將所有請求放入隊列,以毫秒計時單位,有序的進行,從而不會出現(xiàn)數(shù)據(jù)丟失系統(tǒng)數(shù)據(jù)不正確的情況。

經(jīng)過查資料,高并發(fā)的解決方法有倆種,一種是使用緩存、另一種是使用生成靜態(tài)頁面;還有就是從最基礎(chǔ)的地方優(yōu)化我們寫代碼減少不必要的資源浪費:(1.不要頻繁的new對象,對于在整個應(yīng)用中只需要存在一個實例的類使用單例模式.對于String的連接操作,使用StringBuffer或者StringBuilder.對于utility類型的類通過靜態(tài)方法來訪問。2.避免使用錯誤的方式,如Exception可以控制方法推出,但是Exception要保留stacktrace消耗性能,除非必要不要使用instanceof做條件判斷,盡量使用比的條件判斷方式.使用JAVA中效率高的類,比如ArrayList比Vector性能好。)高并發(fā)之前我將高并發(fā)的解決方法誤認為是線程或者互聯(lián)網(wǎng)高并發(fā)系統(tǒng)-需要解決的問題

一:應(yīng)用緩存二:HTTP緩存三:多級緩存四:池化五:異步并發(fā)六:擴容七:隊列互聯(lián)網(wǎng)高并發(fā)系統(tǒng)-需要解決的問題高并發(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)高并發(fā)-應(yīng)用緩存堆緩存堆外緩存磁盤緩存高并發(fā)-應(yīng)用緩存分布式緩存

之前緩存提到是進程內(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進程間分布式緩存。最好的辦法是使用redis實現(xiàn)分布式緩存。高并發(fā)-應(yīng)用緩存分布式緩存高并發(fā)-HTTP緩存瀏覽器緩存是指當(dāng)我們使用瀏覽器訪問一些網(wǎng)站頁面或者http服務(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ù)都可以來進行內(nèi)容緩存。還有CDN就是用來加速用戶訪問的:即用戶首先訪問到全國各地的CDN節(jié)點(使用如ATS、Squid實現(xiàn)),如果CDN沒命中,會回源到中央nginx集群,該集群如果沒有命中緩存(該集群的緩存不是必須的,要根據(jù)實際命中情況等決定),最后回源到后端應(yīng)用集群。高并發(fā)-HTTP緩存瀏覽器緩存是指當(dāng)我們使用瀏覽器高并發(fā)-多級緩存(分布式緩存)高并發(fā)-多級緩存(分布式緩存)高并發(fā)-池化在應(yīng)用系統(tǒng)開發(fā)過程中,我們經(jīng)常會用到池化技術(shù),如對象池、連接池、線程池等,通過池化來減少一些消耗,以提升性能。對象池通過復(fù)用對象從而減少創(chuàng)建對象、垃圾回收的開銷。但是,池化不能太大,太大會影響GC時的掃描時間。連接池如數(shù)據(jù)庫連接池、Redis連接池、Http連接池,通過復(fù)用TCP連接減少創(chuàng)建和釋放連接的時間來提升性能。線程池也是類似的,通過復(fù)用線程提升性能。也就是說池化的目的就是通過復(fù)用技術(shù)提升性能。高并發(fā)-池化在應(yīng)用系統(tǒng)開發(fā)過程中,我們經(jīng)常會用到池化高并發(fā)-擴容1、讀寫分離:當(dāng)數(shù)據(jù)庫訪問量還不是很大的時候,我們可以適當(dāng)增加服務(wù)器,數(shù)據(jù)庫主從復(fù)制的方式將讀寫分離2、垂直分區(qū):當(dāng)寫入操作一旦增加的時候,那么主從數(shù)據(jù)庫將花更多的時間的放在數(shù)據(jù)同步上,這個時候服務(wù)器也是不堪重負的;那么就有了數(shù)據(jù)的垂直分區(qū),數(shù)據(jù)的垂直分區(qū)思路是將寫入操作比較頻繁的數(shù)據(jù)表,如用戶表_user,或者訂單表_orders,那么我們就可以把這個兩個表分離出來,放在不同的服務(wù)器,如果這兩個表和其他表存在聯(lián)表查詢,那么就只能把原來的sql語句給拆分了,先查詢一個表,在查詢另一個,雖然說這個會消耗更過性能,但比起那種大量數(shù)據(jù)同步,負擔(dān)還是減輕了不少;3、水平分區(qū):但是往往事情不盡人意,可能采取垂直分區(qū)能撐一段時間,由于網(wǎng)站太火了,訪問量又每日100w,一下子蹦到了1000w,這個時候可以采取數(shù)據(jù)的進行分離,我們可以根據(jù)user的Id不同進行分配,如采取%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ū),再進行操作;高并發(fā)-擴容1、讀寫分離:當(dāng)數(shù)據(jù)庫訪問量還不是很大的時候,我高并發(fā)-擴容分布式數(shù)據(jù)庫4、分布式數(shù)據(jù)庫(終極方案):TDSQL架構(gòu)采用自動擴容機制、分表邏輯、擴容流程、容災(zāi)機制、強同步方案解決分布式數(shù)據(jù)庫擴容方案高并發(fā)-擴容分布式數(shù)據(jù)庫4、分布式數(shù)據(jù)庫(終極方案):TDS高并發(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模塊負責(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ù);高并發(fā)-擴容分布式數(shù)據(jù)庫系統(tǒng)由三個模塊組成:Schedule高并發(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、用戶名、密碼進行鑒權(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))。高并發(fā)-擴容分布式數(shù)據(jù)庫3、檢測MySQL實例的CPU利用率高并發(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é)同工作.高并發(fā)-擴容(Canal分布式數(shù)據(jù)庫同步系統(tǒng))1.基于C高并發(fā)-隊列應(yīng)用場景1、異步處理:使用隊列的一個主要原因是進行異步處理,比如用戶注冊完成后,需要發(fā)送注冊成功郵件/新用戶積分/優(yōu)惠卷等;緩存過期時,先返回過期數(shù)據(jù),然后異步更新緩存、異步寫日志等。2、系統(tǒng)解耦:比如用戶支付完成訂單后,需要通知生產(chǎn)配貨系統(tǒng)、發(fā)票系統(tǒng)、庫存系統(tǒng)、推薦系統(tǒng)、搜索系統(tǒng)等進行業(yè)務(wù)處理。3、數(shù)據(jù)同步:比如想把mysql變更的數(shù)據(jù)同步到Redis,或者將mysql數(shù)據(jù)同步到mongodb,或者讓機房之間的數(shù)據(jù)同步,或者主從數(shù)據(jù)同步等,有相關(guān)軟件:databus、canal、otter等。使用數(shù)據(jù)總線隊列進行數(shù)據(jù)同步的好處是可以保證數(shù)據(jù)修改的有序。4、流量削峰:系統(tǒng)的瓶頸一般在數(shù)據(jù)庫上,比如扣減庫存、下單等,此時可以考慮使用隊列將變更請求暫時放入隊列,通過緩存+隊列暫存的方式將數(shù)據(jù)庫流量削峰。同樣,對于秒殺系統(tǒng),下單服務(wù)會是該系統(tǒng)的瓶頸,此時可以使用隊列進行排隊和限流,從而保護下單服務(wù),通過隊列暫存或者隊列限流進行流量削峰高并發(fā)-隊列應(yīng)用場景1、異步處理:使用隊列的一個主要原因是進高并發(fā)-隊列(

Canal)1、Canal同步緩存2、Canal下發(fā)任務(wù)給消息隊列高并發(fā)-隊列(Canal)1、Canal同步緩存2、C高可用什么是高可用性高可用性(HA)系統(tǒng)是目前企業(yè)防止核心計算機系統(tǒng)因故障停機的最有效手段。高可用性(HA)的功能1、軟件故障監(jiān)測與排除2、備份和數(shù)據(jù)保護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ù)之間的差別也就隨之消失了。高可用什么是高可用性高可用性(HA)系統(tǒng)是目前企業(yè)防止核心計互聯(lián)網(wǎng)高可用性(HA)系統(tǒng)-需要解決的問題

一:負載均衡與反向代理二:隔離三:限流四:降級五:超時與重試六:回滾七:壓力測試與應(yīng)急預(yù)案互聯(lián)網(wǎng)高可用性(HA)系統(tǒng)-需要解決的問題高可用-負載均衡

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

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

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

反向代理(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ù)器的負載。反向代理服務(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)開銷。高可用-反向代理反向代理(Reve高可用-隔離術(shù)

線程隔離:

線程隔離主要是指線程池隔離,在實際使用時,我們會把請求分類,然后交給不同的線程池處理。當(dāng)一種業(yè)務(wù)的請求處理發(fā)生問題時,不會將故障擴散到其他線程池,從而保證其他服務(wù)可用。進程隔離由于傳統(tǒng)的系統(tǒng)所有功能都集中在一個系統(tǒng)中,為了避免系統(tǒng)其中一個模塊功能出現(xiàn)問題導(dǎo)致整個系統(tǒng)無法使用的情況發(fā)生,將其該系統(tǒng)拆分成多子系統(tǒng)實現(xià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)可用性的要求,會進行多機房部署,每一個機房的服務(wù)都有自己的服務(wù)分組,本機房的服務(wù)應(yīng)該只調(diào)用本機房的服務(wù),不進行跨機房調(diào)用。其中,一個機房服務(wù)發(fā)生問題時,可以通過DNS/負載均衡將請求全部切到另一個機房,或者考慮服務(wù)能自動重試其他機房的服務(wù),從而提升系統(tǒng)可用性。高可用-隔離術(shù)線程隔離:進程隔離集群隔離機房隔高可用-隔離術(shù)

讀寫隔離

為了提高數(shù)據(jù)訪問,一般采用redis主從模式將讀和寫進群分離,在正常情況下,當(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容器時,有的容器寫磁盤非常頻繁,因此要考慮為不同的容器掛載不同的磁盤。高可用-隔離術(shù)讀寫隔離動靜隔離資源隔離高可用-限流在開發(fā)高并發(fā)系統(tǒng)時有三把利器用來保護系統(tǒng):緩存、降級和限流。緩存的目的是提升系統(tǒng)訪問速度和增大系統(tǒng)能處理的容量,可謂是抗高并發(fā)流量的銀彈;而降級是當(dāng)服務(wù)出問題或者影響到核心流程的性能則需要暫時屏蔽掉,待高峰或者問題解決后再打開;而有些場景并不能用緩存和降級來解決,比如稀缺資源(秒殺、搶購)、寫服務(wù)(如評論、下單)、頻繁的復(fù)雜查詢(評論的最后幾頁),因此需有一種手段來限制這些場景的并發(fā)/請求量,即限流。

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

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

降級預(yù)案在進行降級之前要對系統(tǒng)進行梳理,看看系統(tǒng)是不是可以丟卒保帥;從而梳理出哪些必須誓死保護,哪些可降級;比如可以參考日志級別設(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ù)降級高可用-降級降級的最終目的是保證核心服務(wù)可用,即使高可用-超時與重試

在實際開發(fā)過程中,我們見過太多故障時因為沒有設(shè)置超時或者設(shè)置得不對而造成的,而這些故障都是因為沒有意識到超時設(shè)置的重要性而造成的。如果應(yīng)用不設(shè)置超時,則可能會導(dǎo)致請求響應(yīng)慢,慢請求積累導(dǎo)致連鎖反應(yīng),甚至造成應(yīng)用雪塌。而有些中間件或者框架在超時后進行重試(例如dubbo默認重試兩次),讀服務(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)該和熔斷、快速失敗機制配合。所以在進行代碼Review時,一定記得Review超時與重試機制。高可用-超時與重試在實際開發(fā)過程中,高可用-回滾

事務(wù)回滾

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

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

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

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

靜態(tài)化頁面資源后,每次內(nèi)容變更時我們都會生成一個全量新版本放到項目的文件目錄中,從而保證版本可追溯,出現(xiàn)問題時能及時回滾。高可用-回滾事務(wù)回滾代碼庫回滾部署版本回滾數(shù)據(jù)高可用-壓力測試

線下壓力測試

通過如Jmeter,Apac,heab壓力測試系統(tǒng)的某一個接口等(如登錄、查詢訂單)或者某一個組件(例如數(shù)據(jù)庫連接池),然后進行調(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)

拿到全面的壓力測試報告后,接下來就是分析報告,然后進行一些有這對性的優(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)可用高可用-壓力測試線下壓力測試線上壓力測試系統(tǒng)優(yōu)高可用-應(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ò)抖動、某臺機器負載過高、某個服務(wù)變慢、數(shù)據(jù)庫Load值過高,為了防止因為這些問題而出現(xiàn)系統(tǒng)雪崩,需要針對這些情況制定應(yīng)急預(yù)案,從而在出現(xiàn)突發(fā)情況時,有響應(yīng)的措施來解決掉這些問題。

應(yīng)急預(yù)案可按照如下幾步進行:首先進行系統(tǒng)分級,然后進行全鏈路分析、配置監(jiān)控,最后制定應(yīng)急預(yù)案。高可用-應(yīng)急預(yù)案在系統(tǒng)壓力測試之后發(fā)Dubbo

詳細介紹

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

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

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

Registry:服務(wù)目錄框架用于服務(wù)的注冊和服務(wù)事件發(fā)布和訂閱Dubbo

詳細介紹Dubbo是阿里巴巴公Dubbo服務(wù)集群-集群容錯模式Dubbo服務(wù)集群-集群容錯模式Dubbo服務(wù)提供者集群與負載均衡Dubbo服務(wù)提供者集群與負載均衡Dubbo架構(gòu)高并發(fā)高可用選型技術(shù)Dubbo架構(gòu)高并發(fā)高可用選型技術(shù)Dubbo大體部署圖Dubbo大體部署圖SpringCloud19個技術(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客戶端和認證頭轉(zhuǎn)發(fā)提供負載均衡9、SpringCloudSleuthSpringCloud應(yīng)用的分布式追蹤系統(tǒng),和Zipkin,HTrace,ELK兼容。10、SpringCloudDataFlow一個云本地程序和操作模型,組成數(shù)據(jù)微服務(wù)在一個結(jié)構(gòu)化的平臺上。SpringCloud19個技術(shù)SpringCloudSpringCloud19個技術(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個子項目,里面都包含一個或者多個第三方的組件或者框架!SpringCloud19個技術(shù)11、SpringClSpringCloud和dubbo比較-背景Dubbo,是阿里巴巴服務(wù)化治理的核心框架,并被廣泛應(yīng)用于阿里巴巴集團的各成員站點(阿里巴巴現(xiàn)在使用架構(gòu)為HSF)。于2012-10-24最后版本2.5.3成為最后一版本,由當(dāng)當(dāng)接手維護,命名為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無疑是最佳選擇。SpringCloud和dubbo比較-背景DubbSpringcloud架構(gòu)圖Springcloud架構(gòu)圖Springcloud大致部署圖Springcloud大致部署圖SpringcloudDOCKER署的支持SpringcloudDOCKER署的支持SpringCloud和dubbo比較-對比DubboSpringCloud服務(wù)注冊中心ZookeeperSpringCloudNetflixEureka服務(wù)調(diào)用方式RPCRESTAPI服務(wù)網(wǎng)關(guān)無SpringCloudNetflixZuul斷路器無SpringCloudNetflixHystrix分布式配置無SpringCloudConfig服務(wù)跟蹤服務(wù)治理后臺SpringCloudSleuth消息總線無SpringCloudBus數(shù)據(jù)流無SpringCloudStream批量任務(wù)無SpringCloudTask

Batch………………SpringCloud和dubbo比較-對比DubboSp互聯(lián)網(wǎng)高可用的需要技術(shù)對比DubboSpringCloud負載均衡只有后置服務(wù)自帶負載均衡SpringCloudRibbon方向代理沒有(須第三方支持)SpringCloudNetflixZuul隔離沒有(須第三方支持)SpringCloudNetflixHystrix限流沒有(須第三方支持)SpringCloudNetflixHystrix降級沒有(須第三方支持)SpringCloudNetflixHystrix超時與重試NETTYSpringCloudFegin回滾TCC無應(yīng)急預(yù)案無SpringCloudNetflixHystrix互聯(lián)網(wǎng)高可用的需要技術(shù)對比DubboSpringCloud互聯(lián)網(wǎng)高并發(fā)需要技術(shù)對比DubboSpringCloud應(yīng)用緩存沒有(須第三方支持)springboot支持集成HTTP緩存沒有(須第三方支持)springboot支持集成多級緩存沒有(須第三方支持)springboot支持集成池化沒有(須第三方支持),阿里有自己的連接池springboot支持集成異步并發(fā)提供RPC高性能分布式架構(gòu)SpringCloudStream擴容1、支持docker2、借助于數(shù)據(jù)庫擴容技術(shù)1、無縫支持docker2、借助于數(shù)據(jù)庫擴容技術(shù)隊列無,借助于第三方消息無自帶監(jiān)聽服務(wù)SpringCloudStream互聯(lián)網(wǎng)高并發(fā)需要技術(shù)對比DubboSpringCloud應(yīng)SAAS高可用高并發(fā)技術(shù)選型DubboSpringCloud配置管理沒有,有(SpringCloudConfig)服務(wù)發(fā)現(xiàn)Zookeeper有(Eureka)斷路器沒有有(Hystrix)智能路由沒有有(Zuul)微代理沒有有(Zuul)控制總線沒有有(SpringCloudBus)一次性令牌有有全局鎖有有領(lǐng)導(dǎo)選舉有有分布式會話有有(SpringCloudSleuth)群集狀態(tài)有有Docker部署支持無縫支持SAAS高可用高并發(fā)技術(shù)選型DubboSpringClou現(xiàn)有項目改造成本對比DubboSpringCloud現(xiàn)有項目改造(springboot)需要集成dubbo技術(shù)無需改造,無縫集成程序員開發(fā)成本需要學(xué)習(xí)dubbo需要學(xué)習(xí)SpringCloudNetflix維護與部署成本配置管理(第三方)配置管理(SpringCloud)服務(wù)發(fā)現(xiàn)(第三方)服務(wù)發(fā)現(xiàn)(SpringCloud)斷路器(第三方)斷路器(SpringCloud)智能路由(第三方)智能路由(SpringCloud)微代理(第三方)微代理(SpringCloud)控制總線(第三方)控制總線(SpringCloud)群集狀態(tài)(第三方)群集狀態(tài)(SpringCloud)Docker(第三方)Docker(SpringCloud)分布式會話(第三方)分布式會話(SpringCloud)。。。。。?,F(xiàn)有項目改造成本對比DubboSpringCloud現(xiàn)有項技術(shù)架構(gòu)建議1、Dubbo,是阿里巴巴服務(wù)化治理的核心框架,并被廣泛應(yīng)用于阿里巴巴集團的各成員站點(阿里巴巴現(xiàn)在使用架構(gòu)為HSF)。于2012-10-24最后版本2.5.3成為最后一版本,已經(jīng)成為過去,也是過去的王者2、SpringCloud,從命名我們就可以知道,它是SpringSource的產(chǎn)物,Spring社區(qū)的強大背書可以說是Java企業(yè)界最有影響力的組織了,除了SpringSource之外,還有Pivotal和Netfix是其強大的后盾與技術(shù)輸出,是現(xiàn)今微服務(wù)的王者3、Saas的部署最好在Docker環(huán)境下部署,SpringCloud無縫銜接技術(shù)架構(gòu)建議1、Dubbo,是阿里巴巴服務(wù)化治理的核心框架,技術(shù)架構(gòu)建議6、SpringCloud依托于springboot,天然可以部署在Docker環(huán)境下,天生就是為高可用而設(shè)計的,維護成本比dubbo低很多5、針對當(dāng)前項目來說,團隊項目采用springboot,

學(xué)習(xí)成本成本很少4、

SpringCloud和Dubbo技術(shù)在服務(wù)治理上SpringCloud顯然優(yōu)越于Dubbo,配置管理,服務(wù)發(fā)現(xiàn),斷路器,智能路由,微代理,控制總線,一次性令牌,全局鎖,領(lǐng)導(dǎo)選舉,分布式會話,群集狀態(tài),一直是dubbo架構(gòu)部署運行后最為頭疼的事情,SpringCloud一一自帶組件解決了這些問題。技術(shù)架構(gòu)建議6、SpringCloud依托于springSpringcloud技術(shù)介紹1、springcloud:一個云應(yīng)用工具,為云應(yīng)用開發(fā)的配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、全局鎖定、決策競選、分布式會話和集群狀態(tài)管理等操作2、springcloudconfig:配置管理開發(fā)工具包3、springcloudBus:事件消息總線用于集群(例如:配置變化時間)中傳播狀態(tài)變化,與springcloudconfig聯(lián)合實現(xiàn)熱部署4、springcloudNetflixEureka:云端負載均衡基礎(chǔ),一個基于Rest的服務(wù),用于定位服務(wù),以實現(xiàn)云端的負載均衡和中間層服務(wù)器的故障轉(zhuǎn)移5、springcloudNetflix

Hystrix

:容錯管理工具,旨在通過控制服務(wù)和第三方庫的節(jié)點,從而對延遲和故障提供更強大的容錯能力6、Netflix

ZUUL:邊緣服務(wù)工具,提供動態(tài)路由、監(jiān)控、彈性、安全等邊緣服務(wù)7、springcloudsleuth:日志收集工具包、封裝Purpose、Zipkin和Trace8、

Spring

Cloud

Security:安全工具包,為應(yīng)用程序添加安全控制,主要是OAuth2

9、springcloudturbine:聚合服務(wù)器發(fā)送時間流,監(jiān)控集群下Netflix和metrics情況Springcloud技術(shù)介紹1、springclouSpringcloud技術(shù)介紹-配置中心Springcloud技術(shù)介紹-配置中心Springcloud技術(shù)介紹-注冊中心Springcloud技術(shù)介紹-注冊中心Springcloud技術(shù)介紹-網(wǎng)關(guān)服務(wù)路由、安全認證、會話共享、客戶端負載均衡、統(tǒng)一異常處理、跨域請求Springcloud技術(shù)介紹-網(wǎng)關(guān)服務(wù)路Springcloud技術(shù)介紹-斷路由Springcloud技術(shù)介紹-斷路由Springcloud技術(shù)介紹-ELKlogbackELK負責(zé)平臺級服務(wù)日志收集及展示由springcloudsleuthzipkin負責(zé)Springcloud技術(shù)介紹-ELKlogba

SpringCloud架構(gòu)實現(xiàn)計劃-平臺能力規(guī)劃SpringCloud架構(gòu)實現(xiàn)計劃-平臺能力規(guī)劃彈性擴容平臺搭建基礎(chǔ)模塊設(shè)計過程管理能力完善業(yè)務(wù)開發(fā)平臺支持能力完善

容器化部署應(yīng)用無縫遷移基于springcloud服務(wù)化平臺組件安裝、配置SSO、SGOV認證SESSION共享異常、日志、緩存封裝統(tǒng)一權(quán)限管理監(jiān)控預(yù)警管理依賴基于容器的可視化部署平臺開發(fā),測試環(huán)境CI/CO流水線建設(shè)統(tǒng)一接口描述,完善設(shè)計開發(fā)規(guī)范接口自動化測試對實例進行健康檢查和關(guān)鍵指標(biāo)監(jiān)控實現(xiàn)資源的彈性管理(擴容或者減少服務(wù)節(jié)點)

SpringCloud架構(gòu)實現(xiàn)計劃-里程碑實現(xiàn)計劃彈性平臺搭建基礎(chǔ)模塊設(shè)計過程管理容器化部署基于sprin

SpringCloud架構(gòu)實現(xiàn)計劃-總體技術(shù)分層SpringCloud架構(gòu)實現(xiàn)計劃-總體技術(shù)分層

SpringCloud架構(gòu)實現(xiàn)計劃-一期實現(xiàn)技術(shù)SpringCloud架構(gòu)實現(xiàn)計劃-一期實現(xiàn)技術(shù)

SpringCloud架構(gòu)實現(xiàn)計劃-一期實現(xiàn)技術(shù)SpringCloud架構(gòu)實現(xiàn)計劃-一期實現(xiàn)技術(shù)

SpringCloud一期微服務(wù)初步劃分SpringCloud一期微服務(wù)初步劃分SpringCloud一期微服務(wù)架構(gòu)實現(xiàn)SpringCloud一期微服務(wù)架構(gòu)實現(xiàn)SpringCloud一期微服務(wù)部署實現(xiàn)SpringCloud一期微服務(wù)部署實現(xiàn)

SpringCloud架構(gòu)實現(xiàn)計劃-二期實現(xiàn)技術(shù)SpringCloud架構(gòu)實現(xiàn)計劃-二期實現(xiàn)技術(shù)謝謝觀看ThankYou!謝謝觀看ThankYou!討論內(nèi)容SOA、ESB、SAAS、PAAS

、IaaS

、微服務(wù)1:互聯(lián)網(wǎng)高可用性(HA)3:SpringCloud和dubbo比較4:

SpringCloud架構(gòu)技術(shù)描述5:互聯(lián)網(wǎng)高并發(fā)2:

互聯(lián)話題:獨立訪問者數(shù)量(uniquevisitors)、重復(fù)訪問者數(shù)量(repeatvisitors)、頁面瀏覽數(shù)(pageviews)理解

SpringCloud架構(gòu)實現(xiàn)計劃6:討論內(nèi)容SOA、ESB、SAAS、PAAS、IaaSOA(面向服務(wù)的架構(gòu))

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

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

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

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

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

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

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

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

系統(tǒng)能夠提供什么樣的開發(fā)工具,支持什么樣的開發(fā)模式,系統(tǒng)運行情況是否可以及時了解,是否可以及時獲取故障信息,是否可以提供運行狀態(tài)信息,以利于系統(tǒng)的優(yōu)化。SOA(面向服務(wù)的架構(gòu))ESB(企業(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ù)。ESB(企業(yè)服務(wù)總線)SOA與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可在多個提供者、提供者的負載平衡及停止使用提供者(當(dāng)

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論