说点大实话丨知名技术博主 Kirito 测评云原生网关

作者：徐靖峰

关注了阿里云云原生公众号，经常能看到 MSE-Higress 相关的推文，恰逢这次阿里云产品举办了一个 MSE-Higress 云原生网关的测评活动，借此机会体验了一把云原生网关的功能。

购买流程体验

购买网关时，页面明确提示费用没有包含公网和私网 SLB 的费用，这里需要注意，评测时会产生额外费用，同时也建议 MSE-Higress 购买页给出具体的定价，参考 ACK 购买时的体验。

路由管理体验

通过购买页购买后，等了不多久实例便创建完成了，速度还是很快的，这个体验不错。第一个测评内容先体验下网关最主要的功能路由转发的能力，给 MSE-Higress 配置路由 & 服务，访问 httpbin.org 这个公网的服务，熟悉 HTTP 接口测试的同学一定也不会对 httpbin 感到陌生，它内置很多 endpoint，支持丰富的 HTTP 测试场景。

MSE-Higress 的产品设计和领域模型和我之前接触过的一些开源 API 网关差异不大，所以上手还是很快的，首先创建 httpbin 服务：

接着再创建路由，我准备通过 ${网关ip}/httpbin/get 转发至 httpbin.org/get 的方式来进行路由测试。

匹配方式支持前缀匹配、精确匹配、正则匹配三种，基本覆盖了网关路由场景的常见诉求。另外还需要注意的一点是，路由路径一定要配置成 /httpbin/ 而不能是 /httpbin，否则在待会配置路径重写时，会出现问题，我一开始也是因为不了解 MSE-Higress 的设计，错配成了 /httpbin，导致路由不通。

参考文档：《配置重写策略》 [ 1]

下一步，关联好刚刚创建的服务。

最后在路由的策略配置中，配置重写策略，使得网关在请求 upstream service 时，去掉用于路由匹配的 /httpbin 前缀。

MSE-Higress 提供了一个调试的界面，可以很方便地对路由进行调试，就在我信心满满准备完成第一个测试时，竟然调试报错了：

步骤并不复杂，稍微花了点时间搜索了一下注意事项，定位到了问题，原来配置服务时是有提示的："DNS 域名配置，如 www.aliyun.com，公网域名需要在 VPC 内配置公网 NAT 网关，内网域名暂不支持"，于是给 MSE-Higress 所在的 VPC 配置了 NAT 网关，最终调用成功。

➜ ~ curl 101.xx.166.xx/httpbin/get
{
 "args": {},
 "headers": {
  "Accept": "*/*",
  "Host": "101.xx.166.xx",
  "Original-Host": "101.xx.166.xx",
  "Req-Start-Time": "1691746441214",
  "User-Agent": "curl/7.64.1",
  "X-Amzn-Trace-Id": "Root=1-64d60089-5f09b9560522afd56f11b4e0",
  "X-Envoy-Attempt-Count": "1",
  "X-Envoy-External-Address": "140.xx.11.xx",
  "X-Envoy-Original-Path": "/httpbin/get"
 },
 "origin": "140.xx.11.xx, 121.xx.116.xx",
 "url": "http://101.xx.166.xx/get"
}

期间还有一个小插曲，反复保存服务，会触发一个前端的 bug，保存按钮一直在转圈，测评期间稳定复现：

路由策略-限流功能体验

刚刚在测评路由功能时，已经使用到了 MSE-Higress 的一个策略：重写策略，MSE-Higress 共支持 6 种路由策略，分别是：限流、重写、Header 设置、跨域、超时、重试，第二个测评我计划给到另外一个网关场景中常用的功能 -- 限流。

创建限流策略时发现界面有组件嵌入的痕迹，跟其他策略的配置交互体验有一定差异，盲猜是不是前端嵌入了什么已有的界面。产品支持按照 QPS 进行限流，为了方便测评，设置为 1，更容易触发限流。

通过行为管理，可以跳转到应用高可用服务 AHAS 的管理界面，看起来是内部集成了应用高可用服务 AHAS，复用了它的限流能力，专业的事情交给专业的产品来做。

通过一个 shell 脚本进行限流测试：

#!/bin/bash
for i in {1..5}
do
curl 101.xx.166.xx/httpbin/get &
done
wait

验证限流成功。

