概念

什麼是微服務？你是怎麼理解微服務的？

微服務架構是一種架構模式或者説是一種架構風格，它提倡將單一應用程序劃分為一組小的服務，每個服務運行在其獨立的自己的進程中，服務之間相互協調、互相配合，為用户提供最終價值。服務之間採用輕量級的通信機制互相溝通（通常是基於HTTP的RESTful API）,每個服務都圍繞着具體的業務進行構建，並且能夠被獨立的構建在生產環境、類生產環境等。另外，應避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建，可以有一個非常輕量級的集中式管理來協調這些服務，可以使用不同的語言來編寫服務，也可以使用不同的數據存儲。

通俗地來講：

微服務就是一個獨立的職責單一的服務應用程序。在 intellij idea 工具裏面就是用maven開發的一個個獨立的module，具體就是使用springboot 開發的一個小的模塊，處理單一專業的業務邏輯，一個模塊只做一個事情。

微服務強調的是服務大小，關注的是某一個點，具體解決某一個問題/落地對應的一個服務應用，可以看做是idea 裏面一個 module。

微服務有什麼好處？

微服務優點很多，但是我們通常説一個東西好肯定會跟另一個東西比較， 通常説微服務好會和單體項目進行比較。以下是微服務相對於單體項目的一些顯著好處：

單體項目的缺點：

• 可擴展性受限： 單體應用通常在可擴展性方面受到限制，因為整個應用程序必須一起擴展。這意味着即使只有一個組件需要更多資源，也必須擴展整個應用程序，這可能會導致資源浪費。
• 難以維護和更新： 隨着時間的推移，單體應用程序往往變得越來越龐大和複雜，難以理解、維護和更新。每次修改都可能引發意想不到的影響。
• 高風險： 單體應用程序中的一個小錯誤或故障可能會導致整個應用程序崩潰，因此存在較高的風險。此外，長時間不更新的單體應用可能會受到安全威脅。
• 技術棧限制： 單體應用程序通常使用相同的技術棧，這可能會限制您在項目中使用最新的技術和工具的能力。
• 團隊協作複雜： 單體應用程序的所有組件都在一個代碼庫中，這可能導致開發團隊之間的衝突和協作問題，尤其在大型團隊中更為突出。

微服務項目的優點：

• 可擴展性： 微服務架構允許您根據需要獨立地擴展單個服務，而不必擴展整個應用程序，這提供了更高的可擴展性。
• 靈活性和快速開發： 微服務允許開發團隊獨立設計、開發和部署服務，這提高了靈活性，允許團隊更快地推出新功能和更新。
• 故障隔離和容錯性： 單個微服務的故障通常不會影響其他服務，提高了應用程序的容錯性，同時更容易識別和解決故障。
• 技術多樣性： 微服務允許您選擇適合每個服務的最佳技術棧，這有助於充分利用各種技術和工具的優勢。
• 獨立部署和維護： 微服務可以獨立部署和維護，這減少了風險，使團隊能夠更快速地進行修復和更新。
• 團隊協作： 不同團隊可以獨立工作在不同服務上，這提高了團隊的自治和協作能力，減少了衝突。

總的來説，微服務項目通過提供更高的可擴展性、靈活性和容錯性，以及更容易管理的部署和維護過程，有助於克服單體應用程序的一些限制和缺點。但請注意，微服務架構也會引入一些新的複雜性，需要更多的管理和監控。

單體應用、SOA 和微服務架構有什麼區別

單體應用、SOA和微服務架構都是不同的架構風格，適用於不同的情況。

單體應用像一個整體，所有的功能都打包在一個應用中。這種架構風格容易部署和測試，但隨着系統規模的擴大，它的靈活性和可維護性會降低。

