微服務(wù)架構(gòu)起源簡(jiǎn)介及設(shè)計(jì)

微服務(wù)架構(gòu)

起源、簡(jiǎn)介及設(shè)計(jì)獨(dú)立架構(gòu)師唐偉佳現(xiàn)在是1頁(yè)\一共有49頁(yè)\編輯于星期五目錄微服務(wù)架構(gòu)起源1微服務(wù)與關(guān)聯(lián)理論2微服務(wù)架構(gòu)介紹3微服務(wù)應(yīng)用及平臺(tái)設(shè)計(jì)4微服務(wù)相關(guān)技術(shù)5現(xiàn)在是2頁(yè)\一共有49頁(yè)\編輯于星期五企業(yè)架構(gòu)

企業(yè)架構(gòu)是指對(duì)企業(yè)信息管理系統(tǒng)中具有體系的、普遍性的問(wèn)題而提供的通用解決方案，是基于業(yè)務(wù)導(dǎo)向和驅(qū)動(dòng)的架構(gòu)來(lái)理解、分析、設(shè)計(jì)、構(gòu)建、集成、擴(kuò)展、運(yùn)行和管理信息系統(tǒng)。企業(yè)架構(gòu)如同戰(zhàn)略規(guī)劃，可以輔助企業(yè)完成業(yè)務(wù)及IT戰(zhàn)略規(guī)劃。

業(yè)務(wù)架構(gòu)：是把企業(yè)的業(yè)務(wù)戰(zhàn)略轉(zhuǎn)化為日常運(yùn)作的渠道，業(yè)務(wù)戰(zhàn)略決定業(yè)務(wù)架構(gòu)，它包括業(yè)務(wù)的運(yùn)營(yíng)模式、流程體系、組織結(jié)構(gòu)、地域分布等內(nèi)容

IT架構(gòu)：指導(dǎo)IT投資和設(shè)計(jì)決策的IT框架，是建立企業(yè)信息系統(tǒng)的綜合藍(lán)圖，包括數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)和技術(shù)架構(gòu)三部分。現(xiàn)在是3頁(yè)\一共有49頁(yè)\編輯于星期五TOGAF架構(gòu)

TOGAF由國(guó)際標(biāo)準(zhǔn)權(quán)威組織TheOpenGroup制定。1993年開(kāi)始應(yīng)客戶要求制定系統(tǒng)架構(gòu)的標(biāo)準(zhǔn)，在1995年發(fā)表(TOGAF)架構(gòu)框架。TOGAF的基礎(chǔ)是美國(guó)國(guó)防部的信息管理技術(shù)架構(gòu)，是基于一個(gè)迭代的過(guò)程模型，支持最佳實(shí)踐和一套可重用的現(xiàn)有架構(gòu)資產(chǎn)。它可設(shè)計(jì)、評(píng)估、并建立組織的正確架構(gòu)。企業(yè)架構(gòu)方法有很多，但TOGAF是最主流的。現(xiàn)在是4頁(yè)\一共有49頁(yè)\編輯于星期五TOGAF產(chǎn)出物現(xiàn)在是5頁(yè)\一共有49頁(yè)\編輯于星期五TOGAF產(chǎn)出物現(xiàn)在是6頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)起源-企業(yè)轉(zhuǎn)型傳統(tǒng)企業(yè)的IT建設(shè)需要轉(zhuǎn)型，需要面向外部客戶，需要應(yīng)對(duì)外部環(huán)境的快速變化、需要快速創(chuàng)新，IT架構(gòu)也需要向互聯(lián)網(wǎng)企業(yè)學(xué)習(xí)作出相應(yīng)的改進(jìn)，來(lái)支撐企業(yè)的數(shù)字化轉(zhuǎn)型。先是單塊架構(gòu)，后來(lái)為了具備一定的擴(kuò)展和可靠性，就有了垂直架構(gòu)，也就是加了個(gè)負(fù)載均衡，接下來(lái)是SOA，解決應(yīng)用系統(tǒng)之間如何集成和互通，微服務(wù)架構(gòu)則是進(jìn)一步在探討一個(gè)應(yīng)用系統(tǒng)該如何設(shè)計(jì)才能夠更好的開(kāi)發(fā)、管理更加靈活高效?，F(xiàn)在是7頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)起源-問(wèn)題現(xiàn)在是8頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)起源-

