談?wù)勀銓ξ⒎?wù)的理解，微服務(wù)有哪些優(yōu)缺點(diǎn)？

首先，微服務(wù)是對傳統(tǒng)單體架構(gòu)的一種優(yōu)化。當(dāng)一個單體架構(gòu)隨著業(yè)務(wù)的增加而變得臃腫時，微服務(wù)通過將業(yè)務(wù)拆分成小的獨(dú)立單元來進(jìn)行優(yōu)化。

微服務(wù)的優(yōu)點(diǎn)有以下幾點(diǎn)：

1. 業(yè)務(wù)清晰：拆分微服務(wù)后，每個服務(wù)只負(fù)責(zé)一個獨(dú)立的業(yè)務(wù)，沒有與其他業(yè)務(wù)耦合，使新員工能夠快速理解和上手。
2. 性能優(yōu)化：單體架構(gòu)的部署啟動通常是一個挑戰(zhàn)，而微服務(wù)的拆分使得單個服務(wù)可以獨(dú)立部署，大大提升了部署的靈活性，也能夠?yàn)槊總€業(yè)務(wù)單獨(dú)分配服務(wù)器資源。
3. 技術(shù)更新：單體架構(gòu)的技術(shù)升級往往困難且高風(fēng)險，而微服務(wù)的拆分使得單個微服務(wù)的技術(shù)更新更加迅速。
4. 代碼復(fù)用：微服務(wù)的拆分使得某些服務(wù)的業(yè)務(wù)可以被其他服務(wù)調(diào)用，實(shí)現(xiàn)了代碼復(fù)用的效果。

然而，微服務(wù)也有一些缺點(diǎn)：

1. 系統(tǒng)運(yùn)維復(fù)雜度提升：并發(fā)問題、分布式事務(wù)、網(wǎng)絡(luò)問題等都會影響服務(wù)之間的調(diào)用，增加了系統(tǒng)運(yùn)維的復(fù)雜度。
2. 測試難度增加：一旦出現(xiàn)問題，很難確定是哪個中間服務(wù)出現(xiàn)了問題，增加了測試的難度。
3. 運(yùn)維難度提升：單體架構(gòu)只需要查看單獨(dú)的服務(wù)器資源監(jiān)控即可，而微服務(wù)的拆分導(dǎo)致服務(wù)器數(shù)量增加，監(jiān)控和管理變得更加困難。

SpringCloud和SpringCloudAlibaba都有哪些組件？都解決了什么問題？

SpringCloud和SpringCloud Alibaba是兩個不同的微服務(wù)框架，它們都有一些不同的組件，用于解決不同的問題。

SpringCloud Netflix是SpringCloud的一部分，它包括以下組件：

• Zuul網(wǎng)關(guān)：用于路由請求和負(fù)載均衡。
• Hystrix熔斷器：用于保護(hù)和控制微服務(wù)之間的通信，防止故障傳播。
• Feign：用于聲明式的HTTP客戶端，簡化微服務(wù)之間的調(diào)用。
• Ribbon：用于客戶端負(fù)載均衡，將請求分發(fā)給不同的微服務(wù)實(shí)例。
• Eureka注冊中心：用于服務(wù)的注冊和發(fā)現(xiàn)。
• Config：用于集中管理和分發(fā)微服務(wù)的配置信息。

SpringCloud Alibaba是由阿里巴巴開發(fā)的一套基于SpringCloud的微服務(wù)框架，它包括以下組件：

• Gateway：用于網(wǎng)關(guān)服務(wù)，實(shí)現(xiàn)請求的轉(zhuǎn)發(fā)和路由。
• Sentinel：用于熔斷和限流，保護(hù)微服務(wù)免受高負(fù)載和異常情況的影響。
• Feign：用于聲明式的HTTP客戶端，簡化微服務(wù)之間的調(diào)用。
• Ribbon：用于客戶端負(fù)載均衡，將請求分發(fā)給不同的微服務(wù)實(shí)例。
• Dubbo：用于基于TCP的遠(yuǎn)程調(diào)用，提供更高效的通信。
• Nacos：用于配置管理和服務(wù)注冊中心，提供了更靈活的配置和服務(wù)發(fā)現(xiàn)功能。
• Seata：用于分布式事務(wù)的管理，確保多個微服務(wù)之間的事務(wù)一致性。

分布式事務(wù)如何處理？怎么保證事務(wù)一致性？

