一、什么是微服務(wù)Micoreservice?

微服務(wù)的核心就是將傳統(tǒng)的一站式應(yīng)用,根據(jù)業(yè)務(wù)拆分成一個(gè)一個(gè)的服務(wù),徹底地去耦合,每個(gè)微服務(wù)提供單個(gè)業(yè)務(wù)功能的服務(wù),一個(gè)服務(wù)只做一件事; 從技術(shù)角度來(lái)看就是一種小而獨(dú)立的處理過(guò)程,類似進(jìn)程的概念; 每個(gè)微服務(wù)能夠自行獨(dú)立的啟動(dòng)或銷毀,擁有自己獨(dú)立的數(shù)據(jù)庫(kù)。

二、微服務(wù)的優(yōu)缺點(diǎn)有哪些？

優(yōu)點(diǎn):

1.每個(gè)服務(wù)足夠內(nèi)聚,足夠小,代碼容易理解,這樣能聚焦一個(gè)具體的業(yè)務(wù)功能或業(yè)務(wù)需求;

2.開(kāi)發(fā)簡(jiǎn)單,提高開(kāi)發(fā)效率,一個(gè)服務(wù)可能專門只做一件事;

3.微服務(wù)能夠被小團(tuán)隊(duì)單獨(dú)開(kāi)發(fā),這個(gè)小團(tuán)隊(duì)可以有2-5個(gè)開(kāi)發(fā)人員組成;

4.微服務(wù)是松耦合的,是具有功能意義的服務(wù),無(wú)論是在開(kāi)發(fā)階段,還是部署階段都是獨(dú)立的;

5.微服務(wù)可以使用不同的語(yǔ)言開(kāi)發(fā);

6.易于第三方集成,微服務(wù)允許以容易且靈活的方式集成自動(dòng)部署,通過(guò)持續(xù)集成工具,如:Jendis, Hudson;

7.微服務(wù)易于被一個(gè)開(kāi)發(fā)人員理解、修改和維護(hù),這樣小團(tuán)隊(duì)能夠更關(guān)注自己的工作成果,無(wú)需通過(guò)合作來(lái)體現(xiàn)價(jià)值;

8.微服務(wù)只是業(yè)務(wù)邏輯代碼,不會(huì)與HTML和css等其他界面組件混合;

9.每個(gè)微服務(wù)都有獨(dú)立的存儲(chǔ)能力,可以由自己的數(shù)據(jù)庫(kù)管理,也可以由統(tǒng)一的數(shù)據(jù)庫(kù)管理。

缺點(diǎn):

1.開(kāi)發(fā)人員要處理分布式系統(tǒng)的復(fù)雜性;

2.多運(yùn)維難度大,隨著服務(wù)的增加,運(yùn)維的壓力也在增大;

3.系統(tǒng)部署依賴;

4.系統(tǒng)集成測(cè)試;

5.服務(wù)間通信成本;

6.數(shù)據(jù)一致性;

7.性能監(jiān)控;

…等。

三、微服務(wù)和微服務(wù)架構(gòu)的區(qū)別？

1.微服務(wù)強(qiáng)調(diào)的是一個(gè)一個(gè)的個(gè)體,每個(gè)個(gè)體做自己的事情;

2.微服務(wù)架構(gòu)強(qiáng)調(diào)的是整體,其把一個(gè)個(gè)的微服務(wù)組裝起來(lái),對(duì)外提供服務(wù)。

四、微服務(wù)技術(shù)棧有哪些？

技術(shù)棧: 多種技術(shù)的集合體;

1.服務(wù)開(kāi)發(fā): SpringBoot, Spring, SpringMVC;

2.服務(wù)配置與管理: Netflix公司的Archaius, Alibaba的Diamond等;

3.服務(wù)注冊(cè)與發(fā)現(xiàn): Eureka, Zookeeper;

4.服務(wù)調(diào)用: REST, RPC, gRPC;

5.服務(wù)熔斷器: Hystrix, Envoy;

6.服務(wù)負(fù)載均衡: Ribbon, Nginx;

7.服務(wù)接口調(diào)用: Feign;

8.消息隊(duì)列: Kafaka, RabbitMQ, ActiveMQ;

9.消息配置中心管理: SpringCloudConfig, Chef

10.服務(wù)監(jiān)控: Zabbix, Nagios, Metrics, Spectator;

11.服務(wù)路由(API網(wǎng)關(guān)): Zuul;

