共计 10098 个字符，预计需要花费 26 分钟才能阅读完成。
作者：徐靖峰
关注了阿里云云原生公众号，常常能看到 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<String> name);
String sayHello(List<String> name, Integer age);
String sayHello(List<People> name, String first);
String sayHello(People name);
String sayHello(Map<String, Integer> 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]《配置重写策略》
https://help.aliyun.com/zh/mse/user-guide/configure-a-rewrite…
[2]《配置从 HTTP 到 Dubbo 协定转换》
https://help.aliyun.com/zh/mse/user-guide/configure-http-to-d…**
[3]《基于云原生网关实现 gRPC 服务的路由转发》
https://help.aliyun.com/zh/mse/getting-started/route-the-traf…
[4]《治理服务版本》
https://help.aliyun.com/zh/mse/user-guide/manage-service-vers…
[5]《从 Spring Cloud Gateway 迁徙到云原生网关》
https://help.aliyun.com/zh/mse/user-guide/migrate-services-fr…