需要注意的是，在面試中，確實(shí)分布式事務(wù)不等同于Seata，Seata只是分布式事務(wù)的一種實(shí)現(xiàn)工具，而分布式事務(wù)的處理方法可以有多種選擇，具體要根據(jù)實(shí)際需求和場景來確定。

分布式事務(wù)是在分布式系統(tǒng)中保證多個節(jié)點(diǎn)之間操作的一致性的機(jī)制。在分布式環(huán)境下，由于每個節(jié)點(diǎn)可能使用不同的存儲介質(zhì)或位于不同的數(shù)據(jù)庫實(shí)例中，因此需要特殊的處理機(jī)制來保證事務(wù)的一致性。

為了保證分布式事務(wù)的一致性，可以采用以下幾種方法：

1. http接口回調(diào)：類似于配置支付寶支付回調(diào)一樣，盡最大努力通知，
2. mq：可以使用消息隊列來解決分布式事務(wù)的一致性問題。當(dāng)產(chǎn)生業(yè)務(wù)需求時，將相關(guān)操作放入消息隊列中，并使用事務(wù)消息機(jī)制來保證消息的可靠性傳遞。每個節(jié)點(diǎn)在接收到消息后執(zhí)行相應(yīng)的操作，并將結(jié)果發(fā)送回消息隊列。通過消息隊列，可以實(shí)現(xiàn)分布式事務(wù)的異步處理。
3. redis：當(dāng)需要產(chǎn)生事務(wù)時，可以選擇在redis中設(shè)置初始值，每完成一個就減一，直到0位置提交事物，或者當(dāng)事務(wù)過期進(jìn)行回滾。
4. Seata是一個開源的分布式事務(wù)解決方案，它提供了事務(wù)協(xié)調(diào)器（Transaction Coordinator）和事務(wù)參與者（Transaction Participant）來實(shí)現(xiàn)分布式事務(wù)的管理。Seata支持兩階段提交、三階段提交和Saga模式，并提供了高可用和容錯的特性，可以有效地解決分布式事務(wù)的一致性問題。

• 兩階段提交（2PC）：在兩階段提交中，一個事務(wù)協(xié)調(diào)器（Transaction Coordinator）負(fù)責(zé)協(xié)調(diào)多個參與者（Participants）。在第一階段，協(xié)調(diào)器詢問各參與者是否可以提交事務(wù)，參與者將自己的決策（提交或回滾）返回給協(xié)調(diào)器。在第二階段，協(xié)調(diào)器根據(jù)參與者的決策來決定是否提交或回滾事務(wù)。但是，2PC存在阻塞和單點(diǎn)故障等問題。
• 三階段提交（3PC）：三階段提交在兩階段提交的基礎(chǔ)上增加了一個準(zhǔn)備階段（Preparation Phase）。在準(zhǔn)備階段，協(xié)調(diào)器會發(fā)送預(yù)提交請求給參與者，參與者會在準(zhǔn)備階段進(jìn)行事務(wù)的準(zhǔn)備工作。如果所有參與者都準(zhǔn)備就緒，協(xié)調(diào)器會發(fā)送提交請求；否則，協(xié)調(diào)器會發(fā)送回滾請求。三階段提交相對于兩階段提交，減少了阻塞的時間。
• Saga模式：Saga模式是一種基于補(bǔ)償?shù)姆植际绞聞?wù)處理模式。在Saga模式中，每個參與者負(fù)責(zé)自己的事務(wù)操作，并記錄相應(yīng)的補(bǔ)償操作。如果某個參與者的事務(wù)失敗，Saga會根據(jù)事務(wù)記錄執(zhí)行相應(yīng)的補(bǔ)償操作，以保證整個事務(wù)的一致性。

怎樣拆分微服務(wù)以實(shí)現(xiàn)高內(nèi)聚和低耦合？

