微服務(wù)架構(gòu)

秒殺微服務(wù)架構(gòu)圖

項目地址可以參考：秒殺系統(tǒng)

1 微服務(wù)基本概念

1.1 微服務(wù)的理解（優(yōu)缺點）：

優(yōu)勢：可以獨立開發(fā)、部署和擴展每個服務(wù)；更好的故障隔離；可以根據(jù)服務(wù)的需求使用不同的技術(shù)棧；更容易組織圍繞業(yè)務(wù)能力的團隊。
劣勢：可能需要更多的資源來運行所有服務(wù)；網(wǎng)絡(luò)延遲可能會增加；需要更多的跨服務(wù)管理工作（例如服務(wù)發(fā)現(xiàn)，負(fù)載均衡，斷路器）；數(shù)據(jù)一致性可能更難保證。

1.2 服務(wù)拆分的原則及實踐

• 單一職責(zé)原則：每個服務(wù)都應(yīng)該只做一件事情，這樣可以使其獨立開發(fā)、部署和擴展。
• 業(yè)務(wù)驅(qū)動：服務(wù)的邊界應(yīng)該根據(jù)業(yè)務(wù)能力來確定，而不是根據(jù)技術(shù)考慮。
• 數(shù)據(jù)一致性：考慮數(shù)據(jù)如何在多個服務(wù)之間共享和保持一致性。
• 松散耦合：服務(wù)之間應(yīng)該盡可能地解耦，這樣一個服務(wù)的變化不會影響到其它服務(wù)。

2 微服務(wù)網(wǎng)關(guān)

2.1 你說的單一網(wǎng)關(guān)的情況，流量來自于微服務(wù)系統(tǒng)內(nèi)部嗎還是用戶呢？

在一個單一網(wǎng)關(guān)的微服務(wù)架構(gòu)中，這個網(wǎng)關(guān)通常處理來自于兩個主要源的流量：

1. 外部用戶：網(wǎng)關(guān)負(fù)責(zé)處理所有從外部用戶或者第三方系統(tǒng)發(fā)出的請求。這可能包括來自于用戶界面的請求、來自于第三方API的請求，或者其他來源的請求。

2. 內(nèi)部服務(wù)：網(wǎng)關(guān)還可能負(fù)責(zé)處理來自于系統(tǒng)內(nèi)部的服務(wù)間通信。例如，一個服務(wù)可能需要通過網(wǎng)關(guān)請求另一個服務(wù)的資源。

這個單一網(wǎng)關(guān)成為了所有請求的統(tǒng)一入口，提供了路由、認(rèn)證、授權(quán)、限流、熔斷、負(fù)載均衡等功能。然而，這種設(shè)計也可能帶來一些問題，例如單點故障、性能瓶頸等。因此，在設(shè)計微服務(wù)系統(tǒng)時，需要根據(jù)實際的需求和約束來選擇合適的網(wǎng)關(guān)策略。

2.2 一個java的微服務(wù)系統(tǒng)中有幾個網(wǎng)關(guān)？

在一個Java的微服務(wù)系統(tǒng)中，網(wǎng)關(guān)的數(shù)量并不固定，這完全取決于系統(tǒng)的設(shè)計和需求。網(wǎng)關(guān)服務(wù)是微服務(wù)架構(gòu)中的重要組件，它通常負(fù)責(zé)路由、認(rèn)證、授權(quán)、限流、熔斷、負(fù)載均衡等功能，為微服務(wù)提供統(tǒng)一的入口。

以下是幾種可能的網(wǎng)關(guān)設(shè)計策略：

1. 單一網(wǎng)關(guān)：在一些簡單的微服務(wù)架構(gòu)中，可能只有一個網(wǎng)關(guān)服務(wù)，負(fù)責(zé)處理所有進入系統(tǒng)的請求。

2. 多網(wǎng)關(guān)：在更復(fù)雜的微服務(wù)架構(gòu)中，可能會有多個網(wǎng)關(guān)，每個網(wǎng)關(guān)負(fù)責(zé)處理特定類型的請求。例如，可以有一個網(wǎng)關(guān)專門用于處理內(nèi)部服務(wù)間的通信，另一個網(wǎng)關(guān)用于處理外部用戶的請求。

3. 分域網(wǎng)關(guān)：在某些大規(guī)?；蛘叨嘧鈶舻奈⒎?wù)架構(gòu)中，可能會根據(jù)業(yè)務(wù)領(lǐng)域或者租戶劃分多個網(wǎng)關(guān)。

