MCP 网关实战：基于 Higress + Nacos 的零代码工具扩展方案-低调大师

MCP 网关实战：基于 Higress + Nacos 的零代码工具扩展方案

2025-12-08 30

作者：陆胤任

背景

在 AI 大爆发的时代，已经有非常多的 AI 助手，结合 RAG 通过智能问答帮助用户解答问题。单纯地依靠智能问答帮助客户自助解答是远远不够的，我们需要让 AI 助手能够直接调用已有的丰富接口，朝着更强大的智能体演进。我们选用当下最为火热，且已逐步成为标准的 MCP 作为模型和接口之间通信的传输协议。关于 MCP，已有非常多的介绍文章，本文不再赘述。

在企业对外服务的场景下，MCP Server 需要解决以下几个问题：

在服务的多实例高可用场景下，使用 SSE 通信方式如何维护 session；
如何做到动态更新 MCP 工具 Prompt，做到快速更新&调试&验证；
租户隔离的云服务场景下如何对用户的工具调用进行鉴权。

Higress 可以很好地解决上面的问题 1，同时还有完善的运维监控体系，可视化易操作的控制台界面。为了解决问题 2，我们引入了 Nacos 负责注册后端服务以及管理维护 MCP 工具的元数据等信息。在整个 MCP 服务中，Higress 担任 MCP Proxy 的角色，Nacos 担任 MCP Registry 的角色。对于问题 3 租户隔离问题，会在下面鉴权章节中进行详细说明。

Higress 和 Nacos 都是云原生的应用，在部署方面，自然选择使用 K8s 集群进行云原生部署。同时很多企业有自己的专属生产网络环境，一般和外网不通，因此本文会围绕如何利用社区版本的 Higress 和 Nacos（Apache-2.0 开源协议）进行私有化部署。因为内部环境的限制，我们没有办法直接通过 Helm 操作 K8s 集群进行部署，因此本文会围绕如何基于 Higress 和 Nacos 的 docker 镜像在 K8s 集群上进行分角色部署。

通过这套自建的网关服务，使用配置即可实现零代码扩展 Tool，新应用的注册、应用下面工具的扩展、工具 prompt 更新验证都能通过服务集成的可视化控制台，更新发布配置快速完成，接入方式极其简单！更新验证极其快速！ 同时利用 Nacos 的命名空间能力可以做到服务和工具集的隔离，给不同的用户提供不同的 MCP 工具集。

私有化部署

Higress

Higress 支持三种部署方式：Helm、docker compose 和基于 all-in-one 的 docker 镜像进行部署。Higress 官方推荐使用 Helm 的方式进行生产环境的部署，将依赖的模块部署在不同的 pod 上。而因上述环境原因，这里选择使用第三种基于 all-in-one 的 docker 镜像 Dockerfile [ 1] 进行部署，将 Higress 依赖的组件以进程的方式部署在同一 pod 上面，通过多副本的方式实现服务高可用，也实现了对 K8s 集群 Ingress 的无侵入式部署。

我们先尝试直接引用 docker 镜像进行部署时，会报 WASM 的插件错误，查看报错信息是通过 oci 地址去下载 WASM 插件的时候出现了问题。同时 Higress 实现 MCP 功能也依赖了 WASM 插件，这是一个绕不开的问题。

FROM higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/all-in-one:latest

WASM 插件独立部署

Higress 的 plugin-server [ 2] 项目就是为了"解决私有化部署 Higress 网关时拉取插件的痛点，优化了插件的下载与管理效率"，使 Higress 通过 http 的方式去下载独立部署的插件库，而不是通过 oci 去访问外部公开仓库，避免因网络问题导致插件拉取不下来。解决过程主要分为以下三个步骤：

1）私有化部署 plugin-server

FROM higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/plugin-server:1.0.0

2）为 plugin-server 集群申请 K8s Service（Cluster IP）

