您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
Apache Dubbo 3.0.0 正式发布 - 全面拥抱云原生
 
  1359  次浏览      17
 2021-8-10 
 
编辑推荐:
本篇文章主要介绍了背景、Apache Dubbo 3 选择全面拥抱云原生,将 Dubbo 的架构升级,提出了全新的服务发现模型、下一代 RPC 协议和云原生基础设施适配等优化方案等内容。
来自于微信阿里巴巴中间件 ,由火龙果软件Anna编辑、推荐。

背景

自从 Apache Dubbo 在 2011 年开源以来,在一众大规模互联网、IT公司的实践中积累了大量经验后,Dubbo 凭借对 Java 用户友好、功能丰富、治理能力强等优点在过去取得了很大的成功,成为国内外热门主流的RPC 框架之一。

但随着云原生时代的到来,以 Apache Dubbo、Spring Cloud 等为代表的 Java 微服务治理体系面临了许多新的需求,包括期望应用可以更快的启动、应用通信的协议穿透性可以更高、能够对多语言的支持更加友好等。例如Spring 也在今年推出了其基于 GraalVM 的 Spring Native Beta 解决方案,拥有毫秒级启动的能力、更高的处理性能等优化提升。

这样的背景对下一代 Apache Dubbo 提出了两大要求:一是要保留已有的开箱即用和落地实践背景下积累的优点,这也是众多开发者所期望的;二是尽可能地遵循云原生思想,能更好的复用底层云原生基础设施并且更贴合云原生的微服务架构。

拥抱云原生

在如今的大背景下,Apache Dubbo 3 选择全面拥抱云原生,将 Dubbo 的架构升级,提出了全新的服务发现模型、下一代 RPC 协议和云原生基础设施适配等优化方案。

1 全新服务发现模型(应用级服务发现)

应用级注册模型

以 Dubbo 原有的设计,存储在注册中心中的数据会在很大程度上存在重复的内容,这其实浪费了一部分的存储。而当整个集群的规模足够大的时候,由于服务注册发现是服务维度的,注册中心的数据量就会爆发式地增长。

当前同样是微服务治理工具的 Spring Cloud 和 gRPC 都是基于应用级的服务发现,如果仍使用接口级别的注册方式,Dubbo 就很难和他们进行互通。但假如 Dubbo 也可以像 Spring Cloud 一样以服务级注册,那么在异构体系下将可以很轻松地工作起来。

异构下部署方案

应用级服务发现机制是 Apache Dubbo 面向云原生走出的重要一步,它帮 Apache Dubbo 打通了与其他微服务体系之间在地址发现层面的鸿沟,也成为 Apache Dubbo 适配 Kubernetes Native Service 等基础设施的基础。

基于应用级服务发现,注册中心的数据将被重新组织,注册中心的压力大大减轻。同时,由于地址量减少了,应用自身的内存消耗也可以大幅降低。

性能提升

在一般情况下,应用中存储的地址量可以降低约一半,针对上游应用大规模部署的场景(比如部署了 1000 个节点、提供了 50 个服务)甚至可以达到 95% 以上,这对于核心应用的内存压力环境带来的优化是巨大的。

2 下一代 RPC 协议 —— Triple

在云原生时代,Dubbo RPC 协议主要面临两个挑战:

1、生态不互通,Dubbo 协议基于二进制流定制了与 RPC 强绑定的核心语义,包括协议头、标志位、请求 ID 以及请求/响应数据等。而对于越来越多的云原生治理设施,要让他们都 “读” 懂 Dubbo 的二进制 “语义” 并不容易。

2、由于协议设计的问题,Dubbo 协议的协议头已无法再承载更多的元数据信息。而对于 Mesh 等网关型组件,如果想要对数据进行治理就需要对完整的数据包进行解析才能获取到必要的元数据信息(如 RPC 上下文),从性能到易用性方面都会面临挑战。

Dubbo 协议通信方式

在支持已有的功能和解决存在的问题的前提下,Apache Dubbo 3 提出了下一代 RPC 协议——Triple。

基于 Tripe 协议,我们期望可以解决这些问题:

1、跨语言互通的问题。传统的多语言多 SDK 模式和 Mesh 化跨语言模式都需要一种更通用易扩展的数据传输格式;

2、提供更完善的请求模型。除了 Request/Response 模型,还应该支持 Streaming 和 Bidirectional;

请求模型示意图

3、易扩展、穿透性高。包括但不限于 Tracing / Monitoring 等支持,也应该能被各层设备识别,网关设施等可以识别数据报文,对 Service Mesh 部署友好,降低用户理解难度;

4、支持 Java 用户无感知升级。不需要定义繁琐的 IDL 文件,仅需要简单的修改协议名便可以轻松升级到 Triple 协议。

基于这些期望,我们觉得 HTTP/2 作为底层通信协议,使用 protobuf 作为序列化协议的组合是最合理的,这套组合方案也是 gRPC 协议使用的方案。所以对于 Triple 协议来说,我们可以基于 gRPC 协议进行演变,以满足 Apache Dubbo 已有的优秀特性,这同时也保证了在生态系统上新协议和 gRPC 是能够互通和共享的。

Triple 协议通信方式

3 云原生设施接入

针对于 Kubernetes 的场景, Apache Dubbo 3 为此做了两方面的接入:

一是原生支持与 Kubernetes Pod 生命周期对齐,基于 Dubbo QoS 机制,Kubernetes 能够感知到运行在 Pod 容器中的 Dubbo 应用当前是什么状态,而且得益于 Dubbo SPI 机制用户可以自定义探针检测的维度,实现框架和业务的生命周期都达到统一。

第二是 Dubbo 也将支持接入 Kubernetes Native Service 体系,原生支持基于 Kubernetes API Server 和 DNS 的服务发现体系,实现部署架构下的服务概念与 Dubbo 中的服务概念进行对齐。

Kubernetes 架构下部署方案

而对于 Service Mesh 体系,如果应用使用 Apache Dubbo 2 想要部署以 Mesh 方式部署,需要使用 Sidecar 对 Dubbo 流量进行拦截,而同时由于 Dubbo 本身是具有一定的治理能力的,从应用来说会多做了很多无用的事情,从集群的角度来说会造成调用的紊乱。

基于此,Apache Dubbo 3 提出了两种部署模式,一种是配合 Sidecar 部署的 Thin SDK 模式、另一种是直接接入控制面的 Proxyless Mesh 模式。

Dubbo 3 在 Mesh 场景下部署架构

除了部署架构的接入,在 Apache Dubbo 3 中还定义了一套面向云原生流量治理,支持传统 SDK、Mesh 场景的统一治理规则。

Apache Dubbo 3 期望使用这一套规则,便可以实现如金丝雀发布、A/B测试等丰富的路由语义,只需要配置一套规则,写入统一的控制面,就可以统一地控制所有集群。这样无论使用 Kubernetes 直接部署、亦或者是 Mesh 场景下使用 Thin SDK 或 Proxyless 混合部署甚至是用户直接手动部署集群均可以被同一套规则所控制,实现定义一次,到处使用的目标。

   
1359 次浏览       17
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践

最新活动计划
UAF架构体系与实践 5-17[北京]
用户体验与界面设计 5-22[北京]
MBSE(基于模型的系统工程)6-20[北京]
大模型微调原理与实操 6-20[厦门]
图数据库与知识图谱 6-27[北京]
Linux内核编程及设备驱动 7-25[北京]
 
 
最新文章
架构设计-谈谈架构
实现SaaS(软件及服务)架构三大技术挑战
到底什么是数据中台?
响应式架构简介
业务架构、应用架构与云基础架构
最新课程
软件架构设计方法、案例与实践
从大型电商架构演进看互联网高可用架构设计
大型互联网高可用架构设计实践
企业架构师 (TOGAF官方认证)
嵌入式软件架构设计—高级实践
更多...   
成功案例
某新能源电力企业 软件架构设计方法、案例与实践
中航工业某研究所 嵌入式软件开发指南
某轨道交通行业 嵌入式软件高级设计实践
北京 航天科工某子公司 软件测试架构师
北京某领先数字地图 架构师(设计案例)
更多...