sentinel rate limited
{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Host": "101.xx.166.xx",
    "Original-Host": "101.xx.166.xx",
    "Req-Start-Time": "1691747565429",
    "User-Agent": "curl/7.64.1",
    "X-Amzn-Trace-Id": "Root=1-64d604ed-6dc526617e735d4f0f083e86",
    "X-Envoy-Attempt-Count": "1",
    "X-Envoy-External-Address": "140.xx.11.xx",
    "X-Envoy-Original-Path": "/httpbin/get"
  },
  "origin": "140.xx.11.xx, 121.xx.116.163",
  "url": "http://101.xx.166.xx/get"
}
sentinel rate limited
sentinel rate limited
sentinel rate limited

问题记录：限流监控的页面不太稳定，间断出现控制台请求报错，需要优化。

EDAS 微服务集成体验

MSE-Higress 对微服务能力的集成是其亮点之一，除 HTTP 协议族外，还支持 Dubbo 和 gRPC 协议。EDAS 常用于进行微服务应用的托管，MSE-Higress 也对 EDAS 进行了适配，这个测评 case 的内容便是，在 EDAS 中部署一个同时集成了 SpringCloud Alibaba （用于测试 HTTP 协议）和 Dubbo （用于测试 Dubbo 协议）的微服务应用，使用 MSE-Higress 对该应用进行接口代理。

EDAS 应用部署

准备一个 Dubbo 服务：

package moe.cnkirito.sca.provider;

import java.util.List;
import java.util.Map;

public interface IHelloService {

    String sayHello(String str);

    String sayHello();

    String sayHello(List name);

    String sayHello(List name, Integer age);

    String sayHello(List name, String first);

    String sayHello(People name);

    String sayHello(Map map);

    String sayHello(Integer age);

}

准备一个 RestController：

@RestController
public class DemoController {

  @Autowired
  DemoService demoService;

  @RequestMapping(value = "/echo", method = RequestMethod.GET)
  public String echo() {
    return "Hello MSE-Higress";
  }

}

配置应用信息并连接 EDAS 注册中心：

spring:
 application:
  name: sc-dubbo-mixed-app
 cloud:
  nacos:
   discovery:
    server-addr: edas-registry:8848 # EDAS会自行替换该连接串

dubbo:
 application:
  id: sc-dubbo-mixed-app
  name: sc-dubbo-mixed-app
 protocol:
  id: dubbo
  port: 20880
 registry:
  id: nacos
  address: nacos://edas-registry:8848 # EDAS会自行替换该连接串

部署到 EDAS 中，在 EDAS 应用管理的服务列表菜单，确认该应用启动完毕。

MSE-Higress 创建来源

MSE-Higress 为了更好地支持微服务的服务发现，抽象出了“来源”这一领域模型，对应微服务架构中的注册中心。

MSE-Higress 的来源支持容器服务、MSE Nacos、MSE Zookeeper、EDAS 注册中心、SAE 注册中心这几种类型，选择 EDAS 注册中心，便能关联到 sc-dubbo-mixed-app 应用部署的微服务空间。

MSE-Higress 创建服务

MSE-Higress 的管控可以直接访问 EDAS 注册中心，获取到了 sc-dubbo-mixed-app 和 providers:moe.cnkirito.sca.provider.IHelloService:1.0.0:default 这两个服务。

检查服务的协议，正确识别到是 Dubbo 协议。

这里不免让我产生了一些疑问，在导入服务时，MSE-Higress 并没有机会让我指定服务的协议类型，在协议详情中却正确识别到了服务的协议，猜测是判断了服务的命名格式，因为 Dubbo 类型服务注册到 Nacos 中格式形如 providers:xx:xx:xx，产品上采用了约定大于配置的设计。

MSE-Higress 创建路由

SpringCloud 服务提供的是标准的 HTTP 协议，上面的路由管理测评已经覆盖，不再次测评，重点看下 HTTP2Dubbo 是如何配置路由的。这部分内容没有办法望交互生义，还是得对着文档一步步来：《配置从HTTP到Dubbo协议转换》 [ 2]

配置如下：

MSE-Higress 路由调试

测试 Dubbo 路由：

测试 SpringCloud 路由：

EDAS 微服务集成总结

该测评介绍了由 EDAS 托管的 SpringCloud 和 Dubbo 应用，可以很方便地被 MSE-Higress 集成，由 MSE-Higress 充当网关代理，将微服务暴露到集群外被访问，虽然这次测评没有涉及，但理论上还可以借助于 MSE-Higress 提供的限流、鉴权、安全防护，来为微服务体系保驾护航，有一定的想象空间。

