1、Eureka 簡介

Eureka是Spring Cloud Netflix 微服務套件中的一個服務發現組件，本質上是一個基于REST的服務，主要用于AWS云來定位服務以實現中間層服務的負載均衡和故障轉移,它的設計理念就是“注冊中心”。
你可以認為它是一個存儲服務地址信息的大本營，微服務啟動時，會把自己的信息告訴Eureka，這個過程叫做注冊。
當別的服務想要調用這些服務時，就會去問Eureka需要的服務地址在哪里，這個過程叫做發現。

1.1 Eureka 組件
Eureka由兩個組件組成：Eureka Server和Eureka Client。

1.1.1 Eureka Server
Eureka的服務端，提供服務注冊和發現的功能。服務實例啟動后，會向Eureka Server注冊自己的信息，比如主機名、端口號等。然后Eureka Server會保存這些信息，供其他服務查詢使用。

@EnableEurekaServer // 啟用Eureka Server
@SpringBootApplication
public class EurekaServerApplication {public static void main(String[] args) {SpringApplication.run(EurekaServerApplication.class, args);}
}

1.1.2 Eureka Client
Eureka的客戶端，它是一個Java客戶端，用于簡化與服務端的交流，可以很輕松地集成到Spring Cloud應用之中。

@EnableEurekaClient // 啟用Eureka Client
@SpringBootApplication
public class EurekaClientApplication {public static void main(String[] args) {SpringApplication.run(EurekaClientApplication.class, args);}
}

2、Eureka 和 Zookeeper 對比

在微服務架構中，服務發現是一個核心的問題。服務發現讓服務消費者能夠找到網絡中運行的服務提供者的實例。
Eureka和Zookeeper都是流行的服務發現解決方案，但它們的設計理念和實現細節有所不同。

2.1 什么是 CAP 定理
CAP定理是分布式計算領域的一個重要概念，由加州大學伯克利分校的Eric Brewer教授提出。它指出，一個分布式系統不可能同時滿足以下三點：

• Consistency（一致性）：在分布式系統中的所有數據副本，在同一時間內是否具有相同的值。
• Availability（可用性）：保證每個請求不管成功或者失敗都有響應。
• Partition tolerance（分區容錯性）：系統中任意信息的丟失或失敗不會影響系統的繼續運作。

在實際的分布式環境中，網絡分區是不可避免的，因此分區容錯性是必須要實現的，這就意味著，在CAP的三個特性中，我們只能在一致性和可用性之間進行權衡。

2.2 基于 CAP 定理比對 Eureka 和 Zookeeper
根據CAP定理，我們來看看Eureka和Zookeeper是如何做權衡的。

• Zookeeper
  Zookeeper是一個中心化的服務協調系統，廣泛用于名稱服務、配置管理、節點同步等。它保證了強一致性（Consistency）和分區容錯性（Partition tolerance），但不保證可用性（Availability）。這意味著如果Zookeeper集群中的過半節點不可用，整個Zookeeper服務就不可用了。這樣做可以保證所有讀取操作返回的都是最新的數據。

  在Zookeeper中，領導選舉算法保證了服務的一致性。舉個例子，如果在Zookeeper集群中出現網絡分區，那么集群將會分裂成多個部分，每一部分都會嘗試進行新的領導選舉。只有當某一部分節點數量超過半數時，它才能選出新的領導，并繼續對外提供服務。

• Eureka
  與此相反，Eureka則是設計成高可用性（Availability）優先。Eureka可以很好地處理網絡分區問題，它的設計哲學是即便在服務之間出現嚴重的網絡故障，每個服務實例仍然能夠被客戶端發現并使用。Eureka的自我保護模式使得在網絡分區問題發生時，不會立即注銷服務列表中的節點，而是等待一段時間，直到網絡穩定。這樣做雖然能增加可用性，但卻可能因為沒有及時剔除失效的服務實例而返回過時的信息。

  一個具體的例子是，如果Eureka Server與Eureka Client通信出現問題（如網絡延遲），Server不會立即從注冊表中移除這個Client，而是等待Client恢復并發送心跳。這樣做的好處是，即使有少量的服務器或客戶端無法進行通信，整個系統仍然是可用的。

