精华内容
下载资源
问答
  • Dubbo3 预览版

    2021-03-28 15:34:40
    本文将和读者一起解读 Dubbo3 的首个 preview 版本:一方面,我们将深入分析 Dubbo3 云原生变革的核心理念;另一方面,我们将逐个解读 preview 版本的核心功能。 做过微服务开发的开发者相信对 Dubbo 都不陌生,...

    前几天Dubbo 社区刚刚发布了 3.0 的首个预览版本来迎接云原生时代的到来。这是一个具有重大意义、重大改进的版本,为国内众多使用Dubbo2的企业指明了未来的发展道路,我们一起来看看。

    本文转自:https://mp.weixin.qq.com/s/UMhVRA9nje4oEa44U5ibAg  作者:陆龟 阿里巴巴云原生

     

    本文将和读者一起解读 Dubbo3 的首个 preview 版本:一方面,我们将深入分析  Dubbo3 云原生变革的核心理念;另一方面,我们将逐个解读 preview 版本的核心功能

     

    做过微服务开发的开发者相信对 Dubbo 都不陌生,Dubbo 是一款能帮助我们快速解决微服务开发、通信以及流量治理的框架。相比于之前只限定在 Java 语言范围内,Dubbo 的多语言版本在这两年呈现了良好的发展势头,其中,Dubbo Go 语言版本在功能、稳定性各个方面都已非常完备,其它几种主流的多语言版本在社区也有提供。

     

    图片

    云原生视角的微服务变革

     

    Dubbo 主要解决微服务开发、运行域问题,它和微服务的编程、通信、流量治理等密切关联,因此,在探寻 Dubbo3 的云原生变革之前,我们先尝试从云原生视角观察云原生基础设施带给微服务架构和实践的变革,进而总结出 Dubbo 这样一个和微服务实践密切相关的框架所面临的变革与挑战。

     

    图片

    微服务在让业务开发演进更灵活、快捷的同时,也带来了一些它独有的特征和需求:如微服务之后组件数量越来越多,如何解决各个组件的稳定性,如何快速的水平扩容等。

     

    这些诉求,尤其是运维、交付相关诉求,如微服务组件的生命周期、网络、通用服务绑定、服务状态管理等,并不应该是开发人员关注的重点,因为它们已经完全脱离了业务逻辑,开发人员更愿意专注在有业务价值组件上,但这个层次的诉求却是实现微服务交付的关键能力。开发者期望由底层基础设施来提供此类能力支持,而处于不同阶段发展的基础设施却不一定具备这样的能力,因此,在微服务软件架构和底层基础设施之间就出现了一条鸿沟,我们需要有组件能填补这一鸿沟,让微服务组件能更好的接入底层基础设施。

     

    图片

     

    这里从一个更抽象的层面,尝试用两条发展曲线演示了软件架构诉求与底层基础设施能力丰富度之间的关系。总体上,两者之间的发展关系可拆分为两个阶段。

     

    在第一个阶段,软件架构(这条红色的线)从单体应用、到面向服务的软件架构、再到微服务架构,快速演进,从而也提出了上文我们讲到的对基础设施对交付的诉求,这个时候基础设施层还多是以定制化的方式来满足软件架构的诉求,如过往的集中化的 ESB、各个不同的 PaaS 平台等。

     

    第二个阶段,是从容器、Kubernetes 为代表的基础产品的出现开始,蓝线与红线之间的增长速度被快速拉近,以云原生技术为代表的底层基础设施丰富度得到了极大改善,它们不再只是被动的满足微服务开发的诉求,而是开始抽象更多的软件诉求到底层的基础设施,将它们下沉为基础能力,并开始以统一的、标准化的形式向上输出以满足微服务对交付、运维等的诉求,不仅如此,通过更深入的主动创新、持续的向上释放能力,底层基础设施还开始反过来影响微服务的开发、接入方式,如 sidecar、dapr 等模型。

     

    图片

    Dubbo3 的云原生变革

     

    通过上文云对原生基础设施演进给传统微服务带来变革的分析,我们得出,以 Dubbo 为代表的微服务开发框架,应重点在以下方向突破与变革。

    • 更多的微服务组件及能力正下沉到以 Kubernetes 为代表的基础设施层。传统微服务开发框架应剔除一些冗余机制,积极的适配到基础设施层以做到能力复用;微服务框架生命周期、服务治理等能力应更好地与 Kubernetes 服务编排机制融合;

    • 以 Service Mesh 为代表微服务架构给微服务开发带来的新的选择,但由于 Mesh 架构本身的复杂性,其距离大规模生产落地还有一段距离。我们相信,基于 ServiceMesh 的体系会逐步从孵化器走向成熟期,会有越来越多的企业采用 Service Mesh技术,但在未来在很长一段时间内,基于服务框架的传统微服务体系还将是主流,长期仍将占据半壁江山。

     

    我们不妨回想一下,在云原生基础设施能力被充分释放前,围绕 Dubbo 构建微服务时,它给微服务开发提供了哪些能力?或者我们期望它提供哪些能力?

     

    图片

     

    Dubbo2 提供了包括服务注册、服务发现、负载均衡、流量治理等相当丰富的能力,当然还包括微服务最需要的远程通信能力,这些能力很好地解决了微服务的诉求。

     

    而在云原生架构之下,我们需要重新审视,Dubbo2 的哪些能力是冗余的,是需要接入基础设施的?哪些能力是已经不适合云原生时代的,需要被重构的?

     

    图片

     

    首先,是接入云原生基础设施后,一些能力出现了重复,像服务定义、服务注册、甚至是服务治理能力在不同层面基础设施中出现了重复,需要 Dubbo3 作出适配与调整,以更好的解放业务开发效率,利用好这些基础能力。

     

    其次,是 Dubbo 在微服务架构中的最基本的能力:RPC 远程通信。通信协议和数据传输格式的标准化应该算是 Dubbo2 面临的又一重要挑战,在云原生背影下,协议、数据定义、传输格式的标准化和穿透能力成为更需要优先考虑的指标,纵然私有协议具有更高效、灵活的潜力,但考虑到云原生下多语言、组件间互通、网关等代理设备友好性、避免厂商锁定等诉求,在 Dubbo3 中私有协议都应该被摒弃,转而拥抱基于 HTTP/2 的更通用的协议,采用跨语言的更通用的数据定义和传输格式。

     

    最后,是关于服务治理能力,Dubbo 的服务治理能力应该充分结合底层基础设施的特点,比如之前绑定 ip 的流量过滤方案在地址不固定的 Kubernetes 平台就已不再适用,另外,流量治理也要充分的与调度平台的灰度发布、动态扩缩容能力整合起来;考虑到未来微服务可能会有多种不同的部署形态(下文会讲到),Dubbo3 应该制定一种能适用于各种部署形态的路由规则。

     

    从云原生视角来说,Dubbo3 的核心能力基本上也就成围绕以上几点分析展开的,主要涉及:抽象全新的服务发现模型、定义下一代的更能用的 RPC 协议与数据传输格式、服务治理能力重构等。接下来,我们就看看 3.0 preview 中这些能力的具体实现。

     

    图片

    Preview 版本功能速览

     

    就在今天,Dubbo 3.0.0.preview 版本正式通过了 Apache 社区投票并完成了正式发布,作为 3.0 的首个发布版本,代表了社区 3.0 版本的全面启动,也展示了未来 3.0 的发展方向。当然,我们要意识到 preview 版本还远未达到生产可用,它只是为了让大家快速、方便了解 Dubbo3 的一个预览版本,离正式版本甚至 alpha 版本还有一段时间要走,具体大家可关注文后的 Dubbo Roadmap。

     

    以下 preview 版本发布的几个核心特性:

    • 全新的服务发现模型

    • 下一代基于 HTTP/2 的 RPC 协议:Triple

    • 服务治理重构:全新路由规则

    • 性能提升

      • 百万节点级水平扩容

      • 调用链路 QPS 性能提升

     

    在 preview 以上能力中,特别值得注意的是得益于 Dubbo3 与 HSF 的融合,Dubbo3 的整体性能也有望得到大幅提升。

     

    Preview 版本是从架构层面对 Dubbo 的一次全面升级,接下来,社区一方面会从功能完善度、稳定性等几个方面继续增强 3.0 版本,并将在 6 月份发布首个稳定版本,另一方面社区将兑现更多新的功能。首先,接下来即将交付的是 Kubernetes Service 集成,而 Proxyless Mesh、基于反压的智能流量调度等功能正在前期的调研或开发阶段。

     

    下面,我们就选取以上三个核心功能,深入了解它们的实现机制。

     

    1. 全新服务发现模型

    下图是 Dubbo2 的服务发现模型:Provider 注册服务地址,Consumer 经过注册中心协调并发现服务地址,进而对地址发起通信,这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于,它把 “RPC 接口”的信息也融合在了地址发现过程中,而这部分信息往往是和具体的业务定义密切相关的。

    图片

     

    而在接入云原生基础设施后,基础设施融入了微服务概念的抽象,容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示,基础设施即承担了注册中心的职责,又完成了服务注册的动作,而 “RPC 接口”这部分信息,由于与具体的业务相关,不可能也不适合被基础设施托管。

     

    在这样的场景下,对 Dubbo3 的服务注册发现机制提出了两个要求:

    1. Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型,并确保这部分模型足够合理,以支持将地址的注册行为和存储委托给下层基础设施;

    2. Dubbo3 特有的业务接口同步机制,是 Dubbo3 需要保留的优势,需要在 1 中定义的新地址模型之上,通过框架内的自有机制予以解决。

    图片

     

    这样设计的全新的服务发现模型,在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。

     

    图片

     

    在架构兼容性上,如上文所述,Dubbo3 复用下层基础设施的服务抽象能力成为了可能;另一方面,如 Spring Cloud 等业界其它微服务解决方案也沿用这种模型,在打通了地址发现之后,使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。

     

    Dubbo3 服务发现模型更适合构建可伸缩的服务体系,这点要如何理解?这里先举个简单的例子,来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化:假设一个微服务应用定义了 100 个接口(Dubbo 中的服务),则需要往注册中心中注册 100 个服务,如果这个应用被部署在了 100 台机器上,那这 100 个服务总共会产生 100 * 100 = 10000 个虚拟节点;而同样的应用,对于 Dubbo3 来说,新的注册发现模型只需要 1 个服务(只和应用有关和接口无关), 只注册和机器实例数相等的 1 * 100 = 100 个虚拟节点到注册中心。在这个简单的示例中,Dubbo 所注册的地址数量下降到了原来的 1 / 100,对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是,地址发现容量彻底与业务 RPC 定义解藕开来,整个集群的容量评估对运维来说将变得更加透明:部署多少台机器就会有多大负载,不会像 Dubbo2 一样,因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。

     

     

    2. 下一代通信协议:Triple

     

    我们将 Dubbo3 的新协议命名为 Triple,有代表第 3 代协议的意思。在云原生背景下,Triple 协议需要解决两大问题:

     

    • 通信协议和数据传输格式的标准化问题。这涉及到 RPC 协议、数据定义、数据传输等环节,未来可移植性、不被厂商锁定会成为每个上云企业用户的诉求,组件内的私有协议和特有数据格式,必然会成为很多用户选型的顾虑。

     

    • 穿透性、通用性问题。在 Mesh 等架构设想下,微服务甚至所有组件的通信都要经过 sidecar 代理转发,理论上,Sidecar 是要透明的转发流量的(收到什么就转发什么),起码 payload 不应该是 Sidecar 关注的;而 Sidecar 在某些时候也需要感知流量内容的,因为它要基于些做流量的调度,这个时候,Triple 就要做到足够通用 -- 让所有的 Sidecar 都能在预期的地方取到其关注的元数据,而不用解析整个 payload。

     

    图片

     

    除了以上两个核心问题,Triple 协议还需要被设计用来支持更多的业务语义。

     

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

     

    • 在性能上,新的协议应该保留 request Id 机制,以避免 HOL 带来的性能损耗。

     

    • 新协议应该易于扩展,包括但不限于 Tracing、Monitoring、BackPressure 等支持。

     

    基于以上需求,Triple 协议是完全基于 HTTP/2 之上构建的,另外,Triple 协议将会做到完全兼容 gRPC 协议;在服务定义、数据格式定义以及传输格式上,Triple 将更增加对 Protobuf 的支持。

     

     

    3. 统一的路由规则

     

    Dubbo3 会对服务治理规则进行全面的重构,以更好的适应云原生基础设施的变革。

     

    当前的 3.0 preview 版本提供了一个重构后的路由规则机制原型,虽然当前版本的实现还需要继续增强,但从设计理念上,我们可以解读出:Dubbo3 期望提供一种跨平台、跨语言、跨多种部署架构的通用路由规则。

     

    随着微服务对治理需求的挖掘,Dubbo2 路由规则除了在语义表达上不能涵盖所有场景之外,更为重要的是,其基于特定语言、特定主机 ip 的过滤机制,已不再适应底层调度平台的工作机制,Dubbo3 需要引入一种全新设计的路由规则。而对于“跨多种部署架构” 这个点,我们设想未来以 Dubbo 构建的微服务会有三种部署架构:传统 SDK、基于 Sidecar 的 Service Mesh以及脱离 Sidecar 的 Service Mesh,这三种部署形态都将由 Dubbo3 统一的路由规则进行治理。

     

    • 基于 Sidecar 的 Service Mesh,经典的 Mesh 架构,独立的 sidecar 运行时接管所有的流量。

     

    • 脱离 Sidecar 的 Service Mesh,变种 Mesh 架构,没有 sidecar 运行时,富 SDK 直接通过 xDS 与控制面通信,我们将在后续发布关于 Proxyless 模式更详细的解读。

     

    图片

     

    图片

    实践中的 Dubbo3

     

    云原生微服务变革在各大厂商内部早已展开,相比于当前开源社区的 preview 版本,Dubbo3 在阿里巴巴的开发与实践已经在逐步铺开:部分功能已经在阿里巴巴的部分业务线上得到了规模化验证(考拉),并且更多的功能和业务线也将进入试点、推广阶段(饿了么、钉钉等)。有一点是值得特别提及的是:在接下来阿里巴巴的微服务架构升级战略中,Dubbo3 将成为阿里巴巴经济体未来唯一的标准服务框架,它将逐步在所有业务线取代 HSF 和 Dubbo2,并且我们期待在接下来的 1-2 年 Dubbo3 内能覆盖大多数重要的业务线。

     

    说在这里,有必要提一下阿里巴巴的微服务框架演进历程。大概在 2011 年,阿里巴巴开源了 Dubbo2 这一款服务框架并获得极大成功,在 Dubbo2 开源不久,在阿里巴巴内部又发展出了一款全新的服务框架 -- HSF,两者在设计理念上是高度相似的,而经过这么些年的发展,HSF 得以跟随阿里巴巴的业务系统更快速的成长,由其是在大集群、大流量治理下展现出了更好的性能和稳定性。在阿里云原生微服务战略下,整合各个优秀的框架并发展统一品牌的 Dubbo3 被纳入发展规划,在此背景下,Dubbo3 实现了Dubbo2 与 HSF 的融合,并将推动实现内、外技术栈的统一。

     

    除了阿里之外,工商银行等标杆用户也已启动了对 Dubbo3 项目的试点。从社区角度来说,preview 预览版本的发布只是开始,未来随着阿里巴巴、工商银行等更多标杆用户的全面落地,将推动项目更快、更高质量的发展,助力项目保持持续的创新能力和社区生命力。

     

    图片

    未来规划(Roadmap)

     

    以下是 Dubbo3 的 Roadmap,截止此文发稿,社区已经完成了 3.0 preview 版本的发布。

     

    图片

     

    在 6 月份,我们期望能迎来 Dubbo3 的首个社区正式版本。

     

    随后,一直到下半年的 11 月份,我们将重点投入在对 Kubernetes、ServiceMesh 架构的支持上,中间当然也包括了对服务治理规则的全面重构。

     

    在此之后,我们将开始在服务柔性上的尝试,以期提供一种能更高效的利用资源且能提高系统稳定性的流量高度机制。

     

    本文开篇关于云原生微服务变革部分思想引自阿里云高级技术专家、CNCF TOC 张磊 《Microservices - A Cloud Native View》一文分享。

     

    本文转自:https://mp.weixin.qq.com/s/UMhVRA9nje4oEa44U5ibAg     

    展开全文
  • 聊聊Dubbo(一):为何选择 1. 前言 随着现在互联网行业的发展,越来越多的框架、中间件、容器等开源技术不断地涌现,更好地来服务于业务,实现业务并解决问题。然而面对众多的技术选择,我们要如何甄别出适合...

    聊聊Dubbo(一):为何选择

    1. 前言

    随着现在互联网行业的发展,越来越多的框架、中间件、容器等开源技术不断地涌现,更好地来服务于业务,实现业务并解决问题。然而面对众多的技术选择,我们要如何甄别出适合自己团队业务的技术呢?对于人来说,鞋子过大,可能影响奔跑的速度,鞋子过小,可能影响身体的成长。技术对于业务也是如此的关系。

    所以,相对于技术的学习、搭建、使用、运维等技能,我们 对技术的甄别选择更是重中之重。那么本文要讲的Dubbox框架,又是如何在众多的服务框架中脱颖而出,被团队选中践行服务之路?

    2. 服务

    2.1 为什么要做服务

    技术为业务而生,架构也为业务而出现。随着业务的发展、用户量的增长,系统数量增多,调用依赖关系也变得复杂,为了确保系统高可用、高并发的要求,系统的架构也从单体时代慢慢迁移至服务SOA时代,根据不同服务对系统资源的要求不同,我们可以更合理的配置系统资源,使系统资源利用率最大化

     

    系统架构演进

     

    1. 单一应用架构 当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本。 此时,用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
    2. 垂直应用架构 当访问量逐渐增大,单一应用增加机器带来的加速度越来越小,将应用拆成互不相干的几个应用,以提升效率。 此时,用于加速前端页面开发的 Web框架(MVC) 是关键。
    3. 分布式服务架构 当垂直应用越来越多,应用之间交互不可避免,将核心业务抽取出来,作为独立的服务,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求。 此时,用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。
    4. 流动计算架构 当服务越来越多,容量的评估,小服务资源的浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率。 此时,用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

    平台随着业务的发展 从 All in One 环境 就可以满足业务需求(以Java来说,可能只是一两个war包就解决了);发展到需 要拆分多个应用,并且采用MVC的方式 分离前后端,加快开发效率;在发展到服务越来越多,不得不将 一些核心或共用的服务拆分出来,提供实时流动监控计算等,其实发展到此阶段,如果服务拆分的足够精细,并且独立运行,这个时候至少可以 理解为SOA(Service-Oriented Architecture)架构 了。

    2.2 服务带来的挑战

    当迎来服务SOA时代,我们面临要解决的问题会很多,比如:系统的复杂度上升、服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流等。那么面对这些问题为什么还要做分布式服务呢?因为在未来只有砥砺前行,才能走的更高更远。不过看到这些问题不要气馁,先不管这些问题,让我们一步步来梳理下现存有什么问题,我们要完成什么目标,问题自然会迎刃而解。

    根据现在团队的业务系统情况,首先我们要梳理出现存的问题是什么:

    1. 多种调用传输方式:HTTP方式、WebService方式;
    2. 服务调用依赖关系:人工记录,查看代码分析;
    3. 服务调用性能监控:日志记录,人工查看时间;
    4. 服务与应用紧耦合:服务挂掉,应用无法可用;
    5. 服务集群负载配置:Nginx配置,存在单点问题;

    在去选择技术框架时,技术框架最基本要解决上面现存问题,同时我们也要确认出我们的期望,要达到的目标是什么:

    1. 支持当前业务需求,这是最最基本的条件;
    2. 服务避免单点问题,去中心化;
    3. 服务高可用、高并发,解耦服务依赖;
    4. 服务通用化,支持异构系统调用服务;
    5. 服务依赖关系自维护,可视化;
    6. 服务性能监控自统计,可视化;
    7. 服务需自带注册、发现、健康检查、负载均衡等特性;
    8. 开发人员关注度高,上手快,简单轻量,低侵入;

    还有最重要一点,这也是往往很多技术人员进入的误区,“对于技术,不要为了使用而使用,用最简单合适的技术实现解决问题才是正道”。架构是服务于业务的,能快速方便的满足业务需求的架构才是好的架构

     

    没有最好的,只有适合自己的

     

    2.3 服务未来的趋势

    一谈到服务,可能大家很多听说过SOA、MSA等服务的概念名词,近几年MSA炒的比较火,其实每一个概念的背后都在解决不同的问题。此类名词的最大特点就是 一解释就懂,一问就不知,一讨论就打架

    SOA、MSA两者说到底都是对外提供接口的一种架构设计方式。我倒觉得微服务其实就是随着互联网的发展,复杂的平台、业务的出现,导致SOA架构向更细粒度、更通用化程度发展,就成了所谓的微服务了。以这种说法做为根据,我觉得SOA与微服务的区别在于如下几个方面:

    1. 微服务相比于SOA更加精细,微服务更多的以独立的进程的方式存在,互相之间并无影响;
    2. 微服务提供的接口方式更加通用化,例如HTTP RESTful方式,各种终端都可以调用,无关语言、平台限制;
    3. 微服务更倾向于分布式去中心化的部署方式,在互联网业务场景下更适合;

    微服务与SOA有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面,微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的,而它与SOA原则的演化的目标也是相同的,则减少传统的企业服务总线开发的高复杂性。两者之间最关键的区别在于,微服务专注于以自治的方式产生价值。但是两种架构背后的意图是不同的:SOA尝试将应用集成,一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能,快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行

    功能 SOA 微服务
    组件大小 大块业务逻辑 单独任务或小块业务逻辑
    耦合 通常松耦合 总是松耦合
    公司架构 任何类型 小型、专注于功能交叉的团队
    管理 着重中央管理 着重分散管理
    目标 确保应用能够交互操作 执行新功能,快速拓展开发团队

    微服务并不是一种新思想的方法。它更像是一种思想的精炼,一种SOA的精细化演进,并且更好地利用了先进的技术以解决问题,例如容器与自动化等。所以对于我们 去选择服务技术框架时,并不是非黑即白,而是针对SOA、MSA两种架构设计同时要考虑到兼容性,对于现有平台情况架构设计,退则守SOA,进则攻MSA,阶段性选择适合的

    3. 框架

    现在业界比较成熟的服务框架有很多,比如:Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技术实现,都可以进行远程调用,具体技术实现优劣参考以下分析,这也是具体在技术方案选择过程中的重要依据。

    3.1 服务框架对比

    Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成。不过,略有遗憾的是,据说在淘宝内部,dubbo由于跟淘宝另一个类似的框架HSF(非开源)有竞争关系,导致dubbo团队已经解散,反到是当当网的扩展版本Dubbox仍在持续发展,墙内开花墙外香。其它的一些知名电商如当当、国美维护了自己的分支或者在dubbo的基础开发,但是官方的库缺乏维护,相关的依赖类比如Spring,Netty还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final),倒是有些网友写了升级Spring和Netty的插件。

    Dubbox和Dubbo本质上没有区别,名字的含义扩展了Dubbo而已,以下扩展出来的功能,也是选择Dubbox很重要的考察点。

    1. 支持REST风格远程调用(HTTP + JSON/XML);
    2. 支持基于Kryo和FST的Java高效序列化实现;
    3. 支持基于Jackson的JSON序列化;
    4. 支持基于嵌入式Tomcat的HTTP remoting体系;
    5. 升级Spring至3.x;
    6. 升级ZooKeeper客户端;
    7. 支持完全基于Java代码的Dubbo配置;

    Spring Cloud完全基于Spring Boot,是一个非常新的项目,2016年推出1.0的release版本,目前Github上更新速度很快. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统(配置管理,服务发现,熔断,路由,微代理,控制总线,一次性token,全局琐,leader选举,分布式session,集群状态)中快速构建的工具,使用Spring Cloud的开发者可以快速的启动服务或构建应用。它们将在任何分布式环境中工作,包括开发人员自己的笔记本电脑,裸物理机的数据中心,和像Cloud Foundry云管理平台。在未来引领这微服务架构的发展,提供业界标准的一套微服务架构解决方案。

    缺点是项目很年轻,很少见到国内业界有人在生产上成套使用,一般都是只有其中一两个组件。相关的技术文档大部分是英文的,案例也相对较少,使用的话需要摸索的时间会长一些。

    下图是Spring Cloud和Dubbo对比:

     

    Spring Cloud和Dubbo对比

     

    Motan是新浪微博开源的一个Java 框架。它诞生的比较晚,起于2013年,2016年5月开源。Motan 在微博平台中已经广泛应用,每天为数百个服务完成近千亿次的调用。与Dubbo相比,Motan在功能方面并没有那么全面,也没有实现特别多的扩展。用的人比较少,功能和稳定性有待观望。对跨语言调用支持较差,主要支持java

    Hessian采用的是 二进制RPC协议,适用于发送二进制数据。但本身也是一个Web Service框架对RPC调用提供支持,功能简单,使用起来也方便。基于Http协议进行传输。通过Servlet提供远程服务。通过Hessain本身提供的API来发起请求。响应端根据Hessian提供的API来接受请求。

    Hessian优点:

    1. 整个jar很小,轻量;
    2. 配置简单;
    3. 功能强大,抛开了soap(simple object access protocal 简单对象访问协议)、ejb,采用二进制来传递对象;

    rpcx是Go语言生态圈的Dubbo, 比Dubbo更轻量,实现了Dubbo的许多特性,借助于 Go语言优秀的并发特性和简洁语法,可以使用较少的代码实现分布式的RPC服务

    gRPC是Google开发的高性能、通用的开源RPC框架,其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计,基于ProtoBuf(Protocol Buffers)序列化协议开发,且支持众多开发语言。本身它不是分布式的,所以要实现上面的框架的功能需要进一步的开发。

    thrift是Apache的一个跨语言的高性能的服务框架,也得到了广泛的应用。

    以上RPC框架功能比较:

    功能 Hessian Montan rpcx gRPC Thrift Dubbo Dubbox Spring Cloud
    开发语言 跨语言 Java Go 跨语言 跨语言 Java Java Java
    分布式(服务治理) × × ×
    多序列化框架支持 hessian √(支持Hessian2、Json,可扩展) × 只支持protobuf) ×(thrift格式)
    多种注册中心 × × ×
    管理中心 × × ×
    跨编程语言 ×(支持php client和C server) × × × ×
    支持REST × × × × × ×
    关注度
    上手难度
    运维成本
    开源机构 Caucho Weibo Apache Google Apache Alibaba Dangdang Apache

    实际场景中的选择

    1. Spring Cloud:Spring全家桶,用起来很舒服,只有你想不到,没有它做不到。可惜因为发布的比较晚,国内还没出现比较成功的案例,大部分都是试水,不过毕竟有Spring作背书,还是比较看好。
    2. Dubbox:相对于Dubbo支持了REST,估计是很多公司选择Dubbox的一个重要原因之一,但如果使用Dubbo的RPC调用方式,服务间仍然会存在API强依赖,各有利弊,懂的取舍吧。
    3. Thrift:如果你比较高冷,完全可以基于Thrift自己搞一套抽象的自定义框架吧。
    4. Montan:可能因为出来的比较晚,目前除了新浪微博16年初发布的,
    5. Hessian:如果是初创公司或系统数量还没有超过5个,推荐选择这个,毕竟在开发速度、运维成本、上手难度等都是比较轻量、简单的,即使在以后迁移至SOA,也是无缝迁移。
    6. rpcx/gRPC:在服务没有出现严重性能的问题下,或技术栈没有变更的情况下,可能一直不会引入,即使引入也只是小部分模块优化使用。

    3.2 RPC vs REST(JAX-RS)

    由于Dubbo是基础框架,其实现的内容对于我们实施微服务架构是否合理,也需要我们根据自身需求去考虑是否要修改,比如Dubbo的服务调用是通过RPC实现的,但是如果仔细拜读过Martin Fowler的microservices一文,其定义的服务间通信是HTTP协议的REST API。那么这两种有何区别呢?

    1. 服务提供方与调用方接口依赖方式太强

      我们为每个微服务定义了各自的service抽象接口,并通过持续集成发布到私有仓库中,调用方应用对微服务提供的抽象接口存在强依赖关系,因此不论开发、测试、集成环境都需要严格的管理版本依赖,才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题,以及这也会直接影响本地开发的环境要求,往往一个依赖很多服务的上层应用,每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具,这样的依赖关系会成为开发团队的一大噩梦而REST接口相比RPC更为轻量化,服务提供方和调用方的依赖只是依靠一纸契约,不存在代码级别的强依赖,当然REST接口也有痛点,因为接口定义过轻,很容易导致定义文档与实际实现不一致导致服务集成时的问题,但是该问题很好解决,只需要通过每个服务整合swagger,让每个服务的代码与文档一体化,就能解决。所以在分布式环境下,REST方式的服务依赖要比RPC方式的依赖更为灵活。

    2. 服务对平台敏感,难以简单复用

      通常我们在提供对外服务时,都会 以REST的方式提供出去,这样可以实现跨平台的特点,任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时,不得不实现一层代理,用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在,当要对外提供服务时,主要在API网关中配置映射关系和权限控制就可实现服务的复用了。

    相信这些痛点也是为什么当当网在dubbox(基于Dubbo的开源扩展)中增加了对REST支持的原因之一。

    Dubbo实现了服务治理的基础,但是要完成一个完备的微服务架构,还需要在各环节去扩展和完善以保证集群的健康,以减轻开发、测试以及运维各个环节上增加出来的压力,这样才能让各环节人员真正的专注于业务逻辑。

    而Spring Cloud依然发扬了Spring Source整合一切的作风,以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体,并继承了Spring Boot简单配置、快速开发、轻松部署的特点,让原本复杂的架构工作变得相对容易上手一些。所以,如果选择Dubbo请务必在各个环节做好整套解决方案的准备,不然很可能随着服务数量的增长,整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud,相对来说每个环节都已经有了对应的组件支持,可能有些也不一定能满足你所有的需求,但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

     

    微服务结构图

     

    4. Dubbox带来什么

    4.1 Dubbo服务治理

     

    Dubbo服务治理

     

    特性 描述
    透明远程调用 就像调用本地方法一样调用远程方法;只需简单配置,没有任何API侵入;
    负载均衡机制 Client端LB,可在内网替代F5等硬件负载均衡器;
    容错重试机制 服务Mock数据,重试次数、超时机制等;
    自动注册发现 注册中心基于接口名查询服务提 供者的IP地址,并且能够平滑添加或删除服务提供者;
    性能日志监控 Monitor统计服务的调用次调和调用时间的监控中心;
    服务治理中心 路由规则,动态配置,服务降级,访问控制,权重调整,负载均衡,等手动配置。
    自动治理中心 无,比如:熔断限流机制、自动权重调整等;

    4.2 Dubbox扩展特性

    1. 支持REST风格远程调用(HTTP + JSON/XML);
    2. 支持基于Kryo和FST的Java高效序列化实现;
    3. 支持基于Jackson的JSON序列化;
    4. 支持基于嵌入式Tomcat的HTTP remoting体系;
    5. 升级Spring至3.x;
    6. 升级ZooKeeper客户端;
    7. 支持完全基于Java代码的Dubbo配置;

    5. 参考资料与推荐阅读

    1. 分布式RPC框架性能大比拼
    2. 实施微服务,我们需要哪些基础框架?
    3. 微服务(Microservice)那点事
    4. Spring Cloud微服务框架主要子项目和RPC框架的对比
    5. 微服务、SOA 和 API:是敌是友?
    6. 微服务与SOA的实践应用对比
    7. 微服务架构的基础框架选择:Spring Cloud还是Dubbo?
    8. 微服务与SOA架构
    9. Web Service实践之REST vs RPC
    10. RPC好,还是RESTful好?
    11. Rpc和Rest接口,微服务之Rpc
    12. WEB开发中,使用JSON-RPC好,还是RESTful API好?

    个人公众号:程序员黄小斜

    微信公众号【程序员黄小斜】新生代青年聚集地,程序员成长充电站。作者黄小斜,职业是阿里程序员,身份是斜杠青年,希望和更多的程序员交朋友,一起进步和成长!专注于分享技术、面试、职场等成长干货,这一次,我们一起出发。

    关注公众号后回复“2019”领取我这两年整理的学习资料,涵盖自学编程、求职面试、算法刷题、Java技术学习、计算机基础和考研等8000G资料合集。

    技术公众号:Java技术江湖

    微信公众号【Java技术江湖】一位阿里 Java 工程师的技术小站,专注于 Java 相关技术:SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程,偶尔讲点Docker、ELK,同时也分享技术干货和学习经验,致力于Java全栈开发!

    关注公众号后回复“PDF”即可领取200+页的《Java工程师面试指南》强烈推荐,几乎涵盖所有Java工程师必知必会的知识点。

    展开全文
  • dubbo 3、依赖

    2018-07-30 09:36:00
    必须依赖 JDK 1.5+ 1 缺省依赖 通过 mvn dependency:tree > dep.log 命令分析,Dubbo 缺省依赖以下三方库: [INFO] +- com.alibaba:dubbo:jar:2.1.2:compile [INFO] | +- lo...

    必须依赖

    JDK 1.5+ 1

    缺省依赖

    通过 mvn dependency:tree > dep.log 命令分析,Dubbo 缺省依赖以下三方库:

    [INFO] +- com.alibaba:dubbo:jar:2.1.2:compile
    [INFO] |  +- log4j:log4j:jar:1.2.16:compile 
    [INFO] |  +- org.javassist:javassist:jar:3.15.0-GA:compile
    [INFO] |  +- org.springframework:spring:jar:2.5.6.SEC03:compile
    [INFO] |  +- commons-logging:commons-logging:jar:1.1.1:compile
    [INFO] |  \- org.jboss.netty:netty:jar:3.2.5.Final:compile
    

    这里所有依赖都是换照 Dubbo 缺省配置选的,这些缺省值是基于稳定性和性能考虑的。

    • log4j.jar 和 commons-logging.jar 2: 可以直接去掉,dubbo 本身的日志会自动切换为 JDK 的 java.util.logging 输出。但如果其它三方库比如 spring.jar 间接依赖 commons-logging,则不能去掉。
    • javassist.jar 3: 如果 <dubbo:provider proxy="jdk" /><dubbo:consumer proxy="jdk" />,以及 <dubbo:application compiler="jdk" />,则不需要。
    • spring.jar 4: 如果用 ServiceConfigReferenceConfig 的 API 调用,则不需要。
    • netty.jar 5: 如果 <dubbo:protocol server="mina"/><dubbo:protocol server="grizzly"/>,则换成 mina.jar 或 grizzly.jar。如果 <protocol name="rmi"/>,则不需要。

    可选依赖

    以下依赖,在主动配置使用相应实现策略时用到,需自行加入依赖。

    • mina: 1.1.7
    • grizzly: 2.1.4
    • httpclient: 4.1.2
    • hessian_lite: 3.2.1-fixed
    • xstream: 1.4.1
    • fastjson: 1.1.8
    • zookeeper: 3.3.3
    • jedis: 2.0.0
    • xmemcached: 1.3.6
    • jfreechart: 1.0.13
    • hessian: 4.0.7
    • jetty: 6.1.26
    • hibernate-validator: 4.2.0.Final
    • zkclient: 0.1
    • curator: 1.1.10
    • cxf: 2.6.1
    • thrift: 0.8.0
    • servlet: 2.5 6
    • bsf: 3.1 6
    • validation-api: 1.0.0.GA 6
    • jcache: 0.4 6
    1. 理论上 Dubbo 可以只依赖 JDK,不依赖于任何三方库运行,只需配置使用 JDK 相关实现策略
    2. 日志输出包
    3. 字节码生成
    4. 配置解析
    5. 网络传输
    6. JEE

    转载于:https://my.oschina.net/u/3916545/blog/1919218

    展开全文
  • 3、DubboProtocol的refer,在这之前依然会有wrapper加上listener和filter  DubboProtocol  public <T> Invoker<T> refer(Class<T> serviceType, URL url) throws RpcException {  // create rpc invoker. ...
    四、ReferenceBean<T>消费者端初始化过程
    1、ReferenceConfig的init()
       createProxy中也生成了registryUrl
       
       invoker = refprotocol.refer(interfaceClass, urls.get(0));
       同样这里会ProtocolListenerWrapper->ProtocolFilterWrapper->RegistryProtocol
       
    2、RegistryProtocol的refer
       先注册消费者信息/dubbo/interfaceName/customs/{customUrl}
       然后订阅
        RegistryDirectory<T> directory = new RegistryDirectory<T>(type, url);
    registry.register
    directory.subscribe
    当服务提供端地址有变化时候,注册中心会通知订阅者,更新

    RegistryDirectory的
    public synchronized void notify(List<URL> urls) 
    ->refreshInvoker->toInvokers
    invoker = new InvokerDelegete<T>(protocol.refer(serviceType, url), url, providerUrl);
    此时的url是从注册中心拿到的providerUrl,它的protocol为dubbo
    所以会使用DubboProtocol的refer


    3、DubboProtocol的refer,在这之前依然会有wrapper加上listener和filter
       DubboProtocol
       public <T> Invoker<T> refer(Class<T> serviceType, URL url) throws RpcException {
            // create rpc invoker.
            DubboInvoker<T> invoker = new DubboInvoker<T>(serviceType, url, getClients(url), invokers);
            invokers.add(invoker);
            return invoker;
        }

    其中getClients会启动客户端连接服务端,getClients还会根据配置是否使用共享连接,还是每个服务都有一个连接

    4、getClients->initClient->Exchangers.connect->Transporters.connect->Client
       最后就得到了NettyTransporter->NettyClient
       NettyClient的doOpen()就是netty客户端连接服务端过程。
       
    5、回到RegistryProtocol的doRefer
       return cluster.join(directory);
       这个cluster集群方式,可选:failover/failfast/failsafe/failback/forking
       一般还会配置Mock
       那么将会得到MockClusterInvoker->FailoverClusterInvoker->Directory
       
    6、得到invoker后在ReferenceConfig的createProxy最后
        // 创建服务代理,会对接口生成代理类,然后注册到spring容器中,使用时候获取到的就是代理类
        return (T) proxyFactory.getProxy(invoker);
    展开全文
  • 不用spring的包,用dubbo原生的包,添加包完成之后,刷新maven工程 1.1 dubbo的包 <dependency> <groupId>com.alibaba</groupId> <artifactId>dubbo</artifactId> <version>...
  • 3dubbo

    2019-10-09 15:32:20
    dubbo的demo https://blog.csdn.net/aiguo94/article/details/80434059 基于dubbo的项目开发springboot https://www.jianshu.com/p/0d33e3a8c0ca Dubbo 集成 Zookeeper面试题整理 ...
  • Dubbo

    2020-10-24 12:27:05
    DubboDubboDubbo 4-1 互联网项目架构 01-今日内容 02-相关概念-互联网项目架构目标-特点 03-相关概念-互联网项目架构目标-目标 04-相关概念-集群和分布式 ...4-3 dubbo高级特性 11-dubbo高级特性-dub
  • dubbo

    2020-03-12 11:58:17
    目录 1. 什么是Dubbo? 2. dubbo特性 2.1 面向接口代理的高性能RPC调用 ...3.dubbo配置 1. 什么是Dubbo? 阿里巴巴中间件开源的一款高性能、轻量级的开源Java RPC(是远程过程调用Remote Proced...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,238
精华内容 2,895
关键字:

dubbo3