本文參考 嗨客網(wǎng) Java 隨筆

前言

本章節(jié)記錄了一些常見的微服務(wù)面試題及詳細(xì)答案，目錄如下：

文章目錄

• 前言
• • 微服務(wù)特點(diǎn)
  • 微服務(wù)設(shè)計(jì)原則
  • 微服務(wù)優(yōu)缺點(diǎn)
  • SOA架構(gòu)與微服務(wù)架構(gòu)區(qū)別
  • 微服務(wù)最佳實(shí)踐
  • 微服務(wù)間通信
  • • 同步模式
    • 異步模式
  • 使用微服務(wù)面臨的挑戰(zhàn)
  • • 三大挑戰(zhàn)
  • 分布式與微服務(wù)區(qū)別
  • 接口冪等性
  • 分布式事務(wù)
  • 數(shù)據(jù)庫(kù)事務(wù)
  • 分布式CAP和BASE理論
  • • 問題的提出
    • 火車站售票
  • 雙因素身份認(rèn)證
  • 微服務(wù)pact契約測(cè)試
  • 康威定律
  • 什么是CICD
  • JWT（JSON Web Token）
  • • 跨域認(rèn)證的問題
  • 什么是DevOps
  • Ribbon負(fù)載均衡
  • • 服務(wù)器端負(fù)載均衡
  • 服務(wù)熔斷降級(jí)限流
  • 微服務(wù)限流
  • Service Mesh
  • Istio
  • 更多

?

微服務(wù)特點(diǎn)

微服務(wù)特點(diǎn)

簡(jiǎn)單地說，微服務(wù)架構(gòu)是一種以一些微服務(wù)來替代開發(fā)單個(gè)的大而全的應(yīng)用的方法，每一個(gè)小服務(wù)都運(yùn)行在自己的進(jìn)程里，并以輕量級(jí)的機(jī)制（通常是 HTTP RESTful API）來通信。微服務(wù)強(qiáng)調(diào) “小快靈”，任何一個(gè)相對(duì)獨(dú)立的功能服務(wù)不再是一個(gè)模塊，而是一個(gè)獨(dú)立的服務(wù)。

舉個(gè)例子，就是將以前的大兵團(tuán)全功能的部隊(duì)拆分成一個(gè)個(gè)專業(yè)化的小分隊(duì)，各司其職，各自為戰(zhàn)，彼此之間用清晰的接口通信。

類似于真實(shí)世界，以前推崇金字塔結(jié)構(gòu)：從上到下，分層管理，都在一個(gè)大的系統(tǒng)（進(jìn)程）里以內(nèi)部事件或函數(shù)調(diào)用的方法進(jìn)行分工協(xié)作。而當(dāng)前更傾向于扁平化管理，分成若干個(gè)獨(dú)立運(yùn)作的事業(yè)部或小組，各自為戰(zhàn)，卻又以 API/RPC 的方式緊密合作，為一個(gè)或一些用戶提供所需的產(chǎn)品和服務(wù)。

有一利就有一弊，以往一個(gè)程序有幾十個(gè)組件，現(xiàn)在可能就變成了幾十個(gè)微服務(wù)。那么這么多微服務(wù)該如何管理呢？

類似于真實(shí)世界，若干個(gè)小分隊(duì)聯(lián)合作戰(zhàn)得由總參謀部協(xié)調(diào)，彼此之間職責(zé)明確、分工協(xié)作。在軟件世界中就可以前端應(yīng)用及 API gateway 來調(diào)用和協(xié)調(diào)所依賴的微服務(wù)，再加上服務(wù)注冊(cè)（service registry）、服務(wù)發(fā)現(xiàn)（service discovery）等服務(wù)治理功能，依靠強(qiáng)大的度量和監(jiān)控將多個(gè)微服務(wù)整合在一起。