在實際的系統(tǒng)設(shè)計中，微服務(wù)的網(wǎng)關(guān)數(shù)量取決于多種因素，包括系統(tǒng)的規(guī)模、業(yè)務(wù)復(fù)雜度、性能要求、安全性要求等等。所以，并沒有一個固定的答案來確定微服務(wù)系統(tǒng)中應(yīng)該有幾個網(wǎng)關(guān)。

3 微服務(wù)系統(tǒng)內(nèi)部的調(diào)用，比如A調(diào)用服務(wù)B這種需要經(jīng)過網(wǎng)關(guān)嗎？

在微服務(wù)系統(tǒng)的設(shè)計中，服務(wù)之間的調(diào)用是否需要經(jīng)過網(wǎng)關(guān)取決于具體的設(shè)計決策。這主要受到以下兩種設(shè)計模式的影響：

1. 直接服務(wù)調(diào)用：在某些情況下，一個服務(wù)（服務(wù)A）可能會直接調(diào)用另一個服務(wù)（服務(wù)B）。這種設(shè)計模式允許服務(wù)之間的通信不需要經(jīng)過網(wǎng)關(guān)，通?？梢蕴岣咝阅懿p少延遲。然而，這種模式需要在每個服務(wù)中實現(xiàn)鑒權(quán)、限流等功能，可能會增加設(shè)計和開發(fā)的復(fù)雜性。

2. 通過網(wǎng)關(guān)調(diào)用：在另一些情況下，服務(wù)之間的調(diào)用可能需要經(jīng)過網(wǎng)關(guān)。這種設(shè)計模式允許所有的服務(wù)間通信都通過同一點進行，可以在這一點上實現(xiàn)統(tǒng)一的鑒權(quán)、限流、熔斷等功能。這種模式可以簡化服務(wù)的設(shè)計和開發(fā)，但可能會增加延遲并成為系統(tǒng)的單點故障。

以上都是可能的設(shè)計決策，實際的選擇取決于微服務(wù)系統(tǒng)的具體需求和約束。例如，對于一些非常大或者復(fù)雜的微服務(wù)系統(tǒng)，可能會選擇混合的模式，其中一部分服務(wù)調(diào)用通過網(wǎng)關(guān)，而另一部分服務(wù)調(diào)用則直接進行。

4 請求的接收和返回路徑

1 一個請求到達(dá)最終的業(yè)務(wù)服務(wù)器可能會經(jīng)過nginx網(wǎng)關(guān)，微服務(wù)網(wǎng)關(guān)等中間層，最終業(yè)務(wù)服務(wù)器執(zhí)行完請求后的響應(yīng)是按照原路返回嗎還是直接打給發(fā)出請求的客戶端？為什么?

1. 一個網(wǎng)絡(luò)請求在到達(dá)最終的業(yè)務(wù)服務(wù)器之前，確實可能會經(jīng)過多個中間層，比如nginx代理，微服務(wù)網(wǎng)關(guān)等。當(dāng)業(yè)務(wù)服務(wù)器完成請求處理并生成響應(yīng)后，這個響應(yīng)通常會按照原路返回，也就是說，它會首先返回到它來時所經(jīng)過的那些中間層，然后才會返回到發(fā)出請求的客戶端。

   這樣做的原因有以下幾點：

   • 層級架構(gòu)和安全性：請求和響應(yīng)都需要經(jīng)過網(wǎng)絡(luò)中的各層，因為這樣的層級架構(gòu)有助于管理網(wǎng)絡(luò)流量，增強安全性，比如說防火墻、代理服務(wù)器、緩存服務(wù)器等都可以在請求和響應(yīng)的路上對其進行處理。

   • 性能優(yōu)化：有些中間層可能會對響應(yīng)進行緩存或者其他形式的處理以提高性能。比如，一個代理服務(wù)器可能會緩存響應(yīng)，這樣當(dāng)它收到相同的請求時，就可以直接從緩存中提供響應(yīng)，而無需再次將請求發(fā)送到業(yè)務(wù)服務(wù)器。

   • 轉(zhuǎn)換或擴展功能：有些中間層可能會修改響應(yīng)，或者添加一些額外的功能。例如，一個API網(wǎng)關(guān)可能會將后端服務(wù)的響應(yīng)轉(zhuǎn)換為客戶端能理解的格式，或者在響應(yīng)中添加一些額外的頭信息。

2 現(xiàn)在互聯(lián)網(wǎng)大廠，使用的也是你說的這種返回方式嗎？舉一些例子

