微服務(wù)架構(gòu)原理和設(shè)計(jì)方法課件

微服務(wù)架構(gòu)原理和設(shè)計(jì)方法微服務(wù)架構(gòu)原理和設(shè)計(jì)方法課件1目錄微服務(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目錄微服務(wù)架構(gòu)起源1微服務(wù)與關(guān)聯(lián)理論2微服務(wù)架構(gòu)介紹3微服務(wù)2企業(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)三部分。企業(yè)架構(gòu)企業(yè)架構(gòu)是指對(duì)企業(yè)信息管理系統(tǒng)中具有體系的、3TOGAF架構(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是最主流的。TOGAF架構(gòu)TOGAF由國(guó)際標(biāo)準(zhǔn)權(quán)威組織The4TOGAF產(chǎn)出物TOGAF產(chǎn)出物5TOGAF產(chǎn)出物TOGAF產(chǎn)出物6微服務(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ā)、管理更加靈活高效。微服務(wù)架構(gòu)起源-企業(yè)轉(zhuǎn)型傳統(tǒng)企業(yè)的IT建設(shè)需要轉(zhuǎn)型，需7包括幾個(gè)重量級(jí)的技術(shù)體系：粉紅：代表“瞬間事件”

（Moment-Inteval）中文名字：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。配置文件主要有靜態(tài)配置和動(dòng)態(tài)配置兩種。組件：可被獨(dú)立替換和升級(jí)的軟件單元SOA幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個(gè)業(yè)務(wù)系統(tǒng)。微服務(wù)相關(guān)技術(shù)-SpringCloudSpringCloudSecurity對(duì)SpringSecurity的封裝，實(shí)現(xiàn)服務(wù)安全等英文名字：DomainDrivenDesign。微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)象更換零件一樣更換軟件安全認(rèn)證方面，可以基于SpringSecurity結(jié)合Auth2再加上JWT（Jsonwebtoken）做安全令牌，實(shí)現(xiàn)統(tǒng)一的安全認(rèn)證與鑒權(quán)，使得微服務(wù)之間能夠按需隔離和安全互通。Docker通常用于如下場(chǎng)景：微服務(wù)架構(gòu)起源-問(wèn)題包括幾個(gè)重量級(jí)的技術(shù)體系：微服務(wù)架構(gòu)起源-問(wèn)題8微服務(wù)起源-

愿景象更換零件一樣更換軟件微服務(wù)起源-愿景象更換零件一樣更換軟件9微服務(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ù)棧。微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)微服務(wù)是在應(yīng)用技術(shù)棧范疇，跟10微服務(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)景。微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)技術(shù)具體講就是分析、設(shè)計(jì)、建11微服務(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ì)象微服務(wù)與DDD英文名字：DomainDrivenDesi12微服務(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ù)的軟件。微服務(wù)與DDD領(lǐng)域模型既不是脫離代碼實(shí)現(xiàn)的純粹業(yè)務(wù)對(duì)13微服務(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)原則。微服務(wù)與GRASP

GRASP是GeneralRe14微服務(wù)與GRASP基本原則

微服務(wù)與GRASP基本原則

15微服務(wù)與RUP

微服務(wù)與RUP

16微服務(wù)與彩色建模PeterCoad認(rèn)為，領(lǐng)域模型由以下組成：粉紅：代表“瞬間事件”

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