12.全鏈路跟蹤: Zipkin, Brave, Dapper

13.服務(wù)部署: Docker, OpenStack, Kubernetes;

14.數(shù)據(jù)流操作開(kāi)發(fā)包: SpringCloud Stream;

15.事件消息總線: SpringCloud Bus;

…等。

五、為什么要選擇SpringCloud作為微服務(wù)架構(gòu)？

選型依據(jù):

1.整體解決方案(SpringCloud框架有全家桶的一站式整體解決方案,類似宜家家居那樣,從廚房到臥室再到浴室等所有家居都可以在一個(gè)地方全套購(gòu)買,方便快捷),并且框架成熟度高;

2.社區(qū)熱度高,使用的人群多;

3.可維護(hù)性;

4.學(xué)習(xí)曲線等;

六、什么是SpringCloud？

SpringCloud是一個(gè)基于SpringBoot的快速構(gòu)建分布式系統(tǒng)的工具集, 其基于SpringBoot提供了一套微服務(wù)一站式解決方案,包括服務(wù)注冊(cè)與發(fā)現(xiàn), 配置中心, 全鏈路監(jiān)控, 服務(wù)網(wǎng)關(guān), 負(fù)載均衡, 熔斷器等組件; 除了基于Netflix的開(kāi)源組件做高度湊向封裝之外,還有一些選型中立的開(kāi)源組件。

七、什么是微服務(wù)\”全家桶\”？

分布式微服務(wù)架構(gòu)下的一站式解決方案,是各個(gè)微服務(wù)架構(gòu)落地技術(shù)的集合體俗稱微服務(wù)\”全家桶\”。

八、SpringBoot 與 SpringCloud 的關(guān)系？

1.SpringBoot專注于快速方便的開(kāi)發(fā)單個(gè)個(gè)體微服務(wù);

2.SpringCloud是專注于全局的微服務(wù)協(xié)調(diào)治理框架,它將SpirngBoot開(kāi)發(fā)的一個(gè)個(gè)單體微服務(wù)整合并統(tǒng)一管理, 為各個(gè)微服務(wù)之間提供配置管理, 服務(wù)發(fā)現(xiàn), 斷路器, 路由,微代理, 事件總線, 全局鎖, 決策競(jìng)選, 分布式會(huì)話等集成服務(wù);

3.SpringBoot可以離開(kāi)SpringCloud獨(dú)立使用開(kāi)發(fā)項(xiàng)目, 但SpringCloud離不開(kāi)SpringBoot,二者屬于依賴關(guān)系。

九、SpringCloud與Dubbo的區(qū)別？

1.兩者的最大區(qū)別就是SpringCloud拋棄了Dubbo的RPC通信,采用的是HTTP的REST方式;

2.嚴(yán)格來(lái)說(shuō),這兩種方式各有優(yōu)劣,雖然從一定程度上講,REST犧牲了服務(wù)調(diào)用的性能,但也避免了原生RPC帶來(lái)的問(wèn)題; 而且,REST相比RPC更為靈活,服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約,不存在代碼級(jí)別的強(qiáng)依賴,這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下,顯得更加適合;

3.Dubbo只實(shí)現(xiàn)了服務(wù)治理,而SpringCloud的子項(xiàng)目分別覆蓋了微服務(wù)架構(gòu)下的眾多部件,服務(wù)治理只是其中的一個(gè)方面; 但是Dubbo提供了各種Filter,各種要核心要素可以通過(guò)擴(kuò)展Filter來(lái)完善。

十、微服務(wù)的注冊(cè)與發(fā)現(xiàn)是怎么玩的？

微服務(wù)的注冊(cè)與發(fā)現(xiàn)是通過(guò)Eureka組件實(shí)現(xiàn)的，Eureka包含兩大內(nèi)容：Eureka Server 和 Eureka Client；

Eureka Server提供服務(wù)注冊(cè)服務(wù)，各個(gè)節(jié)點(diǎn)啟動(dòng)后，會(huì)在Eureka Server中進(jìn)行注冊(cè)，這樣Eureka Server中的服務(wù)注冊(cè)表中將會(huì)存儲(chǔ)所有可用服務(wù)的節(jié)點(diǎn)信息，服務(wù)節(jié)點(diǎn)的信息可以在界面中直觀看到；Eureka Client是一個(gè)Java客戶端用于簡(jiǎn)化Eureka Server的交互，客戶端同時(shí)也具備一個(gè)內(nèi)置的、使用輪詢(round-robin)負(fù)載算法的負(fù)載均衡器；在應(yīng)用啟動(dòng)后，將會(huì)向Eureka Server發(fā)送心跳(默認(rèn)周期為30s)；如果Eureka Server在多個(gè)心跳周期內(nèi)沒(méi)有接受到某個(gè)節(jié)點(diǎn)的心跳，Eureka Server將會(huì)從服務(wù)注冊(cè)表中把這個(gè)服務(wù)節(jié)點(diǎn)移除(默認(rèn)90秒)。