愿景象更換零件一樣更換軟件現(xiàn)在是9頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)微服務(wù)是在應(yīng)用技術(shù)棧范疇，跟其他的應(yīng)用技術(shù)一樣都是具有系統(tǒng)分析、建模的能力，并不是一個(gè)純粹的框架或技術(shù)，而是一個(gè)綜合性的架構(gòu)模式。微服務(wù)是進(jìn)化出來(lái)的?！敖忉屢粋€(gè)概念需要用另外幾個(gè)概念來(lái)解釋，但是解釋另外幾個(gè)概念還需要其他概念來(lái)解釋”，所以要聚焦領(lǐng)域，每個(gè)領(lǐng)域都是深不見(jiàn)底，都有他的知識(shí)體系，都有他的技術(shù)棧?，F(xiàn)在是10頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)技術(shù)具體講就是分析、設(shè)計(jì)、建模，落地實(shí)施方法。包括幾個(gè)重量級(jí)的技術(shù)體系：TOGAF企業(yè)信息架構(gòu)框架DDD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)SOA面向服務(wù)架構(gòu)GRASP通用軟件職責(zé)設(shè)計(jì)模式彩色建?！纳湍Ｊ紾RASP主要是輔助職責(zé)設(shè)計(jì)，四色原型主要是捕捉實(shí)體的事件發(fā)生序列，不會(huì)讓你丟失關(guān)鍵業(yè)務(wù)場(chǎng)景?，F(xiàn)在是11頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與DDD英文名字：DomainDrivenDesign。中文名字：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。概述：DDD是一種以領(lǐng)域?yàn)楹诵牡脑O(shè)計(jì)和開(kāi)發(fā)理念。DDD通過(guò)維護(hù)一個(gè)深度反應(yīng)領(lǐng)域概念的模型，以及提供了可行的經(jīng)過(guò)實(shí)踐檢驗(yàn)的大量模式來(lái)應(yīng)對(duì)領(lǐng)域的復(fù)雜性，偏向代碼實(shí)現(xiàn)的（領(lǐng)域）對(duì)象現(xiàn)在是12頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與DDD

領(lǐng)域模型既不是脫離代碼實(shí)現(xiàn)的純粹業(yè)務(wù)對(duì)象描述，更不是一一對(duì)應(yīng)代碼里的表或者對(duì)象。注意以下幾點(diǎn)：1.領(lǐng)域模型是精簡(jiǎn)的業(yè)務(wù)知識(shí)，所有權(quán)是業(yè)務(wù)代表而不是技術(shù)代表2.領(lǐng)域模型的目的是構(gòu)建業(yè)務(wù)需求和技術(shù)實(shí)現(xiàn)之間的橋梁，和傳統(tǒng)的buttom-up軟件開(kāi)發(fā)模式相比，是一種up-buttom自上而下的開(kāi)發(fā)模式，可以避免需求偏離，因?yàn)橐婚_(kāi)始就是從業(yè)務(wù)需求出發(fā)去構(gòu)建模型，再參照模型去實(shí)現(xiàn)。3.領(lǐng)域模型是用來(lái)解構(gòu)業(yè)務(wù)真實(shí)需求，可以理解成認(rèn)識(shí)業(yè)務(wù)的一種方法論，領(lǐng)域模型的作用是構(gòu)建一種共同語(yǔ)言，業(yè)務(wù)代表和技術(shù)代表在模型上溝通。4.領(lǐng)域模型是不斷迭代進(jìn)化的，隨需求迭代，業(yè)務(wù)變更而不斷演進(jìn)。5.好的領(lǐng)域模型可以直接反應(yīng)軟件是做什么用的。