2. 是的，互聯(lián)網(wǎng)大廠，包括Google，F(xiàn)acebook，Amazon，阿里巴巴，騰訊等，也通常使用這種按原路返回的方式處理請求和響應(yīng)。這些公司都有大量的用戶和巨大的網(wǎng)絡(luò)流量，所以他們都會使用一種層級的網(wǎng)絡(luò)架構(gòu)來管理和優(yōu)化他們的網(wǎng)絡(luò)流量。

   舉例來說：

   • Google使用他們的全球負(fù)載均衡器和HTTP(S)負(fù)載均衡器，以及全球的緩存服務(wù)來處理請求和響應(yīng)。

   • Amazon則通過他們的AWS服務(wù)，如Elastic Load Balancing(ELB)和Amazon CloudFront等來處理和優(yōu)化他們的網(wǎng)絡(luò)流量。

   • 阿里巴巴和騰訊也有自己的大規(guī)模負(fù)載均衡系統(tǒng)和緩存服務(wù)來處理他們的網(wǎng)絡(luò)請求和響應(yīng)。他們的系統(tǒng)會根據(jù)請求的類型和目標(biāo)，將請求和響應(yīng)路由到正確的服務(wù)器或服務(wù)。

   這些例子都說明了在復(fù)雜的網(wǎng)絡(luò)環(huán)境中，按原路返回的方式可以提供更好的控制和優(yōu)化，這就是為什么這種方式在業(yè)界被廣泛使用的原因。

5 那nginx不也算是一種網(wǎng)關(guān)嗎？ 和 一般我們說的網(wǎng)關(guān)有什么區(qū)別？

Nginx是一個開源的Web服務(wù)器，同時也可以用作反向代理服務(wù)器、郵件代理服務(wù)器以及通用的TCP/UDP代理服務(wù)器。在微服務(wù)架構(gòu)中，Nginx常常被用作一個網(wǎng)關(guān)，負(fù)責(zé)處理來自外部的請求并將其路由到合適的服務(wù)。

然而，Nginx本質(zhì)上是一個反向代理服務(wù)器，它的主要職責(zé)是接受來自客戶端的請求并將其轉(zhuǎn)發(fā)到后端的服務(wù)器，然后將后端服務(wù)器的響應(yīng)返回給客戶端。Nginx可以處理靜態(tài)內(nèi)容，提供負(fù)載均衡和TLS/SSL處理等功能。

當(dāng)我們在微服務(wù)中談?wù)摼W(wǎng)關(guān)時，通常指的是API網(wǎng)關(guān)。API網(wǎng)關(guān)是微服務(wù)架構(gòu)的一部分，它提供了比Nginx更多的功能，包括請求路由、服務(wù)發(fā)現(xiàn)、負(fù)載均衡、身份驗證和授權(quán)、限流和熔斷、API組合和協(xié)議轉(zhuǎn)換等。

簡單來說，Nginx可以作為一個簡單的API網(wǎng)關(guān)，但在微服務(wù)中，我們通常會使用一些更強大的工具作為API網(wǎng)關(guān)，例如Zuul，Spring Cloud Gateway，Kong等。這些工具可以提供更為復(fù)雜和強大的功能，以滿足微服務(wù)架構(gòu)的需求。

6 所以說nginx不是單獨部署，而是類似于tomcat，netty服務(wù)器那樣存在于每一個微服務(wù)的實例中？

不完全是這樣。Nginx實際上通常被部署為一個獨立的服務(wù)，它作為一個反向代理，坐在所有后端微服務(wù)前面。它接收從客戶端發(fā)出的請求，然后將這些請求轉(zhuǎn)發(fā)給相應(yīng)的微服務(wù)。

舉個例子，假設(shè)你有一個微服務(wù)架構(gòu)，其中包含一個用戶服務(wù)、一個訂單服務(wù)和一個產(chǎn)品服務(wù)。你可以在這些服務(wù)前面部署一個Nginx服務(wù)，當(dāng)收到一個請求時，Nginx可以根據(jù)請求的URL和其他規(guī)則將請求轉(zhuǎn)發(fā)給用戶服務(wù)、訂單服務(wù)或產(chǎn)品服務(wù)。

Nginx和Tomcat、Netty這些應(yīng)用服務(wù)器的關(guān)系是不同的。Tomcat和Netty通常被部署在每個微服務(wù)的實例中，它們負(fù)責(zé)接收并處理從Nginx（或其他反向代理）轉(zhuǎn)發(fā)過來的請求。