SOA是一種面向服務的架構風格，將系統劃分為多個獨立的服務。這些服務可以通過網絡調用，並且可以跨平台、跨語言進行交互。SOA的優點是提供了跨系統的服務複用和鬆散耦合的交互方式，但實現SOA需要投入大量的工作，包括服務的定義、接口的選擇、協議的制定等。

微服務架構進一步將系統劃分為多個小型、獨立的服務，每個服務都是一個單獨的應用程序，可以獨立部署、運行和擴展。微服務架構具有更高的靈活性和可維護性，適用於複雜的大型系統，強調服務的自治和獨立性。但是，實施微服務架構也需要投入大量的工作，包括服務的定義、通信機制的選擇、服務的管理等。

分佈式和微服務有什麼區別?

分佈式系統和微服務架構是兩個相關但不同的概念，它們的注重點其實不太一樣。

分佈式系統：它是由多台計算機或多節點組成的系統，各節點之間通過網絡進行通信和協作，共同完成一個或多個共享的任務也就是説分佈式的各個節點其實目標是一致的，之所以要分佈式只是為了有更好的能力，能更快、更高效地承接任務。比如常見的分佈式文件系統、分佈式數據庫。

微服務：其實是一種服務的架構風格，它主要是為了把一個大而全的服務，拆分成多個可以獨立、鬆耦合的服務單元，為了讓這些服務單元可以獨立部署、運行、管理比如電商服務拆分成微服務，可以分為商品服務、用户服務、訂單服務、庫存服務等等

什麼是Spring Cloud ？

Spring cloud 流應用程序啓動器是基於 Spring Boot 的 Spring 集成應用程序，提供與外部系統的集成。Spring cloud Task，一個生命週期短暫的微服務框架，用於快速構建執行有限數據處理的應用程序。

Spring cloud 流應用程序啓動器是基於 Spring Boot 的 Spring 集成應用程序，提供與外部系統的集成。Spring cloud Task，一個生命週期短暫的微服務框架，用於快速構建執行有限數據處理的應用程序。

現在有哪些流行的微服務解決方案？

目前最主流的微服務開源解決方案有三種：

Dubbo：

• Dubbo 是一個高性能、輕量級的 Java 微服務框架，最初由阿里巴巴（Alibaba）開發並於2011年開源。它提供了服務註冊與發現、負載均衡、容錯、分佈式調用等功能，後來一度停止維護，在近兩年，又重新開始迭代，並推出了Dubbo3。
• Dubbo 使用基於 RPC（Remote Procedure Call）的通信模型，具有較高的性能和可擴展性。它支持多種傳輸協議（如TCP、HTTP、Redis）和序列化方式（如JSON、Hessian、Protobuf），可根據需求進行配置。
• Dubbo更多地被認為是一個高性能的RPC（遠程過程調用）框架，一些服務治理功能依賴於第三方組件實現，比如使用ZooKeeper、Apollo等等。

Spring Cloud Netflix：

• Spring Cloud Netflix 是 Spring Cloud 的一個子項目，結合了 Netflix 開源的多個組件，但是Netflix自2018年停止維護和更新Netflix OSS項目，包括Eureka、Hystrix等組件，所以Spring Cloud Netflix也逐漸進入了維護模式。
• 該項目包含了許多流行的 Netflix 組件，如Eureka（服務註冊與發現）、Ribbon（客户端負載均衡）、Hystrix（斷路器）、Zuul（API 網關）等。它們都是高度可擴展的、經過大規模實踐驗證的微服務組件。

Spring Cloud Alibaba：

• Spring Cloud Alibaba 是 Spring Cloud 的另一個子項目，與阿里巴巴的分佈式應用開發框架相關。它提供了一整套與 Alibaba 生態系統集成的解決方案。
• 該項目包括 Nacos（服務註冊與發現、配置管理）、Sentinel（流量控制、熔斷降級）、RocketMQ（消息隊列）等組件，以及與 Alibaba Cloud（阿里雲）的集成。它為構建基於 Spring Cloud 的微服務架構提供了豐富的選項。