出Zookeeper保證的是CP，而Eureka則是AP。在選擇使用Zookeeper還是Eureka時，需要根據實際業務需求和架構特點做出決策。如果你的服務對一致性要求極高，而且可以接受因網絡分區導致的服務不可用，那么Zookeeper可能是更好的選擇。如果你需要的是高可用的服務發現機制，并且可以容忍服務狀態的短暫不一致，那么Eureka是更合適的選項。

3、搭建 Eureka 注冊中心
Eureka Server作為服務發現的關鍵組件，負責存儲服務信息和處理服務注冊與發現。下面我們將詳細介紹如何從零開始搭建Eureka Server。

3.1 POM 文件
首先需要創建一個Spring Boot工程并在pom.xml文件中添加Eureka Server的依賴。你可以使用Spring Initializr來快速生成項目結構。

<dependencies><!-- Eureka Server --><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-eureka-server</artifactId></dependency><!-- Spring Boot Starter Web，用于搭建基于Web的應用 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId></dependency><!-- 測試依賴，可以根據需要選擇添加 --><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><scope>test</scope></dependency>
</dependencies>

此外，你還需要在pom.xml中指定Spring Cloud的版本，通過spring-cloud-dependencies來保證各個組件版本的兼容性：

<dependencyManagement><dependencies><dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-dependencies</artifactId><version>${spring-cloud.version}</version><type>pom</type><scope>import</scope></dependency></dependencies>
</dependencyManagement><properties><spring-cloud.version>Greenwich.SR1</spring-cloud.version>
</properties>

這里${spring-cloud.version}要替換為當前穩定的Spring Cloud版本號。

3.2 配置文件 application.yml
在src/main/resources/目錄下創建或編輯application.yml配置文件，添加Eureka Server的基礎配置：

server:port: 8761  # Eureka服務端口eureka:client:registerWithEureka: false  # 表示不向注冊中心注冊自己fetchRegistry: false  # 表示自己就是注冊中心，我的職責就是維護服務實例，不需要去檢索服務service-url:defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/  # 設置與Eureka Server交互的地址instance:hostname: localhost  # 可以是其他的域名或者IP

3.3 啟動類
在你的Spring Boot應用中創建一個主類，使用@EnableEurekaServer注解來啟動一個服務注冊中心。

package com.example.eurekaserver;import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;@SpringBootApplication
@EnableEurekaServer  // 啟用Eureka Server功能
public class EurekaServerApplication {public static void main(String[] args) {SpringApplication.run(EurekaServerApplication.class, args);}
}

這段代碼會啟用一個Eureka Server實例，允許其他服務向它注冊。

3.4 訪問 Eureka Server WEB 服務管理平臺
一旦啟動了Eureka Server，你可以在瀏覽器中輸入http://localhost:8761來訪問Eureka的管理界面。在這個界面，你能看到所有注冊的服務實例，以及它們的狀態信息。

Eureka的Web界面提供了實時的服務注冊監控，你可以看到哪些服務已經注冊進來，以及它們的健康狀態。

以上步驟是搭建一個單節點的Eureka Server的基本過程。
在生產環境中，為了確保高可用性，通常會搭建Eureka Server集群，我們會在后續的小節中討論如何搭建和配置Eureka Server集群。

接下來我們將深入了解Eureka Server的服務管理平臺，以及如何通過它來監控服務實例的狀態。

4、Eureka 服務管理平臺介紹
Eureka服務管理平臺是Eureka Server自帶的一個Web界面，它提供了實時的服務注冊情況和服務健康狀況的監控。

4.1 Eureka Server 服務管理平臺訪問預覽
一旦Eureka Server啟動，你可以通過在瀏覽器地址欄輸入http://localhost:8761（這里的地址和端口根據你實際的配置決定）來訪問Eureka服務管理平臺。這個界面簡潔直觀，提供了關于當前Eureka實例所有必要信息的概覽。

由于我這里不能直接上傳圖片，你可以通過項目運行后自行查看界面，或者在網絡上搜索Eureka Server界面的相關截圖，這將有助于你獲得一個直觀的感受。

4.2 System Status
在管理平臺的主頁上，你可以看到"System Status"區域，這通常位于頁面的頂部。這里會顯示Eureka自身的狀態，包括：

• Current time：服務器的當前時間。
• Uptime：服務器運行時間。
• Environment：服務器環境信息，如配置的profile。
• Number of CPUs：服務器的CPU數量。
• Total memory：服務器的總內存。
• General runtime info：包括JVM版本等運行時信息。

