接上期后續(xù)

本期分享第二十一章節(jié)

SpringCloud

教學(xué)文檔馬上就分享完了，你們都跟上了嗎？

每天都在學(xué)習(xí)嘛？

有什么不會(huì)的嘛？

今日教學(xué)文檔分享來(lái)了?

SpringCloud有11章節(jié)，本文章僅分享第一篇章

今日新篇章

【微服務(wù)】

https://segmentfault.com/a/1190000018626163??

1.?微服務(wù)簡(jiǎn)介

隨著互聯(lián)網(wǎng)技術(shù)的飛速發(fā)展，目前全球超過(guò)半的人口在使用互聯(lián)網(wǎng)，人們的生活隨著互聯(lián)網(wǎng)的發(fā)展，發(fā)生了翻天覆地的變化。各行各業(yè)都在應(yīng)用互聯(lián)網(wǎng) 國(guó)家政策也在大力支持互聯(lián)網(wǎng)的發(fā)展。隨著越來(lái)越多的用戶參與，業(yè)務(wù)場(chǎng)景越來(lái)越復(fù)雜，傳統(tǒng)的單體架構(gòu)己經(jīng)很難滿足互聯(lián)網(wǎng)技術(shù)的發(fā)展要求。這主要體現(xiàn)在兩方面， 是隨著業(yè)務(wù)復(fù)雜度的提高，代碼的可維護(hù)性、擴(kuò)展性和可讀性在降低； 是維護(hù)系統(tǒng)的成本、修改系統(tǒng)的成本在提高。所以，改變單體應(yīng)用架構(gòu)己經(jīng)勢(shì)在必行。另外，隨著云計(jì)算、大數(shù)據(jù)、人工智能的飛速發(fā)展，對(duì)系統(tǒng)架構(gòu)也提出了越來(lái)越高的要求。

?微服務(wù)(不是一個(gè)框架 而是一種架構(gòu)思想)，是著名的 oo?（面向?qū)ο螅?Object Oriented ）專家 Martin Fowler 提出來(lái)的，它是用來(lái)描述將軟件應(yīng)用程序設(shè)計(jì)為獨(dú)立部署的服務(wù)的種特殊方式。最近兩年，微服務(wù)在各大技術(shù)會(huì)議、文章、書(shū)籍上出現(xiàn)的頻率已經(jīng)讓人 意識(shí)到它對(duì)于軟件領(lǐng)域所帶來(lái)的影響力。微服務(wù)架構(gòu)的系統(tǒng)是個(gè)分布式系統(tǒng)，按業(yè)務(wù)領(lǐng)域劃分為獨(dú)立的服務(wù)單元，有自動(dòng)化運(yùn)維、容錯(cuò)、快速演進(jìn)的特點(diǎn)，它能夠解決傳統(tǒng)單體架構(gòu)系統(tǒng)的痛點(diǎn)，同時(shí)也能滿足越來(lái)越復(fù)雜的業(yè)務(wù)需求。

1.1?單體架構(gòu)不足

在應(yīng)用的初始階段，單體架構(gòu)無(wú)論是在開(kāi)發(fā)速度、運(yùn)維難度上，還是服務(wù)器的成本上都有

著顯著的優(yōu)勢(shì)。在一個(gè)產(chǎn)品的前景不明確的初始階段，用單體架構(gòu)是非常明智的選擇。隨著應(yīng)用業(yè)務(wù)的發(fā)展和業(yè)務(wù)復(fù)雜度的提高，這種架構(gòu)明顯存在很多的不足，主要體現(xiàn)在以下3個(gè)方面：

1.?業(yè)務(wù)越來(lái)越復(fù)雜，單體應(yīng)用的代碼量越來(lái)越大，代碼的可讀性、可維護(hù)性和可擴(kuò)展性下降，新人接手代碼所需的時(shí)間成倍增加，業(yè)務(wù)擴(kuò)展帶來(lái)的代價(jià)越來(lái)越大。

2.?隨著用戶越來(lái)越多，程序承受的并發(fā)越來(lái)越高，單體應(yīng)用的并發(fā)能力有限。