（Party-Place-Thing）藍(lán)色：代表“描述”（Description）微服務(wù)與彩色建模PeterCoad認(rèn)為，領(lǐng)域模型由以下組成17微服務(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ù)重用微服務(wù)與SOASOA產(chǎn)生的背景：18微服務(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ù)的急劇變化。微服務(wù)與SOASOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通19微服務(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微服務(wù)與SOASOA和微服務(wù)的區(qū)別：VS20微服務(wù)與SOA框架區(qū)別微服務(wù)與SOA框架區(qū)別21微服務(wù)架構(gòu)定義微服務(wù)架構(gòu)定義22微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵23微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵24微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵25微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵26微服務(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)即可。微服務(wù)架構(gòu)好處是每個(gè)微服務(wù)組件都是簡(jiǎn)單靈活的，能夠獨(dú)立部署。27微服務(wù)架構(gòu)示例微服務(wù)架構(gòu)示例28微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則29微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則30微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則31微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則32微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則33微服務(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)方式。微服務(wù)平臺(tái)-企業(yè)IT基礎(chǔ)DevOps：負(fù)責(zé)從需求到計(jì)劃任務(wù)，34微服務(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)控等。微服務(wù)應(yīng)用平臺(tái)目標(biāo)微服務(wù)平臺(tái)的主要目標(biāo)主要就是要支撐35微服務(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ā)。微服務(wù)應(yīng)用平臺(tái)總體架構(gòu)開(kāi)發(fā)集成：微服務(wù)平臺(tái)需要具備的36微服務(wù)應(yīng)用平臺(tái)運(yùn)行架構(gòu)微服務(wù)應(yīng)用平臺(tái)運(yùn)行架構(gòu)37微服務(wù)帶來(lái)的問(wèn)題微服務(wù)帶來(lái)的問(wèn)題38關(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)用。關(guān)鍵問(wèn)題-服務(wù)注冊(cè)和路由服務(wù)在啟動(dòng)的時(shí)候，會(huì)將自己要39關(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è)。關(guān)鍵問(wèn)題-安全認(rèn)證安全認(rèn)證方面，可以基于Spring40關(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)一，格式、讀寫(xiě)方式、變更熱更新的模式盡量統(tǒng)一，要采用統(tǒng)一的配置框架需要有個(gè)配置中心來(lái)統(tǒng)一管理業(yè)務(wù)系統(tǒng)中的配置信息。關(guān)鍵問(wèn)題-集中配置配置文件主要有靜態(tài)配置和動(dòng)態(tài)配置兩41關(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ì)采用這種模式。關(guān)鍵問(wèn)題-分布式事務(wù)微服務(wù)架構(gòu)的系統(tǒng)下，進(jìn)程成倍增多，42關(guān)鍵問(wèn)題-同步調(diào)用微服務(wù)架構(gòu)下，相對(duì)于傳統(tǒng)部署方式，存在更多的分布式調(diào)用，“如何在不確定的環(huán)境中交付確定的服務(wù)”，可以理解為，我所依賴的服務(wù)的可靠性是無(wú)法保證的情況下，我如何保證自己能夠正常的提供服務(wù)，不被我依賴的其他服務(wù)拖垮？關(guān)鍵問(wèn)題-同步調(diào)用微服務(wù)架構(gòu)下，相對(duì)于傳統(tǒng)部署方式，43關(guān)鍵問(wèn)題-同步調(diào)用SEDA:stagedevent-drivenarchitecture本質(zhì)上就是采用分布式事件驅(qū)動(dòng)的模式，用異步模擬來(lái)同步，無(wú)阻塞等待，再加上資源分配隔離結(jié)起來(lái)的一個(gè)解決方案。關(guān)鍵問(wèn)題-同步調(diào)用SEDA:stagedeve44TOGAF由國(guó)際標(biāo)準(zhǔn)權(quán)威組織TheOpenGroup制定。SpringCloudBus分布式消息隊(duì)列，是對(duì)KafkaMQ的封裝，實(shí)現(xiàn)可靠消息SpringCloudEureka是SpringCloudNetflix的一部分，它基于NetflixEureka做了二次封裝，完成微服務(wù)架構(gòu)中的服務(wù)治理功能Registry:服務(wù)目錄框架用于服務(wù)的注冊(cè)和服務(wù)事件發(fā)布和訂閱TCC模式：TryConfirmCancel，補(bǔ)償模式的一種特殊實(shí)現(xiàn)通常轉(zhuǎn)賬類交易會(huì)采用這種模式。微服務(wù)架構(gòu)的系統(tǒng)下，進(jìn)程成倍增多，分布式事務(wù)一致性的問(wèn)題更加明顯?？梢杂梢粋€(gè)小團(tuán)隊(duì)負(fù)責(zé)更專注專業(yè)，相應(yīng)的也就更高效可靠。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)三部分。包括幾個(gè)重量級(jí)的技術(shù)體系：Docker通常用于如下場(chǎng)景：配置文件主要有靜態(tài)配置和動(dòng)態(tài)配置兩種。Dubbo