DDD是一種軟件開(kāi)發(fā)模式，目的是為了解構(gòu)復(fù)雜的業(yè)務(wù)需求，降低不同工種間的溝通障礙，實(shí)現(xiàn)結(jié)構(gòu)清晰、可復(fù)用、易維護(hù)的軟件。現(xiàn)在是13頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與GRASP

GRASP是GeneralResponsibilityAssignmentSoftwarePatterns（通用職責(zé)分配軟件模式）的簡(jiǎn)稱，它的核心思想“職責(zé)分配”。

GRASP的主要特征：對(duì)象職責(zé)分配的基本原則。主要應(yīng)用在分析和建模上。GRASP的核心思想：自己干自己的事（職責(zé)的分配）自己干自己的能干的事（職責(zé)的分配）自己只干自己的事（職責(zé)的內(nèi)聚）

如何把現(xiàn)實(shí)世界的業(yè)務(wù)功能抽象成對(duì)象，如何決定一個(gè)系統(tǒng)有多少對(duì)象，每個(gè)對(duì)象都包括什么職責(zé)，GRASP模式給出了最基本的指導(dǎo)原則?，F(xiàn)在是14頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與GRASP基本原則

信息專家給對(duì)象分配職責(zé)的基本原則是什么？創(chuàng)建者假設(shè)系統(tǒng)中存在一個(gè)類A，那么在這個(gè)系統(tǒng)中，誰(shuí)應(yīng)該負(fù)責(zé)創(chuàng)建類A的新實(shí)例？高內(nèi)聚怎樣保持對(duì)象是有重點(diǎn)的、可理解的、可管理的，并且能夠支持低耦合？低耦合怎樣降低依賴性，減少變化帶來(lái)的影響，提高重用性？控制者在UI層之上首先接收和協(xié)調(diào)（控制）系統(tǒng)操作的第一個(gè)對(duì)象是什么？多態(tài)如何處理基于類型的選擇？如何創(chuàng)建可插拔的軟件構(gòu)件？純虛構(gòu)當(dāng)你并不想違背高內(nèi)聚和低耦合或其他目標(biāo)，但是基于專家模式所提供的方案又不合適時(shí)，哪些對(duì)象應(yīng)該承擔(dān)這一職責(zé)？間接性為了避免兩個(gè)或多個(gè)事務(wù)之間直接耦合，應(yīng)該如何分配職責(zé)？如何使對(duì)象解耦合，以支持低耦合并提高復(fù)用性潛力？變化預(yù)防如何設(shè)計(jì)對(duì)象、子系統(tǒng)和系統(tǒng)，使其內(nèi)部的變化或不穩(wěn)定性不會(huì)對(duì)其他元素產(chǎn)生不良影響？現(xiàn)在是15頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與RUP

現(xiàn)在是16頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與彩色建模PeterCoad認(rèn)為，領(lǐng)域模型由以下組成：粉紅：代表“瞬間事件”

（Moment-Inteval）黃色：代表“角色”（Role）綠色：代表“人-物-地點(diǎn)”