這三種方案有什麼區別：

-在面試中，微服務一般主要討論的是Spring Cloud Netflix，其次是Spring Cloud Alibaba，Dubbo更多的是作為一個RPC框架來問。

Spring Cloud有什麼優勢

使用 Spring Boot 開發分佈式微服務時，我們面臨以下問題

• 與分佈式系統相關的複雜性-這種開銷包括網絡問題，延遲開銷，帶寬問題，安全問題。
• 服務發現-服務發現工具管理羣集中的流程和服務如何查找和互相交談。它涉及一個服務目錄，在該目錄中註冊服務，然後能夠查找並連接到該目錄中的服務。
• 冗餘-分佈式系統中的冗餘問題。
• 負載平衡 --負載平衡改善跨多個計算資源的工作負荷，諸如計算機，計算機集羣，網絡鏈路，中央處理單元，或磁盤驅動器的分佈。
• 性能-問題 由於各種運營開銷導致的性能問題。
• 部署複雜性-Devops 技能的要求。

説下微服務有哪些組件？

微服務給系統開發帶來了一些問題和挑戰，如服務調用的複雜性、分佈式事務的處理、服務的動態管理等。為了更好地解決這些問題和挑戰，各種微服務治理的組件應運而生，充當微服務架構的基石和支撐。

微服務的各個組件和常見實現：

• 註冊中心：用於服務的註冊與發現，管理微服務的地址信息。常見的實現包括：
  • Spring Cloud Netflix：Eureka、Consul
  • Spring Cloud Alibaba：Nacos
• 配置中心：用於集中管理微服務的配置信息，可以動態修改配置而不需要重啓服務。常見的實現包括：
  • Spring Cloud Netflix：Spring Cloud Config
  • Spring Cloud Alibaba：Nacos Config
• 遠程調用：用於在不同的微服務之間進行通信和協作。常見的實現保包括：
  • RESTful API：如RestTemplate、Feign
  • RPC（遠程過程調用）：如Dubbo、gRPC
• API網關：作為微服務架構的入口，統一暴露服務，並提供路由、負載均衡、安全認證等功能。常見的實現包括：
  • Spring Cloud Netflix：Zuul、Gateway
  • Spring Cloud Alibaba：Gateway、Apisix等
• 分佈式事務：保證跨多個微服務的一致性和原子性操作。常見的實現包括：
  • Spring Cloud Alibaba：Seata
• 熔斷器：用於防止微服務之間的故障擴散，提高系統的容錯能力。常見的實現包括：
  • Spring Cloud Netflix：Hystrix
  • Spring Cloud Alibaba：Sentinel、Resilience4j
• 限流和降級：用於防止微服務過載，對請求進行限制和降級處理。常見的實現包括：
  • Spring Cloud Netflix：Hystrix
  • Spring Cloud Alibaba：Sentinel
• 分佈式追蹤和監控：用於跟蹤和監控微服務的請求流程和性能指標。常見的實現包括：
  • Spring Cloud Netflix：Spring Cloud Sleuth + Zipkin
  • Spring Cloud Alibaba：SkyWalking、Sentinel Dashboard

Spring、SpringMVC、Springboot、 Springcloud 的區別是什麼？

Spring

Spring是一個生態體系（也可以説是技術體系），是集大成者，它包含了Spring Framework、Spring Boot、Spring Cloud等。它是一個輕量級控制反轉(IOC)和麪向切面(AOP)的容器框架，為開發者提供了一個簡易的開發方式。

Spring的核心特性思想之一IOC，它實現了容器對Bean對象的管理、降低組件耦合，使各層服務解耦。

Spring的另一個核心特性就是AOP，面向切面編程。面向切面編程需要將程序邏輯分解為稱為所謂關注點的不同部分。跨越應用程序多個點的功能稱為跨領域問題，這些跨領域問題在概念上與應用程序的業務邏輯分離。有許多常見的例子，如日誌記錄，聲明式事務，安全性，緩存等。