（開(kāi)源分布式服務(wù)框架），阿里巴巴公司開(kāi)源的一個(gè)高性能優(yōu)秀的服務(wù)框架，使得應(yīng)用可通過(guò)高性能的RPC實(shí)現(xiàn)服務(wù)的輸出和輸入功能，SpringCloud是一系列框架的有序集合：微服務(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ā)布和訂閱TOGAF由國(guó)際標(biāo)準(zhǔn)權(quán)威組織TheOpenGroup制45微服務(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ā)框架的封裝，包括服務(wù)發(fā)現(xiàn)和注冊(cè)、負(fù)載均衡、斷路器、REST客戶端、請(qǐng)求路由等SpringCloudZookeeper對(duì)Zookeeper的封裝，使之能配合其它SpringCloud項(xiàng)目使用，一般當(dāng)作注冊(cè)中心

SpringCloudBus分布式消息隊(duì)列，是對(duì)KafkaMQ的封裝，實(shí)現(xiàn)可靠消息

SpringCloudConfig將配置信息中央化保存SpringCloudSecurity對(duì)SpringSecurity的封裝，實(shí)現(xiàn)服務(wù)安全等微服務(wù)相關(guān)技術(shù)-SpringCloudSpri46微服務(wù)相關(guān)技術(shù)-

dockerDocker是一個(gè)開(kāi)源的應(yīng)用容器引擎，讓開(kāi)發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的容器中，然后發(fā)布到任何流行的Linux機(jī)器上，也可以實(shí)現(xiàn)虛擬化。容器是完全使用沙箱機(jī)制，相互之間不會(huì)有任何接口。Docker通常用于如下場(chǎng)景：使應(yīng)用的打包與部署自動(dòng)化創(chuàng)建輕量、私密的PAAS環(huán)境實(shí)現(xiàn)自動(dòng)化測(cè)試和持續(xù)的集成/部署部署與擴(kuò)展webapp、數(shù)據(jù)庫(kù)和后臺(tái)服務(wù)微服務(wù)相關(guān)技術(shù)-dockerDocker是一個(gè)開(kāi)47微服務(wù)相關(guān)技術(shù)-