在微服務(wù)架構(gòu)中，你可能會有多個Nginx實例以實現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。例如，你可能會在一個負(fù)載均衡器（如Amazon ELB或Google Cloud Load Balancer）后面運行多個Nginx實例。當(dāng)負(fù)載均衡器接收到一個請求時，它可以將請求轉(zhuǎn)發(fā)給任何一個可用的Nginx實例。然后，Nginx實例將請求轉(zhuǎn)發(fā)給相應(yīng)的微服務(wù)。

所以，Nginx并不是存在于每一個微服務(wù)實例中，而是作為反向代理存在于微服務(wù)和客戶端之間。

7 一個java微服務(wù)項目的api-gateway子項目，如何寫代碼才能讓流量走自己這兒

在Java的微服務(wù)架構(gòu)中，API Gateway子項目的主要任務(wù)是接收所有來自客戶端的請求，并將這些請求路由到相應(yīng)的服務(wù)。如果你正在使用Spring Cloud（一種流行的Java微服務(wù)框架），你可以使用Spring Cloud Gateway或者Netflix Zuul作為你的API網(wǎng)關(guān)。

以下是一個簡單的例子，說明如何使用Spring Cloud Gateway作為API網(wǎng)關(guān)：

1. 首先，你需要在你的項目中加入Spring Cloud Gateway的依賴。在你的pom.xml文件中，添加以下代碼：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>

2. 然后，你需要在你的application.yml或者application.properties文件中定義路由規(guī)則。例如：