如果説IOC依賴注入可以幫助我們將應用程序對象相互分離，那麼AOP可以幫助我們將交叉問題與它們所影響的對象分離。二者目的都是使服務解耦，使開發簡易。

當然，除了Spring 的兩大核心功能，還有如下這些，如：

• Spring JDBC
• Spring MVC
• Spring ORM
• Spring Test

SpringMVC

Spring與MVC可以更好地解釋什麼是SpringMVC，MVC為現代web項目開發的一種很常見的模式，簡言之C（控制器）將V（視圖、用户客户端）與M（模塊，業務）分開構成了MVC ，業內常見的MVC模式的開發框架有Struts。

Spring MVC是Spring的一部分，主要用於開發WEB應用和網絡接口，它是Spring的一個模塊，通過DispatcherServlet, ModelAndView 和View Resolver，讓應用開發變得很容易。

SpringBoot

SpringBoot是一套整合了框架的框架。

它的初衷：解決Spring框架配置文件的繁瑣、搭建服務的複雜性。

它的設計理念：約定優於配置（convention over configuration）。

基於此理念實現了自動配置，且降低項目搭建的複雜度。

搭建一個接口服務，通過SpringBoot幾行代碼即可實現。基於Spring Boot，不是説原來的配置沒有了，而是Spring Boot有一套默認配置，我們可以把它看做比較通用的約定，而Spring Boot遵循的是約定優於配置原則，同時，如果你需要使用到Spring以往提供的各種複雜但功能強大的配置功能，Spring Boot一樣支持。

在Spring Boot中，你會發現引入的所有包都是starter形式，如：

• spring-boot-starter-web-services，針對SOAP Web Services
• spring-boot-starter-web，針對Web應用與網絡接口
• spring-boot-starter-jdbc，針對JDBC
• spring-boot-starter-cache，針對緩存支持

Spring Boot是基於 Spring 框架開發的用於開發 Web 應用程序的框架，它幫助開發人員快速搭建和配置一個獨立的、可執行的、基於 Spring 的應用程序，從而減少了繁瑣和重複的配置工作。

Spring Cloud

Spring Cloud事實上是一整套基於Spring Boot的微服務解決方案。它為開發者提供了很多工具，用於快速構建分佈式系統的一些通用模式，例如：配置管理、註冊中心、服務發現、限流、網關、鏈路追蹤等。Spring Boot是build anything，而Spring Cloud是coordinate anything，Spring Cloud的每一個微服務解決方案都是基於Spring Boot構建的。

SpringBoot和SpringCloud的區別？

SpringBoot專注於快速方便得開發單個個體微服務。

SpringCloud是關注全局的微服務協調整理治理框架，它將SpringBoot開發的一個個單體微服務整合並管理起來，為各個微服務之間提供，配置管理、服務發現、。斷路器、路由、微代理、事件總線、全局鎖、決策競選、分佈式會話等等集成服務

SpringBoot可以離開SpringCloud獨立使用開發項目， 但是SpringCloud離不開SpringBoot ，屬於依賴的關係.

SpringBoot專注於快速、方便得開發單個微服務個體，SpringCloud關注全局的服務治理框架。

Spring Cloud各個微服務之間為什麼要用http交互？難道不慢嗎？

Spring Cloud是一個為分佈式微服務架構構建應用程序的開發工具箱，是Spring Boot的擴展，通過各種微服務組件的集成，極大地簡化了微服務應用程序的構建和開發。在分佈式系統中，各個微服務之間的通信是非常重要的，而HTTP作為通信協議具有普遍性和可擴展性，是Spring Cloud微服務架構中主流的通信方式。