3.?測(cè)試的難度越來(lái)越大，單體應(yīng)用的業(yè)務(wù)都在同個(gè)程序中，隨著業(yè)務(wù)的擴(kuò)張、復(fù)雜度的增加，單體應(yīng)用修改業(yè)務(wù)或者增加業(yè)務(wù)或許會(huì)給其他業(yè)務(wù)帶來(lái)定的影響，導(dǎo)致測(cè)試難度增加。

1.2?到底什么是微服務(wù)

什么是微服務(wù)呢？

就是將一個(gè)大的應(yīng)用，拆分成多個(gè)小的模塊，每個(gè)模塊都有自己的功能和職責(zé)，每個(gè)模塊可以進(jìn)行交互，這就是微服務(wù)

對(duì)于微服務(wù)，業(yè)界沒(méi)有嚴(yán)格統(tǒng)一的定義，但是作為“微服務(wù)”這名詞的發(fā)明人，Martin Fowler 對(duì)微服務(wù)的定義似乎更具有權(quán)威性和指導(dǎo)意義，他的理解如下：

簡(jiǎn)而言之，微服務(wù)架構(gòu)的風(fēng)格，就是將單一程序開(kāi)發(fā)成一個(gè)微服務(wù)，每個(gè)微服務(wù)運(yùn)行在自己的進(jìn)程中，并使用輕量級(jí)機(jī)制通信，通常是 HTTP RESTFUL API 。這些服務(wù)圍繞業(yè)務(wù)能力來(lái)劃分構(gòu)建的，并通過(guò)完全自動(dòng)化部署機(jī)制來(lái)獨(dú)立部署這些服務(wù)可以使用不同的編程語(yǔ)言，以及不同數(shù)據(jù)存儲(chǔ)技術(shù)，以保證最低限度的集中式管理。

1.2.1?總結(jié)出微服務(wù)的特點(diǎn)

1.?按業(yè)務(wù)(功能)劃分為一個(gè)獨(dú)立運(yùn)行的程序，即服務(wù)單元。

2.?服務(wù)之間通過(guò) HTTP 協(xié)議相互通信。 http是一個(gè)萬(wàn)能的協(xié)議 (web應(yīng)用都支持的模式)

3.?自動(dòng)化部署。

4.?可以用不同的編程語(yǔ)言。

5.?可以用不同的存儲(chǔ)技術(shù)。

6.?服務(wù)集中化管理。

7.?微服務(wù)是一個(gè)分布式系統(tǒng)。

1.3?微服務(wù)特點(diǎn)的具體闡述

1.3.1?微服務(wù)單元按業(yè)務(wù)來(lái)劃分（不是絕對(duì)的）

微服務(wù)的“微”到底需要定義到什么樣的程度，這是個(gè)非常難以界定的概念，可以從以個(gè)方面來(lái)界定： 是根據(jù)代碼量來(lái)定義，根據(jù)代碼的多少來(lái)判斷程序的大?。?是根據(jù)開(kāi)發(fā)時(shí)間的長(zhǎng)短來(lái)判斷： 是根據(jù)業(yè)務(wù)的大小來(lái)劃分。根據(jù) Martin Fowler 的定義，微服務(wù)的“微”是按照業(yè)務(wù)來(lái)劃分的 。一個(gè)大的業(yè)務(wù)可以拆分成若干小的業(yè)務(wù)， 個(gè)小的業(yè)務(wù)又可以拆分成若干更小的業(yè)務(wù)，業(yè)務(wù)到底怎么拆分才算合適，這需要開(kāi)發(fā)人員自己去決定。例如微博最常見(jiàn)的功能是微博內(nèi)容、關(guān)注和粉絲，而其中微博內(nèi)容又有點(diǎn)贊、評(píng)論等，如何將微博這個(gè)復(fù)雜的程序劃分為單個(gè)的服務(wù)，需要由開(kāi)發(fā)團(tuán)隊(duì)去決定。按業(yè)務(wù)劃分的微服務(wù)單元獨(dú)立部署，運(yùn)行在獨(dú)立的進(jìn)程中 這些微服務(wù)單元是高度組件化的模塊，并提供了穩(wěn)定的模塊邊界，服務(wù)與服務(wù)之間沒(méi)有任何的相合 有非常好的擴(kuò)展性和復(fù)用性。傳統(tǒng)的軟件開(kāi)發(fā)模式通常由 UI 團(tuán)隊(duì)、服務(wù)端團(tuán)隊(duì)、數(shù)據(jù)庫(kù)和運(yùn)維團(tuán)隊(duì)構(gòu)成，相應(yīng)地將軟件按照職能劃分為 、服務(wù)端、數(shù)據(jù)庫(kù)和運(yùn)維等模塊。通常這些開(kāi)發(fā) 員各司其職 很少有人跨職能去工作。 如果按照業(yè)務(wù)來(lái)劃分服務(wù)，每個(gè)服務(wù)都需要獨(dú)立的 UI 、服務(wù)端、數(shù)據(jù)庫(kù)和運(yùn)維。也就是說(shuō)， 個(gè)小的業(yè)務(wù)的微服務(wù)需要?jiǎng)佑?個(gè)團(tuán)隊(duì)的人去協(xié)作，這顯然增加了團(tuán)隊(duì)與團(tuán)隊(duì)之間交流協(xié)作的成本。所以產(chǎn)生了跨職能團(tuán) 隊(duì)，這個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)服務(wù)的所有工作，包括 UI 、服務(wù)端和數(shù)據(jù)庫(kù)。當(dāng)這個(gè)團(tuán)隊(duì)只有 個(gè)人的時(shí)候，就對(duì)開(kāi)發(fā)人員提出了更高的要求。

