前言

今年 3 月份 MCP 协议成为了 AI 的新一轮热点，被大多数人所熟知，彼时 Higress 快速进行跟进，新增了 MCP 协议转换功能，详见：https://higress.cn/ai/mcp-quick-start ，该方案解决了以下问题：

1. 引入 Redis，借助其 pub/sub 特性，解决了 SSE 协议会话保持的问题
2. 提供了 OpenAPI 转换成 MCPServer 的能力，仅需提供符合 OAS 3.0 规范的 OpenAPI 文档，即可自动转换成网关托管的 MCPServer
3. 提供了 Go Template 和 GJSON 表达式，来对请求和响应模版进行精细化处理，这使得用户只需要变更配置即可完成对 MCPServer 的调优，且变更过程流量完全无损，SSE 连接也不会断开。

该功能一经推出，迅速在开源社区引起了用户广泛的关注，同时在交流群中，也有大量用户反馈了配置失败的问题，因为该功能过于原子化且配置复杂，用户很容易遇到配置失败的问题，为进一步增加用户体验，我们决定将 Higress MCP 相关的能力以场景化的方式，集成在 Higress Console 中，即 MCP 服务管理模块。

用户可以在 Higress 2.1.5 版本中正式体验该文中提及的所有特性。

Higress MCP 服务管理介绍

Higress MCP 服务管理功能概览

Higress MCP 服务管理模块提供了以下能力：

• OpenAPI 转换 MCP。根据用户提供的 OAS 3.0 文档，连接网关已有的 HTTP 后端服务，即可自动转换成 MCPServer。
• DB 转换 MCP。用户仅需将数据库实例配置为网关的后端服务，即可自动转换成 MCPServer，目前支持 MySQL、PostgreSQL、Clickhouse、Sqlite。
• MCP 直接路由。可以直接代理 SSE/Streamable 协议的后端服务。
• MCP 认证授权能力。

站在一个 Higress 开源贡献者的视角，我还是先澄清下 Higress 本身的定位，其主要还是承担 AI 网关/MCP 网关的职责，作为一个基础设施，帮助企业更好地构建自身的 MCP 市场，其提供的 MCP 特性支持，可以非常友好地跟 MCP 应用商店（如 mcp.so）、MCP 客户端市场（Cline、Cursor、Cherry Studio）、平台型市场（百炼、魔搭、Dify）等场景结合，Higress 跟这些场景并不是竞争关系。

这篇文章将向大家介绍 Higress 近期在 Wasm 插件生态方面的一个进展——Higress Wasm 插件服务器（Higress Plugin Server）。这个新的组件解决了用户在私有化部署 Higress 网关时拉取插件的痛点，优化了插件的下载与管理效率。

一、Wasm 插件：Higress 的扩展能力与挑战

Higress 自开源以来就一直将 Wasm 技术视为核心的网关扩展手段。Wasm 带来的工程可靠性、沙箱安全性、热更新能力以及 Higress 团队在此基础上构建的域名/路由级生效、Redis 访问能力、AI 特性支持等，都丰富了网关的扩展性，并为企业用户带来了性能提升和成本降低。通过自定义 Wasm 插件，用户可以根据自身的业务需求，在网关层完成鉴权、加解密、会话管理等逻辑，减少了额外资源的小号，降低了后端服务的处理负担。

尽管 Wasm 插件技术本身具备优势，但在实际的企业级部署和大规模应用场景中，我们依然面临一些实际的挑战，主要体现在以下几个方面：

1. OCI 机制带来的私有化部署挑战

当前，Higress Wasm 插件的下载和管理主要依赖 OCI（Open Container Initiative）仓库。

关于 OCI、oras 和 Docker

• OCI (Open Container Initiative)： OCI 旨在为容器镜像和运行时定义开放标准，以确保不同容器技术之间的互操作性。在云原生生态中，OCI 镜像仓库（如 Docker Hub、Harbor、registry.k8s.io 等）是分发容器镜像的标准方式。Higress 最初将 Wasm 插件作为 OCI Artifacts 发布，即将其打包成符合 OCI 规范的制品并存储在 OCI 仓库中。
• Docker： Docker 是目前最流行的容器平台，它使用 OCI 镜像作为其核心分发格式。通常，我们使用 docker pull 和 docker push 命令来拉取和推送容器镜像。
• oras (OCI Registry As Storage)： oras 是一个命令行工具，它允许用户在 OCI 仓库中存储和管理任意内容，而不仅仅是容器镜像。对于 Higress Wasm 插件这类非标准的容器镜像（Wasm 模块），oras 提供了一种方便的方式来与 OCI 仓库进行交互（例如拉取、推送 Wasm 插件）。