spring:
  cloud:
    gateway:
      routes:
      - id: user_service
        uri: lb://user-service // lb是load balance的縮寫，uri表示如果有權(quán)限，就會被路由到//user-service服務(wù)中。
        predicates:
        - Path=/user/**
      - id: order_service
        uri: lb://order-service
        predicates:
        - Path=/order/**

關(guān)于配置中的id, uri和predicates的關(guān)系，我們來具體解析一下：

1. id: 這是路由的唯一標(biāo)識符，用于標(biāo)記一個特定的路由規(guī)則，比如user_service就是一個路由的ID。

2. uri: 這是路由的目標(biāo)地址。lb://user-service表示這個路由將流量導(dǎo)向名為"user-service"的服務(wù)。"lb://"是一個特殊的URI scheme，表示使用Ribbon客戶端負(fù)載均衡。也就是說，這個路由將請求轉(zhuǎn)發(fā)到"user-service"這個服務(wù)，由Ribbon進行負(fù)載均衡。

3. predicates: 這是路由的斷言，決定了哪些請求可以進入這個路由。例如，- Path=/user/**表示只有路徑以"/user/"開頭的請求才會進入這個路由，其他的請求不會進入。

因此，根據(jù)上述配置，如果一個請求的URL路徑以"/user/“開頭，那么這個請求就會被路由到"user-service"這個服務(wù)上。同樣，如果一個請求的URL路徑以”/order/"開頭，那么這個請求就會被路由到"order-service"這個服務(wù)上。在這個過程中，會使用Ribbon進行負(fù)載均衡。

在這個例子中，所有以/user/開頭的請求將被路由到用戶服務(wù)，所有以/order/開頭的請求將被路由到訂單服務(wù)。

4. 最后，確保你的API網(wǎng)關(guān)服務(wù)在所有微服務(wù)的前面，也就是說，所有來自客戶端的請求首先到達(dá)API網(wǎng)關(guān)服務(wù)，然后由API網(wǎng)關(guān)服務(wù)將請求路由到相應(yīng)的服務(wù)。

需要注意的是，上面的例子假設(shè)你已經(jīng)設(shè)置好了服務(wù)發(fā)現(xiàn)（如Eureka或Consul），并且你的其他微服務(wù)已經(jīng)注冊到了服務(wù)發(fā)現(xiàn)中。lb://user-service和lb://order-service這樣的URI表示這些請求將被路由到注冊到服務(wù)發(fā)現(xiàn)中的對應(yīng)服務(wù)。

Spring Cloud Gateway是Spring官方推出的第二代API網(wǎng)關(guān)框架，用來替代Netflix Zuul，用于微服務(wù)架構(gòu)中的API網(wǎng)關(guān)服務(wù)。上述配置是Spring Cloud Gateway的路由配置，其中每一個"-"開頭的項代表一個路由規(guī)則。

8 sprin

g cloud是不是一種rpc框架還是什么
Spring Cloud是一種構(gòu)建和管理微服務(wù)的框架，它提供了在分布式系統(tǒng)（如配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線等）中常用模式的實現(xiàn)。所以，它并不是一個RPC框架，而是一個用于構(gòu)建、部署和管理微服務(wù)的工具集。

RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用）框架是一種通訊協(xié)議，它允許在一個網(wǎng)絡(luò)中的一臺計算機（客戶端）調(diào)用另一臺計算機（服務(wù)器）上的程序或者服務(wù)。常見的Java RPC框架有Dubbo、gRPC等。

Spring Cloud可以和這些RPC框架配合使用，實現(xiàn)微服務(wù)之間的通訊。例如，Spring Cloud提供了對gRPC的支持，可以方便地在Spring Cloud應(yīng)用中使用gRPC。

另外，Spring Cloud主要基于HTTP/REST進行通信，但也支持其他通訊方式。例如，Spring Cloud Stream支持使用消息中間件（如RabbitMQ、Kafka）進行異步通訊，Spring Cloud OpenFeign提供了聲明式的REST客戶端等。

所以，Spring Cloud和RPC框架在微服務(wù)架構(gòu)中扮演的角色是不同的，但他們可以一起使用，實現(xiàn)微服務(wù)的分布式通訊。

9 spring cloud的各大功能模塊應(yīng)該是解耦合的吧

是的，Spring Cloud的設(shè)計理念是微服務(wù)架構(gòu)中各種通用模式的解耦合實現(xiàn)。它包含一系列的子項目（模塊），這些模塊大多都是可插拔的，并且可以根據(jù)具體的需求和場景來選擇使用。每個模塊都關(guān)注于微服務(wù)架構(gòu)中的一個特定領(lǐng)域。以下是一些主要的Spring Cloud模塊：

1. Spring Cloud Netflix：提供了一系列Netflix OSS組件的集成，包括Eureka（服務(wù)發(fā)現(xiàn)）、Hystrix（斷路器）、Zuul（API網(wǎng)關(guān)）、Ribbon（客戶端負(fù)載均衡）等。

2. Spring Cloud Gateway：作為Spring Cloud Netflix Zuul的替代品，提供了一種構(gòu)建API網(wǎng)關(guān)的簡單方式。

3. Spring Cloud Config：用于集中式配置管理，支持從遠(yuǎn)程服務(wù)器（如Git）讀取配置。

4. Spring Cloud Sleuth：用于分布式追蹤，兼容Zipkin。

5. Spring Cloud OpenFeign：提供了一種聲明式的REST客戶端。

6. Spring Cloud Stream：用于構(gòu)建消息驅(qū)動的微服務(wù)，支持多種消息中間件。

7. Spring Cloud Bus：用于傳播集群中的狀態(tài)變化或事件，以實現(xiàn)服務(wù)之間的通信。

8. Spring Cloud Security：在微服務(wù)下提供安全機制，如OAuth2。

每個Spring Cloud模塊都有自己的依賴，可以單獨引入到項目中。因此，可以根據(jù)項目需求選擇使用哪些模塊，從而在微服務(wù)的開發(fā)中實現(xiàn)功能的解耦。

10 URL和URI的區(qū)別，為什么api網(wǎng)關(guān)進行路由時使用了URI？

URI（Uniform Resource Identifier）和URL（Uniform Resource Locator）都是用于識別資源的字符串，它們的設(shè)計目的是為了在網(wǎng)絡(luò)上定位和獲取資源。然而，它們之間有一些重要的區(qū)別。

• URI：是一個字符串，用來唯一標(biāo)識抽象或物理資源的標(biāo)準(zhǔn)。它的目的是為了在網(wǎng)絡(luò)上識別某一實體或者說是資源。它包括兩個部分，URL和URN（Uniform Resource Name）。

• URL：是URI的一個子集，也是一個字符串，表示某一互聯(lián)網(wǎng)上可達(dá)的資源。它表示的是資源的地點（在互聯(lián)網(wǎng)上的位置）。它的語法包括協(xié)議、域名、端口、路徑等部分。

簡單來說，每個URL都是URI，但并非每個URI都是URL。因為URI還包括URN，URN只命名資源而不指定如何定位資源。

在進行路由時，通常使用URI而不是URL，原因如下：

• 使用URI可以提供更大的靈活性。比如在你的配置中的“l(fā)b://user-service”，這個URI并沒有提供具體的位置信息（如IP地址和端口），而是提供了一個邏輯名。這個邏輯名在運行時會被解析成實際的位置，這樣就可以在不改變配置的情況下動態(tài)地改變服務(wù)的位置。

• 使用URI可以更好地抽象服務(wù)。在微服務(wù)架構(gòu)中，我們通常不關(guān)心服務(wù)的具體位置，而是關(guān)心服務(wù)的功能。通過使用URI，我們可以將服務(wù)當(dāng)作一個黑盒，不關(guān)心服務(wù)的內(nèi)部實現(xiàn)和位置，只關(guān)心服務(wù)的接口和行為。這是微服務(wù)架構(gòu)的一種重要理念。

11 一個微服務(wù)系統(tǒng)應(yīng)該有鑒權(quán)中心，什么時候請求會經(jīng)過它呢？

一個微服務(wù)系統(tǒng)的鑒權(quán)中心（通常被稱為認(rèn)證中心或授權(quán)中心）主要負(fù)責(zé)系統(tǒng)的用戶認(rèn)證（確定用戶是誰）和授權(quán)（確定用戶可以做什么）。

以下是幾種常見的情況，請求可能會經(jīng)過鑒權(quán)中心：

1. 用戶登錄: 用戶在進行登錄操作時，請求會發(fā)送到鑒權(quán)中心。鑒權(quán)中心會驗證用戶的憑據(jù)（如用戶名和密碼），如果憑據(jù)有效，它將發(fā)放一個token給用戶，以標(biāo)記用戶的會話狀態(tài)。

2. 服務(wù)間調(diào)用: 在微服務(wù)架構(gòu)中，服務(wù)之間可能會互相調(diào)用。為了保證服務(wù)間調(diào)用的安全性，通常也會經(jīng)過鑒權(quán)中心進行鑒權(quán)和授權(quán)。例如，服務(wù)A調(diào)用服務(wù)B之前，可能需要先向鑒權(quán)中心請求一個授權(quán)令牌。

3. 訪問受保護資源: 當(dāng)用戶嘗試訪問受保護的資源時（比如某個需要特定權(quán)限才能訪問的API），請求需要經(jīng)過鑒權(quán)中心。鑒權(quán)中心會檢查用戶的token，然后決定用戶是否有足夠的權(quán)限來訪問這個資源。

在實際的設(shè)計中，為了提高性能和可用性，鑒權(quán)中心的部分功能可能會通過其他組件實現(xiàn)，比如使用API網(wǎng)關(guān)來進行token的檢查，使用分布式緩存來保存token等。但無論怎樣，鑒權(quán)中心都是整個系統(tǒng)中負(fù)責(zé)處理安全問題的核心組件。

12 如果使用jwt，是不是就可以讓API網(wǎng)關(guān)進行token檢查

是的，你的理解是正確的。使用JWT（JSON Web Token）可以讓API網(wǎng)關(guān)來進行Token檢查，而不需要每次請求都去鑒權(quán)中心（例如一個OAuth2服務(wù)器）驗證。這種方法可以大大提高系統(tǒng)的性能，因為API網(wǎng)關(guān)通常會比鑒權(quán)中心更接近服務(wù)的調(diào)用者。

JWT是一種開放標(biāo)準(zhǔn)（RFC 7519），它定義了一種簡潔的，自包含的方法用于通信雙方之間安全地傳輸信息。JWT可以通過數(shù)字簽名（例如使用HMAC算法或者RSA）來驗證這個信息，并且可以被加密。

在微服務(wù)架構(gòu)中，一種常見的使用JWT的場景是：鑒權(quán)中心在用戶登錄成功后，生成一個JWT，然后將這個JWT作為令牌發(fā)放給用戶。當(dāng)用戶向API網(wǎng)關(guān)發(fā)送請求時，會在請求的頭部（通常是Authorization頭部）攜帶這個令牌。API網(wǎng)關(guān)收到請求后，可以使用預(yù)先共享的秘鑰來驗證JWT的簽名，然后解析JWT中的payload部分，從而獲取到用戶的身份信息和權(quán)限信息。

使用JWT的好處是：一旦JWT被生成，就可以獨立驗證和解析，無需再去查詢數(shù)據(jù)庫或者鑒權(quán)中心，這樣可以大大減輕鑒權(quán)中心的負(fù)載，并且提高系統(tǒng)的響應(yīng)速度。

12.1 jwt的校驗機制

13 一個ip地址為什么可以對應(yīng)多個這樣的域名呢

13.1 我可以增加一個這樣的映射嗎？比如 127.0.0.1 secondkill-user.xxx

可以的。你可以在你的hosts文件中添加任何你需要的域名到IP地址的映射，包括子域名。例如，你可以添加127.0.0.1 secondkill-user.xxx到你的hosts文件。

這樣，當(dāng)你的應(yīng)用或者你的瀏覽器試圖連接到secondkill-user.xxx時，系統(tǒng)將會把它解析為127.0.0.1。但是請記住，這個配置只在你的本地機器上有效。對于其他機器或者在互聯(lián)網(wǎng)上，secondkill-user.xxx的解析需要一個真實的DNS服務(wù)器來處理。

同樣要注意的是，如果你正在使用的域名（在這個例子中是.xxx）是一個真實的頂級域名，那么在真實的網(wǎng)絡(luò)環(huán)境中這可能會導(dǎo)致沖突。因此，當(dāng)你在開發(fā)環(huán)境中使用hosts文件映射時，通常會使用不存在的頂級域名，例如.local，.test等。

14 springboot中的tomcat

15 JWT相關(guān)

15.1 JWT與鑒權(quán)中心

JSON Web Tokens (JWT) 是一種開放標(biāo)準(zhǔn)（RFC 7519），定義了一種緊湊、自包含的方式，用于通信雙方之間以 JSON 對象的形式安全地傳輸信息。這種信息可以被驗證和信任，因為它是數(shù)字簽名的。JWT 可以使用秘密（通過 HMAC 算法）或使用 RSA 或 ECDSA 的公/私鑰對進行簽名。

在鑒權(quán)中心中，JWT 是一種非常常見的技術(shù)，它提供了一種機制，可以在服務(wù)之間安全、有效地傳遞用戶信息。以下是 JWT 在鑒權(quán)中心中的常見使用流程：

1. 客戶端（例如 Web 瀏覽器）向鑒權(quán)中心發(fā)送登錄請求，提供必要的憑證（如用戶名和密碼）。

2. 鑒權(quán)中心驗證提供的憑證。如果憑證有效，鑒權(quán)中心將生成一個包含用戶信息的 JWT，并將其返回給客戶端。

3. 客戶端將收到的 JWT 存儲在本地（例如在瀏覽器的 localStorage 中）。

4. 客戶端在后續(xù)的所有請求中，都會在請求頭中包含這個 JWT。例如，它可以在 Authorization 頭中以 Bearer <token> 的形式發(fā)送 JWT。

5. 服務(wù)端（或者其他任何需要驗證用戶身份的服務(wù)）接收到請求后，會從請求頭中提取 JWT。然后使用公鑰驗證 JWT 的簽名并解析出用戶信息。

6. 如果 JWT 驗證成功，服務(wù)端會根據(jù) JWT 中的用戶信息處理請求。否則，服務(wù)端會拒絕請求。

總的來說，JWT 在鑒權(quán)中心的作用就是為客戶端和服務(wù)端提供了一個安全可靠的用戶身份驗證機制。

15.2 講講jwt以及jwt的生成和校驗過程

JWT（JSON Web Token）是一種開放標(biāo)準(zhǔn)（RFC 7519），它定義了一種緊湊且自包含的方式，用于在各方之間安全地傳輸信息作為JSON對象。這個信息可以被驗證和信任，因為它是數(shù)字簽名的。

JWT由三部分組成，用.分隔：Header（頭部）、Payload（有效載荷）和Signature（簽名）。

1. Header（頭部）：主要包含兩部分，token的類型（即JWT）和采用的加密算法。

例如：

{
  "alg": "HS256",
  "typ": "JWT"
}

2. Payload（有效載荷）：存放有效信息，包含三個部分（也可以自定義其他部分）。

• 標(biāo)準(zhǔn)中注冊的聲明：這里有一些是JWT預(yù)定義的聲明，如iss（token的發(fā)布者）、exp（token的過期時間）等。
• 公共的聲明：可以添加任何的信息，一般添加用戶相關(guān)信息或其他業(yè)務(wù)需要的必要信息，但不建議添加敏感信息，因為這個部分在客戶端可解密。
• 私有的聲明：為了防止沖突，私有聲明一般由發(fā)布者自行定義。

3. Signature（簽名）：是對前兩部分的簽名，以防止數(shù)據(jù)被篡改。

例如，如果你想使用HMAC SHA256算法，你需要使用base64url編碼的header和payload以及一個密鑰，然后進行哈希，來創(chuàng)建簽名。

例如：

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

這樣一來，JWT的三個部分就生成了。在JWT的使用過程中，這個token會在用戶和服務(wù)端傳遞，服務(wù)端會對這個JWT進行驗證。

JWT的驗證過程：

當(dāng)服務(wù)端收到JWT后，會進行以下步驟的驗證：

1. 對比收到的JWT中header和payload的base64編碼，并用.連接起來，然后用之前的密鑰進行加密和第三部分進行對比，從而驗證簽名是否正確。

2. 驗證標(biāo)準(zhǔn)中注冊的聲明，如過期時間，發(fā)布者等信息。

如果這兩個步驟都驗證通過，那么服務(wù)端就可以信任這個JWT中的信息進行處理，否則，JWT驗證失敗，請求被拒絕。

總的來說，JWT提供了一種方法來在服務(wù)端和客戶端安全可靠地傳遞信息。

15.3 講講具體的簽名和驗證過程

具體的 JWT 簽名和驗證過程如下：

簽名過程

1. 當(dāng)用戶向服務(wù)器發(fā)起認(rèn)證請求（比如，輸入用戶名和密碼登錄）時，服務(wù)器驗證用戶的身份。

2. 當(dāng)用戶身份驗證成功后，服務(wù)器會生成一個 JWT。這個 JWT 由三部分組成：header（頭部）、payload（負(fù)載）和 signature（簽名）。

3. Header 部分通常包含兩部分：token 的類型（即 “JWT”）和簽名的算法，比如 HMAC SHA256 或 RSA。

4. Payload 部分則包含聲明。聲明是關(guān)于實體（通常是用戶）和其他附加數(shù)據(jù)的信息。

5. 簽名部分是對 Header 和 Payload 的簽名，它的生成方法如下：

   如果使用 HMAC SHA256 算法，則服務(wù)器會對 “base64UrlEncode(Header) + ‘.’ + base64UrlEncode(Payload)” 進行簽名，使用的密鑰就是服務(wù)器的私鑰。

   如果使用 RSA 算法，服務(wù)器會用私鑰對 “base64UrlEncode(Header) + ‘.’ + base64UrlEncode(Payload)” 進行簽名。

6. 最后，服務(wù)器將生成的 JWT 返回給用戶。用戶在后續(xù)的請求中，都需要在請求的 header 中包含這個 JWT。

驗證過程

1. 當(dāng)用戶發(fā)起請求時，會在請求的 header 中包含 JWT。服務(wù)器接收到請求后，會從 header 中提取出 JWT。

2. 服務(wù)器會對 JWT 進行解碼，分別得到 Header、Payload 和 Signature 三部分。

3. 然后，服務(wù)器會用與簽名時同樣的算法，對 “base64UrlEncode(Header) + ‘.’ + base64UrlEncode(Payload)” 進行簽名。

4. 如果使用的是 HMAC SHA256 算法，服務(wù)器使用的密鑰仍然是服務(wù)器的私鑰。

   如果使用的是 RSA 算法，服務(wù)器則會使用公鑰進行簽名。

5. 服務(wù)器將新生成的簽名和 JWT 中的 Signature 部分進行比較。如果一致，那么就說明這個 JWT 是有效的；如果不一致，那么就說明這個 JWT 是偽造的，服務(wù)器應(yīng)當(dāng)拒絕這個請求。

總的來說，這就是 JWT 的簽名和驗證過程。通過這個過程，服務(wù)器能夠驗證用戶的身份，并確保 JWT 不會被偽造。

15.4 JWT給微服務(wù)系統(tǒng)提供了一種去中心化驗證的能力

是的，JWT （JSON Web Tokens）為微服務(wù)系統(tǒng)提供了一種去中心化的身份驗證機制。在微服務(wù)架構(gòu)中，可能有許多獨立運行且彼此通信的服務(wù)。當(dāng)服務(wù)需要驗證調(diào)用者的身份時，傳統(tǒng)的身份驗證機制可能需要每個服務(wù)都去一個中心化的認(rèn)證服務(wù)進行查詢，這將導(dǎo)致額外的網(wǎng)絡(luò)通信，并可能成為系統(tǒng)的瓶頸。

與此不同，JWT 的主要優(yōu)點在于它是自包含的。一個 JWT 包含了用戶的所有認(rèn)證信息，這意味著一個服務(wù)只需要解碼和驗證來自客戶端的 JWT，就可以知道這個 JWT 是否有效，以及 JWT 所表示的用戶身份。

這種方式的優(yōu)點在于：

1. 降低了網(wǎng)絡(luò)開銷：不需要額外的網(wǎng)絡(luò)請求去查詢用戶的認(rèn)證信息。

2. 解耦身份驗證：每個服務(wù)可以獨立地驗證 JWT，不需要依賴于一個中心化的認(rèn)證服務(wù)。

3. 可擴展性：因為每個服務(wù)都能獨立地進行身份驗證，所以添加新的服務(wù)不會對現(xiàn)有的認(rèn)證機制造成影響。

總的來說，使用 JWT 可以在提高微服務(wù)系統(tǒng)性能和可擴展性的同時，提供強大的用戶身份驗證機制。文章來源地址http://www.zghlxwxcb.cn/news/detail-611155.html

到了這里，關(guān)于微服務(wù)系統(tǒng)面經(jīng)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！