本文參考 嗨客網 Java 隨筆

前言

本章節記錄了一些常見的微服務面試題及詳細答案，目錄如下：

文章目錄

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

?

微服務特點

微服務特點

簡單地說，微服務架構是一種以一些微服務來替代開發單個的大而全的應用的方法，每一個小服務都運行在自己的進程里，并以輕量級的機制（通常是 HTTP RESTful API）來通信。微服務強調 “小快靈”，任何一個相對獨立的功能服務不再是一個模塊，而是一個獨立的服務。

舉個例子，就是將以前的大兵團全功能的部隊拆分成一個個專業化的小分隊，各司其職，各自為戰，彼此之間用清晰的接口通信。

類似于真實世界，以前推崇金字塔結構：從上到下，分層管理，都在一個大的系統（進程）里以內部事件或函數調用的方法進行分工協作。而當前更傾向于扁平化管理，分成若干個獨立運作的事業部或小組，各自為戰，卻又以 API/RPC 的方式緊密合作，為一個或一些用戶提供所需的產品和服務。

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

類似于真實世界，若干個小分隊聯合作戰得由總參謀部協調，彼此之間職責明確、分工協作。在軟件世界中就可以前端應用及 API gateway 來調用和協調所依賴的微服務，再加上服務注冊（service registry）、服務發現（service discovery）等服務治理功能，依靠強大的度量和監控將多個微服務整合在一起。

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

詳細說明：鏈接

?

微服務設計原則

微服務架構演進過程：

近年來我們大家都體會到了互聯網、移動互聯帶來的好處，作為 IT 從業者，在生活中時刻感受互聯網好處的同時，在工作中可能感受的卻是來自自互聯網的一些壓力，那就是我們傳統企業的 IT 建設也是迫切需要轉型，需要面向外部客戶，我們也需要應對外部環境的快速變化、需要快速創新，那么我們的 IT 架構也需要向互聯網企業學習作出相應的改進，來支撐企業的數字化轉型。

我們再看一下應用架構的演進過程，回憶一下微服務架構是如何一步一步進化產生的，最早是應用是單塊架構，后來為了具備一定的擴展和可靠性，就有了垂直架構，也就是加了個負載均衡，接下來是前幾年比較火的 SOA，主要講了應用系統之間如何集成和互通，而到現在的微服務架構則是進一步在探討一個應用系統該如何設計才能夠更好的開發、管理更加靈活高效。

微服務架構的基本思想就是 “圍繞業務領域組件來創建應用，讓應用可以獨立的開發、管理和加速”。

詳細說明：鏈接

?

微服務優缺點

什么是微服務

微服務是用一組小服務構建的一個應用，服務運行在不同的進程中，服務之間通過輕量的通訊機制進行交互，并且服務可以通過自動化部署方式獨立部署。正因為微服務架構中，服務之間是相互獨立的，所以不同的服務可以使用不同的語言來開發，或者根據業務的需求使用不同類型的數據庫。

詳細說明：鏈接

?

SOA架構與微服務架構區別

什么是SOA

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

SOA 將能夠幫助軟件工程師們站在一個新的高度理解企業級架構中的各種組件的開發、部署形式，它將幫助企業系統架構者以更迅速、更可靠、更具重用性架構整個業務系統。較之以往，以 SOA 架構的系統能夠更加從容地面對業務的急劇變化。

詳細說明：鏈接

?

微服務最佳實踐

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

詳細說明：鏈接

?

微服務間通信

許多架構師已經將微服務之間的通信劃分為同步和異步兩種模式。讓我們一個一個來介紹。

同步模式

當我們說到同步時，意思是客戶端向服務端發出請求并等待其響應。線程將被阻塞，直到它接收到返回。實現同步通信最主要的協議是 HTTP。HTTP 可以通過 REST 或 SOAP 實現。現在 REST 在微服務方面發展迅速并超越了 SOAP。對我而言兩者都很好用。

異步模式

當我們談到異步通信時，它意味著客戶端調用服務器，接收到請求的確認，然后忘記它。服務器將處理請求并完成。

現在讓我們討論一下什么時候需要異步。如果你的應用讀操作很多，那么同步可能非常適合，尤其是在需要實時數據時。但是，當你處理大量寫操作而又不能丟失數據記錄時，你可能希望選擇異步操作，因為如果下游系統宕機，你繼續向其發送同步的調用，你將丟失請求和業務交易。經驗法則是永遠不要對實時數據讀取使用異步，也永遠不要對關鍵的業務交易寫操作使用同步，除非你在寫后立即需要數據。你需要在數據可用性和數據的強一致性之間進行選擇。