OCI 机制的挑战

虽然 OCI 机制在云原生环境中是标准且高效的方式，但对于一些企业，尤其是对网络安全性有严格要求的私有化部署场景来说，OCI 仓库的引入成了一个不小的门槛，并带来了以下问题：

• 技术门槛与工具使用不便： 许多用户可能习惯于应用程序的直接安装或通过简单的包管理器进行部署，而对容器镜像、OCI 标准、以及 oras 这类专门用于非镜像内容的 OCI 工具的使用并不熟悉。这增加了 Wasm 插件的上手难度和运维复杂度。
• 网络限制与私有化部署： 许多企业内部网络严格，对外部公共网络（如 Docker Hub、GitHub Container Registry等）的访问有严格限制。私有化部署环境下，更是会因为无法访问外部公开仓库而导致无法配置插件和更新插件。
• 额外的基础设施搭建： 为了在私有环境中拉取插件，用户可能需要单独部署和维护一个内部 OCI 仓库。这无疑增加了部署的复杂度和运维成本，对于仅需简单使用 Wasm 插件的用户而言，为了几个插件去搭建和管理一套完整的 OCI 生态，显得过于笨重。
• 插件迁移困难： 在不同私有化环境（如开发、测试、生产）之间迁移 Wasm 插件时，由于 OCI 仓库的独立性，往往需要用户手动进行插件的拉取、推送和版本管理，且需要适配不同仓库的认证和网络配置，这增加了操作的复杂性和出错的可能性。

2. 重复下载与性能开销：Always 策略的隐忧

Higress 网关拉取 Wasm 插件时，支持插件拉取策略的配置，默认为 IfNotPresent，即本地存在则不重新拉取。这在大多数情况下是合理的。但当用户希望 Wasm 插件能够及时更新（例如在开发测试环境中频繁迭代）或者希望确保始终使用最新版本的插件时，会倾向于将策略设置为 Always，导致以下问题：

• 网络延迟与带宽消耗： Always 策略意味着每次 Wasm 插件被引用或网关 Pod 重启时，都会尝试从 OCI 仓库重新下载插件。会引入不必要的网络延迟，并消耗带宽资源。
• 冗余操作： 即使插件内容没有变化，Always 策略也会触发下载。尽管 OCI 协议本身支持内容哈希校验，但客户端依然需要与仓库进行通信以确认。

3. 用户体验与操作复杂度：

上述问题共同导致了用户在配置和使用 Wasm 插件时，可能会面临不必要的复杂性。我们希望能够提供一种更简单、更符合直觉的插件分发方式，让用户能够更专注于业务逻辑的实现。

正是基于这些痛点，我们开发了 Higress Wasm 插件服务器。

概述

Higress 是一个基于 Istio 和 Envoy 的云原生 API 网关，具备先进的 AI 功能。通过 Go/Rust/JS 编写的 Wasm 插件提供可扩展的架构，并提供了基于 Node 和 Java 的 console 模块，使得用户可以可视化使用 Higress。

Higress 最初由阿里巴巴研发，旨在解决 Tengine 配置 reload 对长连接造成影响，以及 gRPC/Dubbo 服务负载均衡能力不足的问题，于 2022 年开源。如今，阿里云云原生 API 网关、MSE 云原生网关、专有云飞天企业版 API 网关等网关产品系列均采用了 Higress 的统一架构，它已成为阿里云 API 网关产品的基础。

本文主要面向开发者和开源爱好者，围绕 Higress 基本的架构，分享一些 Higress 的基本原理，欢迎一起共建 Higress。

Higress 产品介绍

网关产品在不同场景，不同发展阶段可能会加上很多修饰词前缀，这本质上是网关主要是一层代理，伴随着应用架构的演进，网关的身份也会发生转变。

正如单体式应用到 SOA 架构时 ESB 总线的称谓，微服务架构阶段时的微服务网关，K8s 云原生架构下的云原生网关，再到现如今 AI 时代的 AI 网关。可以发现不仅仅是 Higress 如此，传统的 API 网关产品以及国内外的 API 网关云厂商，都非常默契地将自家用户页面的入口换上了 AI 网关的皮肤。按照用户场景，Higress 可以有以下几种定位：