儘管使用HTTP作為微服務之間的通信協議存在一定的網絡開銷，但是這種不可避免的網絡開銷遠低於我們所能得到的好處。使用HTTP通信可以實現鬆耦合和異步通信，微服務之間可以彼此獨立地進行開發和測試，單個微服務的故障不會影響整個系統的運行，也可以支持各種不同的技術棧之間的互操作性。

另外，使用HTTP作為通信協議還具有優秀的可擴展性。HTTP協議定義了不同的請求方法（例如 GET、POST、DELETE 等），不同請求方法的擴展格式也很靈活，可以用來傳遞各種類型的數據和格式，同時HTTP協議支持緩存，減少重複性的數據傳輸和帶寬開銷。

當然，為了提高微服務之間的通信效率，我們也可以通過一些優化手段來減少HTTP協議的網絡開銷。例如，使用數據壓縮和緩存技術來壓縮和緩存請求和響應，減少網絡數據傳輸量和響應時間；使用負載均衡技術來合理地分配請求和響應，避免單個微服務出現性能瓶頸；使用高速緩存技術來緩存請求和響應，避免重複的請求和響應等等。

因此，Spring Cloud各個微服務之間使用HTTP交互是一個比較成熟的選擇。雖然它可能存在一些網絡開銷，但是在實際應用中，這種開銷是可以優化和控制的，甚至可以提高系統的可擴展性和可靠性。

註冊中心

註冊中心是用來幹什麼的？

註冊中心是用來管理和維護分佈式系統中各個服務的地址和元數據的組件。它主要用於實現服務發現和服務註冊功能。

總結一下注冊中心的作用：

• 服務註冊：各個服務在啓動時向註冊中心註冊自己的網絡地址、服務實例信息和其他相關元數據。這樣，其他服務就可以通過註冊中心獲取到當前可用的服務列表。
• 服務發現：客户端通過向註冊中心查詢特定服務的註冊信息，獲得可用的服務實例列表。這樣客户端就可以根據需要選擇合適的服務進行調用，實現了服務間的解耦。
• 負載均衡：註冊中心可以對同一服務的多個實例進行負載均衡，將請求分發到不同的實例上，提高整體的系統性能和可用性。
• 故障恢復：註冊中心能夠監測和檢測服務的狀態，當服務實例發生故障或下線時，可以及時更新註冊信息，從而保證服務能夠正常工作。
• 服務治理：通過註冊中心可以進行服務的配置管理、動態擴縮容、服務路由、灰度發佈等操作，實現對服務的動態管理和控制。

為什麼需要服務註冊發現?

在分佈式系統中，服務的數量通常會有很多，而且規模還不是一般地大，與此同時，服務的部署和變化也會很頻繁，因此，如果要依賴人工去維護這些服務的關係，實現服務的管理以及調用就會變得非常困難。

服務註冊與發現的作用就是為了解決這個問題，它通過註冊中心來維護服務生產者以及服務消費者之間的關係。當服務啓動之後，其就會向註冊中心註冊自己的信息，比如服務名稱、服務端口、服務的P地址等，當服務消費者需要調用某個服務的時候，它會向註冊中心發起查詢請求，獲取對應服務的信息，然後向生產者服務發送請求。如果一些服務上線或者下線，註冊中心都可以主動通知消費者，這就動態地實現了服務的上下線，在高峯期加機器，低峯期減機器，減少了管理的成本，十分方便。也可以方便實現服務的監控、管理等等。

SpringCloud可以選擇哪些註冊中心？

SpringCloud可以與多種註冊中心進行集成，常見的註冊中心包括：

