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

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

起源、簡介及設(shè)計獨立架構(gòu)師唐偉佳當(dāng)前1頁，總共49頁。目錄微服務(wù)架構(gòu)起源1微服務(wù)與關(guān)聯(lián)理論2微服務(wù)架構(gòu)介紹3微服務(wù)應(yīng)用及平臺設(shè)計4微服務(wù)相關(guān)技術(shù)5當(dāng)前2頁，總共49頁。企業(yè)架構(gòu)

企業(yè)架構(gòu)是指對企業(yè)信息管理系統(tǒng)中具有體系的、普遍性的問題而提供的通用解決方案，是基于業(yè)務(wù)導(dǎo)向和驅(qū)動的架構(gòu)來理解、分析、設(shè)計、構(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)營模式、流程體系、組織結(jié)構(gòu)、地域分布等內(nèi)容

IT架構(gòu)：指導(dǎo)IT投資和設(shè)計決策的IT框架，是建立企業(yè)信息系統(tǒng)的綜合藍(lán)圖，包括數(shù)據(jù)架構(gòu)、應(yīng)用架構(gòu)和技術(shù)架構(gòu)三部分。當(dāng)前3頁，總共49頁。TOGAF架構(gòu)

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

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

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

DDD是一種軟件開發(fā)模式，目的是為了解構(gòu)復(fù)雜的業(yè)務(wù)需求，降低不同工種間的溝通障礙，實現(xiàn)結(jié)構(gòu)清晰、可復(fù)用、易維護(hù)的軟件。當(dāng)前13頁，總共49頁。微服務(wù)與GRASP

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

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

如何把現(xiàn)實世界的業(yè)務(wù)功能抽象成對象，如何決定一個系統(tǒng)有多少對象，每個對象都包括什么職責(zé)，GRASP模式給出了最基本的指導(dǎo)原則。當(dāng)前14頁，總共49頁。微服務(wù)與GRASP基本原則

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

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

（Moment-Inteval）黃色：代表“角色”（Role）綠色：代表“人-物-地點”

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

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

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

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

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

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

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

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

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

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

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

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

SpringCloudNetflix是對Netflix分布式服務(wù)開發(fā)框架的封裝，包括服務(wù)發(fā)現(xiàn)和