互聯(lián)網(wǎng)金融微服務架構(gòu)設計

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

2、，描述服務提供哪些功能，適用服務有哪些要求 服務的注冊和查找問題，定義好的服務信息在哪發(fā)布，如何發(fā)布，到哪查找，如何查找 服務通訊方式，包括具體如何向服務發(fā)送請求，并獲取應答，支持什么樣的交互方式。 服務流程問題，對服務流程的靈活定制，執(zhí)行監(jiān)控等提供管理 服務的管理問題，服務的提供，撤銷，改變這些情況如何進行管理 服務質(zhì)量問題，如何保障安全性，通訊的可靠性，以及事務完整性如何保證 整個系統(tǒng)的效率問題，包括查找效率，通訊效率，服務運行處理效率等 系統(tǒng)能夠提供什么樣的開發(fā)工具，支持什么樣的開發(fā)模式，系統(tǒng)運行情況是否可以及時了解，是否可以及時獲取故障信息，是否可以提供運行狀態(tài)信息，以利于系統(tǒng)的優(yōu)化。

3、,ESB（企業(yè)服務總線）,ESB全稱為Enterprise Service Bus，即企業(yè)服務總線。它是傳統(tǒng)中間件技術(shù)與XML、Web服務等技術(shù)結(jié)合的產(chǎn)物。ESB提供了網(wǎng)絡中最基本的連接中樞，是構(gòu)筑企業(yè)神經(jīng)系統(tǒng)的必要元素。,大規(guī)模分布式的企業(yè)應用需要相對簡單而實用的中間件技術(shù)來簡化和統(tǒng)一越來越復雜、繁瑣的企業(yè)級信息系統(tǒng)平臺。面向服務體系架構(gòu)（SOA）是能夠?qū)贸绦虻牟煌δ軉卧ㄟ^服務之間定義良好的接口和契約聯(lián)系起來。SOA使用戶可以不受限制地重復使用軟件、把各種資源互連起來，只要IT人員選用標準接口包裝舊的應用程序、把新的應用程序構(gòu)建成服務，那么其他應用系統(tǒng)就可以很方便的使用這些功能服務。

4、,SOA 與 ESB的區(qū)別,SOA是一種方式或架構(gòu)，用于具有自服務功能的應用程序，應用程序隨后通過用戶接口（UI）或經(jīng)過工作流將其聚合成用戶需要的功能。服務不僅是可復用代碼的組件，更是運行程序的一部分，客戶端可以不必合并它自己的代碼直接調(diào)用該程序。服務是與業(yè)務相關(guān)的一個定義。 ESB是用于調(diào)節(jié) SOA 中的調(diào)用者及服務提供者的機制。它使得調(diào)用者在不知道提供者或提供者使用的地址的情況下調(diào)用該服務。ESB 可在多個提供者、提供者的負載平衡及停止使用提供者（當失效時）之間進行選擇，并且基于調(diào)用者的需求在提供者之間進行選擇，這些提供者提供了各種質(zhì)量級別的服務。ESB 能夠調(diào)節(jié)同步或異步服務，事實上對于

5、同一服務可以提供同步及異步的訪問。 因此 SOA 和 ESB 是相對應的。具備 SOA 的應用程序應當使用 ESB 來調(diào)用它的服務。SOA 和 ESB 不必用 Web 服務實現(xiàn)。然而，經(jīng)常需要 ESB 來調(diào)用服務，該服務提供自我描述及發(fā)現(xiàn)的能力，這由 Web 服務幫助完成。在 SOA 中經(jīng)常需要由一種技術(shù)實現(xiàn)的調(diào)用者，它們用于調(diào)用由其它技術(shù)實現(xiàn)的服務，這也由 Web 服務幫助完成。所以 SOA、ESB 和 Web 服務都集中于創(chuàng)建這樣的領域：一個應用程序中的功能在其它應用程序中也是可用的，本質(zhì)是復用性。,SAAS (軟件即服務),SaaS是Software-as-a-Service（軟件即服務

6、）的簡稱,它與“on-demand software”（按需軟件)，the application service provider(ASP，應用服務提供商)，hosted software(托管軟件)所具有相似的含義。它是一種通過Internet提供軟件的模式，廠商將應用軟件統(tǒng)一部署在自己的服務器上，客戶可以根據(jù)自己實際需求，通過互聯(lián)網(wǎng)向廠商定購所需的應用軟件服務，按定購的服務多少和時間長短向廠商支付費用，并通過互聯(lián)網(wǎng)獲得廠商提供的服務。,對企業(yè)來說，SaaS的優(yōu)點： 從技術(shù)方面來看：SaaS是簡單的部署，不需要購買任何硬件，剛開始只需要簡單注冊即可。企業(yè)無需再配備IT方面的專業(yè)技術(shù)人員，同

7、時又能得到最新的技術(shù)應用，滿足企業(yè)對信息管理的需求。 從投資方面來看：企業(yè)只以相對低廉的“月費”方式投資，不用一次性投資到位，不占用過多的營運資金，從而緩解企業(yè)資金不足的壓力；不用考慮成本折舊問題，并能及時獲得最新硬件平臺及最佳解決方案。 從維護和管理方面來看：由于企業(yè)采取租用的方式來進行物流業(yè)務管理，不需要專門的維護和管理人員，也不需要為維護和管理人員支付額外費用。很大程度上緩解企業(yè)在人力、財力上的壓力，使其能夠集中資金對核心業(yè)務進行有效的運營；SaaS能使用戶在世界上都是一個完全獨立的系統(tǒng)。如果您連接到網(wǎng)絡，就可以訪問系統(tǒng)。 對企業(yè)來說，SaaS的缺點 1.安全性：企業(yè)，尤其是大型企業(yè)，很