同时记录下该测评进行时，个人觉得可以优化的地方。

改进建议1：服务模型的优化

上文有所提及，服务在 MSE-Higress 中的存在感很弱，在我看来服务应该和路由一样，具备很强的定制属性，包括：

• 协议类型
• 服务发现层的唯一标识
• 通信层的唯一标识
• 负载均衡方式
• 健康检查配置

目前，MSE-Higress 创建服务时，仅支持指定“服务发现层的唯一标识”，其他属性不支持在创建时指定，协议类型和负载均衡方式允许在服务详情页中进行修改，健康检查允许在服务列表页进行修改。

对于“通信层的唯一标识”稍作解释，以 Dubbo 为例，providers:moe.cnkirito.sca.provider.IHelloService:1.0.0:default 是其在 Nacos namespace 中的唯一定位符，用于服务发现，而服务名 moe.cnkirito.sca.provider.IHelloService，版本 1.0.0，分组 default 则是其在通信层的唯一标识，也应当是服务的属性，但是在 MSE-Higress 中，则是服务绑定路由时的配置，有点归属于路由模型的感觉，这点设计欠妥。

改进建议2：Dubbo 协议转换的优化

上述的测评过程中，介绍了一个 Dubbo 协议转换的配置过程，既然已经识别到了是 Dubbo 服务的格式，可以自动解析出 Dubbo 服务的三元组进行填充。

另外，方法映射的设计让我产生了一些疑惑，不清楚是技术原因导致，还是产品设计有意为之，因为在我的认知中，方法级别可以在请求中动态指定，试想一个应用有 n 个服务，一个服务有 m 个接口，完全暴露需要配置 n x m 次。从技术侧考虑，Dubbo 提供的泛化调用可以支持动态指定方法，无需配置参数列表类型。保持这个设计，能够想到的好处是可以允许部分接口暴露，这又回到了那个永恒的话题：安全和易用性的 trade off。

再参考 MSE-Higress 对 gRPC 协议转换的支持，则是另外一个形态：，请求路径为：{包名}.{服务名}/{方法名}，而 gRPC 本身则没有在 MSE-Higress 中以一个服务类型体现在产品设计中。MSE-Higress 有能力支持 Dubbo 和 gRPC 类型的协议转换，但是在产品设计上，还有统一优化的空间。

MSE-Higress 对于 gRPC 的支持可以参考：《基于云原生网关实现gRPC服务的路由转发》 [ 3]

改进建议3：EDAS 注册中心类型支持优化

EDAS 微服务空间背后有两种形态，一种是共享型注册中心的形态，另一种是绑定 MSE Nacos 实例的形态，上述演示时，主要测试了第一种形态，对于第二种形态，MSE-Higress 的支持有些兼容性问题，具体表现为: EDAS 微服务空间绑定的 MSE Nacos 位于 vpc-a 中，MSE-Higress 位于 vpc-b 中，创建来源能够成功，但导入服务时，页面报错：

这背后应该是在支持 EDAS 注册中心时，未考虑其绑定的 MSE Nacos 位于其他 vpc 导致。建议在导入来源时对该 case 进行判断。

插件市场体验

插件体系功能较多，个人精力有限，我只挑选了个别插件进行了使用，表现均符合预期。我挑选了 APISIX 的插件支持情况与 MSE 进行了对比，由于 APISIX 是一款开源产品，我有意筛选的都是一些相对通用的能力，这样才具备比较价值。

除了表格展示的插件之外，两款网关产品还支持很多其他插件，可以发现基本上常见的网关场景所需要的插件，MSE-Higress 都是支持的。与 APISIX 的设计不同，MSE-Higress 并没有将所有功能都堆到插件这一概念上，例如 Mock 和重定向由路由配置控制，跨域和限流通过路由策略控制，也有相当多的功能通过插件提供，在这一点上，我比较认可 MSE-Higress 的设计，这样可以减少网关使用者的理解成本。

但同时，在策略配置灵活度上，MSE-Higress 的设计仍有优化空间，以限流为例，由于其被抽象到了路由策略这一模型中，而该模型没有支持配置到消费者级别，这就让 MSE-Higress 失去了消费者级别限流的能力。