（Party-Place-Thing）藍(lán)色：代表“描述”（Description）現(xiàn)在是17頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與SOASOA產(chǎn)生的背景：IT建設(shè)以部門級(jí)為主，業(yè)務(wù)流程與數(shù)據(jù)局限于部門內(nèi)部豎井應(yīng)用：不同應(yīng)用、不同廠商，會(huì)形成不同的數(shù)據(jù)結(jié)構(gòu)、不同的實(shí)現(xiàn)從關(guān)注部門需求到關(guān)注企業(yè)需求，需要部門間數(shù)據(jù)共享/業(yè)務(wù)共享/客戶共享組織與業(yè)務(wù)流程頻繁變化SOA解決的問(wèn)題：信息孤島互聯(lián)互通業(yè)務(wù)重用現(xiàn)在是18頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與SOASOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過(guò)簡(jiǎn)單、精確定義接口進(jìn)行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML/WebService技術(shù)之后的自然延伸。SOA將能夠幫助軟件工程師們站在新的高度理解企業(yè)級(jí)架構(gòu)中的各種組件的開(kāi)發(fā)、部署形式SOA幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個(gè)業(yè)務(wù)系統(tǒng)。SOA能夠更加從容地面對(duì)業(yè)務(wù)的急劇變化?，F(xiàn)在是19頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與SOASOA和微服務(wù)的區(qū)別：微服務(wù)不再?gòu)?qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線SOA的思想進(jìn)入到單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部實(shí)現(xiàn)真正的組件化SOA和微服務(wù)的共同點(diǎn)：服務(wù)化敏捷快速VS現(xiàn)在是20頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)與SOA框架區(qū)別現(xiàn)在是21頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)定義現(xiàn)在是22頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)內(nèi)涵是由服務(wù)組件組成的系統(tǒng)組件：可被獨(dú)立替換和升級(jí)的軟件單元組件間定義清晰、組件內(nèi)與語(yǔ)言無(wú)關(guān)獨(dú)立開(kāi)發(fā)、獨(dú)立測(cè)試、獨(dú)立部署、獨(dú)立擴(kuò)展按照業(yè)務(wù)而不是技術(shù)來(lái)組織服務(wù)面向業(yè)務(wù)，以減少跨團(tuán)隊(duì)協(xié)作與溝通跨功能團(tuán)隊(duì)（既管業(yè)務(wù)，又管數(shù)據(jù)）開(kāi)發(fā)-運(yùn)維一體的DevOps團(tuán)隊(duì)現(xiàn)在是23頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)內(nèi)涵做全生命周期的產(chǎn)品而不是項(xiàng)目不是完成開(kāi)發(fā)就交給運(yùn)維的項(xiàng)目式組織形式誰(shuí)開(kāi)發(fā)、誰(shuí)運(yùn)營(yíng)（Youbuild,yourunit.）智能端點(diǎn)與通道扁平化強(qiáng)化終端而弱化通道組件間的通訊機(jī)制更加松耦合而高內(nèi)聚RESTfulHTTP協(xié)議和僅提供消息路由功能的輕量級(jí)異步機(jī)制，是微服務(wù)架構(gòu)常用通訊機(jī)制現(xiàn)在是24頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)內(nèi)涵去中心化治理不必采用統(tǒng)一的語(yǔ)義與技術(shù)每個(gè)微服務(wù)可以考慮選用最佳工具去完成去中心化數(shù)據(jù)管理分散存儲(chǔ)與業(yè)務(wù)數(shù)據(jù)自治倡導(dǎo)多樣性持久化，采用不同的技術(shù)存儲(chǔ)現(xiàn)在是25頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)內(nèi)涵自動(dòng)化運(yùn)維（DevOps）自動(dòng)化構(gòu)建、自動(dòng)化部署、彈性擴(kuò)展故障恢復(fù)與容錯(cuò)熔斷機(jī)制、自動(dòng)化監(jiān)控/告警、日志審計(jì)演化式設(shè)計(jì)不斷地應(yīng)對(duì)業(yè)務(wù)的變更不斷地適應(yīng)技術(shù)的更迭現(xiàn)在是26頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)好處是每個(gè)微服務(wù)組件都是簡(jiǎn)單靈活的，能夠獨(dú)立部署。應(yīng)用不需要一個(gè)龐大的應(yīng)用服務(wù)器來(lái)支撐。可以由一個(gè)小團(tuán)隊(duì)負(fù)責(zé)更專注專業(yè)，相應(yīng)的也就更高效可靠。微服務(wù)之間是松耦合的，微服務(wù)內(nèi)部是高內(nèi)聚的，每個(gè)微服務(wù)很容易按需擴(kuò)展。微服務(wù)架構(gòu)與語(yǔ)言工具無(wú)關(guān)，自由選擇合適的語(yǔ)言和工具，高效的完成業(yè)務(wù)目標(biāo)即可?，F(xiàn)在是27頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)架構(gòu)示例現(xiàn)在是28頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用設(shè)計(jì)原則現(xiàn)在是29頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用設(shè)計(jì)原則現(xiàn)在是30頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用設(shè)計(jì)原則現(xiàn)在是31頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用設(shè)計(jì)原則現(xiàn)在是32頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用設(shè)計(jì)原則現(xiàn)在是33頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)平臺(tái)-企業(yè)IT基礎(chǔ)DevOps：負(fù)責(zé)從需求到計(jì)劃任務(wù)，團(tuán)隊(duì)協(xié)作，再到質(zhì)量管理、持續(xù)集成和發(fā)布。個(gè)人基礎(chǔ)環(huán)境：即微服務(wù)應(yīng)用平臺(tái)，他的目標(biāo)主要就是要支撐微服務(wù)應(yīng)用的設(shè)計(jì)開(kāi)發(fā)測(cè)試，運(yùn)行期的業(yè)務(wù)數(shù)據(jù)處理和應(yīng)用的管理監(jiān)控。IT基礎(chǔ)設(shè)施：各種運(yùn)行環(huán)境支撐如IaaS(VM虛擬化)和CaaS(容器虛擬化)等實(shí)現(xiàn)方式。現(xiàn)在是34頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用平臺(tái)目標(biāo)微服務(wù)平臺(tái)的主要目標(biāo)主要就是要支撐微服務(wù)應(yīng)用的全生命周期管理，從需求到設(shè)計(jì)開(kāi)發(fā)測(cè)試，運(yùn)行期的業(yè)務(wù)數(shù)據(jù)處理和應(yīng)用的管理監(jiān)控等。現(xiàn)在是35頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用平臺(tái)總體架構(gòu)