就如 《人月神話》 的作者布魯克斯所提到的 “沒有銀彈”，從來就沒有包治百病的靈丹妙藥，如果有人聲稱有，那他一定是個(gè)騙子。微服務(wù)的問題也不少，小分隊(duì)多了，溝通成本就增加了，性能也可能會(huì)有所下降。

詳細(xì)說明：鏈接

?

微服務(wù)設(shè)計(jì)原則

微服務(wù)架構(gòu)演進(jìn)過程：

近年來我們大家都體會(huì)到了互聯(lián)網(wǎng)、移動(dòng)互聯(lián)帶來的好處，作為 IT 從業(yè)者，在生活中時(shí)刻感受互聯(lián)網(wǎng)好處的同時(shí)，在工作中可能感受的卻是來自自互聯(lián)網(wǎng)的一些壓力，那就是我們傳統(tǒng)企業(yè)的 IT 建設(shè)也是迫切需要轉(zhuǎn)型，需要面向外部客戶，我們也需要應(yīng)對(duì)外部環(huán)境的快速變化、需要快速創(chuàng)新，那么我們的 IT 架構(gòu)也需要向互聯(lián)網(wǎng)企業(yè)學(xué)習(xí)作出相應(yīng)的改進(jìn)，來支撐企業(yè)的數(shù)字化轉(zhuǎn)型。

我們?cè)倏匆幌聭?yīng)用架構(gòu)的演進(jìn)過程，回憶一下微服務(wù)架構(gòu)是如何一步一步進(jìn)化產(chǎn)生的，最早是應(yīng)用是單塊架構(gòu)，后來為了具備一定的擴(kuò)展和可靠性，就有了垂直架構(gòu)，也就是加了個(gè)負(fù)載均衡，接下來是前幾年比較火的 SOA，主要講了應(yīng)用系統(tǒng)之間如何集成和互通，而到現(xiàn)在的微服務(wù)架構(gòu)則是進(jìn)一步在探討一個(gè)應(yīng)用系統(tǒng)該如何設(shè)計(jì)才能夠更好的開發(fā)、管理更加靈活高效。

微服務(wù)架構(gòu)的基本思想就是 “圍繞業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用，讓應(yīng)用可以獨(dú)立的開發(fā)、管理和加速”。

詳細(xì)說明：鏈接

?

微服務(wù)優(yōu)缺點(diǎn)

什么是微服務(wù)

微服務(wù)是用一組小服務(wù)構(gòu)建的一個(gè)應(yīng)用，服務(wù)運(yùn)行在不同的進(jìn)程中，服務(wù)之間通過輕量的通訊機(jī)制進(jìn)行交互，并且服務(wù)可以通過自動(dòng)化部署方式獨(dú)立部署。正因?yàn)槲⒎?wù)架構(gòu)中，服務(wù)之間是相互獨(dú)立的，所以不同的服務(wù)可以使用不同的語言來開發(fā)，或者根據(jù)業(yè)務(wù)的需求使用不同類型的數(shù)據(jù)庫(kù)。

詳細(xì)說明：鏈接

?

SOA架構(gòu)與微服務(wù)架構(gòu)區(qū)別

什么是SOA

SOA（Service Oriented Architecture）面向服務(wù)架構(gòu)，它可以通過網(wǎng)絡(luò)對(duì)松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署、組合和使用。服務(wù)層是 SOA 的接口，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。SOA 是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡(jiǎn)單、精確定義接口進(jìn)行通訊，不涉及底層編程接口和通訊模型。SOA 可以看作是 B/S 模型、XML（標(biāo)準(zhǔn)通用標(biāo)記語言的子集）/Web Service 技術(shù)之后的自然延伸。

SOA 將能夠幫助軟件工程師們站在一個(gè)新的高度理解企業(yè)級(jí)架構(gòu)中的各種組件的開發(fā)、部署形式，它將幫助企業(yè)系統(tǒng)架構(gòu)者以更迅速、更可靠、更具重用性架構(gòu)整個(gè)業(yè)務(wù)系統(tǒng)。較之以往，以 SOA 架構(gòu)的系統(tǒng)能夠更加從容地面對(duì)業(yè)務(wù)的急劇變化。