詳細說明：鏈接

?

使用微服務面臨的挑戰

使用微服務面臨的挑戰主要包括：固有的復雜性、分區的數據庫架構和波及多個服務。

三大挑戰

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

分區的數據庫架構：另外一個關于微服務的挑戰來自于分區的數據庫架構。在商業交易系統中同時給多個業務分主體更新消息很普遍。這種交易對于單個應用來說很容易，因為只有一個數據庫。而在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。使用分布式交易并不一定是好的選擇，不僅僅是因為 CAP 理論，還因為今天高擴展性的NoSQL數據庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。

波及多個服務：一個問題在于，微服務架構模式應用的改變將會波及多個服務。比如，假設你在完成一個項目案例，需要修改服務 A、B、C，而 A 依賴 B，B 依賴 C。在單個應用中，你只需要改變相關模塊，整合變化，部署就好了。相比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務 C，然后是 B，才是 A，幸運的是，許多改變一般只影響一個服務，而需要協調多服務的改變很少。

使用微服務構建適合云的新型應用是很有意義的，因為它讓你既利用了橫向擴展架構，也利用了縱向擴展架構，還額外得到 API 的組合，且在整個業務中可重復利用。

可能在每一分鐘都在交付新服務，這樣你就會擁有一個敏捷的且即時響應的應用程序平臺，當然這一平臺一直在不斷改進中，微服務架構也在前進著。

詳細說明：鏈接

?

分布式與微服務區別

概念

集群是個物理形態，分布式是個工作方式。

分布式：一個業務分拆多個子業務，部署在不同的服務器上。

集群：同一個業務，部署在多個服務器上。

詳細說明：鏈接

?

接口冪等性

什么是冪等性

冪等（Idempotent）是一個數學與計算機學的概念，常見于抽象代數中。

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

在編程中，一個冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。冪等函數或冪等方法是指可以使用相同參數重復執行，并能獲得相同結果的函數 / 方法。這些函數 / 方法不會影響系統狀態，因此不用擔心重復執行會對系統造成改變。例如：

前端重復提交選中的數據，后臺也只會產生對應這個數據的一個反應結果。

用戶發起一筆付款請求，就應該只扣用戶一次錢，即使遇到網絡重發或系統 bug 重發請求，也應該之扣一次錢。

發送驗證短息也應該只發一次，同樣的驗證短信不應該發送多次。

創建業務訂單，一個業務請求只能創建一個業務訂單，創建多個就會出大問題。

這些等等很多的業務邏輯都需要冪等的特性來支持。

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

詳細說明：鏈接

分布式事務

數據庫事務

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

詳細說明：鏈接

?

分布式CAP和BASE理論

問題的提出

在計算機科學領域，分布式一致性是一個相當重要且被廣泛探索與論證問題，首先來看三種業務場景。

火車站售票

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

“請售票給我，如果沒有余票了，請在售票的時候就告訴我票是無效的”

這就對購票系統提出了嚴格的一致性要求----系統的數據（本例中指的就是那趟開往杭州的火車的余票數）無論在哪個售票窗口，每時每刻都必須是準確無誤的！

詳細說明：鏈接

?

雙因素身份認證

如您所知，現代世界已經進入數字時代，與此同時，我們看到了網絡犯罪和在線欺詐的增加。我懷疑您不認識至少一個沒有被其 Facebook 個人資料遭到黑名單攻擊的人，或者是因為黑名單而失去了 Twitter 帳戶。如今，大多數人對保護強大的在線安全的價值極為熟悉，僅是為了保護自己的銀行帳戶。我們都聽說過登錄名，用戶名和密碼，但是實際上有多少人知道什么是雙重身份驗證？有些人可能聽說過它，但是如果您要求他們向您解釋它，即使大多數人每天都使用它，您也會得到一些答案和猜測。

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

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

詳細說明：鏈接

?

微服務pact契約測試

遷移到微服務對測試我們的系統產生了新的挑戰。理論上每個微服務都應該是隔離的并可以獨立操作。但在實踐中一個服務如果沒有其他部分通常沒什么用。另一方面，為一個服務拉起整個系統的拓撲進行測試抵消了微服務期望帶來的模塊化和封裝。

挑戰在于如何檢驗與其他服務集成后沒有問題。我們希望越早越好。而且我們不想將復雜的生產環境重現一遍。一般來說這種檢驗是集成功能測試或叫端到端測試。但實際是當我們的系統越來越復雜，端到端帶來的收益越少。 大量的相互依賴導致誤報和很長的執行周期。 使得測試變得很難管理與調試。

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