?

1.3.2?微服務(wù)通過(guò)?HTTP 來(lái)互相通信

按照業(yè)務(wù)劃分的微服務(wù)單元獨(dú)立部署 并運(yùn)行在各自的進(jìn)程中。微服務(wù)單元之間的通信方般傾向于使用 HTTP 這種簡(jiǎn)單的通信機(jī)制，更多的時(shí)候是使用 RESTfulAPI 。這種接受請(qǐng)求、處理業(yè)務(wù)邏輯、返回?cái)?shù)據(jù)的 HTTP 模式非常高效，并且這種通機(jī)制與平臺(tái)和語(yǔ)言無(wú)關(guān)。例如用 Java 寫(xiě)的服務(wù)可以消費(fèi)用 Go 語(yǔ)言寫(xiě)的服務(wù)

1.3.3?微服務(wù)的數(shù)據(jù)庫(kù)獨(dú)立

在單體架構(gòu)中，所有的業(yè)務(wù)都共用個(gè)數(shù)據(jù)庫(kù)。隨著業(yè)務(wù)量的增加，數(shù)據(jù)庫(kù)的表的數(shù)量越來(lái)越多，難以管理和維護(hù)，并且數(shù)據(jù)量的增 會(huì)導(dǎo)致查詢速度越來(lái)越慢。 例如個(gè)應(yīng)用有這樣幾個(gè)業(yè)務(wù)：用戶的信息、用戶的賬戶、用戶的購(gòu)物 、數(shù)據(jù)報(bào) 服務(wù)等。典型的單體架構(gòu)如微服務(wù)的 個(gè)特點(diǎn)就是按業(yè)務(wù)劃分服務(wù)，服務(wù)與服務(wù)之間無(wú)稠合，就連數(shù)據(jù)庫(kù)也是獨(dú)立的個(gè)典型的微服務(wù)的架構(gòu)就是每個(gè)微服務(wù)都有自己獨(dú)立的數(shù)據(jù)庫(kù)，數(shù)據(jù)庫(kù)之間沒(méi)有何聯(lián)系這樣做的好處在于，隨著業(yè)務(wù)的不斷擴(kuò)張，服務(wù)與服務(wù)不需要提供數(shù)據(jù)庫(kù)集成，而是提供 API接口相互調(diào)用：還有 個(gè)好處是數(shù)據(jù)庫(kù)獨(dú)立，單業(yè)務(wù)的數(shù)據(jù)盆少，易于維護(hù)，數(shù)據(jù)庫(kù)性能有著明顯的優(yōu)勢(shì)，數(shù)據(jù)庫(kù)的遷移也很方便。另外，隨著存儲(chǔ)技術(shù)的發(fā)展，數(shù)據(jù)庫(kù)的存儲(chǔ)方式不再僅僅是關(guān)系型數(shù)據(jù)庫(kù)，非關(guān)系數(shù)據(jù)庫(kù)的應(yīng)用也非常廣泛，例如 MongoDB ，它們有著良好的讀 性能，因此越來(lái)越受歡迎個(gè)典型的微服務(wù)的系統(tǒng)，可能每 個(gè)服務(wù)的數(shù)據(jù)庫(kù)都不相同，每個(gè)服務(wù)所使用的數(shù)據(jù)存儲(chǔ)技