apiVersion: v1
kind: Service
metadata:
  name: higress-plugin-server
  namespace: higress-system
  labels:
    app: higress-plugin-server
    higress: higress-plugin-server
spec:
  type: ClusterIP
  ports:
    - port: 80
      protocol: TCP
      targetPort: 8080
  selector:
    app: higress-plugin-server
    higress: higress-plugin-server

K8s 集群内置的 DNS 为此创建的域名解析记录的格式为 <service-name>.<namespace>.svc.cluster.local。

在没有 K8s 的场景下也可以为 plugin-server 集群申请内网 VIP 或者 SLB 做好服务发现和负载均衡。

3）修改 Higress 内置插件下载地址

依照 github 中的示例，在基于 Higress 镜像的项目 Dockerfile 中声明插件的下载地址。这里有个地方需要注意下，readme 中给出的示例是环境变量的格式。

在 Dockerfile 中声明需要转义一下，${name}/${version} 的形式才可以被正确解析。

...
# 模版
ENV HIGRESS_ADMIN_WASM_PLUGIN_CUSTOM_IMAGE_URL_PATTERN=http://[申请的k8s service地址]/plugins/\${name}/\${version}/plugin.wasm
# mcp wasm 插件下载地址
ENV MCP_SERVER_WASM_IMAGE_URL=http://[申请的k8s service地址]/plugins/mcp-server/1.0.0/plugin.wasm
...

配置完独立的插件 HTTP 下载地址后重新部署，在服务器上可以看到 8080 端口以及 8443 端口可以被正常监听，说明 Higress 具备代理和网关功能的核心数据面组件已经可以正常服务了。

解决完 WASM 插件下载问题，基于 docker 镜像的 Higress 服务就可以被成功拉起并运行了。只不过基于这种模式部署的每个 pod 都是独立、对等、包含全部组件、功能完整的 Higress 服务，需要通过多副本的方式实现高可用。

这种部署模式下，通过 Higress 自身集成的控制台去运维服务&更改配置是不现实的，只能操作一台实例的配置变更，无法让实例间进行配置同步。因此在这种模式下的缺点是，只能通过在项目代码中维护配置文件，需要更改时走发布流程，将配置发布到每台实例上面。不过在我们这个场景下，需要变更配置的情况不多。

粘性会话

在 MCP SSE 通信方式下，天然需要解决粘性会话的问题，Higress 基于 Redis 帮我们解决了这个问题。提前部署好 Redis 实例之后，打开 Higress 的 MCP 功能，并将 Redis 配置更新进去，重新部署一下就可以使用 MCP 的功能了。

...
data:
  higress: |-
    mcpServer:
      enable: true
      sse_path_suffix: /sse
      redis:
        address: xxx.redis.zhangbei.rds.aliyuncs.com:6379
        username: ""
        password: "xxx"
        db: 0
...

这份配置文件可以维护在自己的基于 Higress 镜像的项目中，在部署的时候将配置文件 COPY 到指定目录（这种部署模式下，所有的配置文件都应该这么做）。

