说点大实话丨知名技术博主 Kirito 测评云原生网关
作者:徐靖峰
关注了阿里云云原生公众号,经常能看到 MSE-Higress 相关的推文,恰逢这次阿里云产品举办了一个 MSE-Higress 云原生网关的测评活动,借此机会体验了一把云原生网关的功能。
购买流程体验
![](https://static001.geekbang.org/infoq/8e/8e7fe5e449a3f8e85fa91c2ca0acf0bc.png)
购买网关时,页面明确提示费用没有包含公网和私网 SLB 的费用,这里需要注意,评测时会产生额外费用,同时也建议 MSE-Higress 购买页给出具体的定价,参考 ACK 购买时的体验。
路由管理体验
通过购买页购买后,等了不多久实例便创建完成了,速度还是很快的,这个体验不错。第一个测评内容先体验下网关最主要的功能路由转发的能力,给 MSE-Higress 配置路由 & 服务,访问 httpbin.org 这个公网的服务,熟悉 HTTP 接口测试的同学一定也不会对 httpbin 感到陌生,它内置很多 endpoint,支持丰富的 HTTP 测试场景。
MSE-Higress 的产品设计和领域模型和我之前接触过的一些开源 API 网关差异不大,所以上手还是很快的,首先创建 httpbin 服务:
![](https://static001.geekbang.org/infoq/ec/ec3aa1ea53399ae86b8490b3d14f4700.png)
接着再创建路由,我准备通过 ${网关 ip}/httpbin/get 转发至 httpbin.org/get 的方式来进行路由测试。
![](https://static001.geekbang.org/infoq/9a/9a18118de4317f980e15fbb1be9575a8.png)
匹配方式支持前缀匹配、精确匹配、正则匹配三种,基本覆盖了网关路由场景的常见诉求。另外还需要注意的一点是,路由路径一定要配置成 /httpbin/ 而不能是 /httpbin,否则在待会配置路径重写时,会出现问题,我一开始也是因为不了解 MSE-Higress 的设计,错配成了 /httpbin,导致路由不通。
参考文档:《配置重写策略》 [ 1]
下一步,关联好刚刚创建的服务。
![](https://static001.geekbang.org/infoq/9f/9f69a84acf69936c59e465c577434237.png)
最后在路由的策略配置中,配置重写策略,使得网关在请求 upstream service 时,去掉用于路由匹配的 /httpbin 前缀。
![](https://static001.geekbang.org/infoq/d4/d4c84f6d94b678c94823d1a7e7884bc1.png)
MSE-Higress 提供了一个调试的界面,可以很方便地对路由进行调试,就在我信心满满准备完成第一个测试时,竟然调试报错了:
![](https://static001.geekbang.org/infoq/a4/a4392708e4ab3d68239380fcda56d580.png)
步骤并不复杂,稍微花了点时间搜索了一下注意事项,定位到了问题,原来配置服务时是有提示的:"DNS 域名配置,如 www.aliyun.com,公网域名需要在 VPC 内配置公网 NAT 网关,内网域名暂不支持",于是给 MSE-Higress 所在的 VPC 配置了 NAT 网关,最终调用成功。
期间还有一个小插曲,反复保存服务,会触发一个前端的 bug,保存按钮一直在转圈,测评期间稳定复现:
![](https://static001.geekbang.org/infoq/70/707bf3e7a3030eb3581d0a656b33ebb9.png)
路由策略-限流功能体验
刚刚在测评路由功能时,已经使用到了 MSE-Higress 的一个策略:重写策略,MSE-Higress 共支持 6 种路由策略,分别是:限流、重写、Header 设置、跨域、超时、重试,第二个测评我计划给到另外一个网关场景中常用的功能 -- 限流。
创建限流策略时发现界面有组件嵌入的痕迹,跟其他策略的配置交互体验有一定差异,盲猜是不是前端嵌入了什么已有的界面。产品支持按照 QPS 进行限流,为了方便测评,设置为 1,更容易触发限流。
![](https://static001.geekbang.org/infoq/05/053f0ff0eec12980b3790dd2b97ae604.png)
通过行为管理,可以跳转到应用高可用服务 AHAS 的管理界面,看起来是内部集成了应用高可用服务 AHAS,复用了它的限流能力,专业的事情交给专业的产品来做。
![](https://static001.geekbang.org/infoq/f3/f3743200ca89c4c13446502e67d5b35d.png)
通过一个 shell 脚本进行限流测试:
验证限流成功。
问题记录:限流监控的页面不太稳定,间断出现控制台请求报错,需要优化。
![](https://static001.geekbang.org/infoq/6f/6f300703752e52c6952deefcb9bf2799.png)
EDAS 微服务集成体验
MSE-Higress 对微服务能力的集成是其亮点之一,除 HTTP 协议族外,还支持 Dubbo 和 gRPC 协议。EDAS 常用于进行微服务应用的托管,MSE-Higress 也对 EDAS 进行了适配,这个测评 case 的内容便是,在 EDAS 中部署一个同时集成了 SpringCloud Alibaba (用于测试 HTTP 协议)和 Dubbo (用于测试 Dubbo 协议)的微服务应用,使用 MSE-Higress 对该应用进行接口代理。
EDAS 应用部署
准备一个 Dubbo 服务:
准备一个 RestController:
配置应用信息并连接 EDAS 注册中心:
部署到 EDAS 中,在 EDAS 应用管理的服务列表菜单,确认该应用启动完毕。
![](https://static001.geekbang.org/infoq/0b/0bd306908dc282fe9dbc35b24a7f60f5.png)
MSE-Higress 创建来源
MSE-Higress 为了更好地支持微服务的服务发现,抽象出了“来源”这一领域模型,对应微服务架构中的注册中心。
![](https://static001.geekbang.org/infoq/bb/bb9bedf7f080c8130dfe73ea24757c1e.png)
MSE-Higress 的来源支持容器服务、MSE Nacos、MSE Zookeeper、EDAS 注册中心、SAE 注册中心这几种类型,选择 EDAS 注册中心,便能关联到 sc-dubbo-mixed-app 应用部署的微服务空间。
MSE-Higress 创建服务
![](https://static001.geekbang.org/infoq/7c/7c6e94364be63c8b7f1d56335483232f.png)
MSE-Higress 的管控可以直接访问 EDAS 注册中心,获取到了 sc-dubbo-mixed-app 和 providers:moe.cnkirito.sca.provider.IHelloService:1.0.0:default 这两个服务。
![](https://static001.geekbang.org/infoq/c6/c63b6bae78ab8cf96eabb30fe075457d.png)
检查服务的协议,正确识别到是 Dubbo 协议。
![](https://static001.geekbang.org/infoq/f4/f4e42745ed905544d0294ed6291235f3.png)
这里不免让我产生了一些疑问,在导入服务时,MSE-Higress 并没有机会让我指定服务的协议类型,在协议详情中却正确识别到了服务的协议,猜测是判断了服务的命名格式,因为 Dubbo 类型服务注册到 Nacos 中格式形如 providers:xx:xx:xx,产品上采用了约定大于配置的设计。
MSE-Higress 创建路由
SpringCloud 服务提供的是标准的 HTTP 协议,上面的路由管理测评已经覆盖,不再次测评,重点看下 HTTP2Dubbo 是如何配置路由的。这部分内容没有办法望交互生义,还是得对着文档一步步来:《配置从 HTTP 到 Dubbo 协议转换》 [ 2]
配置如下:
![](https://static001.geekbang.org/infoq/28/282a59c5cb489f25bd15bb8b7e864dc3.png)
MSE-Higress 路由调试
测试 Dubbo 路由:
![](https://static001.geekbang.org/infoq/2e/2e9dd1711942b9651cee415671213e00.png)
测试 SpringCloud 路由:
![](https://static001.geekbang.org/infoq/a5/a5e939dc48708810991da6347c9c43cb.png)
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 服务的三元组进行填充。
![](https://static001.geekbang.org/infoq/71/71b654b7dd5cde5d465cdbf31da5a3ab.png)
另外,方法映射的设计让我产生了一些疑惑,不清楚是技术原因导致,还是产品设计有意为之,因为在我的认知中,方法级别可以在请求中动态指定,试想一个应用有 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 注册中心类型支持优化
![](https://static001.geekbang.org/infoq/82/82739259a07da7d84a24cc871f658d44.png)
EDAS 微服务空间背后有两种形态,一种是共享型注册中心的形态,另一种是绑定 MSE Nacos 实例的形态,上述演示时,主要测试了第一种形态,对于第二种形态,MSE-Higress 的支持有些兼容性问题,具体表现为: EDAS 微服务空间绑定的 MSE Nacos 位于 vpc-a 中,MSE-Higress 位于 vpc-b 中,创建来源能够成功,但导入服务时,页面报错:
![](https://static001.geekbang.org/infoq/00/00914229cdbfc1a254c1020acc99332c.png)
这背后应该是在支持 EDAS 注册中心时,未考虑其绑定的 MSE Nacos 位于其他 vpc 导致。建议在导入来源时对该 case 进行判断。
插件市场体验
插件体系功能较多,个人精力有限,我只挑选了个别插件进行了使用,表现均符合预期。我挑选了 APISIX 的插件支持情况与 MSE 进行了对比,由于 APISIX 是一款开源产品,我有意筛选的都是一些相对通用的能力,这样才具备比较价值。
![](https://static001.geekbang.org/infoq/9a/9a5600441b7b6c355a1ef558b9b6d185.png)
除了表格展示的插件之外,两款网关产品还支持很多其他插件,可以发现基本上常见的网关场景所需要的插件,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 服务引入版本:
Dubbo 服务引入版本:
在 EDAS 上部署以上版本,并扩容成 2 个副本,此时两个副本内容一致。
EDAS 分批部署 V2 版本
SpringCloud 服务新版本:
Dubbo 服务新版本:
在 EDAS 进行分批发布:
![](https://static001.geekbang.org/infoq/e7/e7782c552885719ceb517e0578d5fe31.png)
这里解释下,为什么不使用 EDAS 的金丝雀发布,因为 EDAS 金丝雀发布主要是用于微服务之间的调用,而不是入口流量,而此次测评的恰恰是 MSE-Higress 对 EDAS 应用进行的调用,在这个 case 中,EDAS 需要做的是分批发布,保证后端同时有 v1 和 v2 两个版本即可。
这样就完成了金丝雀发布的准备工作,同时存在了 v1 和 v2 两个版本的应用,剩下的就是对 MSE-Higress 进行配置,让其按照特定比例对这两个版本进行引流(试想一下,如果没有金丝雀发布,由于 v1 和 v2 都是一台机器,那流量比例应该是 1:1)。
MSE-Higress 配置服务版本和标签路由
在服务详情中,可以添加服务版本,这里 MSE-Higress 的体验做的很好,由于关联了注册中心,可以自动获取到对应的标签名和标签值,能够实时计算出对应的节点数量,不用担心配错了。
![](https://static001.geekbang.org/infoq/92/92d7450e4ee60085a6c7cf523a5940e6.png)
需要修改路由关联服务的方式,从单服务改成标签路由,并配置 v1 和 v2 版本流量比例为 80:20。
![](https://static001.geekbang.org/infoq/dd/dd0125f928de40ebc7805a076b6914c9.png)
走到这一步,我发现标签路由怎么都选不到 Dubbo 服务,才注意到上方有提示“多服务和标签路由功能不支持添加 Dubbo 服务”!也就是说我之前的 Dubbo 服务打标签的准备工作都白费了,但我还是将测评过程记录了下来。
流量比例测试
通过调试 /sc-dubbo-mixed-app/echo 10 次,观察返回值:
符合预期。
测试总结
通过上述的例子,可以发现 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-policy
[2] 《配置从 HTTP 到 Dubbo 协议转换》
https://help.aliyun.com/zh/mse/user-guide/configure-http-to-dubbo-protocol-conversion**
[3] 《基于云原生网关实现 gRPC 服务的路由转发》
[4] 《管理服务版本》
https://help.aliyun.com/zh/mse/user-guide/manage-service-versions
[5] 《从 Spring Cloud Gateway 迁移到云原生网关》
版权声明: 本文为 InfoQ 作者【阿里巴巴云原生】的原创文章。
原文链接:【http://xie.infoq.cn/article/907b34ba6bc26ffa9d925abe0】。文章转载请联系作者。
评论