• Eureka：Eureka 是 Netflix 開源的服務發現框架，具有高可用、彈性、可擴展等特點，並與 Spring Cloud 集成良好，已閉源。ap
• Consul：Consul 是一種分佈式服務發現和配置管理系統，由 HashiCorp 開發。它提供了服務註冊、服務發現、健康檢查、鍵值存儲等功能，並支持多數據中心部署。c/ap
• ZooKeeper：ZooKeeper 是 Apache 基金會開源的分佈式協調服務，可以用作服務註冊中心。它具有高可用、一致性、可靠性等特點。 cp
• Nacos：Nacos 是阿里巴巴開源的一個動態服務發現、配置管理和服務管理平台。它提供了服務註冊和發現、配置管理、動態 DNS 服務等功能。 ap
• etcd：etcd 是 CoreOS 開源的一種分佈式鍵值存儲系統，可以被用作服務註冊中心。它具有高可用、強一致性、分佈式複製等特性。 cp

什麼是 Eureka?

Eureka 是一個 Spring Cloud Netflix 的一款老牌註冊中心，設計用於實現雲端部署微服務架構中的服務註冊與發現功能。

在技術領域，特別是分佈式系統中，Eureka作為一個基於 RESTFul 的服務，主要職責包括:

• 服務註冊：允許服務實例向 EurekaServer 註冊自己的信息。這樣，每個服務實例都能讓 Eureka Server 獲取到自身服務以及地址等信息。
• 服務發現：Eureka客户端可以從 Eureka server 查詢到註冊的服務實例信息，進而實現客户端的軟負載均像和故障轉移。服務消費者可以查詢 Eureka Sener 獲取到提供某一服務的所有服務實例列表，然後根據策略選擇一個實例進行通信。
• 健康檢查：Eureka 通過心跳機制監控服務實例的狀態，確保服務列表的時效性和)準確性，如果某個服務實例宕機或天法響應，Eureka Senver將從註冊表中移除該實例，避免了將流量導向不可用的服務(默認 90s)。
• 高可用性：Eureka 通過部署多個 Eureka Server 實例並相互複製註冊信息，可以構建高可用的服務註冊中心集羣，提高系統的整體穩定性。

在 Spring Cloud 中，Eureka 被集成作為服務註冊與服務發現的核心組件,通過 @EnableEurekaServer 和 @EnableEurekaClient 註解可以輕鬆實現服務註冊中心或服務客户端

Eureka 在2020年後 Netflix 宣佈不再積極維護，但它仍然是許多現有系統中服務註冊中心的實現方案，並目有社區進行維護，

Spring Cloud如何實現服務的註冊?

服務發佈時，指定對應的服務名，將服務註冊到 註冊中心(Eureka 、Zookeeper)。

註冊中心加@EnableEurekaServer，服務用@EnableDiscoveryClient，然後用ribbon或feign進行服務直接的調用發現。

説下Eureka、ZooKeeper、Nacos的區別？

可以看到Eureka和ZooKeeper的最大區別是一個支持AP，一個支持CP，Nacos既支持既支持AP，也支持CP。

關於CAP相關理論和概念可以看這篇文章：CAPl理論

• Nacos除了作為註冊中心外，還提供了配置管理、服務發現和事件通知等功能。Nacos默認情況下采用AP架構保證服務可用性，CP架構底層採用Raft協議保證數據的一致性。Nacos適合作為微服務註冊中心和配置管理中心，支持快速發現、配置管理和服務治理等功能。
• Eureka是隻提供註冊中心功能的工具，它的設計理念是AP，即保證服務的可用性，不保證一致性。Eureka的各個節點之間相互註冊，只要有一台Eureka節點存在，整個微服務就可以通訊。
• 而Zookeeper相比前兩者，除了註冊中心的功能，還提供了分佈式協調服務，比如通知、公告、配置管理等。Zookeeper採用CP設計，可以保證數據的一致性，但是犧牲了一部分服務的可用性。Zookeeper適用於需要分佈式協調服務的場景，如配置管理、命名服務等。

請説説Eureka和zookeeper 的區別？

Zookeeper保證了CP，Eureka保證了AP。

CAP理論詳情請看CAP理論

A：高可用

C：一致性

P：分區容錯性