1. 避免業(yè)務(wù)之間的代碼耦合，可通過使用RESTful接口進(jìn)行調(diào)用。這樣，每個微服務(wù)都專注于自己的業(yè)務(wù)領(lǐng)域，不會直接依賴其他服務(wù)的具體實(shí)現(xiàn)細(xì)節(jié)。通過定義清晰的接口和協(xié)議，不同的微服務(wù)之間可以進(jìn)行靈活的交互。
2. 不得直接修改其他服務(wù)的底層表數(shù)據(jù)。微服務(wù)之間應(yīng)該通過接口來進(jìn)行數(shù)據(jù)交互，而不是直接操作其他服務(wù)的底層數(shù)據(jù)。這樣可以保證每個微服務(wù)的數(shù)據(jù)獨(dú)立性和一致性，并且減少對其他服務(wù)的依賴。
3. 應(yīng)該逐個業(yè)務(wù)拆解，如果時間充?？梢灾苯尤娌鸱?，但是需要注意風(fēng)險。將整個系統(tǒng)按照業(yè)務(wù)功能進(jìn)行拆分，每個微服務(wù)都承擔(dān)一個特定的業(yè)務(wù)功能。這樣可以將復(fù)雜的系統(tǒng)分解為更小、更易于管理和維護(hù)的部分。但是，在全面拆分之前，需要進(jìn)行充分的規(guī)劃和評估，以確保拆分后的微服務(wù)能夠滿足系統(tǒng)的需求，并且不會引入過多的復(fù)雜性和風(fēng)險。

為了實(shí)現(xiàn)高內(nèi)聚和低耦合，可以采用以下設(shè)計原則和方法：

• 使用服務(wù)間調(diào)用和異步事件驅(qū)動等方式解決低耦合的需求。通過定義清晰的接口和消息傳遞機(jī)制，不同的微服務(wù)可以通過消息、事件或者遠(yuǎn)程調(diào)用來進(jìn)行通信，從而實(shí)現(xiàn)松耦合的架構(gòu)。
• 將自身的業(yè)務(wù)全部集中在一個服務(wù)中，避免業(yè)務(wù)邏輯的擴(kuò)散和分散。每個微服務(wù)應(yīng)該專注于自己的業(yè)務(wù)領(lǐng)域，不涉及其他微服務(wù)的業(yè)務(wù)邏輯。這樣可以保持高內(nèi)聚，每個微服務(wù)都有清晰的職責(zé)和功能。
• 使用HTTP調(diào)用和消息隊列（MQ）消費(fèi)等方法解決業(yè)務(wù)與業(yè)務(wù)之間的聯(lián)系。通過定義合適的接口和消息格式，不同的微服務(wù)可以通過HTTP調(diào)用或者消息隊列來進(jìn)行數(shù)據(jù)交換和通信。這樣可以實(shí)現(xiàn)微服務(wù)之間的解耦和靈活性。

DDD領(lǐng)域驅(qū)動設(shè)計

DDD革命性在于：領(lǐng)域模型準(zhǔn)確反映了業(yè)務(wù)語言，而傳統(tǒng)微服務(wù)數(shù)據(jù)對象除了簡單setter/getter方法外，沒有任何業(yè)務(wù)方法，即失血模型，那么DDD領(lǐng)域模型就是充血模型（業(yè)務(wù)方法定義在實(shí)體對象中）。

DDD只是一種方法論，沒有一個穩(wěn)定的技術(shù)框架。DDD要求領(lǐng)域是跟技術(shù)無關(guān)、跟存儲無關(guān)、跟通信無關(guān)

4層典型DDD分層結(jié)構(gòu)，

1. 展現(xiàn)層：controller層。無業(yè)務(wù)邏輯
2. 應(yīng)用服務(wù)層：此層可以包含查詢邏輯，但核心業(yè)務(wù)邏輯必須下沉到領(lǐng)域?qū)印?/li>
3. 領(lǐng)域服務(wù)層：業(yè)務(wù)在這里組裝。倉儲（資源庫）接口在此層定義。
4. 基礎(chǔ)設(shè)施層：倉儲（資源庫）實(shí)現(xiàn)層+PO持久化層。

展現(xiàn)層負(fù)責(zé)處理用戶界面和用戶輸入輸出。應(yīng)用服務(wù)層協(xié)調(diào)展現(xiàn)層和領(lǐng)域服務(wù)層之間的交互，并執(zhí)行業(yè)務(wù)流程。領(lǐng)域服務(wù)層包含業(yè)務(wù)邏輯的核心部分，負(fù)責(zé)處理領(lǐng)域?qū)嶓w和領(lǐng)域服務(wù)之間的交互。基礎(chǔ)設(shè)施層提供技術(shù)實(shí)現(xiàn)，如數(shù)據(jù)庫訪問、網(wǎng)絡(luò)通信等。

中臺和微服務(wù)有什么關(guān)系

