开发者社区> 阿里云微服务引擎MSE> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

APISIX+Dubbo+Nacos最佳实践

简介: 微服务引擎MSE面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持Nacos/ZooKeeper/Eureka)、云原生网关(原生支持Ingress/Envoy)、微服务治理(原生支持Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。
+关注继续查看

项目简介


Apache APISIX

image.png

Apache APISIX 是 Apache 软件基金会下的云原生 API 网关,它具有多平台支持、精细化路由、运维友好和插件支持的优点特点。

1、多平台支持:APISIX 提供了多平台解决方案,它不但支持裸机运行,也支持在 Kubernetes 中使用,还支持与 AWS Lambda、Azure Function、Lua 函数和 Apache OpenWhisk 等云服务集成。

2、精细化路由:APISIX 支持使用 NGINX 内置变量做为路由的匹配条件,用户可以自定义匹配函数来过滤请求,匹配路由。

3、运维友好:

  • 全动态能力:APISIX 支持热加载,这意味着用户不需要重启服务就可以更新 APISIX 的配置。请访问为什么 [Apache APISIX 选择 Nginx + Lua 这个技术栈](https://apisix.apache.org/zh/blog/2021/08/25/why-apache-apisix-chose-nginx-and-lua/)?以了解实现原理。
  • 生态友好:APISIX 支持与以下工具和平台集成:HashiCorp Vault、Zipkin、Apache SkyWalking、Consul、Nacos、Eureka。通过 APISIX Dashboard,运维人员可以通过友好且直观的 UI 配置 APISIX。

4、多语言插件支持:APISIX 支持多种开发语言进行插件开发,开发人员可以选择擅长语言的 SDK 开发自定义插件。

APISIX 于 2022年1月 适配Nacos作为其注册中心用于发现后端服务,几乎同时APISIX支持Dubbo协议代理,即支持HTTP协议转Dubbo协议,以实现对Dubbo服务的直接调用。


Apache Dubbo

image.png

Apache Dubbo 是一款 RPC 服务开发框架,用于解决微服务架构下的服务治理与通信问题,官方提供了 Java、Golang 等多语言 SDK 实现。比如Dubbo-go社区就是最新比较活跃的一个新社区。

Dubbo具备了开箱即用、大规模部署、高度可扩展的优点,同时也具有一定的微服务治理的能力。

1、开箱即用:

  • 易用性高,如 Java 版本的面向接口代理特性能实现本地透明调用。
  • 功能丰富,基于原生库或轻量扩展即可实现绝大多数的微服务治理能力。

2、面向超大规模微服务集群设计:极致性能,高性能的 RPC 通信协议设计与实现,横向可扩展,轻松支持百万规模集群实例的地址发现与流量治理。

3、高度可扩展:

  • 调用过程中对流量及协议的拦截扩展,如 Filter、Router、LB 等。
  • 微服务治理组件扩展,如 Registry、Config Center、Metadata Center 等。

4、微服务治理:Dubbo有一些默认的路由等能力,同时也提供了dubbo-admin这样的微服务治理控制台,提供给用户简单的微服务治理功能。

Dubbo 早期版本就将Nacos作为注册配置中心使用,两者紧密结合使用已成为用户的共识。


Alibaba Nacos

image.png

Alibaba Nacos 是Dynamic **Na**ming and **Co**nfiguration **S**ervice的首字母缩写,目标是构建一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台,具有 简单易用,特性丰富,超高性能,超大容量,高可用的优势,Nacos 生态支持所有主流编程语言、RPC框架和网关,包括Dubbo和APISIX。

Nacos从2018年开源以来经历了3个大的版本,从0.X的初露端倪,到1.X的生产可用;而随着Nacos开源社区的发展已经用户的增多,和用户规模的逐渐增大,社区发现Nacos1.0基于HTTP的架构开始暴露一些性能问题,于是新增了gRPC作为更高效的通信方式,同时对内核架构做了大量重构和更新,将性能和扩展性提升了10倍。同时Nacos2.0也在积极进行插件化改造,让Nacos的架构更加易于拓展和更新,变得更加易用和更加能够适应不同用户的不同需求。我们首先推荐大家使用2.X版本来进行使用。

image.png

Nacos 2.X 架构层次如上图,它相比Nacos1.X的最主要变化是:

1、客户端和服务端之间绿色部分的通信层和连接层,增加了gRPC长链接协议,同时也将会补充客户端和服务端之间的流量控制和负载均衡。

2、将增加一些可拓展的接口,实现一些插件,比如将来会实现的的配置加解密,多数据源支持;还有将目前的鉴权抽象成插件实现;还有现在的MCP和XDS协议的支持。


image.png

关于Nacos的生态环境,能支持目前绝大多数开源微服务生态产品;比如RPC框架,即支持阿里自身的Dubbo,sofastack, 也支持像头条的kitex,社区火爆的grpc等;在网关方面,有spring cloud体系的SC gateway, zuul,也有阿里自身的tegine,还有mesh火爆的envoy,当然还是有今天分享主题内容的APISIX;另外在应用框架层面, nacos也能支持spring体系,包括boot, cloud,同时也有社区很火爆的dapr的适配;高可用框架方面, 分布式事务seata和熔断限流的sentinel也都在使用nacos做配置管理和服务发现;最后在mesh探索方面, nacos可以通过mcp协议,与istio互通,帮助istio发现服务,也支持coreDNS和confd,融入k8s体系。

Nacos社区也还会不停的扩大相关的生态图谱,打造一个互联互通的Nacos微服务生态。


最佳实践


开始介绍最佳实践之前,请大家可以现象一下, 如果想要将让用户的入口南北向流量通过网关转发到Dubbo进行一系列微服务的调用,需要如何部署我们的架构?

Dubbo本身可以用nacos做服务发现,进行服务调用;只要简单让网关从nacos中获取到dubbo的服务列表,然后按照url转发是不是就就行?

其实不是的,在实践中,通常会遇到下面2个主要问题:

image.png

首先,除去少量自研的网关,大多数网关暴露出来的服务,通常都是HTTP或者HTTPS协议的,而Dubbo服务通常使用Dubbo协议来进行通信的。 这就有一个协议转换的问题; 而大多数网关并不具备,HTTP协议和Dubbo协议互相转换的能力。

- 其次,网关需要从注册中心中获取Dubbo的服务列表和对应的provider列表;但很多网关甚至都不具备动态获取后端RS的能力,更别说从注册中心中获取了。


一般解决方案


解决上述问题的一般解决方案,通常是在网关和Dubbo服务之间,添加一层适配层,或者叫胶水层,暴露hTTP的接口,将信息转换成Dubbo协议,然后在调用实际的Dubbo服务。

同时还需要针对网关,开发对应的网关插件,以支持网关从Nacos中动态获取和刷新配置服务地址的能力。如果网关并不支持插件能力,还需要对其源码进行改动。

image.png

一般解决方案虽然能够解决前面提到的两个问题,但是其也会引入一些其他的问题:

1、适配层会导致调用的服务多了一次流量转发,RT和稳定性都会受到影响,比如适配服务性能不足了,响应慢了,或者适配服务挂了的情况。同时适配层服务可能需要额外部署在一批服务器上,可能导致更高的成本。

2、网关和适配服务,适配服务和底层服务之间也需要通过注册中心来进行注册和发现,多一层服务,可能会导致Nacos的订阅量翻倍,也可能需要提升Nacos的集群规格,导致一部分提高的成本。

3、针对网关的额外插件开发或源码改动,可能需要投入一定人力进行高难度开发,毕竟大多数网关的开发语言都是C/C++/Lua等,后续还需要投入人员维护。

综上所述,一般的解决方案,不仅需要投入人力进行额外的高难度开发,还对稳定性,响应速度,成本有一定的影响。


APISIX+Dubbo+Nacos 最佳实践


使用APISIX+Dubbo+Nacos,则可以完美符合我们对这个实践的最初构想,即网关直接调用Dubbo服务,且直接从注册中心中获取服务地址自动更新路由。用户不需要额外考虑中间的转换以及服务发现的问题,只需要专注于开发自己的Dubbo业务即可。


image.png

由于APISIX原生支持HTTP和Dubbo协议的转换,不需要适配层来帮忙,实现最简单的直接调用Dubbo服务。同时由于APISIX原生支持将Nacos作为upstream(也就是后端服务的)注册中心来源,支持动态刷新RS列表。

笔者编写了一个简单的[工程Demo](https://github.com/KomachiSion/APISIX-Dubbo-Nacos) 来模拟最佳实践的使用结果。

整个实践过程,仅需要4个步骤:

1、 Clone 工程demo到本地环境;

2、执行docker-compose命令,自动部署APISIX以及Nacos;

3、启动Dubbo样例,可在Nacos上查看到注册的服务;

4、调用APISIX的openAPI, 创建流量的Dubbo路由规则;

自此,APISIX+Dubbo+Nacos的组合使用就已经全部完成,通过demo中的样例uri尝试进行调用。

image.png


计划与展望


虽然使用APISIX+Dubbo+Nacos,能够解决这个实践中最主要的两个问题。但是它在使用中仍然还有需要进步的地方。社区中会在后续的计划和展望中继续优化。

image.png

路由规则自动生成


在刚才的Demo工程中,创建路由规则的动作是手动通过OpenAPI进行创建的,如果需要路由的规则众多,势必对运维人员有较高的要求;同时维护这些uri和后端服务的映射关系,也是一个比较麻烦的事情。

后续社区间是否能进一步的合作,Dubbo的元数据实际上都存放在Nacos中,而APISIX是否能通过读取这部分信息,按照一定的规则自动生成这份路由规则,免去用户自行创建和维护路由规则的可能。


Mesh探索


当前Service Mesh是开源社区中一个很热门的方向,3个社区也都在积极进行Mesh化的探索;例如Nacos就在3.0中规划将Mesh化作为主要的演进方向,直接支持XDS协议;Dubbo3也在进行Mesh化改造,同时也支持XDS协议;而APISIX已经支持作为Ingress Controller来使用;将来3个社区产品获取能通过Mesh的方式,更加紧密的结合使用,提供更多更丰富的功能。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
Data Access 之 MyBatis(八)- MyBatis 通用 Mapper(Part A)(上)
Data Access 之 MyBatis(八)- MyBatis 通用 Mapper(Part A)
7 0
《筑牢高可用基石,AHAS 赋能溪鸟安全生产探索与实践》电子版地址
筑牢高可用基石,AHAS 赋能溪鸟安全生产探索与实践.ppt
10 0
中后台 CSS Modules 最佳实践
中后台 CSS Modules 最佳实践
143 0
ACM 选手图解 LeetCode 搜索插入位置
ACM 选手图解 LeetCode 搜索插入位置
38 0
ACM 选手图解 LeetCode 验证二叉搜索树
ACM 选手图解 LeetCode 验证二叉搜索树
46 0
抢占式实例最佳实践--如何模拟中断事件
由于抢占式实例天然具有被中断的风险,在实例中断前至少5分钟,系统会向您发送中断消息。此时您可以依据 抢占式实例接收中断消息指南 来进行中断消息的处理. 但在开发"中断处理程序"阶段, 由于您实例的中断是由阿里云触发, 概率极低且是非常随机的过程, 调试与验证中断处理程序可能会比较困难.因此,模拟中断事件来增加验证的可操作性是有必要的
301 0
阿里云首发Dubbo3.0 + Nacos2.0
2021.9.1,阿里云微服务引擎(MSE)支持Dubbo3.0+Nacos2.0,扩展性提升10倍,支持服务网格生态,标准、灵活、精准的控制流量,提升系统整体可用性。
1965 0
反射模拟DbUtils实现ResultSet转成Bean实例
前几天接触到了apache的一个小框架DbUtils,真的被其优雅的设计所震撼到了,尤其是其中的 MyBean mybean = QueryRunner.query(sqlConnection,sqlStatement,new BeanHandler(),params); 当时真的是感觉到很是神奇,仅仅是指定了一下那个Bean类的全名,就能从数据库结果集中自动的生成我们需要的Bean对象,真的是太优雅了。
1250 0
+关注
阿里云微服务引擎MSE
面向业界主流开源微服务生态的一站式微服务平台, 提供注册&配置中心全托管(原生支持 Nacos/ZooKeeper/Eureka)、网关(原生支持 Ingress/Envoy)和无侵入的开源增强服务治理(原生支持Spring Cloud/Dubbo)能力。
文章
问答
来源圈子
更多
文章排行榜
最热
最新
相关电子书
更多
Nacos架构&原理
立即下载
Dubbo分布式服务治理实战
立即下载
What's new in Dubbo 2.7.6
立即下载