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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在實(shí)際的系統(tǒng)設(shè)計(jì)中，微服務(wù)的網(wǎng)關(guān)數(shù)量取決于多種因素，包括系統(tǒng)的規(guī)模、業(yè)務(wù)復(fù)雜度、性能要求、安全性要求等等。所以，并沒有一個(gè)固定的答案來(lái)確定微服務(wù)系統(tǒng)中應(yīng)該有幾個(gè)網(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è)計(jì)中，服務(wù)之間的調(diào)用是否需要經(jīng)過網(wǎng)關(guān)取決于具體的設(shè)計(jì)決策。這主要受到以下兩種設(shè)計(jì)模式的影響：

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

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

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

4 請(qǐng)求的接收和返回路徑

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

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

   這樣做的原因有以下幾點(diǎn)：

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

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

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

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

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

   舉例來(lái)說(shuō)：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 首先，你需要在你的項(xiàng)目中加入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)限，就會(huì)被路由到//user-service服務(wù)中。
        predicates:
        - Path=/user/**
      - id: order_service
        uri: lb://order-service
        predicates:
        - Path=/order/**

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

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

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

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

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

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

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

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

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

8 sprin

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

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

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

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

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

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

是的，Spring Cloud的設(shè)計(jì)理念是微服務(wù)架構(gòu)中各種通用模式的解耦合實(shí)現(xiàn)。它包含一系列的子項(xiàng)目（模塊），這些模塊大多都是可插拔的，并且可以根據(jù)具體的需求和場(chǎng)景來(lái)選擇使用。每個(gè)模塊都關(guān)注于微服務(wù)架構(gòu)中的一個(gè)特定領(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)的簡(jiǎ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ū)動(dòng)的微服務(wù)，支持多種消息中間件。

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

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

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

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

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

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

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

簡(jiǎn)單來(lái)說(shuō)，每個(gè)URL都是URI，但并非每個(gè)URI都是URL。因?yàn)閁RI還包括URN，URN只命名資源而不指定如何定位資源。

在進(jìn)行路由時(shí)，通常使用URI而不是URL，原因如下：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12.1 jwt的校驗(yàn)機(jī)制

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

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

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

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

同樣要注意的是，如果你正在使用的域名（在這個(gè)例子中是.xxx）是一個(gè)真實(shí)的頂級(jí)域名，那么在真實(shí)的網(wǎng)絡(luò)環(huán)境中這可能會(huì)導(dǎo)致沖突。因此，當(dāng)你在開發(fā)環(huán)境中使用hosts文件映射時(shí)，通常會(huì)使用不存在的頂級(jí)域名，例如.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 對(duì)象的形式安全地傳輸信息。這種信息可以被驗(yàn)證和信任，因?yàn)樗菙?shù)字簽名的。JWT 可以使用秘密（通過 HMAC 算法）或使用 RSA 或 ECDSA 的公/私鑰對(duì)進(jìn)行簽名。

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

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

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

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

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

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

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

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

15.2 講講jwt以及jwt的生成和校驗(yàn)過程

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

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

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

例如：

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

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

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

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

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

例如：

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

這樣一來(lái)，JWT的三個(gè)部分就生成了。在JWT的使用過程中，這個(gè)token會(huì)在用戶和服務(wù)端傳遞，服務(wù)端會(huì)對(duì)這個(gè)JWT進(jìn)行驗(yàn)證。

JWT的驗(yàn)證過程：

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

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

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

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

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

15.3 講講具體的簽名和驗(yàn)證過程

具體的 JWT 簽名和驗(yàn)證過程如下：

簽名過程

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

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

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

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

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

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

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

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

驗(yàn)證過程

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

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

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

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

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

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

總的來(lái)說(shuō)，這就是 JWT 的簽名和驗(yàn)證過程。通過這個(gè)過程，服務(wù)器能夠驗(yàn)證用戶的身份，并確保 JWT 不會(huì)被偽造。

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

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

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

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

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

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

3. 可擴(kuò)展性：因?yàn)槊總€(gè)服務(wù)都能獨(dú)立地進(jìn)行身份驗(yàn)證，所以添加新的服務(wù)不會(huì)對(duì)現(xiàn)有的認(rèn)證機(jī)制造成影響。

總的來(lái)說(shuō)，使用 JWT 可以在提高微服務(wù)系統(tǒng)性能和可擴(kuò)展性的同時(shí)，提供強(qiáng)大的用戶身份驗(yàn)證機(jī)制。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-680370.html

到了這里，關(guān)于微服務(wù)系統(tǒng)面經(jīng)之一:以秒殺系統(tǒng)為例的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！