8、不情愿使用SaaS正是因為安全問題，他們要保護他們的核心數(shù)據(jù)，不希望這些核心數(shù)據(jù)由第三方來負責。 2.標準化：SaaS解決方案缺乏標準化。這個行業(yè)剛剛起步，沒有明確的解決辦法，一家公司可以設計建立一個解決方案。鑒于復雜和高度可定制的ERP產(chǎn)品，這是一個冒險的建議。,PAAS(平臺即服務),PaaS是Platform-as-a-Service的縮寫，意思是平臺即服務。 把服務器平臺作為一種服務提供的商業(yè)模式。通過網(wǎng)絡進行程序提供的服務稱之為SaaS(Software as a Service)，而云計算時代相應的服務器平臺或者開發(fā)環(huán)境作為服務進行提供就成為了PaaS(Platform as a

9、Service)。 所謂PaaS實際上是指將軟件研發(fā)的平臺（計世資訊定義為業(yè)務基礎平臺）作為一種服務，以SaaS的模式提交給用戶。因此，PaaS也是SaaS模式的一種應用。但是，PaaS的出現(xiàn)可以加快SaaS的發(fā)展，尤其是加快SaaS應用的開發(fā)速度。在2007年國內(nèi)外SaaS廠商先后推出自己的PAAS平臺。,PaaS區(qū)別 簡單地說，PaaS平臺就是指云環(huán)境中的應用基礎設施服務，也可以說是中間件即服務。PaaS平臺在云架構(gòu)中位于中間層，其上層是SaaS，其下層是IaaS3 。在傳統(tǒng)On-Premise部署方式下，應用基礎設施即中間件的種類非常多， 有應用服務器，數(shù)據(jù)庫，ESBs, BPM, Po

10、rtal,消息中間件，遠程對象調(diào)用中間件等等。對于PaaS平臺，Gartner把它們分為兩類，一類是應用部署和運行平臺APaaS（application platform as a service)，另一類是集成平臺IPaaS（integration as a service）。 人們經(jīng)常說的PaaS平臺基本上是指APaaS，如Force和Google App Engine。 國內(nèi)日前上線的中國云應用平臺，能夠為軟件廠商提供領先的IaaS基礎平臺，使得軟件廠商能夠?qū)⒆⒁饬性谄鋺卯a(chǎn)品的云化之上，而將對基礎資源的需求，包括云服務器、云存儲、云監(jiān)控等完全依托在理念領先、技術(shù)成熟、安全可靠的Ia

11、aS平臺上。,IaaS (基礎設施即服務),IaaS（Infrastructure as a Service），即基礎設施即服務。 消費者通過Internet 可以從完善的計算機基礎設施獲得服務。這類服務稱為基礎設施即服務?；?Internet 的服務（如存儲和數(shù)據(jù)庫）是 IaaS的一部分。Internet上其他類型的服務包括平臺即服務（Platform as a Service，PaaS）和軟件即服務（Software as a Service，SaaS）。PaaS提供了用戶可以訪問的完整或部分的應用程序開發(fā)，SaaS則提供了完整的可直接使用的應用程序，比如通過 Internet管理企業(yè)資

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

13、SS,WS/SOA/API）,PaaS中間件 （包括應用服務器MQ/ESB/SOA,多層次多租戶SaaS模式支撐,Hypervisor,OSGI等）,IaaS 、 PaaS、 SaaS,1. SaaS：提供給客戶的服務是運營商運行在云計算基礎設施上的應用程序，用戶可以在各種設備上通過客戶端界面訪問，如瀏覽器。消費者不需要管理或控制任何云計算基礎設施，包括網(wǎng)絡、服務器、操作系統(tǒng)、存儲等等； 2. PaaS：提供給消費者的服務是把客戶采用提供的開發(fā)語言和工具（例如Java，python, .Net等）開發(fā)的 或收購的應用程序部署到供應商的云計算基礎設施上去?？蛻舨恍枰芾砘蚩刂频讓拥脑苹A設施，包

14、括網(wǎng)絡、服務器、操作系統(tǒng)、存儲等，但客戶能控制部署的應用程序，也可能控制運行應用程序的托管環(huán)境配置； 3. IaaS：提供給消費者的服務是對所有計算基礎設施的利用，包括處理CPU、內(nèi)存、存儲、網(wǎng)絡和其它基本的計算資源，用戶能夠部署和運行任意軟件，包括操作系統(tǒng)和應用程序。消費者不管理或控制任何云計算基礎設施，但能控制操作系統(tǒng)的選擇、存儲空間、部署的應用，也有可能獲得有限制的網(wǎng)絡組件（例如路由器、，防火墻，、負載均衡器等）的控制。,SOA和SaaS的區(qū)別,1. SOA包括了關(guān)于軟件是如何被架構(gòu)起來的東西，而SaaS是關(guān)于軟件是如何被應用的。 2. 在SaaS當中，應用程序可以像任何服務一樣被傳遞，