詳細(xì)說明：鏈接

?

微服務(wù)最佳實(shí)踐

微服務(wù)極大的改變了服務(wù)端引擎的架構(gòu)方式。微服務(wù)不是一個(gè)單一的巨型的用來托管應(yīng)用程序所有業(yè)務(wù)邏輯的代碼庫(kù)，而是反映了分布式系統(tǒng)模型，在該模型中，一組應(yīng)用程序組件協(xié)同工作來滿足業(yè)務(wù)需求。通過遵循十項(xiàng)基本的微服務(wù)最佳實(shí)踐，你可以實(shí)現(xiàn)一個(gè)高效的微服務(wù)生態(tài)系統(tǒng)，從而避免不必要的架構(gòu)復(fù)雜性。

詳細(xì)說明：鏈接

?

微服務(wù)間通信

許多架構(gòu)師已經(jīng)將微服務(wù)之間的通信劃分為同步和異步兩種模式。讓我們一個(gè)一個(gè)來介紹。

同步模式

當(dāng)我們說到同步時(shí)，意思是客戶端向服務(wù)端發(fā)出請(qǐng)求并等待其響應(yīng)。線程將被阻塞，直到它接收到返回。實(shí)現(xiàn)同步通信最主要的協(xié)議是 HTTP。HTTP 可以通過 REST 或 SOAP 實(shí)現(xiàn)。現(xiàn)在 REST 在微服務(wù)方面發(fā)展迅速并超越了 SOAP。對(duì)我而言兩者都很好用。

異步模式

當(dāng)我們談到異步通信時(shí)，它意味著客戶端調(diào)用服務(wù)器，接收到請(qǐng)求的確認(rèn)，然后忘記它。服務(wù)器將處理請(qǐng)求并完成。

現(xiàn)在讓我們討論一下什么時(shí)候需要異步。如果你的應(yīng)用讀操作很多，那么同步可能非常適合，尤其是在需要實(shí)時(shí)數(shù)據(jù)時(shí)。但是，當(dāng)你處理大量寫操作而又不能丟失數(shù)據(jù)記錄時(shí)，你可能希望選擇異步操作，因?yàn)槿绻掠蜗到y(tǒng)宕機(jī)，你繼續(xù)向其發(fā)送同步的調(diào)用，你將丟失請(qǐng)求和業(yè)務(wù)交易。經(jīng)驗(yàn)法則是永遠(yuǎn)不要對(duì)實(shí)時(shí)數(shù)據(jù)讀取使用異步，也永遠(yuǎn)不要對(duì)關(guān)鍵的業(yè)務(wù)交易寫操作使用同步，除非你在寫后立即需要數(shù)據(jù)。你需要在數(shù)據(jù)可用性和數(shù)據(jù)的強(qiáng)一致性之間進(jìn)行選擇。

詳細(xì)說明：鏈接

?

使用微服務(wù)面臨的挑戰(zhàn)

使用微服務(wù)面臨的挑戰(zhàn)主要包括：固有的復(fù)雜性、分區(qū)的數(shù)據(jù)庫(kù)架構(gòu)和波及多個(gè)服務(wù)。

三大挑戰(zhàn)

固有的復(fù)雜性：微服務(wù)架構(gòu)有很多優(yōu)點(diǎn)，當(dāng)然也有其不足。比如微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會(huì)帶來固有的復(fù)雜性。開發(fā)者需要在 RPC 或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。

