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

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

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

優(yōu)點:

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

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

3.微服務(wù)能夠被小團隊單獨開發(fā),這個小團隊可以有2-5個開發(fā)人員組成;

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

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

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

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

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

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

缺點:

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

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

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

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

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

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

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

…等。

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

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

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

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

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

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

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

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

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

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

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

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

8.消息隊列: 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ù)流操作開發(fā)包: SpringCloud Stream;

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

…等。

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

選型依據(jù):

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

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

3.可維護性;

4.學習曲線等;

六、什么是SpringCloud？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注；在EurekaServer7001_App主啟動類中加入 @EnableEurekaServer 注解即可！

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

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

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

3.Zookeeper采用CP,節(jié)點采用主從,一旦主機down機,就會在多個從中進行決策選舉一個從作為主,但是選舉時間為30-120s之間,時間太長,在選舉期間會導致集群不可用,從而導致整個注冊中心癱瘓;

4.Eureka采用AP,所有節(jié)點平等,沒有主從,如果有一個節(jié)點掛掉,就會自動切換到下一個可用的節(jié)點,只要有一個Eureka節(jié)點正常運行,就能保證注冊中心可用;只不過查詢到的信息可能不是最新的(不保證強一致性);

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

十二、Eureka保護機制？

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

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

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

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

A (Atomicity) 原子性;

C (Consistency) 一致性;

I (Isolation) 隔離性;

D (Durability) 持久性。

十四、CAP 分別是什么？

C (Consistency) 強一致性;

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

A (Availability) 可用性;

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

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

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

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

十五、什么是Ribbon？

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

十六、什么是負載均衡 ？

負載均衡(Load Balance) 簡單的說就是將用戶的請求平攤到多個服務(wù)上,從而達到系統(tǒng)的HA，即高可用;

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

十七、什么是 Feign？

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

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

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

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

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

二十、什么是 Hystrix？

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

二十一、Hystrix 能干什么？

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

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

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

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

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

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

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

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

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

二十五、Zuul 是什么？

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

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

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

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

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