4.3 DS Replicas
如果你配置了Eureka Server集群，"DS Replicas"部分將會顯示所有的Eureka Server節點。這些副本節點之間會相互注冊，保證服務注冊信息在整個Eureka集群中是一致的。在這個區域，你可以看到其它Eureka Server節點的狀態，這對于確保高可用性是非常關鍵的。

4.4 Instances currently registered with Eureka
這個區域顯示了所有已注冊到Eureka的服務實例，以及它們的狀態。每個服務下面會列出所有的注冊實例，包括它們的應用名、IP地址、端口號、運行狀態等信息。點擊具體的實例，你還可以看到更多的細節，例如服務的metadata、租約信息等。

4.5 General Info
在"General Info"部分，你可以找到Eureka Server自身的一些信息，包括：

• Eureka version：顯示Eureka Server的版本號。
• Started at：Eureka Server啟動的時間。

4.6 Instance Info
"Eureka Server Dashboard"還有"Instance Info"部分，這里提供了每個注冊服務實例的詳細信息。這些信息有助于管理員了解服務實例的健康狀況，以及進行問題排查。

Eureka服務管理平臺提供了豐富的信息和操作界面，管理員可以利用這些信息來監控服務的健康狀態，確保系統的穩定運行。
在實際的生產環境中，還可以結合額外的監控工具，比如Spring Boot Admin等，來更全面地監控系統狀態。

5、搭建高可用集群
在實際生產環境中，為了保證Eureka服務的穩定性和可用性，通常會部署Eureka Server集群。這樣即使某個Eureka Server節點故障，其他節點仍能提供服務注冊和發現的功能，從而實現高可用。

5.1 在 Eureka 應用中定義多環境配置
為了構建Eureka集群，需要為每個Eureka Server節點指定一個獨立的配置文件。

5.1.1 application-eureka1.yml
定義第一個Eureka Server實例的配置文件。例如：

server:port: 8761eureka:instance:hostname: eureka1.feiz.comclient:service-url:defaultZone: http://eureka2.feiz.com:8762/eureka/fetch-registry: trueregister-with-eureka: true

5.1.2 application-eureka2.yml
定義第二個Eureka Server實例的配置文件。例如：

server:port: 8762eureka:instance:hostname: eureka2.feiz.comclient:service-url:defaultZone: http://eureka1.feiz.com:8761/eureka/fetch-registry: trueregister-with-eureka: true

這兩個配置文件中的defaultZone屬性指向了對方的服務注冊中心，從而形成一個互相注冊的關系。

5.2 打包工程
我們需要將Eureka Server項目打包成jar包，以便可以在服務器上運行。

5.2.1 POM 依賴
在pom.xml文件中，Spring Boot已經幫我們定義好了打包的插件，所以一般不需要額外定義。

5.2.2 打包
在項目根目錄下，運行Maven命令進行打包：

mvn clean package

5.2.3 打包結果
打包完成后，在target目錄下會生成對應的jar文件，例如eureka-server-0.0.1-SNAPSHOT.jar。

5.3 上傳打包后的 jar 文件到 Linux 系統
使用FTP或SCP等工具，將打包好的jar文件上傳到兩臺Linux服務器上。

5.4 設置 Linux 主機域名
在/etc/hosts文件中，為兩臺Linux服務器設置域名解析，方便通過域名訪問：

# Example /etc/hosts entries
192.168.1.10 eureka1.feiz.com
192.168.1.11 eureka2.feiz.com

5.5 啟動 Eureka
有了jar文件和配置文件，我們就可以在服務器上啟動Eureka Server的實例了。

5.5.1 使用 java 命令啟動
在Linux服務器上，通過指定配置文件的方式啟動Eureka Server實例：

java -jar eureka-server-0.0.1-SNAPSHOT.jar --spring.profiles.active=eureka1
java -jar eureka-server-0.0.1-SNAPSHOT.jar --spring.profiles.active=eureka2

這里的--spring.profiles.active參數用來指定活動的配置文件。

5.5.2 腳本啟動
為了方便管理，我們可以編寫啟動腳本來控制Eureka Server的啟動、關閉等操作。例如創建一個start-eureka-server.sh的腳本，內容如下：