分區(qū)的數(shù)據(jù)庫(kù)架構(gòu)：另外一個(gè)關(guān)于微服務(wù)的挑戰(zhàn)來自于分區(qū)的數(shù)據(jù)庫(kù)架構(gòu)。在商業(yè)交易系統(tǒng)中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍。這種交易對(duì)于單個(gè)應(yīng)用來說很容易，因?yàn)橹挥幸粋€(gè)數(shù)據(jù)庫(kù)。而在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫(kù)。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)?CAP 理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫(kù)和消息傳遞中間件并不支持這一需求。最終你不得不使用一個(gè)最終一致性的方法，從而對(duì)開發(fā)者提出了更高的要求和挑戰(zhàn)。

波及多個(gè)服務(wù)：一個(gè)問題在于，微服務(wù)架構(gòu)模式應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)。比如，假設(shè)你在完成一個(gè)項(xiàng)目案例，需要修改服務(wù) A、B、C，而 A 依賴 B，B 依賴 C。在單個(gè)應(yīng)用中，你只需要改變相關(guān)模塊，整合變化，部署就好了。相比之下，微服務(wù)架構(gòu)模式就需要考慮相關(guān)改變對(duì)不同服務(wù)的影響。比如，你需要更新服務(wù) C，然后是 B，才是 A，幸運(yùn)的是，許多改變一般只影響一個(gè)服務(wù)，而需要協(xié)調(diào)多服務(wù)的改變很少。

使用微服務(wù)構(gòu)建適合云的新型應(yīng)用是很有意義的，因?yàn)樗屇慵壤昧藱M向擴(kuò)展架構(gòu)，也利用了縱向擴(kuò)展架構(gòu)，還額外得到 API 的組合，且在整個(gè)業(yè)務(wù)中可重復(fù)利用。

可能在每一分鐘都在交付新服務(wù)，這樣你就會(huì)擁有一個(gè)敏捷的且即時(shí)響應(yīng)的應(yīng)用程序平臺(tái)，當(dāng)然這一平臺(tái)一直在不斷改進(jìn)中，微服務(wù)架構(gòu)也在前進(jìn)著。

詳細(xì)說明：鏈接

?

分布式與微服務(wù)區(qū)別

概念

集群是個(gè)物理形態(tài)，分布式是個(gè)工作方式。

分布式：一個(gè)業(yè)務(wù)分拆多個(gè)子業(yè)務(wù)，部署在不同的服務(wù)器上。

集群：同一個(gè)業(yè)務(wù)，部署在多個(gè)服務(wù)器上。

詳細(xì)說明：鏈接

?

接口冪等性

什么是冪等性

冪等（Idempotent）是一個(gè)數(shù)學(xué)與計(jì)算機(jī)學(xué)的概念，常見于抽象代數(shù)中。

f(n) = 1^n // 無論n等于多少，f(n)永遠(yuǎn)值等于1

在編程中，一個(gè)冪等操作的特點(diǎn)是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。冪等函數(shù)或冪等方法是指可以使用相同參數(shù)重復(fù)執(zhí)行，并能獲得相同結(jié)果的函數(shù) / 方法。這些函數(shù) / 方法不會(huì)影響系統(tǒng)狀態(tài)，因此不用擔(dān)心重復(fù)執(zhí)行會(huì)對(duì)系統(tǒng)造成改變。例如：

前端重復(fù)提交選中的數(shù)據(jù)，后臺(tái)也只會(huì)產(chǎn)生對(duì)應(yīng)這個(gè)數(shù)據(jù)的一個(gè)反應(yīng)結(jié)果。

用戶發(fā)起一筆付款請(qǐng)求，就應(yīng)該只扣用戶一次錢，即使遇到網(wǎng)絡(luò)重發(fā)或系統(tǒng) bug 重發(fā)請(qǐng)求，也應(yīng)該之扣一次錢。

發(fā)送驗(yàn)證短息也應(yīng)該只發(fā)一次，同樣的驗(yàn)證短信不應(yīng)該發(fā)送多次。

創(chuàng)建業(yè)務(wù)訂單，一個(gè)業(yè)務(wù)請(qǐng)求只能創(chuàng)建一個(gè)業(yè)務(wù)訂單，創(chuàng)建多個(gè)就會(huì)出大問題。