1.3.4?微服務(wù)的自動(dòng)化部署（CI /CD）(持續(xù)集成 持續(xù)交付)

?

在微服務(wù)架構(gòu)中，系統(tǒng)會(huì)被拆分為若干個(gè)微服務(wù)，每個(gè)微服務(wù)又是一個(gè)獨(dú)立的應(yīng)用程序。單體架構(gòu)的應(yīng)用程序只需要部署一次，而微服務(wù)架構(gòu)有多少個(gè)服務(wù)就需要部署多少次。隨著服務(wù)數(shù)量的增加，如果微服務(wù)按照單體架構(gòu)的部署方式，部署的難度會(huì)呈指數(shù)增加。業(yè)務(wù)的粒度劃分得越細(xì)，微服務(wù)的數(shù)量就越多，這時(shí)需要更穩(wěn)定的部署機(jī)制。隨著技術(shù)的發(fā)展，尤其是 Docker容器技術(shù)的推進(jìn)，以及自動(dòng)化部署工具（例如開(kāi)源組件 Jenkins）的出現(xiàn)，自動(dòng)化部署變得越來(lái)越簡(jiǎn)單。

自動(dòng)化部署可以提高部署的效率，減少人為的控制，部署過(guò)程中出現(xiàn)錯(cuò)誤的概率降低，部署過(guò)程的每一步自動(dòng)化，提高軟件的質(zhì)量。構(gòu)建一個(gè)自動(dòng)化部署的系統(tǒng)，雖然在前期需要開(kāi)發(fā)人員或者運(yùn)維人員的學(xué)習(xí)，但是對(duì)于整個(gè)軟件系統(tǒng)來(lái)說(shuō)是一個(gè)全新的概念。在軟件系統(tǒng)的整個(gè)生命周期之中，每一步是由程序控制的，而不是人為控制，軟件的質(zhì)量提高到了一個(gè)新的高度。隨著 DevOps這種全新概念的推進(jìn)，自動(dòng)化部署必然會(huì)成為微服務(wù)部署 的一種方式。

1.3.5?服務(wù)集中化管理

微服務(wù)系統(tǒng)是按業(yè)務(wù)單元來(lái)劃分服務(wù)的，服務(wù)數(shù)量越多，管理起來(lái)就越復(fù)雜，因此微服務(wù)必須使用集中化管理。目前流行的微服務(wù)框架中，例如 Spring Cloud采用 Eureka來(lái)注冊(cè)服務(wù)和發(fā)現(xiàn)服務(wù)，另外， Zookeeper、 Consul等都是非常優(yōu)秀的服務(wù)集中化管理框架。

1.3.6?分布式架構(gòu)

分布式系統(tǒng)是集群部署的，由很多計(jì)算機(jī)相互協(xié)作共同構(gòu)成，它能夠處理海量的用戶請(qǐng)求。當(dāng)分布式系統(tǒng)對(duì)外提供服務(wù)時(shí)，用戶是毫不知情的，還以為是一臺(tái)服務(wù)器在提供服務(wù)。分布式系統(tǒng)的復(fù)雜任務(wù)通過(guò)計(jì)算機(jī)之間的相互協(xié)作來(lái)完成，當(dāng)然簡(jiǎn)單的任務(wù)也可以在一臺(tái)計(jì)算機(jī)上完成。分布式系統(tǒng)通過(guò)網(wǎng)絡(luò)協(xié)議來(lái)通信，所以分布式系統(tǒng)在空間上沒(méi)有任何限制，即分布式服務(wù)器可以部署不同的機(jī)房和不同的地區(qū)。微服務(wù)架構(gòu)是分布式架構(gòu)，分布式系統(tǒng)比單體系統(tǒng)更加復(fù)雜，主要體現(xiàn)在服務(wù)的獨(dú)立性和服務(wù)相互調(diào)用的可靠性，以及分布式事務(wù)、全局鎖、全局 Id等，而單體系統(tǒng)不需要考慮這些復(fù)雜性。