注；在EurekaServer7001_App主啟動(dòng)類中加入 @EnableEurekaServer 注解即可！

十一、作為服務(wù)注冊(cè)中心Eureka比Zookeeper好在哪里?

1.Eureka遵守AP原則,Zookeeper遵守CP原則;

2.根據(jù)CAP理論,一個(gè)分布式系統(tǒng)不可能同時(shí)滿足一致性,可用性和分區(qū)容錯(cuò)性,由于分區(qū)容錯(cuò)性是分布式系統(tǒng)中必須保證的,因此我們只能在一致性和可用性之間權(quán)衡;

3.Zookeeper采用CP,節(jié)點(diǎn)采用主從,一旦主機(jī)down機(jī),就會(huì)在多個(gè)從中進(jìn)行決策選舉一個(gè)從作為主,但是選舉時(shí)間為30-120s之間,時(shí)間太長(zhǎng),在選舉期間會(huì)導(dǎo)致集群不可用,從而導(dǎo)致整個(gè)注冊(cè)中心癱瘓;

4.Eureka采用AP,所有節(jié)點(diǎn)平等,沒(méi)有主從,如果有一個(gè)節(jié)點(diǎn)掛掉,就會(huì)自動(dòng)切換到下一個(gè)可用的節(jié)點(diǎn),只要有一個(gè)Eureka節(jié)點(diǎn)正常運(yùn)行,就能保證注冊(cè)中心可用;只不過(guò)查詢到的信息可能不是最新的(不保證強(qiáng)一致性);

5.除此之外, Eureaka還有自我保護(hù)機(jī)制; 因此Eureka可以很好地應(yīng)對(duì)因網(wǎng)絡(luò)故障而導(dǎo)致部分節(jié)點(diǎn)失去聯(lián)系的情況,而不會(huì)像Zookeeper那樣使整個(gè)注冊(cè)服務(wù)癱瘓。

十二、Eureka保護(hù)機(jī)制？

1.Eureka自我保護(hù)機(jī)制是一種應(yīng)對(duì)網(wǎng)絡(luò)異常的安全保護(hù)措施,它的架構(gòu)哲學(xué)是寧可保留所有的微服務(wù)(健康的和不健康的微服務(wù)都保留),也不盲目注銷任何健康的微服務(wù),使用自我保護(hù)模式,可以讓Eureka集群更加健壯,穩(wěn)定;

2.默認(rèn)情況下,如果Eureka Server在一定時(shí)間內(nèi)沒(méi)有接收到某個(gè)微服務(wù)實(shí)例的心跳，Eureka Server將會(huì)注銷該實(shí)例(默認(rèn)90秒),但是當(dāng)網(wǎng)絡(luò)發(fā)生故障時(shí),微服務(wù)與Eureka Server之間無(wú)法正常通信,以上行為可能變得非常危險(xiǎn)–因?yàn)榉?wù)本身其實(shí)是健康的,此時(shí)本不應(yīng)該注銷這個(gè)服務(wù);

3.Eureka通過(guò)\”自我保護(hù)模式\”來(lái)解決這個(gè)問(wèn)題–當(dāng)Eureka Server在短時(shí)間丟失過(guò)多客戶端時(shí)(可能發(fā)生了網(wǎng)絡(luò)分區(qū)故障),那么該節(jié)點(diǎn)就會(huì)進(jìn)入自我保護(hù)模式; 一旦進(jìn)入該模式,Eureaka Server就會(huì)保護(hù)注冊(cè)表中的信息,不再刪除服務(wù)注冊(cè)表中的數(shù)據(jù)(也不會(huì)注銷任何微服務(wù)),當(dāng)網(wǎng)絡(luò)故障恢復(fù)后，該Eureka Server節(jié)點(diǎn)會(huì)自動(dòng)退出自我保護(hù)模式。