15、就像你家中電話的語音一樣，看起來似乎就是為你的需求量體裁衣得到的。而SOA的定義和這個無絲毫的聯(lián)系。SOA支持的服務，都是些離散的可以再使用的事務處理，這些事務處理合起來就組成了一個業(yè)務流程，是從基本的系統(tǒng)中提取出來的抽象代碼。 3. SOA是一個框架的方法，而SaaS是一種傳遞模型。 4. 通過SaaS傳遞Web服務并不需要SOA。 5. SaaS主要是指一個軟件企業(yè)向其它企業(yè)提供軟件服務。而SOA一般是企業(yè)內(nèi)部搭建系統(tǒng)的基礎。SaaS注重的是提供服務的思維。而SOA注重的是實現(xiàn)服務的思維。,什么是微服務架構(gòu),微服務架構(gòu)模式（Microservice Architect Pattern）。近

16、兩年在服務的瘋狂增長與云計算技術(shù)的進步，讓微服務架構(gòu)受到重點關(guān)注,微服務架構(gòu)是一種架構(gòu)模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協(xié)調(diào)、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常是基于HTTP的RESTful API）。每個服務都圍繞著具體業(yè)務進行構(gòu)建，并且能夠被獨立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應盡量避免統(tǒng)一的、集中式的服務管理機制，對具體的一個服務而言，應根據(jù)業(yè)務上下文，選擇合適的語言、工具對其進行構(gòu)建。,微服務架構(gòu)優(yōu)勢 首先簡單介紹了微服務（Microservices）的內(nèi)涵及優(yōu)勢，他表示，微服務架構(gòu)的

17、本質(zhì)，是用一些功能比較明確、業(yè)務比較精練的服務去解決更大、更實際的問題。微服務架構(gòu)將服務拆分，分別采用相對獨立的服務對各方面進行管理，彼此之間使用統(tǒng)一的接口來進行交流，架構(gòu)變得復雜，優(yōu)勢也很明顯： 復雜度可控：在將應用分解的同時，規(guī)避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規(guī)模開發(fā)團隊完全掌控，易于保持高可維護性和開發(fā)效率。,什么是微服務架構(gòu),微服務架構(gòu)優(yōu)勢 獨立部署：由于微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發(fā)生變更時無需編譯、部署整個應用。由微服務組成的應用相當于具備

18、一系列可并行的發(fā)布流程，使得發(fā)布更加高效，同時降低對生產(chǎn)環(huán)境所造成的風險，最終縮短應用交付周期。 技術(shù)選型靈活：微服務架構(gòu)下，技術(shù)選型是去中心化的。每個團隊可以根據(jù)自身服務的需求和行業(yè)發(fā)展的現(xiàn)狀，自由選擇最適合的技術(shù)棧。由于每個微服務相對簡單，當需要對技術(shù)棧進行升級時所面臨的風險較低，甚至完全重構(gòu)一個微服務也是可行的。 容錯：當某一組建發(fā)生故障時，在單一進程的傳統(tǒng)架構(gòu)下，故障很有可能在進程內(nèi)擴散，形成應用全局性的不可用。在微服務架構(gòu)下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩(wěn)退化等機制實現(xiàn)應用層面的容錯。 擴展：單塊架構(gòu)應用也可以實現(xiàn)橫向擴展，就是將整個應用完整的復制到不

19、同的節(jié)點。當應用的不同組件在擴展需求上存在差異時，微服務架構(gòu)便體現(xiàn)出其靈活性，因為每個服務可以根據(jù)實際需求獨立進行擴展。,SOA和微服務架構(gòu)的區(qū)別,如果一句話來談SOA和微服務的區(qū)別，即微服務不再強調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務總線，同時SOA的思想進入到單個業(yè)務系統(tǒng)內(nèi)部實現(xiàn)真正的組件化。 微服務架構(gòu)強調(diào)的第一個重點就是業(yè)務系統(tǒng)需要徹底的組件化和服務化，原有的單個業(yè)務系統(tǒng)會拆分為多個可以獨立開發(fā)，設計，運行和運維的小應用。這些小應用之間通過服務完成交互和集成。每個小應用從前端web ui，到控制層，邏輯層，數(shù)據(jù)庫訪問，數(shù)據(jù)庫都完全是獨立的一套。在這里我們不用組件而用小應用這個詞更加

20、合適，每個小應用除了完成自身本身的業(yè)務功能外，重點就是還需要消費外部其它應用暴露的服務，同時自身也將自身的能力朝外部發(fā)布為服務。,首先對于應用本身暴露出來的服務，是和應用一起部署的，即服務本身并不單獨部署，服務本身就是業(yè)務組件已有的接口能力發(fā)布和暴露出來的,其次微服務架構(gòu)本身來源于互聯(lián)網(wǎng)的思路，因此組件對外發(fā)布的服務強調(diào)了采用HTTP Rest API的方式來進行。,微服務的基本思想在于考慮圍繞著業(yè)務領域組件來創(chuàng)建應用，這些就應用可獨立地進行開發(fā)、管理和加速。在分散的組件中使用微服務云架構(gòu)和平臺使部署、管理和服務功能交付變得更加簡單。,互聯(lián)網(wǎng)高并發(fā)相關(guān)名詞,頁面瀏覽數(shù)（page views ）

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

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