開(kāi)發(fā)集成：微服務(wù)平臺(tái)需要具備的一些工具和倉(cāng)庫(kù)

運(yùn)行時(shí)：微服務(wù)平臺(tái)的基礎(chǔ)能力和分布式的支撐能力，微服務(wù)運(yùn)行容器運(yùn)行在這個(gè)平臺(tái)之上。

監(jiān)控治理：對(duì)受管的微服務(wù)進(jìn)行統(tǒng)一的監(jiān)控、配置等能力。

服務(wù)網(wǎng)關(guān)：負(fù)責(zé)與前端的WEB應(yīng)用移動(dòng)APP等渠道集成，對(duì)前端請(qǐng)求進(jìn)行認(rèn)真鑒權(quán)，然后路由轉(zhuǎn)發(fā)。現(xiàn)在是36頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)應(yīng)用平臺(tái)運(yùn)行架構(gòu)現(xiàn)在是37頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)帶來(lái)的問(wèn)題現(xiàn)在是38頁(yè)\一共有49頁(yè)\編輯于星期五關(guān)鍵問(wèn)題-服務(wù)注冊(cè)和路由服務(wù)在啟動(dòng)的時(shí)候，會(huì)將自己要發(fā)布的服務(wù)注冊(cè)到服務(wù)注冊(cè)中心，運(yùn)行時(shí)，如果需要調(diào)用其他微服務(wù)的接口，本地緩存或到注冊(cè)中心獲取服務(wù)提供者的地址，獲得地址后，通過(guò)微服務(wù)容器內(nèi)部的負(fù)載均衡進(jìn)行路由調(diào)用?，F(xiàn)在是39頁(yè)\一共有49頁(yè)\編輯于星期五關(guān)鍵問(wèn)題-安全認(rèn)證安全認(rèn)證方面，可以基于SpringSecurity結(jié)合Auth2再加上JWT（Jsonwebtoken）做安全令牌，實(shí)現(xiàn)統(tǒng)一的安全認(rèn)證與鑒權(quán)，使得微服務(wù)之間能夠按需隔離和安全互通。

認(rèn)證鑒權(quán)一定是個(gè)公共服務(wù)，而不是多個(gè)系統(tǒng)各自建設(shè)?，F(xiàn)在是40頁(yè)\一共有49頁(yè)\編輯于星期五關(guān)鍵問(wèn)題-集中配置配置文件主要有靜態(tài)配置和動(dòng)態(tài)配置兩種。靜態(tài)配置通常是在編譯部署包之前設(shè)置好。動(dòng)態(tài)配置則是系統(tǒng)運(yùn)行過(guò)程中需要調(diào)整的系統(tǒng)變量或者業(yè)務(wù)參數(shù)。