中臺最初是由阿里提出的"小前臺，大中臺"的戰(zhàn)略思想，它并不是一種具體的技術(shù)方式，而是一種企業(yè)戰(zhàn)略和組織架構(gòu)的理念。中臺可以分為數(shù)據(jù)中臺、業(yè)務(wù)中臺和技術(shù)中臺三個方面。數(shù)據(jù)中臺是將企業(yè)內(nèi)部的數(shù)據(jù)資源進(jìn)行整合和開放，實(shí)現(xiàn)數(shù)據(jù)的共享和流轉(zhuǎn)；業(yè)務(wù)中臺是將企業(yè)內(nèi)部的業(yè)務(wù)能力和流程進(jìn)行整合和優(yōu)化，提供給各個業(yè)務(wù)線使用；技術(shù)中臺是將企業(yè)的技術(shù)能力進(jìn)行整合和開放，提供給各個業(yè)務(wù)線使用。中臺的目標(biāo)是通過復(fù)用和共享現(xiàn)有資源，實(shí)現(xiàn)快速的業(yè)務(wù)更新迭代和快速選型。

微服務(wù)是一種架構(gòu)風(fēng)格，將一個應(yīng)用程序拆分為多個小型、獨(dú)立部署的服務(wù)，每個服務(wù)都能夠獨(dú)立運(yùn)行和擴(kuò)展。微服務(wù)提供了較好的技術(shù)支撐，能夠?qū)崿F(xiàn)高內(nèi)聚和低耦合，使系統(tǒng)更加靈活和可維護(hù)。中臺的落地需要微服務(wù)的支撐，通過微服務(wù)的方式來構(gòu)建中臺，可以將中臺拆分為多個小型服務(wù)，每個服務(wù)負(fù)責(zé)特定的業(yè)務(wù)功能或技術(shù)能力。這樣可以實(shí)現(xiàn)中臺的快速發(fā)展和創(chuàng)新。

中臺和微服務(wù)是相輔相成的。中臺提供了資源和能力的整合和共享，為企業(yè)的業(yè)務(wù)線提供支持和服務(wù)；微服務(wù)提供了技術(shù)支撐，實(shí)現(xiàn)了業(yè)務(wù)功能的獨(dú)立和靈活。通過結(jié)合中臺和微服務(wù)，企業(yè)可以實(shí)現(xiàn)業(yè)務(wù)的快速發(fā)展和系統(tǒng)架構(gòu)的靈活性。

你的項(xiàng)目中是怎么保證微服務(wù)敏捷開發(fā)的？

在我們的項(xiàng)目中，我們采用敏捷開發(fā)方法來保證微服務(wù)的快速開發(fā)和迭代。敏捷開發(fā)的核心思想是通過設(shè)立單個任務(wù)目標(biāo)，進(jìn)行業(yè)務(wù)更新的快速迭代，并且可以隨時進(jìn)行上線。為了支持敏捷開發(fā)，我們采取了以下幾個措施：

1. 代碼分支管理：我們使用版本控制工具（如Git）來管理代碼，每個任務(wù)都在自己的分支上進(jìn)行開發(fā)。這樣，不同的任務(wù)可以并行開發(fā)，互不干擾。同時，我們可以隨時將某個分支合并到主分支上進(jìn)行上線。
2. 站立會議：每天早上，我們進(jìn)行短暫的站立會議，通常持續(xù)5-10分鐘。在會議中，每個團(tuán)隊成員都分享自己的任務(wù)進(jìn)度和遇到的問題。這樣可以快速跟進(jìn)每個任務(wù)的進(jìn)度，及時解決問題，并保持團(tuán)隊的協(xié)同性。
3. 進(jìn)度面板：我們使用項(xiàng)目管理工具（如Jira）來跟蹤任務(wù)的進(jìn)度。通過在進(jìn)度面板上創(chuàng)建任務(wù)、設(shè)置優(yōu)先級和狀態(tài)，我們可以清晰地了解每個任務(wù)的狀態(tài)和進(jìn)度。這有助于團(tuán)隊成員之間的溝通和協(xié)作，以及項(xiàng)目整體的可視化管理。
4. 開發(fā)環(huán)境支持：為了支持敏捷開發(fā)，我們建立了多個環(huán)境，包括測試環(huán)境、預(yù)發(fā)布環(huán)境和生產(chǎn)環(huán)境。在測試環(huán)境中，我們可以進(jìn)行功能測試和集成測試，確保代碼的質(zhì)量和穩(wěn)定性。預(yù)發(fā)布環(huán)境用于模擬生產(chǎn)環(huán)境，進(jìn)行最后的驗(yàn)證和性能測試。而生產(chǎn)環(huán)境是最終部署和運(yùn)行的環(huán)境。