在商业化集成上，由于 MSE-Higress 是阿里云官方提供的一款网关产品，还额外提供了诸如：waf 安全防护、edas 鉴权插件、IDaaS 认证鉴权等集成，在公共云组装式开发的模式下，可以更好地跟已有的云产品联动，这是相比开源网关提供的插件能力最大的优势。

EDAS x MSE-Higress 金丝雀发布体验

MSE-Higress 在配置路由时，允许关联到多个服务，借助于这个特性，可以完成很多灰度的实践，这个测评将验证 MSE-Higress 和 EDAS 配合完成金丝雀发布的场景。

金丝雀的意义是先引流一小部分流量到新版本服务，大部分流量仍然保持在旧版本。

仍然使用之前的 sc-dubbo-mixed-app 应用，但需要稍作改造，为 SpringCloud 和 Dubbo 服务引入版本的概念，参考《管理服务版本》 [ 4] 一节，可知在 Nacos 服务发现场景下，MSE-Higress 是通过节点标签来进行路由的，以下是我的改造。

EDAS 部署 V1 版本

SpringCloud 服务引入版本：

spring:
 application:
  name: sc-dubbo-mixed-app
 cloud:
  nacos:
   discovery:
    server-addr: edas-registry:8848 # EDAS会自行替换该连接串  
    metadata: 
     x-version: v1

@RestController
public class DemoController {
  @Autowired
  DemoService demoService;

  @RequestMapping(value = "/echo", method = RequestMethod.GET)
  public String echo() {
    return "Hello MSE-Higress V1";
  }
}

Dubbo 服务引入版本：

@DubboService(group = "default", version = "1.0.0",parameters = {"x-version:v1"})
public class IHelloServiceImpl implements IHelloService {
  @Override
  public String sayHello() {
    return "Hello MSE-Higress V1";
  }
}

在 EDAS 上部署以上版本，并扩容成 2 个副本，此时两个副本内容一致。

EDAS 分批部署 V2 版本

SpringCloud 服务新版本：

@DubboService(group = "default", version = "1.0.0",parameters = {"x-version:v1"})
public class IHelloServiceImpl implements IHelloService {
  @Override
  public String sayHello() {
    return "Hello MSE-Higress V1";
  }
}

@RestController
public class DemoController {

  @Autowired
  DemoService demoService;

  @RequestMapping(value = "/echo", method = RequestMethod.GET)
  public String echo() {
    return "Hello MSE-Higress V2";
  }
}

Dubbo 服务新版本：

@DubboService(group = "default", version = "1.0.0",parameters = {"x-version:v2"})
public class IHelloServiceImpl implements IHelloService {

  @Override
  public String sayHello() {
    return "Hello MSE-Higress V2";
  }
  
}

在 EDAS 进行分批发布：

这里解释下，为什么不使用 EDAS 的金丝雀发布，因为 EDAS 金丝雀发布主要是用于微服务之间的调用，而不是入口流量，而此次测评的恰恰是 MSE-Higress 对 EDAS 应用进行的调用，在这个 case 中，EDAS 需要做的是分批发布，保证后端同时有 v1 和 v2 两个版本即可。

这样就完成了金丝雀发布的准备工作，同时存在了 v1 和 v2 两个版本的应用，剩下的就是对 MSE-Higress 进行配置，让其按照特定比例对这两个版本进行引流（试想一下，如果没有金丝雀发布，由于 v1 和 v2 都是一台机器，那流量比例应该是 1:1）。

MSE-Higress 配置服务版本和标签路由

在服务详情中，可以添加服务版本，这里 MSE-Higress 的体验做的很好，由于关联了注册中心，可以自动获取到对应的标签名和标签值，能够实时计算出对应的节点数量，不用担心配错了。

需要修改路由关联服务的方式，从单服务改成标签路由，并配置 v1 和 v2 版本流量比例为 80:20。

走到这一步，我发现标签路由怎么都选不到 Dubbo 服务，才注意到上方有提示“多服务和标签路由功能不支持添加Dubbo服务”！也就是说我之前的 Dubbo 服务打标签的准备工作都白费了，但我还是将测评过程记录了下来。

流量比例测试

通过调试 /sc-dubbo-mixed-app/echo 10 次，观察返回值：

Hello MSE-Higress

Hello MSE-Higress

Hello MSE-Higress

Hello MSE-Higress V2

Hello MSE-Higress

Hello MSE-Higress

Hello MSE-Higress

Hello MSE-Higress V2

Hello MSE-Higress

Hello MSE-Higress

符合预期。

测试总结