這些等等很多的業(yè)務(wù)邏輯都需要冪等的特性來支持。

簡(jiǎn)單來理解就是，冪等就是一個(gè)操作，這個(gè)操作不管執(zhí)行多少次，產(chǎn)生的效果和返回的結(jié)果都是一樣的。比如說有一個(gè) getOne () 函數(shù)，無論執(zhí)行這個(gè)函數(shù)多少次，它返回的都是 1，這時(shí)就可以說它是一個(gè)冪等函數(shù)。

詳細(xì)說明：鏈接

分布式事務(wù)

數(shù)據(jù)庫(kù)事務(wù)

在說分布式事務(wù)之前，我們先從數(shù)據(jù)庫(kù)事務(wù)說起。 數(shù)據(jù)庫(kù)事務(wù)可能大家都很熟悉，在開發(fā)過程中也會(huì)經(jīng)常使用到。但是即使如此，可能對(duì)于一些細(xì)節(jié)問題，很多人仍然不清楚。比如很多人都知道數(shù)據(jù)庫(kù)事務(wù)的幾個(gè)特性：原子性(Atomicity )、一致性( Consistency )、隔離性或獨(dú)立性( Isolation)和持久性(Durabilily)，簡(jiǎn)稱就是 ACID。但是再往下比如問到隔離性指的是什么的時(shí)候可能就不知道了，或者是知道隔離性是什么但是再問到數(shù)據(jù)庫(kù)實(shí)現(xiàn)隔離的都有哪些級(jí)別，或者是每個(gè)級(jí)別他們有什么區(qū)別的時(shí)候可能就不知道了。

詳細(xì)說明：鏈接

?

分布式CAP和BASE理論

問題的提出

在計(jì)算機(jī)科學(xué)領(lǐng)域，分布式一致性是一個(gè)相當(dāng)重要且被廣泛探索與論證問題，首先來看三種業(yè)務(wù)場(chǎng)景。

火車站售票

假如說我們的終端用戶是一位經(jīng)常坐火車的旅行家，通常他是去車站的售票處購(gòu)買車票，然后拿著車票去檢票口，再坐上火車，開始一段美好的旅行----一切似乎都是那么和諧。想象一下，如果他選擇的目的地是杭州，而某一趟開往杭州的火車只剩下最后一張車票，可能在同一時(shí)刻，不同售票窗口的另一位乘客也購(gòu)買了同一張車票。假如說售票系統(tǒng)沒有進(jìn)行一致性的保障，兩人都購(gòu)票成功了。而在檢票口檢票的時(shí)候，其中一位乘客會(huì)被告知他的車票無效----當(dāng)然，現(xiàn)代的中國(guó)鐵路售票系統(tǒng)已經(jīng)很少出現(xiàn)這樣的問題了。但在這個(gè)例子中我們可以看出，終端用戶對(duì)于系統(tǒng)的需求非常簡(jiǎn)單：

“請(qǐng)售票給我，如果沒有余票了，請(qǐng)?jiān)谑燮钡臅r(shí)候就告訴我票是無效的”

這就對(duì)購(gòu)票系統(tǒng)提出了嚴(yán)格的一致性要求----系統(tǒng)的數(shù)據(jù)（本例中指的就是那趟開往杭州的火車的余票數(shù)）無論在哪個(gè)售票窗口，每時(shí)每刻都必須是準(zhǔn)確無誤的！

詳細(xì)說明：鏈接

?

雙因素身份認(rèn)證