1. 當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用。也就是説，服務註冊功能對高可用性要求比較高，但zk會出現這樣一種情況，當master節點因為網絡故障與其他節點失去聯繫時，剩餘節點會重新選leader。問題在於，選取leader時間過長，30 ~ 120s，且選取期間zk集羣都不可用，這樣就會導致選取期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大概率會發生的事，雖然服務能夠恢復，但是漫長的選取時間導致的註冊長期不可用是不能容忍的。
2. Eureka保證了可用性，Eureka各個節點是平等的，幾個節點掛掉不會影響正常節點的工作，剩餘的節點仍然可以提供註冊和查詢服務。而Eureka的客户端向某個Eureka註冊或發現時發生連接失敗，則會自動切換到其他節點，只要有一台Eureka還在，就能保證註冊服務可用，只是查到的信息可能不是最新的。除此之外，Eureka還有自我保護機制，如果在15分鐘內超過85%的節點沒有正常的心跳，那麼Eureka就認為客户端與註冊中心發生了網絡故障，此時會出現以下幾種情況：
   1. Eureka不在從註冊列表中移除因為長時間沒有收到心跳而應該過期的服務。
   2. Eureka仍然能夠接受新服務的註冊和查詢請求，但是不會被同步到其他節點上（即保證當前節點仍然可用）
   3. 當網絡穩定時，當前實例新的註冊信息會被同步到其他節點。

因此，Eureka可以很好地應對因網絡故障導致部分節點失去聯繫的情況，而不會像Zookeeper那樣使整個微服務癱瘓

Nacos和Eureka的區別

Nacos和Eureka整體結構類似，服務註冊、服務拉取、心跳等待，但是也存在一些差異：

• Nacos與eureka的共同點

  • 都支持服務註冊和服務拉取
  • 都支持服務提供者心跳方式做健康檢測

• Nacos與Eureka的區別

  • Nacos支持服務端主動檢測提供者狀態：臨時實例採用心跳模式，非臨時實例採用主動檢測模式
  • 臨時實例心跳不正常會被剔除，非臨時實例則不會被剔除
  • Nacos支持服務列表變更的消息推送模式，服務列表更新更及時
  • Nacos集羣默認採用AP方式，當集羣中存在非臨時實例時，採用CP模式；Eureka採用AP方式

Eureka實現原理了解嗎？

Eureka的實現原理，大概可以從這幾個方面來看：

1. 服務註冊與發現: 當一個服務實例啓動時，它會向Eureka Server發送註冊請求，將自己的信息註冊到註冊中心。Eureka Server會將這些信息保存在內存中，並提供REST接口供其他服務查詢。服務消費者可以通過查詢服務實例列表來獲取可用的服務提供者實例，從而實現服務的發現。
2. 服務健康檢查: Eureka通過心跳機制來檢測服務實例的健康狀態。服務實例會定期向Eureka Server發送心跳，也就是續約，以表明自己的存活狀態。如果Eureka Server在一定時間內沒有收到某個服務實例的心跳，則會將其標記為不可用，並從服務列表中移除，下線實例。
3. 服務負載均衡: Eureka客户端在調用其他服務時，會從本地緩存中獲取服務的註冊信息。如果緩存中沒有對應的信息，則會向Eureka Server發送查詢請求。Eureka Server會返回一個可用的服務實例列表給客户端，客户端可以使用負載均衡算法選擇其中一個進行調用。

其它的註冊中心，如Nacos、Consul等等，在服務註冊和發現上，實現原理都是大同小異。

Eureka Server怎麼保證高可用？

Eureka Server保證高可用，主要通過這三個方面來實現：