另外，分布式系統(tǒng)的應(yīng)用都是集群化部署，會(huì)給數(shù)據(jù)一致性帶來(lái)困難。分布式系統(tǒng)中的服務(wù)通信依賴于網(wǎng)絡(luò)，網(wǎng)絡(luò)不好，必然會(huì)對(duì)分布式系統(tǒng)帶來(lái)很大的影響。在分布式系統(tǒng)中，服務(wù)之間相互依賴，如果一個(gè)服務(wù)出現(xiàn)了故障或者是網(wǎng)絡(luò)延遲，在高并發(fā)的情況下，會(huì)導(dǎo)致線程阻塞，在很短的時(shí)間內(nèi)該服務(wù)的線程資源會(huì)消耗殆盡，最終使得該服務(wù)不可用。由于服務(wù)的相互依賴，可能會(huì)導(dǎo)致整個(gè)系統(tǒng)的不可用，這就是“雪崩效應(yīng)”。為了防止此類事件的發(fā)生，分布式系統(tǒng)必然要采取相應(yīng)的措施，例如“熔斷機(jī)制”。

1.3.7?熔斷機(jī)制Hystrix

為了防止“雪崩效應(yīng)”事件的發(fā)生，分布式系統(tǒng)采用了熔斷機(jī)制。在用SpringCloud構(gòu)建的微服務(wù)系統(tǒng)中，采用了熔斷器（即Hystrix令 組件的 C ircuit Breaker）去做熔斷。例如在微服務(wù)系統(tǒng)中，有 a、 b、 c、 d、 e、

如果此時(shí)服務(wù) b出現(xiàn)故障或者網(wǎng)絡(luò)延遲，服務(wù) b會(huì)出現(xiàn)大量的線程阻塞，有可能在很短的時(shí)間內(nèi)線程資源就被消耗完了，導(dǎo)致服務(wù) b的不可用。如果服務(wù) b為較 底層的服務(wù)，會(huì)影響到其他服務(wù)，導(dǎo)致其他服務(wù)會(huì)一直等待服務(wù) b的處理。如果服務(wù) b遲遲不處理，大量的網(wǎng)絡(luò)請(qǐng)求不僅僅堆積在服務(wù) b，而且會(huì)堆積到依賴于服務(wù) b的其他服務(wù)。而因服務(wù) b出現(xiàn)故障影響的服務(wù)，也會(huì)影響到依賴于因服務(wù) b出現(xiàn)故障影響的服務(wù)的其他服務(wù)，從而由 b開(kāi)始，影響到整個(gè)系統(tǒng)，導(dǎo)致整個(gè)系統(tǒng)的不可用。這是一件非?？膳碌氖拢?yàn)榉?wù)器運(yùn)營(yíng)商的不可靠，必然會(huì)導(dǎo)致服務(wù)的不可靠，而網(wǎng)絡(luò)服務(wù)商的不可靠性，也會(huì)導(dǎo)致服務(wù)的不可靠。在高并發(fā)的場(chǎng)景下，稍微有點(diǎn)不可靠，由于故障的傳播性，會(huì)導(dǎo)致大量的服務(wù)不可用，甚至導(dǎo)致整個(gè)系統(tǒng)崩潰。

為了解決這一難題，微服務(wù)架構(gòu)引入了熔斷機(jī)制。當(dāng)服務(wù) b出現(xiàn)故障，請(qǐng)求失敗次數(shù)超過(guò)設(shè)定的閥值之后，服務(wù) b就會(huì)開(kāi)啟熔斷器，之后服務(wù) b不進(jìn)行任何的業(yè)務(wù)邏輯操作，執(zhí)行快速失敗，直接返回請(qǐng)求失敗的信息。其他依賴于 b的服務(wù)就不會(huì)因?yàn)榈貌坏巾憫?yīng)而線程阻塞，這時(shí)除了服務(wù) b和依賴于服務(wù) b的部分功能不可用外，其他功能正常。

1.4?微服務(wù)的優(yōu)勢(shì)

相對(duì)于單體服務(wù)來(lái)說(shuō)，微服務(wù)具有很多的優(yōu)勢(shì)，主要體現(xiàn)在以下方面。