如您所知，現(xiàn)代世界已經(jīng)進(jìn)入數(shù)字時(shí)代，與此同時(shí)，我們看到了網(wǎng)絡(luò)犯罪和在線欺詐的增加。我懷疑您不認(rèn)識(shí)至少一個(gè)沒有被其 Facebook 個(gè)人資料遭到黑名單攻擊的人，或者是因?yàn)楹诿麊味チ?Twitter 帳戶。如今，大多數(shù)人對(duì)保護(hù)強(qiáng)大的在線安全的價(jià)值極為熟悉，僅是為了保護(hù)自己的銀行帳戶。我們都聽說過登錄名，用戶名和密碼，但是實(shí)際上有多少人知道什么是雙重身份驗(yàn)證？有些人可能聽說過它，但是如果您要求他們向您解釋它，即使大多數(shù)人每天都使用它，您也會(huì)得到一些答案和猜測(cè)。

您可能已經(jīng)聽說過 “雙重身份驗(yàn)證”，但這究竟是什么？好吧，簡(jiǎn)單地說，它是第二層保護(hù)。有些人也稱其為 “多因素身份驗(yàn)證”，只是使您更加困惑。

由于基本的在線安全協(xié)議通常可以簡(jiǎn)化為簡(jiǎn)單的用戶名和密碼，因此網(wǎng)絡(luò)犯罪分子逐漸可以輕松獲取您的個(gè)人信息 。此類數(shù)據(jù)的范圍從與家人，朋友和親人的私人交談到財(cái)務(wù)記錄以及您想避免由第三方掌握的所有其他敏感數(shù)據(jù)。

詳細(xì)說明：鏈接

?

微服務(wù)pact契約測(cè)試

遷移到微服務(wù)對(duì)測(cè)試我們的系統(tǒng)產(chǎn)生了新的挑戰(zhàn)。理論上每個(gè)微服務(wù)都應(yīng)該是隔離的并可以獨(dú)立操作。但在實(shí)踐中一個(gè)服務(wù)如果沒有其他部分通常沒什么用。另一方面，為一個(gè)服務(wù)拉起整個(gè)系統(tǒng)的拓?fù)溥M(jìn)行測(cè)試抵消了微服務(wù)期望帶來的模塊化和封裝。

挑戰(zhàn)在于如何檢驗(yàn)與其他服務(wù)集成后沒有問題。我們希望越早越好。而且我們不想將復(fù)雜的生產(chǎn)環(huán)境重現(xiàn)一遍。一般來說這種檢驗(yàn)是集成功能測(cè)試或叫端到端測(cè)試。但實(shí)際是當(dāng)我們的系統(tǒng)越來越復(fù)雜，端到端帶來的收益越少。 大量的相互依賴導(dǎo)致誤報(bào)和很長(zhǎng)的執(zhí)行周期。 使得測(cè)試變得很難管理與調(diào)試。

這甚至有一個(gè)測(cè)試金字塔理論（最初由 Mike Cohn 在他的著作 ‘Succeeding with Agile’ 中提到）講述了為了優(yōu)化你的投入，你需要更少的高層次的端到端測(cè)試，寫更多的低層次的單元測(cè)試。

詳細(xì)說明：鏈接

?

康威定律

康威定律是馬爾文·康威 1967 提出的：“設(shè)計(jì)系統(tǒng)的架構(gòu)受制于產(chǎn)生這些設(shè)計(jì)的組織的溝通結(jié)構(gòu)。” 通俗的來講：產(chǎn)品必然是其（人員）組織溝通結(jié)構(gòu)的縮影。

跨部門溝通是非常難的，系統(tǒng)各個(gè)模塊的接口也反映了它們之間的信息流動(dòng)和合作方式。

詳細(xì)說明：鏈接

?

什么是CICD

如果你經(jīng)歷體驗(yàn)過傳統(tǒng)的應(yīng)用發(fā)布，你可能就會(huì)覺得 CICD 有足夠吸引你的地方，反之亦然。一般一個(gè)研發(fā)體系中都會(huì)存在多個(gè)角色：開發(fā)、測(cè)試、運(yùn)維。當(dāng)時(shí)我們的應(yīng)用發(fā)布模式可以能是這樣的：