AI 网关

AI 网关相比传统 API 网关有了一些本质的变化：

AI 网关伴随 AI 原生架构演进，会提供各类 AI 原子能力和场景化能力，助力企业应用完成智能化升级。同时，随着越来越多 AI 的概念被提出，例如 MCP、A2A，为了解决对应的场景的问题，Higress 也提供了对应的解决方案，在这些场景下我们也可能会称呼 Higress 为 MCP 网关、Agent 网关。

作为一个 Web 开发，一定不会对下面的跨域报错陌生。

当一个资源从与该资源本身所在的服务器不同的域或端口请求一个资源时，资源会发起一个跨域 HTTP 请求。例如站点 http://www.aliyun.com 的某 HTML 页面请求 http://www.alibaba.com/image.jpg。

出于安全原因，浏览器限制从页面脚本内发起的跨域请求，有些浏览器不会限制跨域请求的发起，但是会将结果拦截。 这意味着使用这些 API 的 Web 应用只能加载同一个域下的资源，除非使用 CORS 机制（Cross-Origin Resource Sharing 跨源资源共享）获取目标服务器的授权来解决这个问题。

这也是本文将要探讨的主要问题，需要额外强调的是，跨域问题产生的主体是“浏览器”，这也是为什么，当我们使用 curl、postman、各种语言的 HTTP 客户端等工具时，从来没有被跨域问题困扰过。

Spring Cloud Gateway 是 Spring Cloud 微服务生态下的网关组件，一直以来备受 Java 社区的用户关注，很多企业选择使用其作为微服务网关或者业务网关。在阿里云上，也不乏有很多网关类型的产品供用户使用，例如 API Gateway 和 MSE Higress，使用 PaaS 化的方式提供网关能力，用户不再需要关注网关的实现，直接获得开箱即用的能力。在从前，用户只能选择自建 Spring Cloud Gateway，或者购买云产品，而今天介绍的 EDAS 增强 Spring Cloud Gateway 的新姿势，给用户提供了一个新的选择。

让 Spring Cloud Gateway 生产可用

开源 Spring Cloud Gateway 存在一些让企业级用户担忧的因素，包括内存泄漏问题，以及路由设计问题，EDAS 根据云服务总线 CSB 多年沉淀下来的 Spring Cloud Gateway 使用经验，对诸多已经存在的问题进行了治理，对诸多的风险因素也进行了规避，彻底打消用户使用 Spring Cloud Gateway 技术侧的顾虑。

• 内存泄漏问题，该问题来自于 CSB 的生产实践，Spring Cloud Gateway 底层依赖 netty 进行 IO 通信，熟悉 netty 的人应当知道其有一个读写缓冲的设计，如果通信内容较小，一般会命中 chunked buffer，而通信内容较大时，例如文件上传，则会触发内存的新分配，而 Spring Cloud Gateway 在对接 netty 时存在逻辑缺陷，会导致新分配的池化内存无法完全回收，导致堆外内存泄漏。并且这块堆外内存时 netty 使用 unsafe 自行分配的，通过常规的 JVM 工具还无法观测，非常隐蔽。

EDAS 建议为 Spring Cloud Gateway 应用增加启动参数 -Dio.netty.allocator.type=unpooled，使得请求未命中 chunked buffer 时，分配的临时内存不进行池化，规避内存泄漏问题。-Dio.netty.allocator.type=unpooled 不会导致性能下降，只有大报文才会触发该内存的分配，而网关的最佳实践应该是不允许文件上传这类需求，加上该参数是为了应对非主流场景的一个兜底行为。

• 开源 Spring Cloud Gateway 并未提供路由配置校验能力，当路由配置出错时，可能会带来灾难性的后果，例如在配置路由时，误将 POST 写成了 PEST： predicates: Method=PEST，可能会导致网关中所有路由失效，爆炸半径极大。

EDAS 建议为 Spring Cloud Gateway 应用配置 spring.cloud.gateway.fail-on-route-definition-error: false ，降低爆炸半径。通过 EDAS 创建的路由，将会经过校验，确保路由的格式正确，提前规避问题。

以上只是 EDAS 增强 Spring Cloud Gateway 方案的部分案例，EDAS 围绕性能、安全、稳定性等方面，全面为用户的网关保驾护航，让用户彻底回归到业务本身。