??1. 將一個(gè)復(fù)雜的業(yè)務(wù)分解成若干小的業(yè)務(wù)，每個(gè)業(yè)務(wù)拆分成一個(gè)服務(wù)，服務(wù)的邊界明確，將復(fù)雜的問(wèn)題簡(jiǎn)單化。服務(wù)按照業(yè)務(wù)拆分，編碼也是按照業(yè)務(wù)來(lái)拆分，代碼的可讀性和可擴(kuò)展性增加。新人加入團(tuán)隊(duì)，不需要了解所有的業(yè)務(wù)代碼，只需要了解他所接管的服務(wù)的代碼，新人學(xué)習(xí)時(shí)間成本減少。

??2. 由于微服務(wù)系統(tǒng)是分布式系統(tǒng)，服務(wù)與服務(wù)之間沒(méi)有任何的禍合。隨著業(yè)務(wù)的增加，可以根據(jù)業(yè)務(wù)再拆分服務(wù)，具有極強(qiáng)的橫向擴(kuò)展能力。隨著應(yīng)用的用戶量的增加，井發(fā)量增加，可以將微服務(wù)集群化部署，從而增加系統(tǒng)的負(fù)載能力。簡(jiǎn)而言之，微服務(wù)系統(tǒng)的微服務(wù)單元具有很強(qiáng)的橫向擴(kuò)展能力。

??3. 服務(wù)與服務(wù)之問(wèn)通過(guò) HTTP網(wǎng)絡(luò)通信協(xié)議來(lái)通信，單個(gè)微服務(wù)內(nèi)部高度禍合，服務(wù)與服務(wù)之間完全獨(dú)立，無(wú)調(diào)合。這使得微服務(wù)可以采用任何的開(kāi)發(fā)語(yǔ)言和技術(shù)來(lái)實(shí)現(xiàn)。開(kāi)發(fā)人員不再被強(qiáng)迫使用公司以前的技術(shù)或者已經(jīng)過(guò)時(shí)的技術(shù)，而是可以自由選擇最適合業(yè)務(wù)場(chǎng)景的或者最適合自己的開(kāi)發(fā)語(yǔ)言和技術(shù)，提高開(kāi)發(fā)效率、降低開(kāi)發(fā)成本。

??4. 如果是一個(gè)單體的應(yīng)用，由于業(yè)務(wù)的復(fù)雜性、代碼的禍合性，以及可能存在的歷史問(wèn)題。在重寫(xiě)一個(gè)單體應(yīng)用時(shí)，要求重寫(xiě)的應(yīng)用的人員了解所有的業(yè)務(wù)，所以重寫(xiě)單體應(yīng)用是非常困難的，并且重寫(xiě)風(fēng)險(xiǎn)也較高。如果是微服務(wù)系統(tǒng)，由于微服務(wù)系統(tǒng)是按照業(yè)務(wù)的進(jìn)行拆分的，并且有堅(jiān)實(shí)的服務(wù)邊界，所以重寫(xiě)某個(gè)服務(wù)就相當(dāng)于重寫(xiě)某一個(gè)業(yè)務(wù)的代碼，非常簡(jiǎn)單。

??5. 微服務(wù)的每個(gè)服務(wù)單元都是獨(dú)立部署的，即獨(dú)立運(yùn)行在某個(gè)進(jìn)程里。微服務(wù)的修改和部署對(duì)其他服務(wù)沒(méi)有影響。試想，假設(shè)一個(gè)應(yīng)用只有一個(gè)簡(jiǎn)單的修改，如果是單體架構(gòu)，需要測(cè)試和部署整個(gè)應(yīng)用；而如果采用微服務(wù)架構(gòu)，只需要測(cè)試并部署被修改的那個(gè)服務(wù)，這就大大減少了測(cè)試和部署的時(shí)間。

??6. 微服務(wù)在 CAP理論中采用的是 AP架構(gòu)，即具有高可用和分區(qū)容錯(cuò)的特點(diǎn)。高可用主要體現(xiàn)在系統(tǒng) 7 x 24小時(shí)不間斷的服務(wù)，它要求系統(tǒng)有大量的服務(wù)器集群，從而提高了系統(tǒng)的負(fù)載能力。另外，分區(qū)容錯(cuò)也使得系統(tǒng)更加健壯。

1.5?微服務(wù)的不足(正視它的不足)

凡事都有兩面性，微服務(wù)也不例外，微服務(wù)相對(duì)于單體應(yīng)用來(lái)說(shuō)具有很多的優(yōu)勢(shì)，當(dāng)然也有它的不足，主要體現(xiàn)在如下方面：