...
# custom config
COPY config/configmaps/higress-config.yaml /data/configmaps/higress-config.yaml
COPY config/mcpbridges/default.yaml /data/mcpbridges/default.yaml
COPY config/secrets/higress-console.yaml /data/secrets/higress-console.yaml
RUN chmod +x /data/configmaps/higress-config.yaml && \
    chmod +x /data/secrets/higress-console.yaml && \
    chmod +x /data/mcpbridges/*
...

当整个 MCP 网关搭建完并使用的时候，在 redis 上通过 PSUBSCRIBE mcp-server-sse:* 命令可以看到如下的调用信息。

自定义构建镜像

官方构建出来的镜像一般会要求体积小，满足最小运行要求，所以很多功能其实并不集成在 Higress 的镜像中。如果你的企业有自己约定的通用镜像，或者是想在原本的基础上集成一些新的功能，如使用阿里云的 SLS、云监控等功能，就需要根据 all-in-one 镜像的 Dockerfile 内容进行自定义构建。这里有个注意的点是，Higress 中的 envoy 模块要求的 glibc 是 2.18 及以上版本。

其实只需要将 Higress 的 Dockerfile 文件内容移植过来就行，然后再声明下独立部署的 WASM 插件下载地址，就能实现基于指定镜像进行 Higress 自定义构建打包部署了。

Higress 服务搭建好后，就可以走对外公网访问的流程了：（1）一个是绑定 8001 端口，通过 Higress 控制台进行查看相关配置的域名，限制为只允许内网访问。注：这种模式下无法通过控制台直接去更改配置；（2）另一个是绑定 8080 端口，对外提供 MCP 网关服务的域名。

完整的 Dockerfile 如下：

FROM [企业内部基础镜像]
# 下面为 Higress all-in-one dockerfile中的内容
ARG HUB=higress-registry.cn-hangzhou.cr.aliyuncs.com/higress
...
# 模版
ENV HIGRESS_ADMIN_WASM_PLUGIN_CUSTOM_IMAGE_URL_PATTERN=http://[申请的k8s service地址]/plugins/\${name}/\${version}/plugin.wasm
# mcp wasm 插件下载地址
ENV MCP_SERVER_WASM_IMAGE_URL=http://[申请的k8s service地址]/plugins/mcp-server/1.0.0/plugin.wasm
...
# 注意 dockerfile 中会去 github 下载对应处理器架构下的 yq 模块，企业内网环境下可以提前下载下来
COPY ./yq_linux_[arch] /usr/local/bin/yq
...
# custom config
COPY config/configmaps/higress-config.yaml /data/configmaps/higress-config.yaml
COPY config/mcpbridges/default.yaml /data/mcpbridges/default.yaml
COPY config/secrets/higress-console.yaml /data/secrets/higress-console.yaml
RUN chmod +x /data/configmaps/higress-config.yaml && \
    chmod +x /data/secrets/higress-console.yaml && \
    chmod +x /data/mcpbridges/*
...

Nacos

Nacos 的部署相对简单，除了通过 kubectl 或者 nacos-operator 工具直接操作 K8s 集群部署外，还可以直接基于 nacos-server 的镜像进行部署 Dockerfile [ 3] 。因上文提到的内部环境问题，我们这里选择基于 nacos-server 的镜像，将服务部署于 K8s 集群上面。

FROM nacos-registry.cn-hangzhou.cr.aliyuncs.com/nacos/nacos-server:latest

集群模式部署

Nacos 集群模式下使用的一致性协议是基于 Raft 实现的，因此最小需要部署 3 台实例。

在引用 nacos-server 镜像的 dockerfile 中，声明 cluster 的部署模式。我们查看 nacos 的启动脚本，发现在 peer-finder（插件）目录不存在的情况下，如果定义了 $NACOS_SERVERS 变量，会将 $NACOS_SERVERS 变量中的值写入 $CLUSTER_CONF 文件中，$CLUSTER_CONF 文件的默认路径是 /home/nacos/conf/cluster.conf，其中定义的就是 Nacos 集群的静态成员地址列表，它在集群首次启动时会被读取，用于告知每个节点"邻居"在哪，从而让它们能够互相发现、建立连接，并初始化 Raft 一致性协议。

...
PLUGINS_DIR="/home/nacos/plugins/peer-finder"
function print_servers() {
   if [[ ! -d "${PLUGINS_DIR}" ]]; then
    echo "" >"$CLUSTER_CONF"
    for server in ${NACOS_SERVERS}; do
      echo "$server" >>"$CLUSTER_CONF"
    done
  else
    bash $PLUGINS_DIR/plugin.sh
    sleep 30
  fi
}
...

因此我们可以在 Dockerfile 中维护当前集群下的 [实例 IP:端口] 列表，供 Nacos 集群启动时读取并初始化。

...
ENV MODE=cluster
ENV NACOS_AUTH_TOKEN=xxx
ENV NACOS_AUTH_IDENTITY_KEY=xxx
ENV NACOS_AUTH_IDENTITY_VALUE=xxx
ENV NACOS_SERVERS="10.0.0.1:8848 10.0.0.2:8848 10.0.0.3:8848"
# nacos 用户名密码
ENV NACOS_USERNAME=xxx
ENV NACOS_PASSWORD=xxx
...

实例间动态发现

上面这种固定 IP 列表的方式缺点是显而易见的。它是一个静态的配置，当出现集群的扩缩容时，实例是没有办法自动去更新成员 IP 列表的，需要手动修改并发布，整个过程非常繁琐，严重情况下可能会影响线上服务的稳定性；且在云原生容器化背景下，IP 并不是固定的，随时有可能会因为故障迁移而改变 IP，维护静态 IP 列表与云原生的理念背道而驰。线上生产是完全不推荐这种方式的。

再回到上面 docker-startup.sh 脚本，可以通过 peer-finder 插件来实现集群间实例的发现，取代手动维护 cluster.conf 文件。peer-finder 插件运行依赖于 K8s 集群 Headless Service 域名，会去执行类似于 nslookup 命令查找 Service 下面的所有健康 Pod 的 IP 列表，类比于服务发现的能力 [ 4] ，这样就不用再手动去维护实例 IP 列表。

但是 peer-finder 的运行依赖于 StatefulSet 的实例部署模式，需要每个实例有固定的实例名。因为我们内部环境的限制，我们现在部署的都是无状态的实例，所以没有办法通过 peer-finder 来做这个事情。但是我们可以参照 peer-finder 脚本的实现思路，来自己写一个启动脚本。

1）首先为 Nacos 集群申请 Headless 的 Service。

apiVersion: v1
kind: Service
metadata:
  name: nacos-headless
  namespace: mcp-nacos
  labels:
    app: mcp-nacos
    nacos: mcp-nacos
spec:
  clusterIP: None
  ports:
  - name: peer-finder-port
    port: 8848
    protocol: TCP
    targetPort: 8848
  selector:
    app: mcp-nacos
  sessionAffinity: None
  type: ClusterIP

2）这里修改下 nacos-docker 的启动脚本，提供一个简单的实现。（仅供参考）

...
原docker-startup.sh内容
...
# 新增内容
# 注释掉 JAVA启动命令
# exec $JAVA ${JAVA_OPT}
export JAVA_OPT # export JAVA 启动参数，方面下面读取
HEADLESS_SERVICE_FQDN="xxx.svc.cluster.local"
CLUSTER_CONF_FILE="/home/nacos/conf/cluster.conf"
UPDATE_SCRIPT="/home/nacos/bin/update-cluster.sh" # 原子更新脚本
NACOS_START_CMD="$JAVA $JAVA_OPT"
# 1. 动态创建 update-cluster.sh 脚本
cat > ${UPDATE_SCRIPT} << 'EOF'
#!/bin/bash
set -e
NACOS_PORT=${NACOS_APPLICATION_PORT:-8848}
CLUSTER_CONF_FILE="/home/nacos/conf/cluster.conf"
TMP_CONF_FILE="/home/nacos/conf/cluster.conf.tmp"
> "${TMP_CONF_FILE}"
# 从标准输入读取 nslookup 的原始输出
awk '
/^Name:/ { flag=1; next }
flag && /^Address:/ { print $2; flag=0 }
' | while IFS= read -r ip; do
    if [ -n "$ip" ]; then
      echo "${ip}:${NACOS_PORT}" >> "${TMP_CONF_FILE}"
    fi
done
# 排序以确保文件内容的一致性，避免不必要的更新
sort -o "${TMP_CONF_FILE}" "${TMP_CONF_FILE}"
# 只有在新旧配置不同时才执行更新
# 检查旧文件是否存在
if [ ! -f "${CLUSTER_CONF_FILE}" ] || ! cmp -s "${TMP_CONF_FILE}" "${CLUSTER_CONF_FILE}"; then
    echo "[$(date)][update-script] Peer list changed. Updating config."
    mv "${TMP_CONF_FILE}" "${CLUSTER_CONF_FILE}"
    echo "[$(date)][update-script] cluster.conf updated:"
    cat "${CLUSTER_CONF_FILE}"
else
    rm "${TMP_CONF_FILE}"
fi
EOF
chmod +x ${UPDATE_SCRIPT}
# 2. 启动前的初始化循环
MAX_INIT_RETRIES=30
RETRY_COUNT=0
MIN_PEERS=3 # 期望的集群最小副本数量
echo "[INFO] Initializing cluster config. Waiting for at least ${MIN_PEERS} peers to be available..."
while true; do
  # 直接将 nslookup 的输出通过管道传给更新脚本
  nslookup "${HEADLESS_SERVICE_FQDN}" | ${UPDATE_SCRIPT}
  # 检查生成的配置文件行数
  LINE_COUNT=$(wc -l < "${CLUSTER_CONF_FILE}")
  if [ "${LINE_COUNT}" -ge "${MIN_PEERS}" ]; then
    echo "[INFO] Initial cluster.conf is ready with ${LINE_COUNT} peers."
    break
  fi
  RETRY_COUNT=$((RETRY_COUNT+1))
  if [ "${RETRY_COUNT}" -gt "${MAX_INIT_RETRIES}" ]; then
    echo "[WARN] Could not find ${MIN_PEERS} peers after ${MAX_INIT_RETRIES} retries. Starting with ${LINE_COUNT} peers found."
    break
  fi
  echo "[INFO] Found ${LINE_COUNT} peers. Waiting for more... Retrying in 5 seconds."
  sleep 5
done
# 3. 在后台启动我们自己的监控循环
(
  while true; do
    sleep 15 # 每 15 秒检查一次
    echo "[$(date)][monitor] Checking for peer updates..."
    nslookup "${HEADLESS_SERVICE_FQDN}" | ${UPDATE_SCRIPT}
  done
) &
# 4. 启动 Nacos 主进程
echo "[INFO] Starting Nacos server..."
exec sh -c "${NACOS_START_CMD}"

这样我们 cluster.conf 文件中的成员 IP 列表就实现了自动更新。

线上生产环境还是推荐使用有状态 StatefulSet 的部署模式，并结合 peer-finder 的能力实现实例间的互相发现。而不是用无状态的实例，自己去写脚本实现。后续我们也会升级到 StatefulSet 的模式进行部署。

配置外置 Mysql

在集群部署模式下，就无法使用 Nacos 内置的不支持数据共享的 Derby 数据库，需要配置外置的 Mysql 数据库。提前部署好 Mysql 实例之后，按照 Nacos 中的 mysql-schema.sql [ 5] 数据库配置文件将表初始化，再将 mysql 配置信息写入 Dockerfile 中即可。

...
# mysql config
ENV SPRING_DATASOURCE_PLATFORM=mysql
ENV MYSQL_DATABASE_NUM=1
ENV MYSQL_SERVICE_HOST=xxx.mysql.zhangbei.rds.aliyuncs.com
ENV MYSQL_SERVICE_PORT=3306
ENV MYSQL_SERVICE_DB_NAME=nacos
ENV MYSQL_SERVICE_USER=xxx
ENV MYSQL_SERVICE_PASSWORD=xxx
...

在为 Nacos 做服务暴露的时候，只需要暴露 Nacos 控制台的 8080 端口，且限制为只允许内网访问即可。因为 Nacos 只是内部作为维护管理 MCP 工具元数据信息的 MCP Registry 使用，对用户侧不感知；且 Higress 和 Nacos 都部署在内网的 K8s 集群上面，内部通信通过 K8s 的 Service 即可，无需将 Nacos 的 8848 端口暴露给公网。

申请 K8s Service 供 Higress 使用

注意 Higress 拉取/订阅 Nacos 中的配置会通过 gRPC 的方式调用，这里的 Service 需要暴露 8848 和 9848 两个端口给 Higress 使用。

apiVersion: v1
kind: Service
metadata:
  name: pre-oss-mcp-nacos-endpoint
  namespace: aso-oss-mcp-nacos
  labels:
    app: mcp-nacos
    nacos: mcp-nacos
spec:
  type: ClusterIP
  ports:
  - name: subscribe-port
    port: 8848
    protocol: TCP
    targetPort: 8848
  - name: grpc-port
    port: 9848
    protocol: TCP
    targetPort: 9848
  selector:
    app: nacos

同理，如果想使用企业内部的镜像，或者是想在原本的基础上即成一些新的功能，如使用阿里云的 SLS、云监控等功能，也可根据 Nacos 的 Dockerfile 进行自定义构建部署。

鉴权

Higress 自身提供了丰富的鉴权 [6 ] 能力，如果你的企业本身就基于 Higress 搭建了自己的网关并使用了 Higress 提供的鉴权能力，这种场景下直接复用原来的方案即可。

另一种场景下，企业中会有多个服务 Provider，每个 Provider 有不同的鉴权方式。如下图所示，某个服务提供者会通过拦截器对请求中携带的用户 Cookie 进行 RAM 鉴权；另一个服务提供者会通过 tengine lua 脚本对请求进行自定义鉴权；以及后续注册的服务可能有其他的鉴权方式。

一方面，我们并不希望使用 Higress 的鉴权能力去覆盖全部的鉴权场景，开发维护成本过高，我们优先考虑直接复用服务提供者已有的鉴权能力；另一方面，如果通过网关层鉴权需要将 AK 或者认证信息存放在 Higress 服务上，在安全层面也不是一个合适的做法。

这里推荐的做法是直接在 MCP 工具调用的时候，将鉴权信息透传给服务提供者，让服务提供者完成鉴权。

MCP 验证

根据文档 [ 7] 中的操作示例，我们可以简单做个全链路测试验证。主要分为以下三步：

1）在 Nacos 中注册服务，并配置 MCP 工具的元数据信息：

在 public 命名空间下，创建服务信息。

在机器上将自己的服务作为永久实例注册进去。（这里为了快速验证黑屏登陆机器操作，线上生产环境还是须要白屏操作）

curl -X POST 'http://127.0.0.1:8848/nacos/v1/ns/instance?namespaceId=[namespace]&serviceName=[service_name]&groupName=[group_name]&ip=[服务域名]&port=[服务端口]&ephemeral=false'

注册完之后，就能在 Nacos 控制台上看到注册的服务配置以及健康状态。

接着在 Nacos 控制台上配置 MCP 工具，添加一个简单工具，可以选择一个无参数 GET 接口，并发布。

{
  "requestTemplate": {
    "url": "/xxx/list.json",
    "method": "GET",
    "headers": [],
    "argsToUrlParam": true
  },
  "responseTemplate": {
    "body": "{{.}}"
  }
}

2）在 Higress 中配置 MCP Nacos 的服务来源：

这里为了快速测试关闭了 Nacos 的认证，线上环境建议开启 Nacos 的认证。

3）在 Cursor/Cherry Studio 中配置对外暴露的 Higress 服务地址和 uri，即可使用 MCP 工具：

设计图

容灾架构

进入浏览器查看原图：https://img.alicdn.com/imgextra/i2/O1CN0138v82b1L7vNY3RQdo_!!6000000001253-2-tps-6507-5451.png

在整个 MCP 网关中，通过 uri 来路由不同的 MCP 工具，实现工具的隔离。

逻辑模块图

时序图

附录：

[1] 基于 all-in-one 的 docker 镜像

https://github.com/higress-group/higress-standalone/blob/main/all-in-one/Dockerfile

[2] higress-plugin-server

https://www.cnkirito.moe/higress-plugin-server/

[3] 基于 nacos-server 的镜像进行部署

https://github.com/nacos-group/nacos-docker/blob/master/build/Dockerfile

[4] 脚本源码

https://github.com/kmodules/peer-finder/blob/master/peer-finder.go

[5] mysql-schema.sql

https://github.com/alibaba/nacos/blob/develop/distribution/conf/mysql-schema.sql

[6] Higress 提供丰富鉴权能力

https://higress.cn/docs/latest/plugins/authentication/basic-auth/

[7] 基于 Nacos + Higress 的 MCP 开发新范式，手把手教程来了！

[8] Nacos 3.0 正式发布：MCP Registry、安全零信任、链接更多生态

[9] 修改内置插件的镜像地址

https://higress.cn/docs/latest/ops/how-tos/builtin-plugin-url/

[10] Nacos 集群模式

https://nacos.io/docs/latest/manual/admin/deployment/deployment-cluster/

微信关注我们

原文链接：https://my.oschina.net/u/3874284/blog/18910578

转载内容版权归作者及来源网站所有！

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

Zadig v4.1 全新发布:智能工作流、全景数据洞察、飞书生态集成

在 v4.0 发布"开发自由"理念后，Zadig 并未止步。今天，我们正式推出 Zadig v4.1.0 ------ 一次围绕智能增效、数据驱动与生态融合的全面进化。本次升级不仅深度强化了工作流的智能灵活性与系统企业级可靠性，更在研发效能数据洞察上实现了突破性重构。同时，我们很高兴宣布与飞书官方合作，实现从项目管理到 CI/CD 的全链路打通，真正构建起可观测、可决策的协同交付闭环。此外，多项企业级核心能力现已向社区免费开放，让每一位开发者都能享受更强大的研发体验！ ✈️ 生态融合：与飞书深度协同，打通研发数据流 Zadig v4.1.0 与飞书项目及协同套件实现深度集成，构建从需求到发布的全链路自动化协同。研发任务可直接触发构建、部署与发布审批，无缝衔接项目管理与工程交付，在提升自动化水平的同时，关键打通了管理意图与工程执行间的数据壁垒，形成可观测、可反馈的协同闭环，为团队效能与软件质量的持续提升提供坚实支撑。 🔄 工作流引擎：智能与灵活全面升级 Zadig v4.1.0 进一步强化工作流的智能控制与扩展能力：智能化执行控制：支持基于条件的任务状态判断，实现精细化流程管控...

2025-12-08

44

1. 背景在分布式系统中，消息队列（MQ）是实现系统解耦、异步通信的重要工具。然而，MQ消费时出现的消息乱序问题，经常会对业务逻辑的正确执行和系统稳定性产生不良影响。本文将详细探讨MQ消息乱序问题的根源，并提供一系列在实际应用中可行的解决方案。 2. MQ消息乱序问题分析常见的MQ消息乱序问题的根源主要可以归结为以下几点： 2.1 相同topic内的消息乱序 1). 并发消费：在分布式系统中，为了提高消息处理的吞吐量，通常会配置多个消费者实例来并发消费同一个队列中的消息。然而，由于消费者实例的机器性能、网络延迟以及处理速度的差异，可能导致消息的消费顺序与发送顺序不一致。 2). 消息分区：为了支持更高效的消息存储和消费，MQ系统通常会采用分区化的设计。然而，当同一业务逻辑的多条消息被分发到不同的分区时，消费者在消费这些消息时就可能出现乱序现象。 3). 网络延迟与抖动：消息在传输过程中可能会受到网络延迟和抖动的影响，导致消息到达消费者端的时间顺序与发送顺序不一致。 4). 消息重试与故障恢复：当消费者处理消息失败或出现故障时，MQ系统通常会进行消息重试或故障恢复操作。如果重...

2025-12-08

28

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。