#!/bin/bash
nohup java -jar eureka-server-0.0.1-SNAPSHOT.jar --spring.profiles.active=$1 > eureka-server.log 2>&1 &

然后就可以用這個腳本來啟動Eureka Server：

./start-eureka-server.sh eureka1
./start-eureka-server.sh eureka2

搭建Eureka高可用集群的步驟就是這樣的，有了Eureka集群，即使某個節點宕機，其他節點還能繼續提供服務，從而確保了整個微服務架構的高可用性。

接下來，我們可以通過在客戶端配置這些Eureka Server地址，將客戶端注冊到集群，這樣客戶端就能享受到高可用服務發現的好處了。

推薦幾個 Spring Cloud 學習的文章

• 01、Feign的核心概念及入門案例
• 02、Feign原生注解
• 03、Spring Cloud 2020.x 集成Open Feign
• 04、集成OkHttp及連接池配置詳解
• 05、集成Ribbion實現客戶端負載均衡
• 06、Ribbion配置類源碼分析
• 07、Ribbion負載均衡策略源碼分析
• 08、Feign超時配置詳解及源碼分析
• 09、Fegin 開啟日志打印、Gzip壓縮
• 10、Feign 、Ribbon 重試機制源碼分析
• …

6、集群原理

6.1 服務注冊
當一個微服務實例啟動時，它會向Eureka Server注冊自己的信息，比如IP地址、端口號、健康指標等。這些信息會存儲在Eureka Server的內存中。

6.2 服務同步
在集群環境下，每個Eureka Server節點都會存有一份服務實例的注冊信息。為了保持這些信息的一致性，Eureka Server節點之間會相互復制（replicate）這些信息：

• 當一個服務實例在Eureka Server A上注冊時，Server A會將這個信息同步給其他的Eureka Server節點（比如Server B）。
• 這個同步過程是通過復制一個注冊操作的請求到集群中的其它節點來完成的。
• 通過這樣的方式，每個節點都有機會獲取最新的注冊信息，保證了服務注冊的一致性。

6.3 心跳檢測
服務實例會定期向Eureka Server發送“心跳”（即續約），默認情況下每30秒一次，以告知Eureka Server它還活著。

• 如果Eureka Server在一定時間內沒有接收到某個服務實例的心跳，它會在其注冊表中將這個實例剔除。
• 但在自我保護模式下，為了應對因網絡問題導致的心跳失敗，Eureka Server不會立即剔除實例，會有一個寬限期。

6.4 自我保護模式
Eureka Server能夠進入自我保護模式。在這種模式下，Eureka Server會保護注冊表中的信息，不會刪除未發送心跳的服務實例：

• 這種做法可以在網絡分區故障發生時阻止Eureka Server錯誤地剔除大量服務實例。
• 當網絡穩定時，Eureka Server會自動退出自我保護模式。

6.5 故障轉移
當一個Eureka Server節點宕機后，由于服務注冊信息已經同步到了其他節點，微服務實例可以自動將注冊請求轉移到其他健康的Eureka Server節點上：

• 這實現了故障轉移和服務的高可用。
• 客戶端通常會有一個Eureka Server的地址列表，當嘗試與一個節點通信失敗時，它會嘗試聯系列表中的下一個節點。

當然可以。針對第四點（6.6 讀寫操作的分離）的內容，我們可以展開解釋，使其更加詳盡和容易理解：

6.6 讀寫操作的分離

在Eureka Server集群中，讀寫分離的概念對于維護整個系統的高性能和高可用性至關重要。這里的“讀”主要指客戶端從Eureka獲取注冊服務列表的操作，而“寫”則指服務實例注冊和續約的操作。

• 寫操作：對于注冊和續約這樣的寫操作，它們必須在集群中的每個節點上進行復制。當一個服務實例向Eureka Server注冊時，這個注冊信息會被同步到集群中的所有其他節點。這種復制確保了即使某個節點發生故障，服務實例的注冊信息仍然可以在其他節點上被訪問到，從而保持系統的一致性。

• 讀操作：相比之下，讀操作則可以從任何一個Eureka Server節點獲取，無需跨節點復制。這意味著任何時候當客戶端需要獲取服務列表時，它都可以快速地從任一可用的節點獲得數據，而不需要等待跨節點之間的信息同步。這減少了單個節點的負擔，并顯著提高了系統的響應速度。