1.?微服務(wù)的復(fù)雜度

2.?分布式事務(wù)問(wèn)題

3.?服務(wù)的劃分（按照功能劃分 還是按照組件來(lái)劃分呢） 分工

4.?服務(wù)的部署（不用自動(dòng)化部署 自動(dòng)化部署）

1.6?微服務(wù)架構(gòu)的設(shè)計(jì)原則（項(xiàng)目起步搭建）

開(kāi)閉原則 單一原則??6大設(shè)計(jì)原則 ?架構(gòu)設(shè)計(jì)和代碼設(shè)計(jì)思路一樣的

軟件設(shè)計(jì)就好比建筑設(shè)計(jì)。 Architect這個(gè)詞在建筑學(xué)中是“建筑師”的意思，而在軟件領(lǐng)域里則是“架構(gòu)師”的意思，可見(jiàn)它們確實(shí)有相似之處。無(wú)論是建筑師還是架構(gòu)師，他們都希望把作品設(shè)計(jì)出自己的特色，并且更愿意把創(chuàng)造出的東西被稱為藝術(shù)品。然而現(xiàn)實(shí)卻是，建筑設(shè)計(jì)和軟件設(shè)計(jì)有非常大的區(qū)別。建筑師設(shè)計(jì)并建造出來(lái)的建筑往往很難有變化，除非拆了重建。而架構(gòu)師設(shè)計(jì)出來(lái)的軟件系統(tǒng)，為了滿足產(chǎn)品的業(yè)務(wù)發(fā)展，在它的整個(gè)生命周期中，每一個(gè)版本都有很多的變化。

軟件設(shè)計(jì)每一個(gè)版本都在變化，所以軟件設(shè)計(jì)應(yīng)該是漸進(jìn)式發(fā)展。軟件從一開(kāi)始就不應(yīng)該被設(shè)計(jì)成微服務(wù)架構(gòu)，微服務(wù)架構(gòu)固然有優(yōu)勢(shì)，但是它需要更多的資源，包括服務(wù)器資源、技術(shù)人員等。追求大公司所帶來(lái)的技術(shù)解決方案，刻意地追求某個(gè)新技術(shù)，企圖使用技術(shù)解決所有的問(wèn)題，這些都是軟件設(shè)計(jì)的誤區(qū)。

技術(shù)應(yīng)該是隨著業(yè)務(wù)的發(fā)展而發(fā)展的，任何脫離業(yè)務(wù)的技術(shù)是不能產(chǎn)生價(jià)值的。在初創(chuàng)公司，業(yè)務(wù)很單一時(shí)，如果在 LAMP單體構(gòu)架夠用的情況下，就應(yīng)該用 LAMP，因?yàn)樗_(kāi)發(fā)速度快，性價(jià)比高。隨著業(yè)務(wù)的發(fā)展，用戶量的增加，可以考慮將數(shù)據(jù)庫(kù)讀寫(xiě)分離、加緩存、加復(fù)雜均衡服務(wù)器、將應(yīng)用程序集群化部署等。如果業(yè)務(wù)還在不斷發(fā)展，這時(shí)可以考慮使用分布式系統(tǒng)，例如微服務(wù)架構(gòu)的系統(tǒng)。不管使用什么樣的架構(gòu)，驅(qū)動(dòng)架構(gòu)的發(fā)展一定是業(yè)務(wù)的發(fā)展，只有當(dāng)前架構(gòu)不再適合當(dāng)前業(yè)務(wù)的發(fā)展，才考慮更換架構(gòu)。

在微服務(wù)架構(gòu)中，有三大難題，那就是**服務(wù)故障的傳播性(熔斷)、服務(wù)的劃分和分布式事務(wù)**。在微服務(wù)設(shè)計(jì)時(shí)，一定要考慮清楚這三個(gè)難題，從而選擇合適的框架。目前比較流行的微服務(wù)框架有 Spring社區(qū)的 Spring Cloud、 Google公司的 Kubemetes等。不管使用哪一種框架或者工具，都需要考慮這三大難題。為了解決服務(wù)故障的傳播性，一般的微服務(wù)框架都有熔斷機(jī)制組件。另外，服務(wù)的劃分沒(méi)有具體的劃分方法，一般來(lái)說(shuō)根據(jù)業(yè)務(wù)來(lái)劃分服務(wù)，領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)具有指導(dǎo)作用。最后，分布式事務(wù)一般的解決辦法就是兩階段提交或者三階段提交，不管使用哪一種都存在事務(wù)失敗，導(dǎo)致數(shù)據(jù)不一致的情況，關(guān)鍵時(shí)刻還得人工去恢復(fù)數(shù)據(jù)?？傊?，微服務(wù)的設(shè)計(jì)一定是漸進(jìn)式的，并且是隨著業(yè)務(wù)的發(fā)展而發(fā)展的。