jenkinsJenkins是一個(gè)開(kāi)源軟件項(xiàng)目，是基于Java開(kāi)發(fā)的一種持續(xù)集成工具，用于監(jiān)控持續(xù)重復(fù)的工作，旨在提供一個(gè)開(kāi)放易用的軟件平臺(tái)，使軟件的持續(xù)集成變成可能。Jenkins功能包括：1、持續(xù)的軟件版本發(fā)布/測(cè)試項(xiàng)目。2、監(jiān)控外部調(diào)用執(zhí)行的工作。微服務(wù)相關(guān)技術(shù)-jenkinsJenkins是一個(gè)48ThankYou!ThankYou!49微服務(wù)架構(gòu)原理和設(shè)計(jì)方法微服務(wù)架構(gòu)原理和設(shè)計(jì)方法課件50目錄微服務(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目錄微服務(wù)架構(gòu)起源1微服務(wù)與關(guān)聯(lián)理論2微服務(wù)架構(gòu)介紹3微服務(wù)51企業(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)三部分。企業(yè)架構(gòu)企業(yè)架構(gòu)是指對(duì)企業(yè)信息管理系統(tǒng)中具有體系的、52TOGAF架構(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是最主流的。TOGAF架構(gòu)TOGAF由國(guó)際標(biāo)準(zhǔn)權(quán)威組織The53TOGAF產(chǎn)出物TOGAF產(chǎn)出物54TOGAF產(chǎn)出物TOGAF產(chǎn)出物55微服務(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ā)、管理更加靈活高效。微服務(wù)架構(gòu)起源-企業(yè)轉(zhuǎn)型傳統(tǒng)企業(yè)的IT建設(shè)需要轉(zhuǎn)型，需56包括幾個(gè)重量級(jí)的技術(shù)體系：粉紅：代表“瞬間事件”

（Moment-Inteval）中文名字：領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。配置文件主要有靜態(tài)配置和動(dòng)態(tài)配置兩種。組件：可被獨(dú)立替換和升級(jí)的軟件單元SOA幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個(gè)業(yè)務(wù)系統(tǒng)。微服務(wù)相關(guān)技術(shù)-SpringCloudSpringCloudSecurity對(duì)SpringSecurity的封裝，實(shí)現(xiàn)服務(wù)安全等英文名字：DomainDrivenDesign。微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)象更換零件一樣更換軟件安全認(rèn)證方面，可以基于SpringSecurity結(jié)合Auth2再加上JWT（Jsonwebtoken）做安全令牌，實(shí)現(xiàn)統(tǒng)一的安全認(rèn)證與鑒權(quán)，使得微服務(wù)之間能夠按需隔離和安全互通。Docker通常用于如下場(chǎng)景：微服務(wù)架構(gòu)起源-問(wèn)題包括幾個(gè)重量級(jí)的技術(shù)體系：微服務(wù)架構(gòu)起源-問(wèn)題57微服務(wù)起源-

愿景象更換零件一樣更換軟件微服務(wù)起源-愿景象更換零件一樣更換軟件58微服務(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ù)棧。微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)微服務(wù)是在應(yīng)用技術(shù)棧范疇，跟59微服務(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)景。微服務(wù)架構(gòu)起源-技術(shù)基礎(chǔ)技術(shù)具體講就是分析、設(shè)計(jì)、建60微服務(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ì)象微服務(wù)與DDD英文名字：DomainDrivenDesi61微服務(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ù)的軟件。微服務(wù)與DDD領(lǐng)域模型既不是脫離代碼實(shí)現(xiàn)的純粹業(yè)務(wù)對(duì)62微服務(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)原則。微服務(wù)與GRASP

GRASP是GeneralRe63微服務(wù)與GRASP基本原則

微服務(wù)與GRASP基本原則

64微服務(wù)與RUP

微服務(wù)與RUP

65微服務(wù)與彩色建模PeterCoad認(rèn)為，領(lǐng)域模型由以下組成：粉紅：代表“瞬間事件”

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