围绕让 Spring Cloud Gateway 生产可用这个基本话题，让用户在云上放心的使用 Spring Cloud Gateway，EDAS 推出了一个新的功能，使用无侵入式的方式增强 Spring Cloud Gateway。

前言

本文整理自云原生技术实践营广州站 Meetup 的分享，其中的经验来自于我们团队开发的阿里云 CSB 2.0 这款产品，这是一款基于开源 SpringCloud Gateway 为 code base 开发的产品，在完全兼容开源用法的前提下，做了非常多企业级的改造，涉及功能特性、稳定性、安全、性能等方面。

为什么需要微服务网关

从功能角度来看，微服务网关通常用来统一提供认证授权、限流、熔断、协议转换等功能。

从使用场景上来看

• 南北向流量，需要流量网关和微服务网关配合使用，主要是为了区分外部流量和微服务流量，将内部的微服务能力，以统一的 HTTP 接入点对外提供服务
• 东西向流量，在一些业务量比较大的系统中，可能会按照业务域隔离出一系列的微服务，在同一业务域内的微服务通信走的是服务发现机制，而跨业务域访问，则建议借助于微服务网关。

前言

继上一篇文章《Kirito 杭州买房记 | 纯小白向杭州购房攻略》过去已经有 2 年了，预计在今年 6~9 月，我的房子就要交付了，所以我也开始了全屋定制之路。现在杭州的期房大多数是精装修交付，也就是说厨房和卫生间等部分都包含在房价中，我需要操心的全屋定制部分仅包含：

柜子部分

• 卧室衣柜
• 书房书柜
• 餐边柜
• 电视柜

家具部分

• 沙发
• 茶几
• 餐桌

最近一两个月，我跑遍了附近各个全屋定制的商家，从一个装修小白，成长为了一个略懂的小白，本文记录了我这段时间的积累，可以当做一份入门攻略。

本文主要介绍打柜子的部分，家具部分捎带提一下。

本文偏小白向，如果描述有偏差，欢迎指正，适合阅读人群：从未经历过但即将需要全屋定制，未亲自参与过全屋定制，关注了 Kirito 并好奇怎么发了一个技术无关的文章的读者。

问题发现

客户端：业务应用使用 lettuce 客户端

服务端：Redis server 部署架构采用 1 主 + 1 从 + 3 哨兵

Redis 和业务应用部署在同一个 K8s 集群中，Redis Server 暴露了一个 redis-service，指向到 master 节点，业务应用通过 redis-service 连接 Redis。

某个时刻起，开始发现业务报错，稍加定位，发现是 Redis 访问出了问题，搜索业务应用日志，发现关键信息：

1

org.springframework.data.redis.RedisSystemException: Error in execution; nested exception is io.lettuce.core.RedisCommandExecutionException: READONLY You can't write against a read only replica.

这是一个 Redis 访问的报错，看起来跟 Redis 的读写配置有关。

前言

过去一年，我的工作重心投入到了 API 网关（阿里云 CSB）中，这对于我来说是一个新的领域，但和之前接触的微服务治理方向又密不可分。API 网关适配微服务场景需要完成一些基础能力的建设，其一便是对接注册中心，从而作为微服务的入口流量，例如 Zuul、SpringCloud Gateway 都实现了这样的功能。实际上很多开源网关在这一特性上均存在较大的局限性，本文暂不讨论这些局限性，而是针对服务发现这一通用的场景，分享我对它的一些思考。

背景

最近由于业务需求，我负责的一块系统需要对外开放 Open API，原本不是什么难事，因为阿里云内部的 Open API 开放机制已经非常成熟了，根本不需要我去设计，但这次的需求主要是因为一些原因，需要自己设计一些规范，那就意味着，需要对 Open API 进行一些规范约束了，遂有此文。

Open API 和前端页面一样，一直都是产品的门面， Open API 不规范，会拉低产品的专业性。在云场景下，很多用户会选择自建门户，对接云产品的 Open API，这对我们提出的诉求便是构建一套成熟的 Open API 机制。

站在业务角度，有一些指导原则，指导我们完善 Open API 机制：

• 前端页面使用的接口和 Open API 提供的接口是同一套接口
• 任意的前端页面接口都应该有对应的 Open API

站在技术角度，有很多的 API 开放标准可供我们参考，一些开源产品的 Open API 文档也都非常完善。一方面，我会取其精华，另一方面，要考虑自身产品输出形态的特殊性。本文将围绕诸多因素，尝试探讨出一份合适的 Open API 开放规范。