2.?SpringCloud簡(jiǎn)介(管家 注重服務(wù)的管理)

Spring Cloud作為 Java語(yǔ)言的微服務(wù)框架，它依賴于 Spring Boot，有快速開(kāi)發(fā)、持續(xù)交付和容易部署等特點(diǎn)。 Spring Cloud的組件非常多，涉及微服務(wù)的方方面面，井在開(kāi)源社區(qū) Spring和 Netflix、 Pivotal兩大公司的推動(dòng)下越來(lái)越完善，如今alibaba也加入到其中。?spring 官方 netflix alibaba

Spring Cloud在開(kāi)發(fā)部署上繼承了 Spring Boot的一些優(yōu)點(diǎn)，提高其在開(kāi)發(fā)和部署上的效率。 Spring Cloud的首要目標(biāo)就是通過(guò)提供一系列開(kāi)發(fā)組件和框架，幫助開(kāi)發(fā)者迅速搭建一個(gè)分布式的微服務(wù)系統(tǒng)。 Spring Cloud是通過(guò)包裝其他技術(shù)框架來(lái)實(shí)現(xiàn)的，例如包裝開(kāi)源的 Netflix oss組件，實(shí)現(xiàn)了一套通過(guò)基于注解、 Java配置和基于模版開(kāi)發(fā)的微服務(wù)框架。 Spring Cloud提供了開(kāi)發(fā)分布式微服務(wù)系統(tǒng)的一些常用組件，例如服務(wù)注冊(cè)和發(fā)現(xiàn)、配置中心、熔斷器、遠(yuǎn)程調(diào)用，智能路由、微代理、控制總線、全局鎖、分布式會(huì)話等。

2.1?SpringCloud版本對(duì)應(yīng)關(guān)系【開(kāi)發(fā)重點(diǎn)】

A B C D E F G H?I(2020版) ????2021.0.1????2.6.3??2021.0.3?----- 2.6.8

https://start.spring.io/actuator/info?

?

2.2?SpringCloud常用組件表 （管家）

服務(wù)的注冊(cè)和發(fā)現(xiàn)。（eureka,nacos,consul）

服務(wù)的負(fù)載均衡。(ribbon，loadBalance)

服務(wù)的相互調(diào)用。（openFeign，dubbo）

服務(wù)的容錯(cuò)。（hystrix，sentinel）

服務(wù)網(wǎng)關(guān)。（gateway，zuul）

服務(wù)配置的統(tǒng)一管理。（config-server,nacos）

服務(wù)消息總線。(bus)

服務(wù)安全組件。(security,Oauth2.0)

服務(wù)監(jiān)控。(admin) （jvm）

鏈路追蹤。(sleuth+zipkin)....

2.3?總結(jié)

SpringCloud就是微服務(wù)理念的一種具體落地實(shí)現(xiàn)方式，幫助微服務(wù)架構(gòu)提供了必備的功能

目前開(kāi)發(fā)中常用的落地實(shí)現(xiàn)有三種：

Dubbo+Zookeeper 半自動(dòng)化的微服務(wù)實(shí)現(xiàn)架構(gòu) ?(別的管理沒(méi)有)

SpringCloud Netflix 一站式微服務(wù)架構(gòu)

SpringCloud Alibaba 新的一站式微服務(wù)架構(gòu)

三大公司

Spring Netflix Alibaba

2.4?最終架構(gòu)圖詳見(jiàn)PDF

?

完整版獲取可私信小動(dòng)~

更多干貨我們下期再說(shuō)！

下期會(huì)分享

第二十二章節(jié)

Elasticsearch

相關(guān)知識(shí)~

下期見(jiàn)！