通過(guò)制定規(guī)范控制配置與介質(zhì)分離，配置不要放在Jar包里。配置的方式要統(tǒng)一，格式、讀寫方式、變更熱更新的模式盡量統(tǒng)一，要采用統(tǒng)一的配置框架需要有個(gè)配置中心來(lái)統(tǒng)一管理業(yè)務(wù)系統(tǒng)中的配置信息?，F(xiàn)在是41頁(yè)\一共有49頁(yè)\編輯于星期五關(guān)鍵問(wèn)題-分布式事務(wù)微服務(wù)架構(gòu)的系統(tǒng)下，進(jìn)程成倍增多，分布式事務(wù)一致性的問(wèn)題更加明顯。微服務(wù)之間是獨(dú)立的、調(diào)用協(xié)議也是無(wú)狀態(tài)的，要解決的是一定時(shí)間后的數(shù)據(jù)達(dá)到最終一致?tīng)顟B(tài)，一般采用傳統(tǒng)的業(yè)務(wù)補(bǔ)償與沖正方式。

可靠事件模式：即事件的發(fā)送和接收保障高可靠性，來(lái)實(shí)現(xiàn)事務(wù)的一致性。

補(bǔ)償模式：ConfirmCancel，如果確認(rèn)失敗，則全部逆序取消。

TCC模式：TryConfirmCancel，補(bǔ)償模式的一種特殊實(shí)現(xiàn)通常轉(zhuǎn)賬類交易會(huì)采用這種模式。現(xiàn)在是42頁(yè)\一共有49頁(yè)\編輯于星期五關(guān)鍵問(wèn)題-同步調(diào)用微服務(wù)架構(gòu)下，相對(duì)于傳統(tǒng)部署方式，存在更多的分布式調(diào)用，“如何在不確定的環(huán)境中交付確定的服務(wù)”，可以理解為，我所依賴的服務(wù)的可靠性是無(wú)法保證的情況下，我如何保證自己能夠正常的提供服務(wù)，不被我依賴的其他服務(wù)拖垮？現(xiàn)在是43頁(yè)\一共有49頁(yè)\編輯于星期五關(guān)鍵問(wèn)題-同步調(diào)用SEDA:stagedevent-drivenarchitecture本質(zhì)上就是采用分布式事件驅(qū)動(dòng)的模式，用異步模擬來(lái)同步，無(wú)阻塞等待，再加上資源分配隔離結(jié)起來(lái)的一個(gè)解決方案。現(xiàn)在是44頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)相關(guān)技術(shù)-dubboDubbo

（開(kāi)源分布式服務(wù)框架），阿里巴巴公司開(kāi)源的一個(gè)高性能優(yōu)秀的服務(wù)框架，使得應(yīng)用可通過(guò)高性能的RPC實(shí)現(xiàn)服務(wù)的輸出和輸入功能，主要核心部件：Remoting:網(wǎng)絡(luò)通信框架，實(shí)現(xiàn)了sync-over-async和Logorequest-response消息機(jī)制.RPC:一個(gè)遠(yuǎn)程過(guò)程調(diào)用的抽象，支持負(fù)載均衡、容災(zāi)和集群功能Registry:服務(wù)目錄框架用于服務(wù)的注冊(cè)和服務(wù)事件發(fā)布和訂閱現(xiàn)在是45頁(yè)\一共有49頁(yè)\編輯于星期五微服務(wù)相關(guān)技術(shù)-SpringCloudSpringCloud是一系列框架的有序集合：利用SpringBoot的開(kāi)發(fā)便利性，簡(jiǎn)化了分布式系統(tǒng)基礎(chǔ)設(shè)施的開(kāi)發(fā)。

SpringCloudEureka是SpringCloudNetflix的一部分，它基于NetflixEureka做了二次封裝，完成微服務(wù)架構(gòu)中的服務(wù)治理功能

SpringCloudNetflix是對(duì)Netflix分布式服務(wù)開(kāi)發(fā)框架的封裝