c 开发微网站开发,企业网站设计哪个好,黄骅贴吧十一万,免费无代码开发平台排行榜简介#xff1a; Dubbo 3.0 是在云原生背景下诞生的#xff0c;使用 Dubbo 构建的微服务遵循云原生思想#xff0c;能更好的复用底层云原生基础设施、贴合云原生微服务架构。
Dubbo3.0 介绍
作者 | 十眠
自从 Apache Dubbo 在 2011 年开源以来#xff0c;经过多年一众大…简介 Dubbo 3.0 是在云原生背景下诞生的使用 Dubbo 构建的微服务遵循云原生思想能更好的复用底层云原生基础设施、贴合云原生微服务架构。
Dubbo3.0 介绍
作者 | 十眠
自从 Apache Dubbo 在 2011 年开源以来经过多年一众大规模互联网、IT 公司的实践积累了大量经验Dubbo 凭着对 Java 用户友好、功能丰富、治理能力强等优点在过去取得了很大的认可成为国内外流行主流的 RPC 框架之一。
但随着云原生时代的到来对以 Apache Dubbo、Spring Cloud 等为代表的 Java 微服务治理体系提出了新的要求包括期望应用可以更快的启动、应用通信的协议穿透性可以更高、能够对多语言的支持更加友好等。比如 Spring 在今年也推出了其基于 GraalVM 的 Spring Native Beta 解决方案拥有毫秒级启动的能力、更高的处理性能等。
这样的背景对下一代 Apache Dubbo 提出了两大要求
1、要保留已有开箱即用和落地实践背景下带来的好处这也是众多开发者所期望的
2、尽可能地遵循云原生思想能更好的复用底层云原生基础设施、贴合云原生微服务架构。
Dubbo 3.0 是在云原生背景下诞生的使用 Dubbo 构建的微服务遵循云原生思想能更好的复用底层云原生基础设施、贴合云原生微服务架构。这体现在
服务支持部署在容器、Kubernetes 平台服务生命周期可实现与平台调度周期对齐支持经典 Service Mesh 微服务架构引入了 Proxyless Mesh 架构进一步简化 Mesh 的落地与迁移成本提供更灵活的选择作为桥接层支持与 SpringCloud、gRPC 等异构微服务体系的互调互通。
在云原生大背景下Apache Dubbo 3.0 选择全面拥抱云原生对 Dubbo 架构升级提出了全新的服务发现模型、下一代 RPC 协议和云原生基础设施适配等。 Dubbo3.0 商业版
下面我先介绍阿里云上微服务治理相关的三款云产品EDAS、MSE、SAE。
EDAS
阿里云 aPaaS 产品一站式部署发布平台同时它是一艘航母具备微服务治理、监控、压测、限流降级等一系列能力同时它也是一个 AIOps 平台。
EDAS 3.0 作为分布式架构、数字化转型上云的首选在线业务应用托管平台在微服务治理、应用发布变更以及智能运维等多个维度为用户应用提供智能化、自动化的解决方案。
在 PaaS 层面我们始终拥抱开源技术并保持和社区版本兼容的时效性在企业特性上例如服务治理、应用监控等方面我们提供一个稳定成熟的产品来降低企业构建互联网化应用的门槛例如企业级应用服务 EDAS 3.0 就是这样一个典型的产品。
——阿里巴巴合伙人、阿里云智能基础产品事业部 高级研究员 蒋江伟
MSE
微服务引擎Micro Service Engine简称 MSE是一个面向业界主流开源微服务生态的一站式微服务平台 帮助微服务用户更稳定、更便捷、更低成本的使用开源微服务技术构建微服务体系。提供注册中心、配置中心全托管兼容 Nacos/ZooKeeper/Eureka、网关兼容 Zuul/Kong/Spring Cloud Gateway和无侵入的开源增强服务治理能力。
SAE
Serverless 应用引擎简称 SAE是首款面向应用的 Serverless PaaS提供成本更优、效率更高的一站式应用托管方案。支持 Spring Cloud/Dubbo/HSF 应用零改造上云提供监控诊断、自动构建镜像、Java 全链路加速、多发布策略、秒级自动弹性等能力支持 Jenkins/云效/插件等部署应用还能通过 Docker 镜像部署任何语言的应用。
以上三款云产品所有的服务治理能力开箱即用支持近五年来市面上所有开源 Dubbo、Spring Cloud 框架包括 Dubbo 3.0以下的所有能力无需修改一行代码与配置您只需将您的 Dubbo 3.0 的应用接入 EDAS/MSE/SAE 都是开箱即用的能力。
1、完整的服务契约详情
在治理的过程中服务契约是所有功能的原材料。在进行测试验证其可用性的时候需要知道服务提供的方法并根据方法参数自动填充模板进而进行测试在配置流量规则时候需要能知道方法的参数从而根据流量特征来进行流量规则配置在进行服务降级、服务鉴权等配置的时候需要根据方法的具体名称和参数类型来给不同的方法在不同的参数或者返回值的时候进行不同的降级/鉴权策略。
开源的 Swagger 已经做得比较不错了但是 MSE 的服务契约更加简单高效。开源的 Swagger 只需要引入依赖并在编码的时候配置好 API 注解然后启动一个 Swagger 的 Server 端就能看到详情美中不足的是没有适配 Dubbo。
考虑到要让用户不修改任何代码配置就能使用且老旧版本的应用代码和镜像也得支持。因为如果需要开发的话会因为侵入性比较大会影响迭代效率我们还是选择了 Agent 方案这样可以做到无需修改任何代码和配置只需要将应用接入 One Agent就可以在 MSE 控制台看到微服务的详情。 当然如果应用本身已经接入了 Swagger我们也能够做到很好的兼容支持。最后我们可以简单地看一下服务契约的效果已经同时支持了 Spring Cloud 和 Dubbo 应用。
可以详细的查看应用注册了哪些服务以及这些服务的消费者有哪些可以详细地查看应用提供的所有微服务方法可以详细地查看应用提供的所有方法的返回值、参数的详情服务测试、服务降级、服务鉴权这些功能能够直接获取服务契约的数据以便后续的治理规则配置。
2、全链路流量控制
在微服务场景下想让流量精确命中到整个链路上的某一个应用的灰度版本想要控制流量在整条链路上完整且精确地按照预期流转目前开源并没有提供这样的能力。但是我们常会碰到以下的场景导致我们不得不去面对全链路流量控制的这个诉求。
如何做到项目/测试环境隔离
我们首先通过新建项目环境给每个项目环境都有唯一的一个项目标签。当流量带上这个项目标签后会路由到该项目环境否则会去主干环境。项目环境隔离带来的好处是每个开发人员都可以有自己的项目环境防止开发者们开发过程中的互相影响。
如何实现全链路灰度
我们首先划分出灰度的机器然后对线上所有应用部署灰度版本灰度流量全部进入灰度版本正常流量进入生产版本。灰度版本只针对灰度流量验证有效减少风险。当我们要灰度发布 N 个应用需要做到灰度流量在这 N 个应用的灰度版本之间路由。
下面这张图很好地说明使用流量控制让我们的开发同学在开发环境 1 和开发环境 2 各自部署各自的应用可以实现环境隔离与全链路灰度的能力。 但是如果没有全链路流量控制的这套机制各种开发/灰度/生产环境都要进行逻辑或者物理隔离这就需要部署N套整套的微服务架构成本非常高。 可以看到上图的基于全链路流量控制的方案才是更加合理的部署方案设计我们提供了开箱即用全链路流量控制的能力下面以电商架构中的下单场景为例介绍全链路流控功能。
客户下单后流量从入口应用或者微服务网关进来调用交易中心交易中心再调用商品中心商品中心调用下游的库存中心。交易中心和商品中心各有两个新版本1和2在运行需要对这两个新版本进行灰度验证。此时在入口应用或者微服务网关上期望将满足特定流控规则的请求流量路由到新版本其余流量全部路由到线上正式版本。 我们只需在 EDAS 控制台创建如下全链路流量控制规则 同时我们还提供了流量控制的监控大盘可以实时查看各个应用的 qps 指标来确认流量走向是否符合预期。 3、标签路由
EDAS/MSE 服务治理提供了标签路由的流量控制能力。每个 pod/ecs 都可以打上标签标签被识别后会在控制台上展示然后我们可以对标签设置比例和内容规则。 可以设置各个标签的流量比例 也可以点击流量规则设置各个标签的内容流量规则 如果有全链路诉求。上述 是否透传 开关可以用来透传标签。
4、开箱即用的服务测试
服务测试即为用户提供一个云上私网 Postman 让用户能够轻松调用自己的服务。用户无需感知云上复杂的网络拓扑结构无需关系服务的协议无需自建测试工具只需要通过控制台即可实现服务调用。支持 Dubbo 3.0 框架以及 Dubbo 3.0 主流的 Triple 协议。 5、离群实例摘除
在微服务架构中当服务提供者的应用实例出现异常时服务消费者无法及时感知会影响服务的正常调用进而影响消费者的服务性能甚至可用性。 在上图的示例场景中系统包含 4 个应用A、B、C 和 D其中应用 A 会分别调用应用 B、C 和 D。当应用 B、C 或 D 的某些实例异常时如图中应用 B、C 和 D 标识的各有 1个和 2 个异常实例如果应用 A 无法感知会导致部分调用失败如果业务代码写的不够优雅有可能影响应用 A 的性能甚至整个系统的可用性。
在这里主要介绍一下离群实例摘除。那什么是离群实例在微服务集群中出现间歇性的单机抖动 load 极高、 CPU 短时无法响应、线程池满等由于这些个别节点的抖动会导致整体集群的服务质量下降。这种情况在云上时常出现特别是对于一些大客户来说这种能力极为重要。为了提高业务的稳定性我们需要一种自动化的方案当出现离群实例时可以自动将其摘除同时当其恢复健康后又需要将其放回集群继续提供服务。
一句话总结提供了业务单点异常自愈能力。
我们只需要选择框架类型与应用然后配置允许的错误率下限即可。 6、服务鉴权
相比于开源的 Dubbo 3.0MSE 提供了开箱即用的服务鉴权能力保护你的敏感业务可以做到精准地控制服务调用的权限。
当我们的业务发展后我们的服务还会遇到权限控制的需求比如优惠券部门的某个应用同时包含了优惠券查询接口和优惠券发放接口对于优惠券查询接口来说默认公司内部的所有应用都有权限调用的但优惠券发放接口只有客服和运营部门的某些应用才有权限调用。
如下图所示MSE 用户可以对自己的服务进行权限管理这里以 Dubbo 为例下图中配置表明应用 cartservice 发布的 com.alibabacloud.hipstershop.CartService 服务的 addItemToCart 的方法只允许 frontend 这个应用调用。 精准的权限管理可以让你更好地管理微服务调用的权限保证业务的合规性保障数据的安全。
7、服务 Mock
相比于开源 Dubbo 3.0 服务 Mock 能力MSE 提供的是开箱即用的完整解决方案。
当您遇到业务高峰期发现下游的服务提供者遇到性能瓶颈甚至影响业务时。您可以通过服务 Mock 实现服务降级对部分的服务消费者进行降级操作让不重要的业务方不进行真实地调用直接返回 Mock 的结果将宝贵的下游服务提供者资源保留给重要的业务调用方使用从而提升整体服务的稳定性。
开源已有的 Sentinel、Hystrix 等开源的熔断降级主要是对不稳定的弱依赖服务调用进行熔断降级暂时切断不稳定调用避免局部不稳定因素导致整体的雪崩。熔断降级作为保护自身的手段通常在服务消费端进行配置。
服务降级功能既支持在服务调用报错时候进行降级同时也支持在服务调用正常时也开启这样可以很好地保护服务提供者将有限的资源更多地分配给关键的服务消费者。
在开发的过程中相信我们大家都到过下游依赖方开发进度比较慢导致自己的开发进度被 block 的情况在使用 微服务治理 Mock 功能之后可以通过固定地 Mock 某个返回值从而使得开发的过程不需要依赖于下游依赖方的进度同时还可以灵活地在控制台变更 Mock 的规则从而达到快速开发的目的。
如下图所示当应用接入 MSE 之后就可以在控制台中通过如下方式来提供服务 Mock 的功能。 8、服务监控
对于Dubbo应用线上监控以及诊断能力是必不可少的能力我们提供了以下完整且开箱即用的应用监控能力可以让应用的运维变得轻松高效。
应用详情应用依赖服务以及应用实例/状态码统计应用的系统信息与慢调用次数监控应用数据的统计分析应用的调用拓扑分析小结
EDAS/MSE/SAE 服务治理中心是商业化版的 Dubbo Admin但不止于此我们通过无侵入方式增强市面上 Dubbo/Spring Cloud 等框架的全部版本提供了一站式完整的微服务治理能力的解决方案。
不只是 Dubbo3.0
同时EDAS/MSE/SAE 服务治理也将 Dubbo 3.0 一些优秀的设计以及能力通过无侵入服务治理能力普惠到 Dubbo 2.x 以及 Spring Cloud 框架。
1、微服务与K8s生命周期对齐
如果微服务没有实现其接口当部署架构 K8s 化在应用的 缩容、扩容、重启、新版本发布 这些过程中会出现影响业务的错误所以要配置好微服务在 K8s 环境下的健康检查。
其实仅仅是做健康检查其实不够因为出现上述场景的原因可能有很多
1、应用的下线过程中应用提供者正常收到 kill 信号提供者处理完在途请求再停止注册中心感知提供者下线消费者收到下线通知消费者刷新调用列表 等等这些过程中都可能出现错误和延迟。
2、应用上线过程中也可能出问题服务还未注册订阅完成Pod的健康检查已经就绪Dubbo 还没准备好大流量就进来了数据库/Redis 建立连接导致初次请求失败JVM 类加载出现锁导致启动缓慢健康检查写的有问题导致滚动发布过程中没有一个健康的节点等等。
上述的阶段都有可能出现问题这些问题都是需要解决和保证的。这个可以通过开源的方式一个个去解决比如调整注册中心的配置调整连接池的配置调整镜像打包文件自己写代码实现在途请求处理完的逻辑等等。也可以选择使用 MSE 方案不需要修改代码只需要接入 MSE 即可 只需要接入一次接入过程在 5 分钟之内。
Readiness 检查
MSE 会提供一个 Readiness 接口该接口会在微服务启动完全就绪后返回的 status 会成为 200否则返回 503。
Liveness 检查
MSE 会提供一个 Liveness 接口该接口在判断微服务就绪后且服务状态为健康返回的 status 会成为 200否则返回 503 。
我们只需将相关配置配置在K8s提供的接口上即可。
2、无损上下线
若您的应用没有具备无损下线的能力您的任何应用在发布的过程中会造成短暂的服务不可用短时间内业务监控会出现大量 io 异常报错。如果您的业务没做好事务那么还会引起数据不一致的问题您需要紧急手动订正错误数据。每次发布您需要发告示停机发布否则您的用户会出现一段时间服务不可用会对用户产品体验造成影响。
对于任何一个线上应用如何在服务更新部署过程中保证业务无感知是开发者必须要解决的问题即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求目前开源的框架均不能很好地解决这个问题。
当您的应用接入MSE/EDAS/SAE 后将通过无侵入的方式自动增强 Dubbo 和 Spring Cloud 流量的无损下线能力。微服务治理中心将无损下线的能力整合在 K8S 的生命周期中对 ACK 集群中的应用进行部署、回滚、缩容等操作时会自动实现无损下线的效果。
3、服务并行注册订阅
Dubbo 默认服务注册/订阅行为是串行执行当您的 Dubbo 应用中服务数过多该流程会变得很长影响应用启动时长存在一定的稳定性风险为了应用可以更快的启动MSE 会通过无侵入的方式增强你的微服务框架只需加一个开关就能开启服务并行注册与订阅大大减少应用启动时长。
总结
Apache Dubbo 3.0.0 是捐给 Apache 后的一个里程碑版本代表着 Apache Dubbo 全面拥抱云原生的一个节点。
EDAS/MSE/SAE 服务治理能力也在随着云原生微服务的发展以及 Dubbo 的演进而不断丰富随着客户大规模上云后一些云原生场景下微服务的痛点也不断浮出水面我们致力于无侵入的微服务治理增强在解决客户痛点的过程中保证云上客户的业务永远在线使得云原生微服务的架构升级更加 easy 。
原文链接 本文为阿里云原创内容未经允许不得转载。