十三、傳統(tǒng)的 ACID 分別是什么？

A (Atomicity) 原子性;

C (Consistency) 一致性;

I (Isolation) 隔離性;

D (Durability) 持久性。

十四、CAP 分別是什么？

C (Consistency) 強(qiáng)一致性;

同樣數(shù)據(jù)在分布式系統(tǒng)中所有地方都是被復(fù)制成相同的;

A (Availability) 可用性;

所有在分布式系統(tǒng)活躍的節(jié)點(diǎn)都能夠處理操作并且能相應(yīng)查詢;

P (Partition Tolerance) 分區(qū)容錯(cuò)性;

在兩個(gè)復(fù)制系統(tǒng)之間,如果發(fā)生了計(jì)劃之外的網(wǎng)絡(luò)連接問(wèn)題,對(duì)于這種情況,有一套容錯(cuò)性設(shè)計(jì)來(lái)保證;

CAP理論的核心是: 一個(gè)分布式系統(tǒng)不可能同時(shí)很好的滿足一致性,可用性和分區(qū)容錯(cuò)性, 最多只能同時(shí)實(shí)現(xiàn)兩種。

十五、什么是Ribbon？

SpringCloud Ribbon 是基于Netfix Ribbon 實(shí)現(xiàn)的一套客戶端負(fù)軟載均衡工具。

十六、什么是負(fù)載均衡 ？

負(fù)載均衡(Load Balance) 簡(jiǎn)單的說(shuō)就是將用戶的請(qǐng)求平攤到多個(gè)服務(wù)上,從而達(dá)到系統(tǒng)的HA，即高可用;

分類: 集中式LB, 進(jìn)程內(nèi)LB。

十七、什么是 Feign？

Feign是一個(gè)聲明式的WebService客戶端, 其內(nèi)置了Ribbon的負(fù)載均衡,還有它的面向接口編程，優(yōu)雅而簡(jiǎn)單的實(shí)現(xiàn)了服務(wù)的調(diào)用，讓編寫WebService客戶端更簡(jiǎn)單。

十八、分布式系統(tǒng)面臨的問(wèn)題？

復(fù)雜分布式系統(tǒng)結(jié)構(gòu)中的應(yīng)用程序有數(shù)十個(gè)依賴關(guān)系，每個(gè)依賴關(guān)系在某些時(shí)候?qū)⒚媾R不可避免的依賴失敗。

十九、什么是服務(wù)雪崩？

多個(gè)微服務(wù)之間調(diào)用的時(shí)候,假設(shè)微服務(wù)A調(diào)用微服務(wù)B和C,微服務(wù)B和C又調(diào)用其他微服務(wù),這就是所謂的\”扇出\”; 如果扇出鏈路上的某個(gè)微服務(wù)的調(diào)用不可用或響應(yīng)時(shí)間過(guò)長(zhǎng),對(duì)微服務(wù)A的調(diào)用就會(huì)占用越來(lái)越多的系統(tǒng)資源,進(jìn)而引起系統(tǒng)崩潰,所謂的\”雪崩效應(yīng)\”(是一種 服務(wù)提供者 的不可用導(dǎo)致 服務(wù)調(diào)用者的不可用，并將不可用逐漸放大的過(guò)程)。

二十、什么是 Hystrix？

Hystrix 是一個(gè)用于處理分布式系統(tǒng)的延遲和容錯(cuò)的開(kāi)源庫(kù)(基于Netfix); 在分布式系統(tǒng)里,許多依賴不可避免的會(huì)失敗,比如超時(shí),異常等, Hystrix能夠保證在一個(gè)依賴出現(xiàn)問(wèn)題的情況下,不會(huì)導(dǎo)致整體服務(wù)失敗,避免級(jí)聯(lián)故障,以提高分布式系統(tǒng)的彈性;斷路器本事是一種開(kāi)關(guān)裝置,當(dāng)某個(gè)服務(wù)單元發(fā)生故障后,通過(guò)斷路器的故障監(jiān)控(類似熔斷保險(xiǎn)絲),向調(diào)用方返回一個(gè)符合預(yù)期的,可處理的備選響應(yīng)(FallBack),而不是長(zhǎng)時(shí)間的等待或者拋出調(diào)用方無(wú)法處理的異常,這樣就保證了服務(wù)調(diào)用方的線程不會(huì)被長(zhǎng)時(shí)間,不必要地占用, 從而避免了故障在分布式系統(tǒng)的蔓延，乃至雪崩。