通过上述的例子，可以发现 MSE-Higress 和 EDAS 应用在 Nacos 服务发现场景下实现金丝雀发布还是很简单的，但从中也看出了一些问题，就是产品仅告诉了用户怎么达到金丝雀发布的验证态，没有走完最后一公里，即金丝雀发布验证到什么阶段可以认为发布完毕了，发布完之后，怎么完成 EDAS 的分批发布，怎么修改标签路由，达到一个运行终态。并且，这个流程配置还是很复杂的，要结合到用户的运维系统中，有一定集成工作，至少应该在 EDAS 这样的系统中提供一个基于 MSE-Higress 金丝雀发布入口应用的最佳实践。

体验总结

大概浏览了下 MSE-Ingress 的其他功能，精力有限加上篇幅限制，没法一一罗列，简单总结下。

MSE-Higress 除了文章开头的购买流程外，还支持作为一个 ACK 集群的 Ingress 网关，这得益于其云原生的基因，并且可以对标到 Nginx Ingress，这对于愿意拥抱云原生生态的公司是一个福音，我这次就不单独评测这一功能了。

文档支持上，我本次的测评完全是参考控制台文案及文档完成，可以看的出来，文档体系相对比较完善，一些常见的疑问，也都在文档中高亮了，点赞。需要注意的是一些新功能上线之后，需要对已有的相关文档进行更新，以《从 Spring Cloud Gateway 迁移到云原生网关》 [ 5]  为例，目前已经支持了 EDAS 共享注册中心来源了，对于文档中使用 EDAS 共享注册中心这一 case 而言，就不需要先迁移了，可能会让 SpringCloud Gateway 迁移用户产生误解。

MSE-Higress 可以很好地承担安全网关和流量网关的作用，但对于是否能够很好的承担起微服务网关/业务网关的作用，我觉得有待讨论。因为业务网关很直接的诉求是将企业内部的大量 API 通过网关暴露出来，MSE-Higress 的领域模型是路由/服务这套模型，这就限制于了其对于业务能力的抽象，路由大多数时候还是一个泛接口的作用，往往用于承接一个后端应用模型。从用户形态来看，可能是偏运维侧的用户会关注目前的 MSE-Higress 形态，而不是开发。

如果深入使用 MSE-Higress，可能会有精细化管理 API 接口的诉求，目前 MSE-Higress 的产品设计似乎不能很好地满足这一诉求，具体表现为 MSE-Higress 的路由模型和 API 精细化管理的需求之间的矛盾。MSE-Higress 的路由模型如果配置为泛路由 /order/* 的前缀匹配模式，则会将应用的所有接口暴露出去；如果配置为 /order/createOrder 的精确匹配模式，可以达到精细化管理的诉求，但接口级别常见的需求 API 出入参定义、参数映射、错误码管理，跟路由的模型无法很好的适配。这可能是大多数研发用户使用 MSE-Higress 未来可能面临的问题。

整体而言，我还是很看好 MSE-Higress 这款产品的。 产品界面交互还时髦，大多数操作流程很流畅；产品集成上，从它跟 WAF、EDAS、ACK 等产品的集成来看，可以看出阿里云对它的定位不仅仅是一个网关组件，而是希望能够借助它完成一个产品生态的构建，云原生公众号上 Serverless 挺火的，MSE-Higress 还不支持 Serverless 服务，这点倒是有点意外。同时它还具备 Higress 的开源属性，也解决了一部分选型时被阿里云绑死的顾虑。

参与云原生网关 MSE-Higress 测评赢大奖

2023 年 8 月 10 日-2023 年 9 月 15 日，通过体验 MSE-Higress，围绕三大主题，进行测评创作，有机会赢取 30 元猫超卡、米家台灯 Lite、CHERRY 机械键盘 MX3.0S 等大奖。

评测活动详情：阿里云产品测评赢大奖丨云原生网关 MSE-Higress

相关链接：

[1] 《配置重写策略》

help.aliyun.com/zh/mse/user…

[2] 《配置从HTTP到Dubbo协议转换》

help.aliyun.com/zh/mse/user…**

[3] 《基于云原生网关实现 gRPC 服务的路由转发》

help.aliyun.com/zh/mse/gett…

[4] 《管理服务版本》

help.aliyun.com/zh/mse/user…

[5] 《从 Spring Cloud Gateway 迁移到云原生网关》

help.aliyun.com/zh/mse/user…