• 多實例部署: 通過將多個Eureka Server實例部署在不同的節點上，可以實現高可用性。當其中一個實例發生故障時，其他實例仍然可以提供服務，並保持註冊信息的一致性。
• 服務註冊信息的複製: 當一個服務實例向Eureka Server註冊時，每個Eureka Server實例都會複製其他實例的註冊信息，以保持數據的一致性。當某個Eureka Server實例發生故障時，其他實例可以接管其工作，保證整個系統的正常運行。
• 自我保護機制: Eureka還具有自我保護機制。當Eureka Server節點在一定時間內沒有接收到心跳時，它會進入自我保護模式。在自我保護模式下，Eureka Server不再剔除註冊表中的服務實例，以保護現有的註冊信息。這樣可以防止由於網絡抖動或其他原因導致的誤剔除，進一步提高系統的穩定性。

eureka自我保護機制是什麼?

什麼是自我保護模式？

1. 自我保護的條件：一般情況下，微服務在 Eureka 上註冊後，會每 30 秒發送心跳包，Eureka 通過心跳來判斷服務是否健康，同時會定期刪除超過 90 秒沒有發送心跳服務。
2. 有兩種情況會導致 Eureka Server 收不到微服務的心跳
   1. 是微服務自身的原因
   2. 是微服務與 Eureka 之間的網絡故障

通常(微服務的自身的故障關閉)只會導致個別服務出現故障，一般不會出現大面積故障，而(網絡故障)通常會導致 Eureka Server 在短時間內無法收到大批心跳。考慮到這個區別，Eureka 設置了一個閥值，當判斷掛掉的服務的數量超過閥值時，Eureka Server 認為很大程度上出現了網絡故障，將不再刪除心跳過期的服務。

3. 那麼這個閥值是多少呢？

15 分鐘之內是否低於 85%；Eureka Server 在運行期間，會統計心跳失敗的比例在 15 分鐘內是否低於 85%,這種算法叫做 Eureka Server 的自我保護模式。

為什麼要自我保護？

1. 因為同時保留"好數據"與"壞數據"總比丟掉任何數據要更好，當網絡故障恢復後，這個 Eureka 節點會退出"自我保護模式"。
2. Eureka 還有客户端緩存功能(也就是微服務的緩存功能)。即便 Eureka 集羣中所有節點都宕機失效，微服務的 Provider 和 Consumer都能正常通信。
3. 微服務的負載均衡策略會自動剔除死亡的微服務節點。

Consul是什麼?

Consul 是 HasiCorp 公司用 Golang 開發的一款開源的服務註冊中心以及配置中心，提供了服務註冊與發現、健康檢查、KV 存儲、多數據中心支持、DNS 和 HTTP API 接口等功能，而且提供了可視化控制枱用於操作。

Consul 的優點有很多

• 基於 Raft 協議，比較簡潔
• 支持簡單檢查，同時支持 HTTP 和 DNS 協議
• 支持跨數據中心的 WAN 集羣
• 提供了跨平台的圖形化界面，支持 Windows、Linux、Mac 等系統

單體服務拆成多個微服務，這些服務之間如何自動發現彼此?具體原理是什麼?

這些微服務之間一般需要藉助註冊中心，然後通過服務發現機制定位彼此。

核心原理是：服務啓動時將自己的地址和元數據註冊到註冊中心(Nacos、Consul)，調用方通過註冊中心動態獲取可用服務實例列表，然後基於負載均衡策略(如輪詢、隨機)發起請求。

整個過程還得依賴心跳檢測確保實例狀態實時更新，例如老服務的下線，新服務的上線。

每個微服務啓動後，會向註冊中心(如Nacos、Consul)發送自己的信息(IP、端口、服務名等)，告訴註冊中心“我上線了”

註冊中心會存儲所有已註冊服務的信息，並通過心跳檢測(如每隔5秒發一次“我還活着”)監控服務狀態，若某服務超過一定時間沒心跳，註冊中心會標記它為“下線”

當服務 A需要調用服務B時，會向註冊中心查詢服務 B的所有可用實例(IP+端口)，然後從這些實例中選一個(如輪詢、隨機)發起請求。