微服務(wù)優(yōu)雅上下線的實踐方法
導語
本文介紹了微服務(wù)優(yōu)雅上下線的實踐方法及原理，包括適用于 Spring 應(yīng)用的優(yōu)雅上下線邏輯和服務(wù)預(yù)熱，以及使用 Docker 實現(xiàn)無損下線的 Demo。同時，本文還總結(jié)了優(yōu)雅上下線的價值和挑戰(zhàn)。
作者簡介
顏松柏
騰訊云微服務(wù)架構(gòu)師
擁有超過10年的 IT 從業(yè)經(jīng)驗，精通軟件架構(gòu)設(shè)計，微服務(wù)架構(gòu)，云架構(gòu)設(shè)計等多個領(lǐng)域，在泛互、金融、教育、出行等多個行業(yè)擁有豐富的微服務(wù)架構(gòu)經(jīng)驗。
前言
微服務(wù)優(yōu)雅上下線的原理是指在微服務(wù)的發(fā)布過程中，保證服務(wù)的穩(wěn)定性和可用性，避免因為服務(wù)的變更而造成流量的中斷或錯誤。
微服務(wù)優(yōu)雅上下線的原理可以從三個角度來考慮：
-
服務(wù)端的優(yōu)雅上線，即在服務(wù)啟動后，等待服務(wù)完全就緒后再對外提供服務(wù)，或者有一個服務(wù)預(yù)熱的過程。
-
服務(wù)端的無損下線，即在服務(wù)停止前，先從注冊中心注銷，拒絕新的請求，等待舊的請求處理完畢后再下線服務(wù)。
-
客戶端的容災(zāi)策略，即在調(diào)用服務(wù)時，通過負載均衡、重試、黑名單等機制，選擇健康的服務(wù)實例，避免調(diào)用不可用的服務(wù)實例。
微服務(wù)優(yōu)雅上下線可以提高微服務(wù)的穩(wěn)定性和可靠性，減少發(fā)布過程中的風險和損失。
優(yōu)雅上線
優(yōu)雅上線，也叫無損上線，或者延遲發(fā)布，或者延遲暴露，或者服務(wù)預(yù)熱。
優(yōu)雅上線的目的是為了提高發(fā)布的穩(wěn)定性和可靠性，避免因為應(yīng)用的變更而造成流量的中斷或錯誤。
優(yōu)雅上線的方法
優(yōu)雅上線的方法有以下幾種：
-
延遲發(fā)布：即延遲暴露應(yīng)用服務(wù)，比如應(yīng)用需要一些初始化操作后才能對外提供服務(wù)，如初始化緩存，數(shù)據(jù)庫連接池等相關(guān)資源就位，可以通過配置或代碼來實現(xiàn)延遲暴露。
-
QoS 命令：即通過命令行或 HTTP 請求來控制應(yīng)用服務(wù)的上線和下線，比如在應(yīng)用啟動時不向注冊中心注冊服務(wù)，而是在服務(wù)健康檢查完之后再手動注冊服務(wù)。
-
服務(wù)注冊與發(fā)現(xiàn)：即通過注冊中心來管理應(yīng)用服務(wù)的狀態(tài)和路由信息，比如在應(yīng)用啟動時向注冊中心注冊服務(wù)，并監(jiān)聽服務(wù)狀態(tài)變化事件，在應(yīng)用停止時向注冊中心注銷服務(wù)，并通知其他服務(wù)更新路由信息。
-
灰度發(fā)布：即通過分流策略來控制應(yīng)用服務(wù)的流量分配，比如在發(fā)布新版本的應(yīng)用時，先將部分流量導入到新版本的應(yīng)用上，觀察其運行情況，如果沒有問題再逐步增加流量比例，直到全部切換到新版本的應(yīng)用上。
上面的方法核心思想都是一個，就是等服務(wù)做好了準備再把請求放行過去。
優(yōu)雅上線的實現(xiàn)
大部分優(yōu)雅上線都是通過注冊中心和服務(wù)治理能力來實現(xiàn)的。
對于初始化過流程較長的應(yīng)用，由于注冊通常與應(yīng)用初始化過程同步進行，因此可能出現(xiàn)應(yīng)用還未完全初始化就已經(jīng)被注冊到注冊中心供外部消費者調(diào)用，此時直接調(diào)用可能會導致請求報錯。
所以，通過服務(wù)注冊與發(fā)現(xiàn)來做優(yōu)雅上線的基本思路是：
-
在應(yīng)用啟動時，提供一個健康檢查接口，用于反饋服務(wù)的狀態(tài)和可用性。
-
應(yīng)用啟動后，可以采用下列方法來使新的請求暫時不進入新版的服務(wù)實例。
-
暫時不向注冊中心注冊服務(wù)。
-
隔離服務(wù)，有些注冊中心支持隔離服務(wù)實例，比如北極星。
-
將權(quán)重配置為0。
-
將服務(wù)實例的 Enable 改為 False。
-
讓健康檢查接口返回不健康的狀態(tài)。
-
在新版本的應(yīng)用實例完成初始化操作后，確保了可用性后，再對應(yīng)的將上述的方法取消，這樣就可以讓新的請求被路由到新版本的應(yīng)用實例上。
-
如果需要預(yù)熱，就讓流量進入新版本的應(yīng)用實例時按比例的一點點增加。
這樣，就可以實現(xiàn)優(yōu)雅上線的過程，保證請求進來的時候，不會因為新版本的應(yīng)用實例沒有準備好而導致請求失敗。
優(yōu)雅上線的北極星代碼 Demo
我們以 Spring Cloud 和 北極星 為例，講一下如何通過服務(wù)注冊與發(fā)現(xiàn)來做優(yōu)雅上線的過程。
首先，我們需要創(chuàng)建一個 Spring Cloud 項目，并添加北極星的依賴。
然后，我們需要在 application.properties 文件中配置北極星的相關(guān)信息，如注冊中心地址，服務(wù)名，分組名等，例如：
spring:
application:
name: ${application.name}
cloud:
polaris:
address: grpc://${修改為第一步部署的 Polaris 服務(wù)地址}:8091
namespace: default
然后，我們需要創(chuàng)建一個 Controller 類，提供一個簡單的接口，用于返回服務(wù)的信息，例如：
public class ProviderController {
private int port;
public String hello() {
return "Hello, I am provider, port: " + port;
}
}
最后，如果需要我們可以重寫健康檢查接口，用于反饋服務(wù)的狀態(tài)和可用性。這里我們需要引入 Actuator。
public class DatabaseHealthIndicator implements HealthIndicator {
public Health health() {
if (isDatabaseConnectionOK()) {
return Health.up().build();
} else {
return Health.down().withDetail("Error Code", "DB-001").build();
}
}
private boolean isDatabaseConnectionOK() {
// 檢查數(shù)據(jù)庫連接、緩存等
return true;
}
}
這樣，我們就完成了一個簡單的服務(wù)提供者應(yīng)用，并且可以通過北極星來實現(xiàn)服務(wù)注冊與發(fā)現(xiàn)。
接下來，我們需要創(chuàng)建一個服務(wù)消費者應(yīng)用，并且也添加北極星的依賴和配置信息。
然后，使用 RestTemplate 來調(diào)用服務(wù)提供者的接口，例如：
public class ConsumerApplication {
public static void main(String[] args) {
SpringApplication.run(ConsumerApplication.class, args);
}
// 開啟負載均衡
public RestTemplate restTemplate() {
return new RestTemplate();
}
public class ConsumerController {
private RestTemplate restTemplate;
("/hello")
public String hello() {
// 使用服務(wù)名來調(diào)用服務(wù)提供者的接口
return restTemplate.getForObject("<http://provider/hello>", String.class);
}
}
}
這里我們使用了 @LoadBalanced 注解來開啟負載均衡功能，并且使用服務(wù)名 provider 來調(diào)用服務(wù)提供者的接口。
這樣，我們就完成了一個簡單的服務(wù)消費者應(yīng)用，并且可以通過北極星來實現(xiàn)服務(wù)注冊與發(fā)現(xiàn)。
接下來，我們就可以通過以下步驟來實現(xiàn)優(yōu)雅上線的過程：
-
在發(fā)布新版本的服務(wù)提供者應(yīng)用時，先啟動新版本的應(yīng)用實例，但是不向注冊中心注冊服務(wù)，或者讓健康檢查接口返回不健康的狀態(tài)，這樣就不會有新的請求進入新版本的應(yīng)用實例。這可以通過配置或代碼來實現(xiàn)，例如：
# 不向注冊中心注冊服務(wù)
spring.cloud.polaris.discovery.register=false
// 讓健康檢查接口返回不健康的狀態(tài)
this.isHealthy = false;
-
在新版本的應(yīng)用實例完成初始化操作后，再向注冊中心注冊服務(wù)，或者讓健康檢查接口返回健康的狀態(tài)，這樣就可以讓新的請求被路由到新版本的應(yīng)用實例上。這可以通過配置或代碼來實現(xiàn)，例如：
# 向注冊中心注冊服務(wù)
spring.cloud.polaris.discovery.register=true
// 讓健康檢查接口返回健康的狀態(tài)
this.isHealthy = true;
這樣，就可以實現(xiàn)優(yōu)雅上線的過程，保證正在處理的請求不會被中斷，而新的請求會被路由到新版本的應(yīng)用上。
不過，如果對優(yōu)雅上線的極致要求不高，北極星本身就是支持優(yōu)雅上線的，無須做額外的操作。因為北極星的邏輯是，當 Spring 的 Bean 全部加載完成后，Controller 能訪問后才會去注冊服務(wù)。所以，在絕大多數(shù)的場景下，它已經(jīng)滿足了優(yōu)雅上線的要求。
服務(wù)預(yù)熱
服務(wù)預(yù)熱是指在服務(wù)上線之前，先讓服務(wù)處于一個運行狀態(tài)，讓其加載必要的資源、建立連接等，以便在服務(wù)上線后能夠快速響應(yīng)請求。如下圖所示。
在流量較大情況下，剛啟動的服務(wù)直接處理大量請求可能由于應(yīng)用內(nèi)部資源初始化不徹底從而出現(xiàn)請求阻塞、報錯等問題。此時通過服務(wù)預(yù)熱，在服務(wù)剛啟動階段通過小流量幫助服務(wù)在處理大量請求前完成初始化，可以幫助發(fā)現(xiàn)服務(wù)上線后可能存在的問題，例如資源不足、連接數(shù)過多等，從而及時進行調(diào)整和優(yōu)化，確保服務(wù)的穩(wěn)定性和可靠性。
云原生 API 網(wǎng)關(guān)實現(xiàn)服務(wù)預(yù)熱
云原生 API 網(wǎng)關(guān)是騰訊云基于開源微服務(wù)網(wǎng)關(guān)推出的一款高性能高可用的云上網(wǎng)關(guān)托管產(chǎn)品。我們可以通過簡單的幾個配置就能實現(xiàn)服務(wù)預(yù)熱。
首先我們在網(wǎng)關(guān)新建后端服務(wù)的時候，可以打開下圖中的慢啟動開關(guān)。同時可以設(shè)置慢啟動的時間。
開啟后，服務(wù)端有新的服務(wù)節(jié)點上線后，會在設(shè)置的慢啟動的時間內(nèi)，將新節(jié)點的權(quán)重從1逐步增加到目標值。這個新節(jié)點的流量會慢慢增加。
如果有多個新增節(jié)點，那所有新增的節(jié)點都會慢啟動。
針對后端來源是 K8S 服務(wù) 、注冊中心、IP 列表的服務(wù)都可以實現(xiàn)慢啟動，也就是服務(wù)預(yù)熱。
優(yōu)雅下線
無損下線、優(yōu)雅下線都是同一個意思。都是為了避免服務(wù)下線的時候由于請求沒有處理完導致請求失敗的情況。
優(yōu)雅下線的方法
無損下線的一些常用的工具或框架有：
-
Dubbo-go：支持多種注冊中心、負載均衡、容災(zāi)策略等，可以實現(xiàn)優(yōu)雅上下線的設(shè)計與實踐。
-
Spring Cloud：提供了多種組件來實現(xiàn)服務(wù)的配置、路由、監(jiān)控、熔斷等，可以通過監(jiān)聽 ContextClosedEvent 事件來實現(xiàn)優(yōu)雅下線的邏輯。
-
Docker：可以通過 Docker Stop 或 Docker Kill 命令來停止容器，前者會發(fā)送 SIGTERM 信號給容器的 PID1 進程，后者會發(fā)送 SIGKILL 信號。如果程序能響應(yīng) SIGTERM 信號，就可以實現(xiàn)優(yōu)雅下線的操作。
Spring Cloud 優(yōu)雅下線的原理
ContextClosedEvent 是 Spring 容器在關(guān)閉時發(fā)布的一個事件，可以通過實現(xiàn) ApplicationListener 接口來監(jiān)聽這個事件，并在 onApplicationEvent 方法中執(zhí)行一些自定義的邏輯。
對于 Spring Cloud 中的微服務(wù)來說，當收到 ContextClosedEvent 事件時，可以做以下幾件事情：
-
從注冊中心注銷當前服務(wù)，這樣就不會再有新的請求進入。
-
拒絕或者延遲新的請求，這樣就可以保證正在處理的請求不會被中斷。
-
等待一段時間，讓舊的請求處理完畢，或者超時。
-
關(guān)閉服務(wù)，釋放資源。
這樣就可以實現(xiàn)優(yōu)雅下線的邏輯，避免因為服務(wù)的變更而造成流量的中斷或錯誤。
Spring Boot 優(yōu)雅下線的 Demo
在舊版本里面，我們需要實現(xiàn) TomcatConnectorCustomizer 和 ApplicationListener<ContextClosedEvent>接口，然后就可以在 Customize 方法中獲取到 Tomcat 的 Connector 對象，并在 onApplicationEvent 方法中監(jiān)聽到 Spring 容器的關(guān)閉事件。
在2.3及以后版本，我們只需要在 application.yml 中添加幾個配置就能啟用優(yōu)雅關(guān)停了。
# 開啟優(yōu)雅停止 Web 容器，默認為 IMMEDIATE：立即停止
server:
shutdown: graceful
# 最大等待時間
spring:
lifecycle:
: 30s
這個開關(guān)的具體實現(xiàn)邏輯在我們在 GracefulShutdown 里。
然后我們需要添加 Actuator 依賴，然后在配置中暴露 Actuator 的 Shutdown 接口。
# 暴露 shutdown 接口
management:
endpoint:
shutdown:
enabled: true
endpoints:
web:
exposure:
include: shutdown
這個時候，我們調(diào)用 http://localhost:8080/actuator/shutdown 就可以執(zhí)行優(yōu)雅關(guān)停了，它會返回如下內(nèi)容：
{
"message": "Shutting down, bye..."
}
優(yōu)缺點
我覺得這種方法有以下的優(yōu)點和缺點：
優(yōu)點：
-
簡單易用，只需要實現(xiàn)兩個接口，就可以實現(xiàn)優(yōu)雅下線的邏輯。
-
適用于 Tomcat 作為內(nèi)嵌容器的 Spring Boot 應(yīng)用，不需要額外的配置或依賴。
-
可以保證正在處理的請求不會被中斷，而新的請求不會進入，避免了服務(wù)的變更造成流量的中斷或錯誤。
缺點：
-
只適用于 Tomcat 作為內(nèi)嵌容器的 Spring Boot 應(yīng)用，如果使用其他的容器或部署方式，可能需要另外的實現(xiàn)。
-
需要等待一定的時間，讓正在處理的請求完成或超時，這可能會影響服務(wù)的停止速度和資源的釋放。
-
如果正在處理的請求過多或過慢，可能會導致線程池無法優(yōu)雅地關(guān)閉，或者超過系統(tǒng)的終止時間，造成強制關(guān)閉。
Docker 優(yōu)雅下線的 Demo
這里用一個簡單的 JS 應(yīng)用來演示 Docker 實現(xiàn)無損下線的過程。
首先，我們需要創(chuàng)建一個 Dockerfile 文件，用于定義一個簡單的應(yīng)用容器，代碼如下：
# 基于 node:14-alpine 鏡像
FROM node:14-alpine
# 設(shè)置工作目錄
WORKDIR /app
# 復制 package.json 和 package-lock.json 文件
COPY package*.json ./
# 安裝依賴
RUN npm install
# 復制源代碼
COPY . .
# 暴露 3000 端口
EXPOSE 3000
# 啟動應(yīng)用
CMD [ "node", "app.js" ]
然后，我們需要創(chuàng)建一個 app.js 文件，用于定義一個簡單的 Web 應(yīng)用，代碼如下：
// 引入 express 模塊
const express = require('express');
// 創(chuàng)建 express 應(yīng)用
const app = express();
// 定義一個響應(yīng) /hello 路徑的接口
app.get('/hello', (req, res) => {
// 返回 "Hello, I am app" 字符串
res.send('Hello, I am app');
});
// 監(jiān)聽 3000 端口
app.listen(3000, () => {
// 打印日志信息
console.log('App listening on port 3000');
});
接下來，我們需要在終端中執(zhí)行以下命令，來構(gòu)建和運行我們的應(yīng)用容器，并查看頁面結(jié)果。
# 構(gòu)建鏡像，命名為 app:1.0.0
docker build -t app:1.0.0 .
# 運行容器，命名為 app-1，映射端口為 3001:3000
docker run -d --name app-1 -p 3001:3000 app:1.0.0
# 查看容器運行狀態(tài)和端口映射信息
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a8a9f9f7c6c4 app:1.0.0 "docker-entrypoint.s…" 10 seconds ago Up 9 seconds 0.0.0.0:3001->3000/tcp app-1
# 在瀏覽器中訪問 <http://localhost:3001/hello> ，可以看到返回 "Hello, I am app" 字符串
這個時候假設(shè)我們要發(fā)布一個新版本的應(yīng)用，我們需要修改 app.js 文件中的代碼，把返回的字符串修改為 “Hello, I am app v2”。
然后，我們需要在終端中執(zhí)行以下命令，來構(gòu)建和運行新版本的應(yīng)用容器：
# 構(gòu)建鏡像，命名為 app:2.0.0
docker build -t app:2.0.0 .
# 運行容器，命名為 app-2，映射端口為 3002:3000
docker run -d --name app-2 -p 3002:3000 app:2.0.0
# 查看容器運行狀態(tài)和端口映射信息
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b7b8f8f7c6c4 app:2.0.0 "docker-entrypoint.s…" 10 seconds ago Up 9 seconds 0.0.0.0:3002->3000/tcp app-2
a8a9f9f7c6c4 app:1.0.0 "docker-entrypoint.s…" 2 minutes ago Up 2 minutes 0.0.0.0:3001->3000/tcp app-1
# 在瀏覽器中訪問 <http://localhost:3002/hello> ，可以看到返回 "Hello, I am app v2" 字符串
接下來，需要優(yōu)雅地下線舊版本的應(yīng)用容器，讓它完成正在處理的請求，然后停止接收新的請求，最后退出進程。
# 向舊版本的應(yīng)用容器發(fā)送 SIGTERM 信號，讓它優(yōu)雅地終止
docker stop app-1
# 查看容器運行狀態(tài)和端口映射信息
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b7b8f8f7c6c4 app:2.0.0 "docker-entrypoint.s…" 2 minutes ago Up 2 minutes 0.0.0.0:3002->3000/tcp app-2
# 在瀏覽器中訪問 <http://localhost:3001/hello> ，可以看到無法連接到服務(wù)器的錯誤
這樣，我們就實現(xiàn)了通過 Docker 來做優(yōu)雅下線的過程，保證正在處理的請求不會被中斷，而新的請求會被路由到新版本的應(yīng)用上。
這里主要用到了 Docker Stop 命令。Docker Stop 命令會向容器發(fā)送 SIGTERM 信號，這是一種優(yōu)雅終止進程的方式，它會給目標進程一個清理善后工作的機會，比如完成正在處理的請求，釋放資源等。如果目標進程在一定時間內(nèi)（默認為 10 秒）沒有退出，Docker Stop 命令會再發(fā)送 SIGKILL 信號，強制終止進程。
所以，使用 Docker Stop 命令能實現(xiàn)優(yōu)雅下線的前提是，容器中的應(yīng)用能夠正確地響應(yīng) SIGTERM 信號，并在收到該信號后執(zhí)行清理工作。如果容器中的應(yīng)用忽略了 SIGTERM 信號，或者在清理工作過程中出現(xiàn)異常，那么 Docker Stop 命令就無法實現(xiàn)優(yōu)雅下線的效果。
讓容器中的應(yīng)用正確地響應(yīng) SIGTERM 信號的方法，主要取決于容器中的 1 號進程是什么，以及它如何處理信號。如果容器中的 1 號進程就是應(yīng)用本身，那么應(yīng)用只需要在代碼中為 SIGTERM 信號注冊一個處理函數(shù)，用于執(zhí)行清理工作和退出進程。例如，在 Node.js 中，可以這樣寫：
// 定義一個處理 SIGTERM 信號的函數(shù)
function termHandler() {
// 執(zhí)行清理工作
console.log('Cleaning up...');
// 退出進程
process.exit(0);
}
// 為 SIGTERM 信號注冊處理函數(shù)
process.on('SIGTERM', termHandler);
北極星的優(yōu)雅下線
北極星的心跳默認是5秒維持一次，客戶端的緩存默認是2秒刷新一次。理論上，在極致情況下，服務(wù)下線會有2秒的不可用時間。但客戶端都有重試機制，且大部分客戶端的超時時間都是大于2秒的。因此大部分情況下，服務(wù)在北極星下線是不會造成業(yè)務(wù)感知的。
北極星的優(yōu)雅下線有多種方式。其中上面的 Spring Boot 與 Docker 的方式是其中兩種。
另外一種是可以在服務(wù)下線的時候，在 PreStop 的時候去做服務(wù)隔離與反注冊。
這樣的隔離操作可以手動做，也可以通過腳本來自動做。
如上圖，被隔離的實例將不會被主調(diào)方發(fā)現(xiàn)，這樣就不會有新的需求進來，在處理完成現(xiàn)有的請求后，就可以執(zhí)行下線操作了。
總結(jié)
優(yōu)雅上下線的價值
在微服務(wù)實踐中，實現(xiàn)優(yōu)雅上下線能給我們帶來以下好處：
-
最小化服務(wù)中斷：通過優(yōu)雅上下線，可以最小化服務(wù)中斷的時間和影響范圍，從而確保服務(wù)的可用性和穩(wěn)定性。
-
避免數(shù)據(jù)丟失：優(yōu)雅下線可以確保正在處理的請求能夠完成，避免數(shù)據(jù)丟失和請求失敗。
-
提高用戶體驗：優(yōu)雅上下線可以確保用戶在使用服務(wù)時不會遇到任何中斷或錯誤，從而提高用戶體驗和滿意度。
-
簡化部署流程：通過使用自動化工具和流程，可以簡化部署流程，減少人工干預(yù)和錯誤，提高部署效率和質(zhì)量。
-
提高可維護性：通過使用監(jiān)控和日志記錄工具，可以及時發(fā)現(xiàn)和解決問題，提高服務(wù)的可維護性和可靠性。
這些好處可以幫助企業(yè)提高服務(wù)質(zhì)量和效率，提升用戶滿意度和競爭力。
優(yōu)雅上下線的挑戰(zhàn)
但同時，優(yōu)雅上下線也面臨一些挑戰(zhàn)：
-
復雜性增加：微服務(wù)架構(gòu)通常由多個服務(wù)組成，每個服務(wù)都有自己的生命周期和依賴關(guān)系，因此優(yōu)雅上下線需要考慮多個服務(wù)之間的交互和協(xié)調(diào)，增加了系統(tǒng)的復雜性。
-
部署流程復雜：優(yōu)雅上下線需要使用自動化工具和流程，這需要投入大量的時間和資源來構(gòu)建和維護，增加了部署流程的復雜性。
-
數(shù)據(jù)一致性問題：優(yōu)雅下線需要確保正在處理的請求能夠完成，但這可能會導致數(shù)據(jù)一致性問題，需要采取措施來解決這個問題。
-
人員技能要求高：微服務(wù)架構(gòu)需要具備更高的技術(shù)水平和技能，需要擁有更多的開發(fā)和運維經(jīng)驗，這對企業(yè)的人員要求較高。
綜上所述，企業(yè)需要認真考慮這些挑戰(zhàn)，并采取相應(yīng)的措施來解決這些問題，以確保在微服務(wù)實踐中更好的落地優(yōu)雅上下線。
往期
推薦
《基于 DTS 同步 MySQL 全增量數(shù)據(jù)至 CKafka，構(gòu)建實時數(shù)倉的最佳實踐 》
《微服務(wù)引擎 TSE 5月產(chǎn)品動態(tài)，TSE 云原生網(wǎng)關(guān)支持節(jié)點規(guī)格升降配》
《消息隊列產(chǎn)品5月產(chǎn)品動態(tài)，消息隊列 CKafka 支持按量轉(zhuǎn)包年包月》
《業(yè)務(wù)高速增長，如祺出行如何用騰訊云消息隊列 RocketMQ 應(yīng)對挑戰(zhàn)》
《重新理解RocketMQ Commit Log存儲協(xié)議》
掃描下方二維碼關(guān)注本公眾號，
了解更多微服務(wù)、消息隊列的相關(guān)信息！
解鎖超多鵝廠周邊！
戳原文，查看更多微服務(wù)引擎 TSE的信息！
點個在看你最好看