• 「開發(fā)團(tuán)隊(duì)」 在開發(fā)環(huán)境中完成軟件開發(fā)，單元測(cè)試，測(cè)試通過，提交到代碼版本管理庫(kù);
• 「開發(fā)同學(xué)」 通知運(yùn)維同學(xué)項(xiàng)目可以發(fā)布了，然后運(yùn)維同學(xué)下載代碼進(jìn)行打包和構(gòu)建，生成應(yīng)用制品;
• 「運(yùn)維同學(xué)」 使用部署腳本將生成的制品部署到測(cè)試環(huán)境，并提示測(cè)試同學(xué)可以進(jìn)行產(chǎn)品的測(cè)試;
• 「測(cè)試同學(xué)」 開始進(jìn)行手動(dòng)、自動(dòng)化測(cè)試，測(cè)試完成后提醒運(yùn)維同學(xué)可以進(jìn)行預(yù)生產(chǎn)環(huán)境部署;
• 「運(yùn)維同學(xué)」 開始進(jìn)行預(yù)生產(chǎn)環(huán)境部署，然后測(cè)試同學(xué)進(jìn)行測(cè)試，測(cè)試完成后，開始部署生產(chǎn)環(huán)境。

當(dāng)然我描述的可能只是其中的一部分，手動(dòng)操作很多、出現(xiàn)的問題很多。上面看似很流暢的過程，其實(shí)每次構(gòu)建或發(fā)布都可能會(huì)出現(xiàn)問題。未對(duì)每次提交驗(yàn)證、構(gòu)建環(huán)境不一致：開發(fā)人員本地測(cè)試成功后提交代碼，運(yùn)維同學(xué)下載代碼進(jìn)行編譯卻出現(xiàn)了錯(cuò)誤。

詳細(xì)說明：鏈接

?

JWT（JSON Web Token）

JSON Web Token（縮寫 JWT）是目前最流行的跨域認(rèn)證解決方案，本文介紹它的原理和用法。

跨域認(rèn)證的問題

互聯(lián)網(wǎng)服務(wù)離不開用戶認(rèn)證。一般流程是下面這樣。

用戶向服務(wù)器發(fā)送用戶名和密碼。

服務(wù)器驗(yàn)證通過后，在當(dāng)前對(duì)話（session）里面保存相關(guān)數(shù)據(jù)，比如用戶角色、登錄時(shí)間等等。

服務(wù)器向用戶返回一個(gè) session_id，寫入用戶的 Cookie。

用戶隨后的每一次請(qǐng)求，都會(huì)通過 Cookie，將 session_id 傳回服務(wù)器。

服務(wù)器收到 session_id，找到前期保存的數(shù)據(jù)，由此得知用戶的身份。

這種模式的問題在于，擴(kuò)展性（scaling）不好。單機(jī)當(dāng)然沒有問題，如果是服務(wù)器集群，或者是跨域的服務(wù)導(dǎo)向架構(gòu)，就要求 session 數(shù)據(jù)共享，每臺(tái)服務(wù)器都能夠讀取 session。

詳細(xì)說明：鏈接

?

什么是DevOps

DevOps（Development 和 Operations 組合）是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)（應(yīng)用程序/軟件工程）、技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。一些國(guó)際組織對(duì)其定義如下：

DevOps 強(qiáng)調(diào)對(duì)應(yīng)用進(jìn)行快速、小規(guī)模、可迭代的開發(fā)和部署，以更好地應(yīng)對(duì)和滿足客戶的需求。它要求進(jìn)行文化的轉(zhuǎn)變，即將開發(fā)和運(yùn)維只能作為一個(gè)合作的整體來看待，注重提高業(yè)務(wù)價(jià)值，旨在精簡(jiǎn)整個(gè) IT 價(jià)值鏈。

從定義來看，其實(shí) devops 就是為了讓開發(fā)、運(yùn)維和 QA 可以高效協(xié)作的流程。（可以把 DevOps 看作開發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）三者的交集）。

