1. 什么是微服務(wù)
- 以前的模式是 所有的代碼在同一個工程中 部署在同一個服務(wù)器中 同一個項目的不同模塊不同功能互相搶占資源
- 微服務(wù) 將工程根據(jù)不同的業(yè)務(wù)規(guī)則拆分成微服務(wù) 微服務(wù)部署在不同的機器上 服務(wù)之間進行相互調(diào)用
- Java微服務(wù)的框架有 dubbo（只能用來做微服務(wù)）勺届，spring cloud（提供了服務(wù)的發(fā)現(xiàn)酝豪，斷路器等）
- 微服務(wù)化的核心就是將傳統(tǒng)的一站式應(yīng)用,根據(jù)業(yè)務(wù)拆分成一個一個的服務(wù),徹底地去耦合,
- 每一個微服務(wù)提供單個業(yè)務(wù)功能的服務(wù),一個服務(wù)做一件事,
- 從技術(shù)角度看就是一種小而獨立的處理過程,類似進程概念,能夠自行單獨啟動或銷毀
- 擁有自己獨立的數(shù)據(jù)庫
2. springcloud如何實現(xiàn)服務(wù)的注冊和發(fā)現(xiàn)
服務(wù)在發(fā)布時 指定對應(yīng)的服務(wù)名（服務(wù)名包括了IP地址和端口） 將服務(wù)注冊到注冊中心（eureka或者zookeeper）
這一過程是springcloud自動實現(xiàn) 只需要在main方法添加@EnableDisscoveryClient 同一個服務(wù)修改端口就可以啟動多個實例
調(diào)用方法：傳遞服務(wù)名稱通過注冊中心獲取所有的可用實例 通過負載均衡策略調(diào)用（ribbon和feign）對應(yīng)的服務(wù)
3.Ribbon和Feign的區(qū)別
Ribbon和Feign都是用于調(diào)用其他服務(wù)的撤蟆，不過方式不同挥萌。
1.啟動類使用的注解不同叫胁，Ribbon用的是@RibbonClient斑响，F(xiàn)eign用的是@EnableFeignClients菱属。
2.服務(wù)的指定位置不同，Ribbon是在@RibbonClient注解上聲明舰罚，F(xiàn)eign則是在定義抽象方法的接口中使用@FeignClient聲明纽门。
3.調(diào)用方式不同，Ribbon需要自己構(gòu)建http請求营罢，模擬http請求然后使用RestTemplate發(fā)送給其他服務(wù)膜毁，步驟相當繁瑣。
Feign則是在Ribbon的基礎(chǔ)上進行了一次改進，采用接口的方式瘟滨，將需要調(diào)用的其他服務(wù)的方法定義成抽象方法即可候醒，
不需要自己構(gòu)建http請求。不過要注意的是抽象方法的注解杂瘸、方法簽名要和提供服務(wù)的方法完全一致倒淫。
4.springcloud斷路器的作用
當一個服務(wù)調(diào)用另一個服務(wù)由于網(wǎng)絡(luò)原因或者自身原因出現(xiàn)問題時 調(diào)用者就會等待被調(diào)用者的響應(yīng) 當更多的服務(wù)請求到這些資源時 導致更多的請求等待 這樣就會發(fā)生連鎖效應(yīng)（雪崩效應(yīng)） 斷路器就是解決這一問題
斷路器有完全打開狀態(tài)
一定時間內(nèi) 達到一定的次數(shù)無法調(diào)用 并且多次檢測沒有恢復的跡象 斷路器完全打開，那么下次請求就不會請求到該服務(wù)
半開
短時間內(nèi) 有恢復跡象 斷路器會將部分請求發(fā)給該服務(wù) 當能正常調(diào)用時 斷路器關(guān)閉
關(guān)閉
當服務(wù)一直處于正常狀態(tài) 能正常調(diào)用 斷路器關(guān)閉
5. 微服務(wù)之間是如何獨立通訊的spring Cloud和 Dubbo有哪些區(qū)別?
本質(zhì)區(qū)別：
dubbo 是 基于 RPC 遠程 過程調(diào)用
cloud 是基于 http rest api 調(diào)用
最大區(qū)別: Spring Cloudi拋棄了 Dubbo的RPC通信,采用的是基于HTP的REST方式败玉。
嚴格來說,這兩種方式各有優(yōu)劣敌土。雖然從一定程度上來說,后者犧牲了服務(wù)調(diào)用的性能,但也避兔了上面提到的原生RPC帶來的問題。
而且REST相比RPC更為靈活,服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約,不存在代碼級別的強依賴,這在強調(diào)快速演化的微服務(wù)環(huán)境下,顯得更加合適
很明顯, Spring Cloud的功能比 DUBBO更加強大,涵蓋面更廣,而且作為 Spring的挙頭項目,它也能夠與 Spring FrameworkSpring Boot.运翼、 Spring Data返干、 Spring Batch等其他 Springi項目完美融合,這些對于微服務(wù)而言是至關(guān)重要的。使用 Dubbo構(gòu)建的微服務(wù)架構(gòu)就像組裝電腦,各環(huán)節(jié)我們的選擇自由度很高,但是最終結(jié)果很有可能因為一條內(nèi)存質(zhì)量不行就點不亮了,總是讓人不怎么放心,但是如果你是一名高手,那這些都不是問題;而 Spring Cloud就像品牌機,在 Spring Source的整合下,做了大量的兼容性測試,保證了機器擁有更高的穩(wěn)定性,但是如果要在使用非原裝組件外的東西,就需要對其基礎(chǔ)有足夠的了解
6.Spring Boot和 Spring Cloud,請你談?wù)剬λ麄兊睦斫?什么是服務(wù)熔斷?
spring boot 是一個快速整合第三方框架 關(guān)注的是 微觀 具體關(guān)注快速方便的開發(fā)單個個體的 服務(wù)
spring cloud 關(guān)注的是 宏觀 具體關(guān)注全局的微服務(wù)協(xié)調(diào)整理治理框架 將spring boot 開發(fā)的一個個單體服務(wù)整合 并管理起來
它為各個微服務(wù)之間提供 配置管理 服務(wù)發(fā)現(xiàn) 斷路器路由 微代理 全局鎖 分布式會話 等 集成服務(wù)
舉個例子 ： 一所醫(yī)院 boot 是 一個一個科室 cloud 是把一個一個科室 組合起來 對外稱之為 醫(yī)院
存在依賴關(guān)系 cloud 離不開boot
7.hystrix 斷路器
服務(wù)熔斷 是指 由于某些原因使得服務(wù)出現(xiàn)了過載現(xiàn)象血淌，為防止造成整個系統(tǒng)故障矩欠，從而采用的一種保護措施，所以很多地方把熔斷亦稱為過載保護悠夯。
8. 什么是服務(wù)降級 微服務(wù)的優(yōu)缺點分別是什么?
用 通俗易懂的來說 ： 整體資源快不夠了癌淮，忍痛將某些服務(wù)先關(guān)掉，待渡過難關(guān)沦补，再開啟回來
9. 說下你在項目開發(fā)中碰到的坑你所知道的微服務(wù)技術(shù)棧有哪些?
微服務(wù)技術(shù)棧 ： 多種技術(shù)的結(jié)合體
我們在討論分布式的微服務(wù)架構(gòu)的時候 它需要有哪些維度乳蓄？
1 服務(wù)治理 2 服務(wù)注冊 3 服務(wù)調(diào)用 4 負載均衡 5 服務(wù)監(jiān)控
10.請說說eureka和 zookeeper,兩個的區(qū)別?
首先 說CAP 是什么 所謂的CAP C強一致性 A可用性 P 分區(qū)容錯性
著名的CAP理論指出,
一個分布式系統(tǒng)不可能同時滿足C(一致性)、A(可用性)和P(分區(qū)容錯性)夕膀。由于分區(qū)容錯性P在是分布式系統(tǒng)中必須要保證的,因此我們只能在A和C之間進行權(quán)衡虚倒。
zookeeper 遵守 CP
當向注冊中心查詢服務(wù)列表時, 我們可以容忍注冊中心返回的是幾分鐘以前的注冊信息, 但不能接受服務(wù)直接down掉不可用。
也就是說,服務(wù)注冊功能對可用性的要求要高于一致性产舞。
但是zookeeper 會出現(xiàn)這樣一種情況, 當 master節(jié)點因為網(wǎng)絡(luò)故障與其他節(jié)點失去聯(lián)系時,剩余節(jié)點會重新進行 leader選舉裹刮。
問題在于,選舉 leader的時間太長,30~120s,目選舉期間整個zookeeper 集群都是不可用的,這就導致在選舉期間注冊服務(wù)癱瘓。
在云部署的環(huán)境下,因網(wǎng)絡(luò)問題使得zookeeper 集群失去 master節(jié)點是較大概率會發(fā)生的事,雖然服務(wù)能夠最終恢復,但是漫長的選舉時間導致的注冊長期不可用是不能容忍的庞瘸。
或許 這個回答太過于抽象 用一種其他說法來說 就是 ：
當有一個zookeeper 掛了 那其他的zookeeper 會進行 一次選舉 （強一致性 ： 我一定要保持數(shù)據(jù)一致性） 而在此選舉期間 zookeeper 是不可用的 而當前 有用戶正在使用 用戶就不爽了 捧弃。
eureka 遵守 AP
Eureka:看明白了這一點,因此在設(shè)計時就優(yōu)先保證可用性。
Eureka各個節(jié)點都是平等的,幾個節(jié)點掛掉不會影響正常節(jié)點的工作,剩余的節(jié)點依然可以提供注冊和查詢服務(wù)擦囊。
而 Eureka的客戶端在向某個 Eureka注冊或時如果發(fā)現(xiàn)連接失敗,則會自動切換至其它節(jié)點
只要有一臺 Eureka還在,就能保證注冊服務(wù)可用(保證可用性),只不過查到的信息可能不是最新的不保證強一致性)违霞。
除此之外, Eureka還有一種自我保護機制,如果在15分鐘內(nèi)超過85%的節(jié)點都沒有正常的心跳,那么 Eurekas就認為客戶端與注冊中心出現(xiàn)了網(wǎng)絡(luò)故障,此時會出現(xiàn)以下幾種情況:
1. Eureka不再從注冊列表中移除因為長時間沒收到心跳而應(yīng)該過期的服務(wù)
2. Ureka仍然能夠接受新服務(wù)的注冊和査詢請求,但是不會被同步到其它節(jié)點上(即保證當前節(jié)點依然可用)
3.當網(wǎng)絡(luò)穩(wěn)定時,當前實例新的注冊信息會被同步到其它節(jié)點中
因此, Eureka可以很好的應(yīng)對因網(wǎng)絡(luò)故障導致部分節(jié)點失去聯(lián)系的情況,而不會像 zookeeper那樣使整個注冊服務(wù)癱瘓。
11.SpringCloud核心組件
1）Spring Cloud核心組件：Eureka（Eureka是微服務(wù)架構(gòu)中的注冊中心瞬场，專門負責服務(wù)的注冊與發(fā)現(xiàn)）
Eureka Client： 負責將這個服務(wù)的信息注冊到Eureka Server中
Eureka Server： 注冊中心买鸽，里面有一個注冊表，保存了各個服務(wù)所在的機器和端口號
2）Spring Cloud核心組件：Feign（ Feign的一個關(guān)鍵機制就是使用了動態(tài)代理）
沒有底層的建立連接贯被、構(gòu)造請求眼五、解析響應(yīng)的代碼妆艘，直接就是用注解定義一個 FeignClient接口，然后調(diào)用那個接口就可以了看幼。人家Feign Client會在底層根據(jù)你的注解批旺，跟你指定的服務(wù)建立連接、構(gòu)造請求诵姜、發(fā)起靕求汽煮、獲取響應(yīng)、解析響應(yīng)棚唆，等等暇赤。這一系列臟活累活，人家Feign全給你干了宵凌。
1.首先鞋囊，如果你對某個接口定義了@FeignClient注解，F(xiàn)eign就會針對這個接口創(chuàng)建一個動態(tài)代理
2.接著你要是調(diào)用那個接口瞎惫，本質(zhì)就是會調(diào)用 Feign創(chuàng)建的動態(tài)代理溜腐，這是核心中的核心
3.Feign的動態(tài)代理會根據(jù)你在接口上的@RequestMapping等注解，來動態(tài)構(gòu)造出你要請求的服務(wù)的地址
4.最后針對這個地址微饥，發(fā)起請求逗扒、解析響應(yīng)
3）Spring Cloud核心組件：Ribbon（它的作用是 負載均衡 古戴，會幫你在每次請求時選擇一臺機器欠橘，均勻的把請求分發(fā)到各個機器上）
Ribbon的負載均衡默認使用的最經(jīng)典的 Round Robin輪詢算法,還有隨機算法
此外，Ribbon是和Feign以及Eureka緊密協(xié)作现恼，完成工作的肃续，具體如下：
首先Ribbon會從 Eureka Client里獲取到對應(yīng)的服務(wù)注冊表，也就知道了所有的服務(wù)都部署在了哪些機器上叉袍，在監(jiān)聽哪些端口號始锚。
然后Ribbon就可以使用默認的Round Robin算法失乾，從中選擇一臺機器
Feign就會針對這臺機器呻逆，構(gòu)造并發(fā)起請求。
4）Spring Cloud核心組件：Hystrix（ Hystrix是隔離义黎、熔斷以及降級的一個框架）
微服務(wù)架構(gòu)中恐怖的服務(wù)雪崩問題
這么多服務(wù)互相調(diào)用润文，要是不做任何保護的話姐呐，某一個服務(wù)掛了，就會引起連鎖反應(yīng)典蝌，導致別的服務(wù)也掛曙砂。比如積分服務(wù)掛了，會導致訂單服務(wù)的線程全部卡在請求積分服務(wù)這里骏掀，沒有一個線程可以工作鸠澈，瞬間導致訂單服務(wù)也掛了柱告，別人請求訂單服務(wù)全部會卡住，無法響應(yīng)笑陈。
隔離：Hystrix會搞很多個小小的線程池 际度，比如訂單服務(wù)請求庫存服務(wù)是一個線程池，請求倉儲服務(wù)是一個線程池新锈，請求積分服務(wù)是一個線程池甲脏。每個線程池里的線程就僅僅用于請求那個服務(wù)。
熔斷：但是如果積分服務(wù)都掛了妹笆，每次調(diào)用都要去卡住幾秒鐘干啥呢块请？有意義嗎？當然沒有拳缠！ 所以我們直接對積分服務(wù)熔斷不就得了墩新，比如在5分鐘內(nèi)請求積分服務(wù)直接就返回了，不要去走網(wǎng)絡(luò)請求卡住幾秒鐘窟坐， 這個過程海渊，就是所謂的熔斷
降級：沒問題，咱們就來個降級：每次調(diào)用積分服務(wù)哲鸳，你就在數(shù)據(jù)庫里記錄一條消息臣疑，說給某某用戶增加了多少積分，因為積分服務(wù)掛了徙菠，導致沒增加成功讯沈！這樣等積分服務(wù)恢復了，你可以根據(jù)這些記錄手工加一下積分婿奔。 這個過程缺狠，就是所謂的降級
5）Spring Cloud核心組件：Zuul（這個組件是負責網(wǎng)絡(luò)路由的）
所以一般微服務(wù)架構(gòu)中都必然會設(shè)計一個網(wǎng)關(guān)在里面，像android萍摊、ios挤茄、pc前端、微信小程序冰木、H5等等穷劈，不用去關(guān)心后端有幾百個服務(wù)，就知道有一個網(wǎng)關(guān)踊沸，所有請求都往網(wǎng)關(guān)走歇终，網(wǎng)關(guān)會根據(jù)請求中的一些特征，將請求轉(zhuǎn)發(fā)給后端的各個服務(wù)雕沿。
而且有一個網(wǎng)關(guān)之后练湿，還有很多好處，比如可以做 統(tǒng)一的降級审轮、限流肥哎、認證授權(quán)辽俗、安全 ，等等篡诽。
服務(wù)治理為心臟崖飘，路由網(wǎng)關(guān)、消息中心杈女、斷路器朱浴、鏈路追蹤、配置中心等為依托达椰，構(gòu)造了整個微服務(wù)框架的「五臟六腑