通過以上措施，我們能夠?qū)崿F(xiàn)快速、高效的微服務(wù)開發(fā)和部署。敏捷開發(fā)方法使我們能夠快速響應(yīng)業(yè)務(wù)需求的變化，通過快速迭代來持續(xù)提供高質(zhì)量的軟件。同時，站立會議和進(jìn)度面板等工具幫助我們保持團(tuán)隊的協(xié)作和可視化管理。各個環(huán)境的支持則確保我們能夠進(jìn)行充分的測試和驗(yàn)證，最終將穩(wěn)定的代碼部署到生產(chǎn)環(huán)境中。

微服務(wù)的鏈路追蹤、持續(xù)集成、AB發(fā)布要怎么做？

鏈路追蹤

鏈路追蹤是一種監(jiān)控和分析系統(tǒng)中各個組件之間請求路徑和性能的技術(shù)。通常，我們可以使用ELK（Elasticsearch、Logstash、Kibana）等工具來實(shí)現(xiàn)鏈路追蹤。具體步驟如下：

• 在每個微服務(wù)中，添加代碼來生成一個唯一的業(yè)務(wù)id，并將該id傳遞給所有相關(guān)的服務(wù)。
• 將每個服務(wù)的日志發(fā)送到集中式日志系統(tǒng)，如Elasticsearch。
• 使用Kibana等工具來查詢和分析鏈路日志，可以根據(jù)業(yè)務(wù)id關(guān)聯(lián)和追蹤整個請求路徑，以及查看各個環(huán)節(jié)的性能指標(biāo)。

持續(xù)集成

持續(xù)集成是一種軟件開發(fā)實(shí)踐，通過頻繁地將代碼集成到主干分支，并進(jìn)行自動化的構(gòu)建、測試和部署，以確保代碼質(zhì)量和快速交付。實(shí)現(xiàn)持續(xù)集成可以使用以下方法：

• 使用版本控制系統(tǒng)（如Git）管理代碼，并建立主干分支和開發(fā)分支。
• 使用構(gòu)建工具（如Maven、Gradle）來自動化構(gòu)建過程，包括編譯、打包等。
• 使用自動化測試工具（如JUnit）編寫測試用例，并在構(gòu)建過程中執(zhí)行測試。
• 使用持續(xù)集成工具（如Jenkins）設(shè)置流水線，定義構(gòu)建、測試和部署的步驟，并觸發(fā)自動化流程。

AB發(fā)布

AB發(fā)布是一種逐步推出新功能或更新的發(fā)布策略，它可以在生產(chǎn)環(huán)境中逐漸引入新功能，以降低風(fēng)險和影響。具體步驟如下：

• 在預(yù)發(fā)布環(huán)境中部署新功能或更新，只對少部分用戶或流量進(jìn)行測試。
• 監(jiān)控和收集預(yù)發(fā)布環(huán)境的性能和穩(wěn)定性數(shù)據(jù)，確保新功能正常運(yùn)行。
• 根據(jù)收集的數(shù)據(jù)和測試結(jié)果，決定是否繼續(xù)推出新功能。
• 如果新功能通過了測試并且運(yùn)行穩(wěn)定，可以通過全量發(fā)布的方式將其應(yīng)用于整個生產(chǎn)環(huán)境，或者根據(jù)需要進(jìn)行灰度發(fā)布或金絲雀發(fā)布，逐漸擴(kuò)大用戶范圍。

總結(jié)

微服務(wù)的應(yīng)用級別確實(shí)相對簡單，但在實(shí)際開發(fā)中仍有一些技術(shù)難點(diǎn)需要解決。對于微服務(wù)組件的使用，確實(shí)不存在太大差距，但在設(shè)計和開發(fā)過程中需要積累經(jīng)驗(yàn)。學(xué)習(xí)微服務(wù)的上手時間相對較短，可能只需一周到一個月的時間。然而，設(shè)計經(jīng)驗(yàn)和技術(shù)難點(diǎn)是需要個人長期積累的，不能急于求成。

因此，在使用和開發(fā)微服務(wù)時，更應(yīng)該關(guān)注方案思考，展示自己對該領(lǐng)域的理解和見解。這樣能夠體現(xiàn)出你對問題的思考深度和解決方案的創(chuàng)新性。希望這次面試種子題目的解答能夠幫助你應(yīng)對面試官的問題！文章來源地址http://www.zghlxwxcb.cn/news/detail-646431.html

到了這里，關(guān)于微服務(wù)面試必讀：拆分、事務(wù)、設(shè)計的綜合解析與實(shí)踐指南的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！