23、st比Vector性能好。),互聯(lián)網(wǎng)高并發(fā)系統(tǒng)-需要解決的問題,一：應用緩存,二：HTTP緩存,三：多級緩存,四：池化,五：異步并發(fā),六：擴容,七：隊列,高并發(fā)-應用緩存,堆緩存 使用Java堆內(nèi)存來存儲緩存對象。使用堆緩存的好處是沒有序列化/反序列化，是最快的緩存。缺點也很明顯，當緩存的數(shù)據(jù)量很大時，GC（垃圾回收）暫停時間會變長，存儲容量受限于堆空間大小。一般通過軟引用/弱引用來存儲緩存對象，即當堆內(nèi)存不足時，可以強制回收這部分內(nèi)存釋放堆內(nèi)存空間。一般使用堆緩存存儲較熱的數(shù)據(jù)。有Guava Cache、Ehcache 3.x、MapDB實現(xiàn),堆外緩存 即緩存數(shù)據(jù)存儲在堆外內(nèi)存，可以減少GC

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

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

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

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

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

29、形式對以后的擴展有了很大的限制，當我由10個分區(qū)增加到20個的時候，所有的數(shù)據(jù)都得重新分區(qū)，那么將是一個的很龐大的計算量；以下提供幾種常見的算法： 哈希算法：就是采用user_id%的方式; 范圍：可以根據(jù)user_id字符值范圍分區(qū)，如1-1000為一區(qū)，1001-2000則是另一個區(qū)等； 映射關(guān)系：就是將user_id存在的所對應的分區(qū)放在數(shù)據(jù)庫中保存，當用戶操作時先去查詢所在分區(qū)，再進行操作；,高并發(fā)-擴容分布式數(shù)據(jù)庫,4、分布式數(shù)據(jù)庫（終極方案）：TDSQL架構(gòu)采用自動擴容機制、分表邏輯、擴容流程、容災機制、強同步方案解決分布式數(shù)據(jù)庫擴容方案,高并發(fā)-擴容分布式數(shù)據(jù)庫,系統(tǒng)由三個模塊組

30、成：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)，當set內(nèi)主節(jié)點故障，發(fā)起高一致性主備切換流程；4、監(jiān)控各個set的CPU、磁盤容量、各個表的資源消耗情況，必要的時候自動發(fā)起擴容流程；5、Scheduler自身的容災通過ZooKeqzer的選舉機制完成，保證中心控制節(jié)點無單點。 Agent模塊

31、負責監(jiān)控本機MySQL實例的運行情況，主要功能包括： 1、用短連接的方式周期性訪問本機的MySQL實例，檢測是否可讀、可寫，若發(fā)生異常，會將異常信息上報到ZooKeeper，最終會由上面描述的Scheduler模塊檢測到這個異常情況，從而發(fā)起容災切換； 2、檢測主備復制的執(zhí)行情況，會定期上報主備復制的延時和延遲的事務數(shù)，若發(fā)生了主備切換，自動向新主機重建主備，因此MySQL的主備不需要DBA干預，對于新增的實例會自動采用xtrabackup通過主機自動重建數(shù)據(jù)；,高并發(fā)-擴容分布式數(shù)據(jù)庫,3、檢測MySQL實例的CPU利用率和各個表的請求量、數(shù)據(jù)量、CPU利用率，上報到ZooKeeper，Zo

32、oKeeper通過全局的資源情況抉擇如何擴容、縮容； 監(jiān)控是否有下發(fā)到自身的擴容任務，如有則會執(zhí)行擴容流程（下面會有描述）； 監(jiān)控是否要發(fā)生容災切換，并按計劃執(zhí)行主備切換流程。 網(wǎng)關(guān)基于MySQL Proxy開發(fā)，在網(wǎng)絡層、連接管理、SQL解析、路由等方面做了大量優(yōu)化，主要特點和功能如下： 1、解析SQL，將識別出的DDL語句直接存到ZooKeeper，讓Keeper來統(tǒng)一調(diào)度； 2、Watch ZooKeeper的路由信息，拉取最新的路由表保存到本地文件和內(nèi)存； 3、將SQL請求路由到對應的set，支持讀寫分離； 4、對接入的IP、用戶名、密碼進行鑒權(quán)； 5、記錄完整的SQL執(zhí)行信息，與秒級