（Party-Place-Thing）藍(lán)色：代表“描述”（Description）微服務(wù)與彩色建模PeterCoad認(rèn)為，領(lǐng)域模型由以下組成66微服務(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ù)重用微服務(wù)與SOASOA產(chǎn)生的背景：67微服務(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ù)的急劇變化。微服務(wù)與SOASOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通68微服務(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微服務(wù)與SOASOA和微服務(wù)的區(qū)別：VS69微服務(wù)與SOA框架區(qū)別微服務(wù)與SOA框架區(qū)別70微服務(wù)架構(gòu)定義微服務(wù)架構(gòu)定義71微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵72微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵73微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵74微服務(wù)架構(gòu)內(nèi)涵微服務(wù)架構(gòu)內(nèi)涵75微服務(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)即可。微服務(wù)架構(gòu)好處是每個(gè)微服務(wù)組件都是簡(jiǎn)單靈活的，能夠獨(dú)立部署。76微服務(wù)架構(gòu)示例微服務(wù)架構(gòu)示例77微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則78微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則79微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則80微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則81微服務(wù)應(yīng)用設(shè)計(jì)原則微服務(wù)應(yīng)用設(shè)計(jì)原則82微服務(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)方式。微服務(wù)平臺(tái)-企業(yè)IT基礎(chǔ)DevOps：負(fù)責(zé)從需求到計(jì)劃任務(wù)，83微服務(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)控等。微服務(wù)應(yīng)用平臺(tái)目標(biāo)微服務(wù)平臺(tái)的主要目標(biāo)主要就是要支撐84微服務(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ā)。微服務(wù)應(yīng)用平臺(tái)總體架構(gòu)開(kāi)發(fā)集成：微服務(wù)平臺(tái)需要具備的85微服務(wù)應(yīng)用平臺(tái)運(yùn)行架構(gòu)微服務(wù)應(yīng)用平臺(tái)運(yùn)行架構(gòu)86微服務(wù)帶來(lái)的問(wèn)題微服務(wù)帶來(lái)的問(wèn)題87關(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)用。關(guān)鍵問(wèn)題-服務(wù)注冊(cè)和路由服務(wù)在啟動(dòng)的時(shí)候，會(huì)將自己要88關(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è)。關(guān)鍵問(wèn)題-安全認(rèn)證安全認(rèn)證方面，可以基于Spring89關(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)一，格式、讀寫(xiě)方式、變更熱更新的模式盡量統(tǒng)一，要采用統(tǒng)一的配置框架需要有個(gè)配置中心來(lái)統(tǒng)一管理業(yè)務(wù)系統(tǒng)中的配置信息。關(guān)鍵問(wèn)題-集中配置配置文件主要有靜態(tài)配置和動(dòng)態(tài)配置兩90關(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ì)采用這種模式。關(guān)鍵問(wèn)題-分布式事務(wù)微服務(wù)架構(gòu)的系統(tǒng)下，進(jìn)程成倍增多，91關(guān)鍵問(wèn)題-同步調(diào)用微服務(wù)架構(gòu)下，相對(duì)于傳統(tǒng)部署方式，存在更多的分布式調(diào)用，“如何在不確定的環(huán)境中交付確定的服務(wù)”，可以理解為，我所依賴的服務(wù)的可靠性是無(wú)法保證的情況下，我如何保證自己能夠正常的提供服務(wù)，不被我依賴的其他服務(wù)拖垮？關(guān)鍵問(wèn)題-同步調(diào)用微服務(wù)架構(gòu)下，相對(duì)于傳統(tǒng)部署方式，92關(guān)鍵問(wèn)題-同步調(diào)用SEDA:stagedevent-drivenarchitecture本質(zhì)上就是采用分布式事件驅(qū)動(dòng)的模式，用異步模擬來(lái)同步，無(wú)阻塞等待，再加上資源分配隔離結(jié)起來(lái)的一個(gè)解決方案。關(guān)鍵問(wèn)題-同步調(diào)用SEDA:stagedeve93TOGAF由國(guó)際標(biāo)準(zhǔn)權(quán)威組織TheOpenGroup制定。SpringCloudBus分布式消息隊(duì)列，是對(duì)KafkaMQ的封裝，實(shí)現(xiàn)可靠消息SpringCloudEureka是SpringCloudNetflix的一部分，它基于NetflixEureka做了二次封裝，完成微服務(wù)架構(gòu)中的服務(wù)治理功能Registry:服務(wù)目錄框架用于服務(wù)的注冊(cè)和服務(wù)事件發(fā)布和訂閱TCC模式：TryConfirmCancel，補(bǔ)償模式的一種特殊實(shí)現(xiàn)通常轉(zhuǎn)賬類交易會(huì)采用這種模式。微服務(wù)架構(gòu)的系統(tǒng)下，進(jìn)程成倍增多，分布式事務(wù)一致性的問(wèn)題更加明顯?？梢杂梢粋€(gè)小團(tuán)隊(duì)負(fù)