二十一、Hystrix 能干什么？

服務(wù)降級(jí)、服務(wù)熔斷、服務(wù)限流、服務(wù)監(jiān)控。

二十二、什么是服務(wù)熔斷？

熔斷機(jī)制是應(yīng)對(duì)雪崩效應(yīng)的一種微服務(wù)鏈路保護(hù)機(jī)制; 當(dāng)扇出鏈路的某個(gè)微服務(wù)不可用或響應(yīng)時(shí)間過(guò)長(zhǎng)時(shí),會(huì)進(jìn)行服務(wù)降級(jí),進(jìn)而熔斷該節(jié)點(diǎn)微服務(wù)的調(diào)用,快速返回錯(cuò)誤的響應(yīng)信息; 當(dāng)檢測(cè)到該節(jié)點(diǎn)微服務(wù)調(diào)用響應(yīng)正常后恢復(fù)調(diào)用鏈路; 在SpringCloud框架里,熔斷機(jī)制通過(guò)Hystrix實(shí)現(xiàn),Hystrix會(huì)監(jiān)控服務(wù)間的調(diào)用狀況,當(dāng)失敗的調(diào)用達(dá)到一定閥值,就會(huì)啟動(dòng)熔斷機(jī)制,默認(rèn)是5秒內(nèi)調(diào)用20次；(熔斷機(jī)制的注解是@HystrixCommand)

二十三、服務(wù)降級(jí)是什么？

1.當(dāng)服務(wù)器壓力劇增的情況下,根據(jù)實(shí)際業(yè)務(wù)情況及流量,對(duì)一些服務(wù)和頁(yè)面有策略的不處理或換種簡(jiǎn)單的方式處理,從而釋放釋放服務(wù)器資源以保證核心交易正常運(yùn)作;

2.服務(wù)降級(jí)一般是從整體負(fù)荷考慮,就是當(dāng)某個(gè)服務(wù)熔斷之后,服務(wù)器將不再被調(diào)用,此時(shí)客戶端可以自己準(zhǔn)備一個(gè)本地的fallback回調(diào),返回一個(gè)默認(rèn)值; 這樣做,雖然服務(wù)水平下降了,但好歹還可以用,比服務(wù)直接掛掉的要強(qiáng);

3.服務(wù)降級(jí)處理是在客戶端完成的，與服務(wù)端無(wú)關(guān)。

二十四、什么是服務(wù)監(jiān)控 (Hystrix Dashboard)？

除了隔了依賴服務(wù)的調(diào)用之外,Hystrix還提供了準(zhǔn)實(shí)時(shí)的調(diào)用監(jiān)控(Hystrix Dashboard)，Hystrix會(huì)持續(xù)的記錄所有通過(guò)Hystrix 發(fā)起請(qǐng)求的執(zhí)行信息, 并以統(tǒng)計(jì)報(bào)表和圖形的形式展示給用戶,包括每秒執(zhí)行多少請(qǐng)求、多少成功、多少失敗等信息，并轉(zhuǎn)化為可視化界面。

二十五、Zuul 是什么？

Zuul(路由網(wǎng)關(guān))包含了對(duì)請(qǐng)求的路由和過(guò)濾兩個(gè)重要的功能;

其中路由功能負(fù)責(zé)將外部請(qǐng)求轉(zhuǎn)發(fā)到具體的微服務(wù)實(shí)例上,是實(shí)現(xiàn)外部訪問(wèn)統(tǒng)一入口的基礎(chǔ)；而過(guò)濾功能則負(fù)責(zé)對(duì)請(qǐng)求的處理過(guò)程進(jìn)行干預(yù),是實(shí)現(xiàn)請(qǐng)求校驗(yàn),服務(wù)聚合等功能的基礎(chǔ)。

二十六、SpringCloud Config分布式配置中心是什么？

SpringCloud Config為服務(wù)構(gòu)架中的微服務(wù)提供集中化的外部配置支持,配置服務(wù)器為各個(gè)不同微服務(wù)應(yīng)用的所有環(huán)境提供了一個(gè)中心化的外部配置, 集中管理配置文件, 將配置信息已REST接口的形式暴露。

需要的Java架構(gòu)師方面的資料可以關(guān)注之后私信哈，回復(fù)“資料”領(lǐng)取免費(fèi)架構(gòu)視頻資料，記得要點(diǎn)贊轉(zhuǎn)發(fā)噢！??！