33、監(jiān)控平臺對接完成實時的SQL請求的時耗，成功率等指標監(jiān)控分析； 6、對count、distinct、sum、avg、max、min、order by、group by等聚合類SQL一般需要訪問后端的多個set，網(wǎng)關(guān)會分析結(jié)果并做合并再返回，暫不支持跨set join和分布式事務； 7、網(wǎng)關(guān)無狀態(tài)，既支持與業(yè)務部署到一起，也可以獨立部署（可通過TGW或者LVS做容災）。,高并發(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運行時推送同步配置到nod

34、e節(jié)點 b. node節(jié)點將同步狀態(tài)反饋到manager上 3. 基于zookeeper，解決分布式狀態(tài)調(diào)度的，允許多node節(jié)點之間協(xié)同工作.,高并發(fā)-隊列應用場景,1、異步處理：使用隊列的一個主要原因是進行異步處理，比如用戶注冊完成后，需要發(fā)送注冊成功郵件/新用戶積分/優(yōu)惠卷等；緩存過期時，先返回過期數(shù)據(jù)，然后異步更新緩存、異步寫日志等。,2、系統(tǒng)解耦：比如用戶支付完成訂單后，需要通知生產(chǎn)配貨系統(tǒng)、發(fā)票系統(tǒng)、庫存系統(tǒng)、推薦系統(tǒng)、搜索系統(tǒng)等進行業(yè)務處理。,3、數(shù)據(jù)同步：比如想把mysql變更的數(shù)據(jù)同步到Redis，或者將mysql數(shù)據(jù)同步到mongodb,或者讓機房之間的數(shù)據(jù)同步，或者主從數(shù)

35、據(jù)同步等，有相關(guān)軟件：databus、canal、otter等。使用數(shù)據(jù)總線隊列進行數(shù)據(jù)同步的好處是可以保證數(shù)據(jù)修改的有序。,4、流量削峰：系統(tǒng)的瓶頸一般在數(shù)據(jù)庫上，比如扣減庫存、下單等，此時可以考慮使用隊列將變更請求暫時放入隊列，通過緩存+隊列暫存的方式將數(shù)據(jù)庫流量削峰。同樣，對于秒殺系統(tǒng)，下單服務會是該系統(tǒng)的瓶頸，此時可以使用隊列進行排隊和限流，從而保護下單服務，通過隊列暫存或者隊列限流進行流量削峰,高并發(fā)-隊列（ Canal ）,1、Canal 同步緩存,2、Canal 下發(fā)任務給消息隊列,高可用,什么是高可用性,高可用性（HA）系統(tǒng)是目前企業(yè)防止核心計算機系統(tǒng)因故障停機的最有效手段。

36、高可用性（HA）的功能 1、軟件故障監(jiān)測與排除 2、備份和數(shù)據(jù)保護 3、管理站能夠監(jiān)視各站點的運行情況，能隨時或定時報告系統(tǒng)運行狀況，故障能及時報告和告警，并有必要的控制手段 4、實現(xiàn)錯誤隔離以及主、備份服務器間的服務切換 HA的工作方式：HA有主從方式和雙工方式兩種工作模式 高可用性方案則利用更少的冗余部件同時由軟件檢測故障，一旦故障發(fā)生立即隔離損壞部件，通過提供故障恢復實現(xiàn)最大化系統(tǒng)和應用的可用性。 容錯技術(shù)隨著處理器速度的加快和價格的下跌而越來越多地轉(zhuǎn)移到軟件中。未來容錯技術(shù)將完全在軟件環(huán)境下完成，那時它和高可用性技術(shù)之間的差別也就隨之消失了。,互聯(lián)網(wǎng)高可用性（HA）系統(tǒng)-需要解決的問題

37、,一：負載均衡與反向代理,二：隔離,三：限流,四：降級,五：超時與重試,六：回滾,七：壓力測試與應急預案,高可用-負載均衡,負載均衡 建立在現(xiàn)有網(wǎng)絡結(jié)構(gòu)之上，它提供了一種廉價有效透明的方法擴展網(wǎng)絡設備和服務器的帶寬、增加吞吐量、加強網(wǎng)絡數(shù)據(jù)處理能力、提高網(wǎng)絡的靈活性和可用性。,軟件負載均衡解決方案是指在一臺或多臺服務器相應的操作系統(tǒng)上安裝一個或多個附加軟件來實現(xiàn)負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優(yōu)點是基于特定環(huán)境，配置簡單，使用靈活，成本低廉，可以滿足一般的負載均衡需求。 軟件解決方案缺點也較多，因為每

38、臺服務器上安裝額外的軟件運行會消耗系統(tǒng)不定量的資源，越是功能強大的模塊，消耗得越多，所以當連接請求特別大的時候，軟件本身會成為服務器工作成敗的一個關(guān)鍵；軟件可擴展性并不是很好，受到操作系統(tǒng)的限制；由于操作系統(tǒng)本身的Bug，往往會引起安全問題。,硬件負載均衡解決方案是直接在服務器和外部網(wǎng)絡間安裝負載均衡設備，這種設備通常稱之為負載均衡器，由于專門的設備完成專門的任務，獨立于操作系統(tǒng)，整體性能得到大量提高，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。,高可用-反向代理,反向代理（Reverse Proxy）方式是指以代理服務器來接受internet上的連接請求，然后將請求

39、轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡上的服務器，并將從服務器上得到的結(jié)果返回給internet上請求連接的客戶端，此時代理服務器對外就表現(xiàn)為一個反向代理服務器。,代理服務器有三種： 1 標準的代理緩沖服務器 一個標準的代理緩沖服務被用于緩存靜態(tài)的網(wǎng)頁（例如：html文件和圖片文件等）到本地網(wǎng)絡上的一臺主機上（即代理服務器）。 2 透明代理緩沖服務器 透明代理緩沖服務和標準代理服務器的功能完全相同。但是，代理操作對客戶端的瀏覽器是透明的（即不需指明代理服務器的IP和端口）。 3 反向代理緩沖服務器 反向代理是和前兩種代理完全不同的一種代理服務。使用它可以降低原始WEB服務器的負載。反向代理服務器承擔了對原始WEB服務

40、器的靜態(tài)頁面的請求，防止原始服務器過載。 安全反向代理用途： 可以提供從防火墻外部代理服務器到防火墻內(nèi)部安全內(nèi)容服務器的加密連接。 可以允許客戶機安全地連接到代理服務器，從而有利于安全地傳輸信息。 安全反向代理會造成各安全連接加密數(shù)據(jù)所涉及的系統(tǒng)開銷而變慢。 SSL 提供了高速緩存機制，連接雙方重復使用先前協(xié)商的安全參數(shù)，大大降低后續(xù)連接的系統(tǒng)開銷。,高可用-隔離術(shù),線程隔離: 線程隔離主要是指線程池隔離，在實際使用時，我們會把請求分類，然后交給不同的線程池處理。當一種業(yè)務的請求處理發(fā)生問題時，不會將故障擴散到其他線程池，從而保證其他服務可用。,進程隔離 由于傳統(tǒng)的系統(tǒng)所有功能都集中在一個系統(tǒng)

41、中，為了避免系統(tǒng)其中一個模塊功能出現(xiàn)問題導致整個系統(tǒng)無法使用的情況發(fā)生，將其該系統(tǒng)拆分成多子系統(tǒng)實現(xiàn)物理隔離，故通過進程隔離使得某一個子系統(tǒng)出現(xiàn)問題時不影響到其他子系統(tǒng)。,集群隔離 隨著調(diào)用方的增多，當秒殺（并發(fā)量特別大功能）類似的服務被刷新會影響到其他服務的穩(wěn)定性時，應該考慮為秒殺（并發(fā)量特別大功能）類似的服務提供單獨的服務集群，即分服務分組，這樣當某一個分組出現(xiàn)問題時，不會影響到其他分組，從而實現(xiàn)了故障隔離愿景。,機房隔離 隨著對系統(tǒng)可用性的要求，會進行多機房部署，每一個機房的服務都有自己的服務分組，本機房的服務應該只調(diào)用本機房的服務，不進行跨機房調(diào)用。其中，一個機房服務發(fā)生問題時，可以通

42、過DNS/負載均衡將請求全部切到另一個機房，或者考慮服務能自動重試其他機房的服務，從而提升系統(tǒng)可用性。,高可用-隔離術(shù),讀寫隔離 為了提高數(shù)據(jù)訪問，一般采用redis主從模式將讀和寫進群分離，在正常情況下，當主redis集群出現(xiàn)問題時，從redis集群還是可以用的，從而不影響用戶的訪問。,動靜隔離 例如當用戶訪問如結(jié)算頁時，如果JS/CSS等靜態(tài)資源也在結(jié)算頁系統(tǒng)中時，很可能因為訪問量太大導致帶寬被打滿導致出現(xiàn)不可用。 為了不影響結(jié)算等用戶操作的功能，將其JS/CSS等靜態(tài)資源靜態(tài)化與用戶操作功能分開部署。,資源隔離 最常見的資源如磁盤、CPU、網(wǎng)絡；對于寶貴的資源都會存在競爭問題。 我們可以

43、使用JIMDB數(shù)據(jù)同步時要dump數(shù)據(jù)，SSD盤容量用了50%以上，dump到同一塊磁盤時遇到了容量不足的問題，我們通過單獨掛一塊SAS盤來專門同步數(shù)據(jù)。還有如使用Docker容器時，有的容器寫磁盤非常頻繁，因此要考慮為不同的容器掛載不同的磁盤。,高可用-限流,在開發(fā)高并發(fā)系統(tǒng)時有三把利器用來保護系統(tǒng)：緩存、降級和限流。緩存的目的是提升系統(tǒng)訪問速度和增大系統(tǒng)能處理的容量，可謂是抗高并發(fā)流量的銀彈；而降級是當服務出問題或者影響到核心流程的性能則需要暫時屏蔽掉，待高峰或者問題解決后再打開；而有些場景并不能用緩存和降級來解決，比如稀缺資源（秒殺、搶購）、寫服務（如評論、下單）、頻繁的復雜查詢（評論的

44、最后幾頁），因此需有一種手段來限制這些場景的并發(fā)/請求量，即限流。 限流的目的是通過對并發(fā)訪問/請求進行限速或者一個時間窗口內(nèi)的的請求進行限速來保護系統(tǒng)，一旦達到限制速率則可以拒絕服務（定向到錯誤頁或告知資源沒有了）、排隊或等待（比如秒殺、評論、下單）、降級（返回兜底數(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模塊，限制每秒的平均速率）；其他還有

45、如限制遠程接口調(diào)用速率、限制MQ的消費速率。另外還可以根據(jù)網(wǎng)絡連接數(shù)、網(wǎng)絡流量、CPU或內(nèi)存負載等來限流。,高可用-降級,降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結(jié)算）。 降級預案 在進行降級之前要對系統(tǒng)進行梳理，看看系統(tǒng)是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日志級別設置預案： 一般：比如有些服務偶爾因為網(wǎng)絡抖動或者服務正在上線而超時，可以自動降級； 警告：有些服務在一段時間內(nèi)成功率有波動（如在95100%之間），可以自動降級或人工降級，并發(fā)送告警； 錯誤：比如可用率低于90%，或者數(shù)據(jù)庫連接池被打爆了，或者訪問

46、量突然猛增到系 統(tǒng)能承受的最大閥值，此時可以根據(jù)情況自動降級或者人工降級； 嚴重錯誤：比如因為特殊原因數(shù)據(jù)錯誤了，此時需要緊急人工降級。 降級按照是否自動化可分為：自動開關(guān)降級和人工開關(guān)降級。 降級按照功能可分為：讀服務降級、寫服務降級。 降級按照處于的系統(tǒng)層次可分為：多級降級。 降級的功能點主要從服務端鏈路考慮，即根據(jù)用戶訪問的服務調(diào)用鏈路來梳理哪里需要降級： 頁面降級、頁面片段降級、頁面異步請求降級、服務功能降級、讀降級、寫降級 自動開關(guān)降級：超時降級、統(tǒng)計失敗次數(shù)降級、故障降級、限流降級 人工開關(guān)降級：讀服務降級、寫服務降級,高可用-超時與重試,在實際開發(fā)過程中，我們見過太多故障時因為沒

47、有設置超時或者設置得不對而造成的，而這些故障都是因為沒有意識到超時設置的重要性而造成的。如果應用不設置超時，則可能會導致請求響應慢，慢請求積累導致連鎖反應，甚至造成應用雪塌。而有些中間件或者框架在超時后進行重試（例如dubbo默認重試兩次），讀服務天然適合重試，但寫服務大多不能重試（如寫訂單、支付等），重試次數(shù)太多會導致多倍請求流量。 例如模擬了Ddos攻擊（分布式拒絕服務(DDoS:Distributed Denial of Service)攻擊指借助于客戶/服務器技術(shù)，將多個計算機聯(lián)合起來作為攻擊平臺，對一個或多個目標發(fā)動DDoS，通常，攻擊者使用一個偷竊帳號將DDoS主控程序安裝在一個計

48、算機上，在一個設定的時間主控程序?qū)⑴c大量代理程序通訊，代理程序已經(jīng)被安裝在網(wǎng)絡上的許多計算機上。代理程序收到指令時就發(fā)動攻擊。利用客戶/服務器技術(shù)，主控程序能在幾秒鐘內(nèi)激活成百上千次代理程序的運行。），后果可能是災難，因此，務必設置合理的重試機制，并且應該和熔斷、快速失敗機制配合。所以在進行代碼Review時，一定記得Review超時與重試機制。,高可用-回滾,事務回滾 在執(zhí)行數(shù)據(jù)庫SQL時，如果我們檢測到哦事務提交沖突，那么事務中所有執(zhí)行的SQL要進行回滾，目的是防止數(shù)據(jù)庫出現(xiàn)數(shù)據(jù)不一致。,代碼庫回滾 在開發(fā)項目時一定要將代碼維護到代碼倉庫，從而進行版本管理。有了版本控制系統(tǒng)后可記錄代碼的歷

49、史版本，在出現(xiàn)問題時候可以方便回滾。,部署版本回滾 代碼測試完成后，接下來要進行系統(tǒng)部署，在部署時要考慮當代碼邏輯出現(xiàn)錯誤后如何快速恢復,數(shù)據(jù)版本回滾 在設計消息隊列時，重要業(yè)務會對消息隊列進行副本處理，以便萬一業(yè)務邏輯出現(xiàn)問題能進行歷史數(shù)據(jù)回滾，從而修復問題。,靜態(tài)資源版本回滾 靜態(tài)化頁面資源后，每次內(nèi)容變更時我們都會生成一個全量新版本放到項目的文件目錄中，從而保證版本可追溯，出現(xiàn)問題時能及時回滾。,高可用-壓力測試,線下壓力測試 通過如Jmeter，Apac，he ab 壓力測試系統(tǒng)的某一個接口等（如登錄、查詢訂單）或者某一個組件（例如數(shù)據(jù)庫連接池），然后進行調(diào)優(yōu)（如調(diào)優(yōu)JVM參數(shù)，優(yōu)化代

50、碼等），實現(xiàn)單個接口或者組件的性能最優(yōu)。,線上壓力測試 線上壓力測試份方式非常多，按讀分為讀壓、寫壓測和混合壓測，按照數(shù)據(jù)仿真度分為仿真壓力測試和引流壓力測試，按照給用戶提供服務分為隔離集群壓力測試和線上集群壓力測試。,系統(tǒng)優(yōu)化和容災 拿到全面的壓力測試報告后，接下來就是分析報告，然后進行一些有這對性的優(yōu)化，如硬件升級、系統(tǒng)擴容、參數(shù)調(diào)優(yōu)、代碼優(yōu)化（代碼同步改異步）、架構(gòu)優(yōu)化（如加緩存、讀寫分離、歷史數(shù)據(jù)歸檔）等。在擴容時也需要考慮容災，比如分組部署、跨機房部署。容災是通過部署多組（單機房或多機房）相同系統(tǒng)，當其中一組出現(xiàn)問題時，可以切換到另一個分組，保證系統(tǒng)可用,高可用-應急預案,在系統(tǒng)壓力

51、測試之后發(fā)現(xiàn)一些系統(tǒng)瓶頸，在系統(tǒng)優(yōu)化之后會提升系統(tǒng)吐吞量并降低響應時間，容災之后的系統(tǒng)可用性得以保障，但還是會存在一些風險，如網(wǎng)絡抖動、某臺機器負載過高、某個服務變慢、數(shù)據(jù)庫Load值過高，為了防止因為這些問題而出現(xiàn)系統(tǒng)雪崩，需要針對這些情況制定應急預案，從而在出現(xiàn)突發(fā)情況時，有響應的措施來解決掉這些問題。 應急預案可按照如下幾步進行：首先進行系統(tǒng)分級，然后進行全鏈路分析、配置監(jiān)控，最后制定應急預案。,Dubbo詳細介紹,Dubbo 是阿里巴巴公司開源的一個高性能優(yōu)秀的服務框架，使得應用可通過高性能的 RPC 實現(xiàn)服務的輸出和輸入功能，可以和 Spring框架無縫集成。 主要核心部件： Rem

52、oting: 網(wǎng)絡通信框架，實現(xiàn)了 sync-over-async 和 request-response 消息機制. RPC: 一個遠程過程調(diào)用的抽象，支持負載均衡、容災和集群功能 Registry: 服務目錄框架用于服務的注冊和服務事件發(fā)布和訂閱,Dubbo服務集群-集群容錯模式,Dubbo 服務提供者集群與負載均衡,Dubbo架構(gòu)高并發(fā)高可用選型技術(shù),Dubbo大體部署圖,Spring Cloud 19個技術(shù),Spring Cloud 工具框架 1、Spring Cloud Config 配置中心，利用git集中管理程序的配置。 2、Spring Cloud Netflix 集成眾多Net

53、flix的開源軟件 3、Spring Cloud Bus 消息總線，利用分布式消息將服務和服務實例連接在一起，用于在一個集群中傳播狀態(tài)的變化 4、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的應用程序 5、Spring Cloud Cloud Foundry Service Broker 為建立管理云托管服務的服務代理提供了一個起點。 6、Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul實現(xiàn)的領導選舉和平民狀態(tài)模式的抽象和實現(xiàn)。 7、Spring Cloud

54、Consul 基于Hashicorp Consul實現(xiàn)的服務發(fā)現(xiàn)和配置管理。 8、Spring Cloud Security 在Zuul代理中為OAuth2 rest客戶端和認證頭轉(zhuǎn)發(fā)提供負載均衡 9、Spring Cloud Sleuth SpringCloud應用的分布式追蹤系統(tǒng)，和Zipkin，HTrace，ELK兼容。 10、Spring Cloud Data Flow 一個云本地程序和操作模型，組成數(shù)據(jù)微服務在一個結(jié)構(gòu)化的平臺上。,Spring Cloud 19個技術(shù),11、Spring Cloud Stream 基于Redis,Rabbit,Kafka實現(xiàn)的消息微服務，簡單聲明模型

55、用以在Spring Cloud應用中收發(fā)消息。 12、Spring Cloud Stream App Starters 基于Spring Boot為外部系統(tǒng)提供spring的集成 13、Spring Cloud Task 短生命周期的微服務，為SpringBooot應用簡單聲明添加功能和非功能特性。 14、Spring Cloud Task App Starters 15、Spring Cloud Zookeeper 服務發(fā)現(xiàn)和配置管理基于Apache Zookeeper。 16、Spring Cloud for Amazon Web Services 快速和亞馬遜網(wǎng)絡服務集成。 17、Spr

56、ing Cloud Connectors 便于PaaS應用在各種平臺上連接到后端像數(shù)據(jù)庫和消息經(jīng)紀服務。 18、Spring Cloud Starters （項目已經(jīng)終止并且在Angel.SR2后的版本和其他項目合并） 19、Spring Cloud CLI 插件用Groovy快速的創(chuàng)建Spring Cloud組件應用。 Spring Cloud共集成了19個子項目，里面都包含一個或者多個第三方的組件或者框架！,Spring Cloud和dubbo比較-背景,Dubbo，是阿里巴巴服務化治理的核心框架，并被廣泛應用于阿里巴巴集團的各成員站點(阿里巴巴現(xiàn)在使用架構(gòu)為HSF)。 于2012-10-

57、24最后版本2.5.3成為最后一版本，由當當接手維護，命名為dubbox Spring Cloud，從命名我們就可以知道，它是Spring Source的產(chǎn)物，Spring社區(qū)的強大背書可以說是Java企業(yè)界最有影響力的組織了，除了Spring Source之外，還有Pivotal和Netfix是其強大的后盾與技術(shù)輸出。其中Netflix開源的整套微服務架構(gòu)套件是Spring Cloud的核心。 如果拿Dubbo與Netflix套件做對比，前者在國內(nèi)影響力較大，后者在國外影響力較大，在背景上可以打個平手；但是若要與Spring Cloud做對比，由于Spring Source的加入，在背書上，Spring Cloud略勝一籌，但是在高并發(fā)上dubbo曾經(jīng)在阿里的運營中實際承載過過億用戶同時在線的，而Netflix 并沒有實際的上線應用中體現(xiàn)過。 Spring Cloud下面有19個子項目（可能還會新增）分別覆蓋了微服務架構(gòu)下的方方面面，服務治理只是其中的一個方面，一定程度來說，Dubbo只是Spring Cloud Netflix中的一個子集。但是在選擇框架上，方案完整度恰恰是一個需要重點關(guān)注的內(nèi)容，當然從高可用和高并發(fā)一起考慮，Spring Cloud 無疑是最佳選擇。,Spring cloud 架構(gòu)圖,Spring clou