詳細(xì)說明：鏈接

?

Ribbon負(fù)載均衡

服務(wù)器端負(fù)載均衡

負(fù)載均衡是我們處理高并發(fā)、緩解網(wǎng)絡(luò)壓力和進(jìn)行服務(wù)器擴(kuò)容的重要手段之一，但是一般情況下我們所說的負(fù)載均衡通常都是指服務(wù)器端負(fù)載均衡，服務(wù)器端負(fù)載均衡又分為兩種，一種是硬件負(fù)載均衡，還有一種是軟件負(fù)載均衡。

硬件負(fù)載均衡主要通過在服務(wù)器節(jié)點(diǎn)之前安裝專門用于負(fù)載均衡的設(shè)備，常見的如：F5。軟件負(fù)載均衡則主要是在服務(wù)器上安裝一些具有負(fù)載均衡功能的軟件來完成請(qǐng)求分發(fā)進(jìn)而實(shí)現(xiàn)負(fù)載均衡，常見的如：LVS 、 Nginx 、Haproxy。

詳細(xì)說明：鏈接

?

服務(wù)熔斷降級(jí)限流

服務(wù)熔斷降級(jí)限流

針對(duì)下面的情形，如圖所示

當(dāng) Service A 調(diào)用 Service B，失敗多次達(dá)到一定閥值，Service A 不會(huì)再去調(diào) Service B，而會(huì)去執(zhí)行本地的降級(jí)方法！對(duì)于這么一套機(jī)制:在 Spring cloud 中結(jié)合 Hystrix，將其稱為熔斷降級(jí)!

詳細(xì)說明：鏈接

?

微服務(wù)限流

在高并發(fā)訪問下，系統(tǒng)所依賴的服務(wù)的穩(wěn)定性對(duì)系統(tǒng)的影響非常大，依賴有很多不可控的因素，比如網(wǎng)絡(luò)連接變慢，資源突然繁忙，暫時(shí)不可用，服務(wù)脫機(jī)等。我們要構(gòu)建穩(wěn)定、可靠的分布式系統(tǒng)，就必須要有這樣一套容錯(cuò)機(jī)制。常用的的容錯(cuò)技術(shù)如：隔離，降級(jí)，熔斷，限流等策略，本文將詳細(xì)的介紹微服務(wù)中的容錯(cuò)機(jī)制。

詳細(xì)說明：鏈接

?

Service Mesh

Service Mesh 又譯作 “服務(wù)網(wǎng)格”，作為服務(wù)間通信的基礎(chǔ)設(shè)施層。

服務(wù)網(wǎng)格（Service Mesh）是處理服務(wù)間通信的基礎(chǔ)設(shè)施層。它負(fù)責(zé)構(gòu)成現(xiàn)代云原生應(yīng)用程序的復(fù)雜服務(wù)拓?fù)鋪砜煽康亟桓墩?qǐng)求。在實(shí)踐中，Service Mesh 通常以輕量級(jí)網(wǎng)絡(luò)代理陣列的形式實(shí)現(xiàn)，這些代理與應(yīng)用程序代碼部署在一起，對(duì)應(yīng)用程序來說無需感知代理的存在。

詳細(xì)說明：鏈接

?

Istio

什么是Istio？

官方對(duì) Istio 的介紹濃縮成了一句話：

An open platform to connect, secure, control and observe services.

翻譯過來，就是 ”連接、安全加固、控制和觀察服務(wù)的開放平臺(tái)“。開放平臺(tái)就是指它本身是開源的，服務(wù)對(duì)應(yīng)的是微服務(wù)，也可以粗略地理解為單個(gè)應(yīng)用。

詳細(xì)說明：鏈接

更多

原文大綱： 鏈接

更多文章，可以關(guān)注下方公眾號(hào)：

總結(jié)

以上是生活随笔為你收集整理的微服务面试题及详细答案的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。