重要性：

• 性能提升：讀寫分離可以顯著減少因寫操作復制而產生的網絡負載，因此提升了整個集群的性能。
• 減少瓶頸：通過允許讀操作在任一節點上執行，它避免了所有請求都集中在單個節點上，這樣可以有效分散流量，減少了單點瓶頸的風險。
• 彈性擴展：讀寫分離使得Eureka Server集群能夠更加彈性地擴展。根據讀寫負載的變化，可以靈活地增加或減少節點數量，以實現最優的資源利用。

注意事項：

• 數據一致性：雖然讀操作可以從任一節點獲得，但Eureka Server會通過復制機制確保每個節點的數據最終一致。
• 故障轉移策略：集群中的節點必須要有故障轉移機制，確保當一個節點不可用時，其它節點能夠接管它的職責，保持服務的連續性。

通過上面這些機制，Eureka集群確保了即使在某個Eureka Server節點出現故障的情況下，整個服務發現框架也能夠繼續正常工作，不會影響到微服務的正常運行。
這就是為什么即使在分布式系統中常常出現的網絡分區、通信故障、服務故障等問題發生時，Eureka仍然能夠提供穩定的服務發現功能。

7、Eureka 優雅停服
在微服務架構中，服務的可用性至關重要。但有時候也需要對服務進行升級或者維護，這時候如果能夠優雅地停止服務，就可以避免對用戶造成過多的影響，同時也能保護服務不受損害。

7.1 自我保護模式
Eureka Server的自我保護模式是為了應對網絡不穩定的情況。在網絡狀況不佳時，Eureka Client可能無法及時地向Server發送心跳。如果Eureka Server在這種情況下仍按常規流程剔除沒有發送心跳的Client，那么可能會導致大量服務實例被錯誤移除，造成“腦裂”問題。
所以在自我保護模式下，Eureka Server寧可保留所有服務實例，也不去主動剔除任何一個，即使它們已經很長時間沒有發送心跳了。

7.2 為什么要自我保護
這個模式能保證在網絡不穩定導致Eureka Client和Server之間的通信出現問題時，服務注冊信息不會被輕易丟掉。這樣就可以防止因為臨時的網絡問題而導致整個微服務架構不穩定。自我保護模式保證了在不可靠的網絡環境下，服務注冊表的穩定性和可靠性。

7.3 關閉自我保護
有些情況下，我們可能希望關閉自我保護模式，特別是在測試環境中，以確保當一個服務實例真的宕機時，它能夠被及時從注冊表中移除。
要關閉自我保護模式，可以在Eureka Server的配置文件中設置:

eureka:server:enable-self-preservation: false

關閉自我保護模式后，如果Eureka Client在配置的時間內沒有向Server發送心跳，那么這個實例將會被Server從注冊列表中剔除。這確實會提高注冊表的準確性，但同時也增加了在網絡不穩定時誤剔除服務實例的風險。

優雅停服是微服務管理中的一個重要環節，它能確保服務的升級和維護對用戶的影響降到最低。
在實際應用自我保護模式時，我們需要根據具體的業務需求和網絡環境來權衡是否開啟此模式。
通常在生產環境下建議開啟自我保護模式，以提高微服務架構的穩定性和健壯性。而在開發和測試環境中，可以考慮關閉它，以便更快地發現并處理服務實例的故障。

我們繼續深入講講如何進行Eureka的優雅停服以及在整個過程中可能遇到的一些注意事項。

7.4 優雅停服的流程
優雅停服意味著服務在停止之前會完成當前處理的請求，并且不再接受新的請求。具體到Eureka Client，需要做到以下幾點：

7.4.1 停止流量轉發
在停服之前，首先要確保不再有新的流量進入該服務實例。這可以通過在負載均衡器中摘除實例來實現。

7.4.2 服務下線
然后，服務實例需要主動向Eureka Server發送下線請求，告知注冊中心自己將停止服務。

7.4.3 等待處理請求完成
在服務實際停止之前，需要等待服務實例完成當前正在處理的所有請求。

7.4.4 停止服務實例
最后，當所有請求都處理完成后，可以安全地停止服務實例。

在Spring Cloud中，可以通過Spring Boot的Actuator來實現優雅停服。Actuator暴露了一個/actuator/shutdown端點，可以通過調用這個端點來優雅地關閉服務。為了能夠使用這個特性，需要在application.yml或application.properties文件中添加以下配置：