詳細說明：鏈接

?

康威定律

康威定律是馬爾文·康威 1967 提出的：“設計系統的架構受制于產生這些設計的組織的溝通結構。” 通俗的來講：產品必然是其（人員）組織溝通結構的縮影。

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

詳細說明：鏈接

?

什么是CICD

如果你經歷體驗過傳統的應用發布，你可能就會覺得 CICD 有足夠吸引你的地方，反之亦然。一般一個研發體系中都會存在多個角色：開發、測試、運維。當時我們的應用發布模式可以能是這樣的：

• 「開發團隊」 在開發環境中完成軟件開發，單元測試，測試通過，提交到代碼版本管理庫;
• 「開發同學」 通知運維同學項目可以發布了，然后運維同學下載代碼進行打包和構建，生成應用制品;
• 「運維同學」 使用部署腳本將生成的制品部署到測試環境，并提示測試同學可以進行產品的測試;
• 「測試同學」 開始進行手動、自動化測試，測試完成后提醒運維同學可以進行預生產環境部署;
• 「運維同學」 開始進行預生產環境部署，然后測試同學進行測試，測試完成后，開始部署生產環境。

當然我描述的可能只是其中的一部分，手動操作很多、出現的問題很多。上面看似很流暢的過程，其實每次構建或發布都可能會出現問題。未對每次提交驗證、構建環境不一致：開發人員本地測試成功后提交代碼，運維同學下載代碼進行編譯卻出現了錯誤。

詳細說明：鏈接

?

JWT（JSON Web Token）

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

跨域認證的問題

互聯網服務離不開用戶認證。一般流程是下面這樣。

用戶向服務器發送用戶名和密碼。

服務器驗證通過后，在當前對話（session）里面保存相關數據，比如用戶角色、登錄時間等等。

服務器向用戶返回一個 session_id，寫入用戶的 Cookie。

用戶隨后的每一次請求，都會通過 Cookie，將 session_id 傳回服務器。

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

這種模式的問題在于，擴展性（scaling）不好。單機當然沒有問題，如果是服務器集群，或者是跨域的服務導向架構，就要求 session 數據共享，每臺服務器都能夠讀取 session。

詳細說明：鏈接

?

什么是DevOps

DevOps（Development 和 Operations 組合）是一組過程、方法與系統的統稱，用于促進開發（應用程序/軟件工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。一些國際組織對其定義如下：

DevOps 強調對應用進行快速、小規模、可迭代的開發和部署，以更好地應對和滿足客戶的需求。它要求進行文化的轉變，即將開發和運維只能作為一個合作的整體來看待，注重提高業務價值，旨在精簡整個 IT 價值鏈。

從定義來看，其實 devops 就是為了讓開發、運維和 QA 可以高效協作的流程。（可以把 DevOps 看作開發、技術運營和質量保障（QA）三者的交集）。

詳細說明：鏈接

?

Ribbon負載均衡

服務器端負載均衡

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

硬件負載均衡主要通過在服務器節點之前安裝專門用于負載均衡的設備，常見的如：F5。軟件負載均衡則主要是在服務器上安裝一些具有負載均衡功能的軟件來完成請求分發進而實現負載均衡，常見的如：LVS 、 Nginx 、Haproxy。

詳細說明：鏈接

?

服務熔斷降級限流

服務熔斷降級限流

針對下面的情形，如圖所示

當 Service A 調用 Service B，失敗多次達到一定閥值，Service A 不會再去調 Service B，而會去執行本地的降級方法！對于這么一套機制:在 Spring cloud 中結合 Hystrix，將其稱為熔斷降級!

詳細說明：鏈接

?

微服務限流

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

詳細說明：鏈接

?

Service Mesh

Service Mesh 又譯作 “服務網格”，作為服務間通信的基礎設施層。

服務網格（Service Mesh）是處理服務間通信的基礎設施層。它負責構成現代云原生應用程序的復雜服務拓撲來可靠地交付請求。在實踐中，Service Mesh 通常以輕量級網絡代理陣列的形式實現，這些代理與應用程序代碼部署在一起，對應用程序來說無需感知代理的存在。

詳細說明：鏈接

?

Istio

什么是Istio？

官方對 Istio 的介紹濃縮成了一句話：

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

翻譯過來，就是 ”連接、安全加固、控制和觀察服務的開放平臺“。開放平臺就是指它本身是開源的，服務對應的是微服務，也可以粗略地理解為單個應用。

詳細說明：鏈接

更多

原文大綱： 鏈接

更多文章，可以關注下方公眾號：

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。