management:endpoints:web:exposure:include: shutdownendpoint:shutdown:enabled: true

在應用程序準備停止時，可以發出一個HTTP POST請求到/actuator/shutdown端點。這將觸發上述流程，優雅地關閉服務實例。

7.5 處理停服時遇到的問題
在進行優雅停服時，可能會遇到一些問題，例如：

• 服務調用鏈中斷：如果服務實例在處理請求時依賴于其他服務，需要確保這些依賴服務在停服過程中仍然可用。
• 超時設置：停服過程中需要合理設置超時時間，以確保服務實例有足夠的時間完成正在處理的請求。
• 數據一致性：如果服務實例在處理事務請求，需要確保事務能夠正確提交或回滾，避免數據不一致。

在實際操作中，通常需要先在測試環境中模擬停服流程，確保各個環節都能夠正確執行，然后再在生產環境中實施。這樣做可以最大限度地減少停服給用戶帶來的影響，并確保服務的穩定性和數據的一致性。

在微服務架構中，優雅停服是一項重要的技能。正確地執行優雅停服不僅能夠保護正在運行的業務流程，也是保障服務質量和用戶體驗的關鍵。 實踐中需要結合具體的業務特點和技術環境來制定詳細的停服策略，以確保服務平穩過渡到新的狀態。

7.6 服務恢復策略

搞定優雅停機之后，咱們看看停機后的服務恢復策略，以及在服務停機期間如何保持業務連續性,這個是挺重要的，畢竟服務總得起來，業務也不能停。

當服務需要重新上線時，有以下幾個步驟可以確保服務的平穩恢復：

7.6.1 服務實例重啟
將服務實例重新啟動，并確保所有的配置項都是最新的。

7.6.2 注冊到Eureka
啟動時，服務實例會自動注冊到Eureka Server。確保服務實例的健康檢查是通過的，服務實例能夠正常提供服務。

7.6.3 服務同步
Eureka Client會定期從Server拉取服務注冊列表，確保本地的信息是最新的。

7.6.4 流量逐步切換
在確保服務實例穩定運行后，可以通過負載均衡器逐步將流量切換到新的服務實例上，避免流量突增對新實例造成沖擊。

7.7 業務連續性策略
在服務停機期間，為了保持業務的連續性，可以采取以下措施：

7.7.1 服務降級
在服務無法正常提供時，可以啟用服務降級策略，比如返回一個默認值或者從緩存中獲取數據。

7.7.2 流量切換
如果是計劃內的停機，可以提前將流量切換到其他地理位置的服務實例，或者是切換到備份服務上。

7.7.3 用戶通知
對于長時間的停機，合理的用戶通知也是很必要的。提前通知用戶，減少用戶的困擾。

7.7.4 監控和報警
確保有監控系統持續監控服務的狀態，一旦服務恢復或出現異常，及時報告。

推薦幾個 Spring Cloud 學習的文章

• 01、Feign的核心概念及入門案例
• 02、Feign原生注解
• 03、Spring Cloud 2020.x 集成Open Feign
• 04、集成OkHttp及連接池配置詳解
• 05、集成Ribbion實現客戶端負載均衡
• 06、Ribbion配置類源碼分析
• 07、Ribbion負載均衡策略源碼分析
• 08、Feign超時配置詳解及源碼分析
• 09、Fegin 開啟日志打印、Gzip壓縮
• 10、Feign 、Ribbon 重試機制源碼分析
• …

搞定了這些，就算服務需要停機升級或者維護，對用戶的影響也能降到最低。重點是，不管停不停機，服務質量和用戶體驗始終是咱們要維護的。

最后說一句(求關注，求贊，別白嫖我)

最近無意間獲得一份阿里大佬寫的刷題筆記和面經，一下子打通了我的任督二脈，進大廠原來沒那么難。

這是大佬寫的， 7701頁的阿里大佬寫的刷題筆記，讓我offer拿到手軟

本文已收錄于，我的技術網站 小鄭說編程，有大廠完整面經，工作技術，架構師成長之路，等經驗分享

求一鍵三連：點贊、分享、收藏

點贊對我真的非常重要！在線求贊，加個關注我會非常感激！@小鄭說編程