有哪些网站结构是不合理的,手机端网页模板免费,南非网站域名,作文网入口摘要#xff1a; Dubbo 在过去一段时间疏于维护#xff0c;去年阿里高调宣布重启 Dubbo 开源之后#xff0c;社区里问的最多的问题是#xff0c;这次开源与上次有什么一样#xff0c;还有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么关系#xff1f;希望通过这次Dubb…摘要 Dubbo 在过去一段时间疏于维护去年阿里高调宣布重启 Dubbo 开源之后社区里问的最多的问题是这次开源与上次有什么一样还有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么关系希望通过这次Dubbo沙龙的分享能够解答这些问题。
本文章是根据朱勇老师在上海Dubbo沙龙的演讲稿进行整理意在为大家展示最真实、最一手的沙龙技术干货。前言大家好非常荣幸有机会和大家做这个分享。我先做个自我介绍我叫朱勇来自阿里巴巴中间件团队主要工作在应用容器、微服务、RPC几个领域。我是 09 年加入阿里13年加入中间件团队。今天的话题是与 Dubbo 的开源现状和未来规划我们知道Dubbo 过去一段时间疏于维护去年阿里高调宣布重启 Dubbo 开源之后社区里问的最多的问题是这次开源与上次有什么一样还有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么关系希望通过这次的分享能够解答这些问题。这次分享包含以下几个环节Dubbo 基本原理、Dubbo 社区、开源现状、以及后续规划几个部分。Dubbo 工作原理考虑到有些同学可能对 Dubbo 不太熟悉我先简单介绍下 Dubbo 的工作原理和架构。简单的说Dubbo 是 基于 Java 的 RPC 框架。Dubbo 工作分为 4 个角色分别是服务提供者、服务消费者、注册中心、和监控中心。按照工作阶段又分为部署阶段和运行阶段。其中部署阶段在图中以蓝色的线来表示代表服务注册、服务订阅的过程而运行阶段在图中以红色的线来表示代表一次 RPC 的完整调用。部署阶段中服务提供方在启动时在指定的端口上暴露服务并向注册中心汇报自己的地址服务调用方启动时向注册中心订阅自己感兴趣的服务。运行阶段注册中心先将地址列表推送给服务消费者服务消费者选取一个地址向对端发起调用。在这个过程中服务消费者和服务提供者的运行状态会上报给监控中心。其实这里讲的基本原理套用到任何一个成熟的服务框架都是合适的但是 Dubbo 在框架设计上有着自己的设计哲学。这里是 Dubbo 的整体架构图。首先这张图看起来很复杂、信息量很大。我先介绍一下这张图的解读方式。这张图从左往右看分为两部分左半边蓝色背景的部分代表服务消费者右半边绿色背景的部分代表服务提供者。从上往下看又分为九层。左边九层按功能来划分又被分为了三大类分别是面向用户的 Biz 层、框架核心 RPC 以及负责远程传输的 Remoting右边按面向人群又划分为了两类上面两层是面向用户的 API而下面七层是面向扩展提供者的 SPI。图中的线代表对象与对象之间不同的关系紫色代表继承黑色代表依赖蓝色虚线代表服务注册、服务订阅的过程也就是上面讲的部署阶段红色代表一次完整的 RPC 调用也就是运行阶段。我们顺着红色的线来看下一次完整的 RPC 调用是如何进行的。首先从图的左边开始服务消费者从 Proxy 层发起一次 RPC 调用Dubbo 从 Registry 层拿到服务的地址列表再通过 Cluster 层选择其中的一个作为目标地址再流经 Protocol 决定的执行链最后将服务信息包括要调用的服务名、方法名、参数等序列化再经过应用协议编码通过 Transport 层发送到网络上。右边的服务提供者从网络上收到数据以后从下往上依次通过应用协议解码、反序列化得到要调用的服务信息再经由执行链最终通过 Invoker 找到目标服务的目标方法执行并返回结果。解读完 Dubbo 的架构图再来看看架构图中体现的设计原则。Dubbo 秉承高内聚、低耦合的设计这一点体现在架构图中九层的清晰划分上并且也体现在依赖的方向上。黑色的线条的方向永远是从上指向下没有循环依赖和反向依赖的出现。Dubbo 还有一个很重要的设计哲学就是平等对待第三方的扩展即 Dubbo 内建的功能也是通过同样的扩展机制提供出来的第三方的扩展和内建功能可以相互取代。正是由于 Dubbo 将第三方扩展当成框架的一等公民为未来基于这个机制建立生态带来了可能性。这一点我们在后面规划部分进一步展开。Dubbo 社区Dubbo 社区我想从战略、社区、生态和回馈四个方面讲一讲。首先阿里巴巴将开源提到了新的战略高度去年云栖大会上阿里云宣布了加大技术投入、拥抱开源的策略。阿里巴巴在开源领域耕耘多年目前在 Github 上有 150 多个开源项目总 Star 数在 17 万并且 Alibaba 这个 Group 在全球的排名进入前十。这其中有不少我们大家耳熟能详的项目包括 JStorm, RocketMQ, FastJson, Druid, Weex当然还有我们 Dubbo。其中 JStorm 和 RocketMQ 成为 Apache 的顶级项目而 Weex 和 Dubbo 也正在 Apache 中孵化。社区方面Dubbo 这两年疏于维护很多开发者提交的 Pull Request 和 Issue 没有得到及时的解决一些公司不得不维护 Dubbo 私有分支版本分化严重导致社区无法 分享这些分支上的成果。我们希望改变这一点让整个社区都能享受到开源的好处。一个活跃的社区将会产生一个繁荣的生态而一个繁荣的生态将会普惠所有使用 Dubbo 的人最终形成社区和生态共同发展的良性循环。另外在阿里内部负责 Dubbo 的团队就是负责服务框架的团队我们在大流量、大规模集群、服务治理领域有着丰富的实践这些会有计划地回馈给社区。这里强调一点为了打消社区对 Dubbo 未来发展的顾虑我们做出了把 Dubbo 捐献给 Apache 基金会的决定并且在2018新年之前Dubbo 正式进入 Apache 孵化。Apache 认为 社区的重要性大于代码非常注重多样性强调一个项目需要有多个公司和个人贡献者参与避免被一家公司左右所以现在 Dubbo 的发展完全是按 Apache Way 社区化的方式来运作的个人贡献者的参与方式可以是多种形式除了贡献代码外还可以通过报 Issue、增强文档、参与邮件讨论等方式只要让社区看到你的贡献你就可以一步一步从 Contributor 成为 Committer再从 Committer 成为 PMC Member。所以希望 大家多参与 Dubbo 的社区互动多分享你们在实践中的经验反馈碰到的问题只有你们的参与Dubbo 的未来才有可能成功。这里顺便分享下 Dubbo 进入 Apache 孵化的历程希望对其他要把自己的项目捐献给 Apache 的小伙伴们有帮助。进入 Apache 分为三个阶段准备阶段、孵化阶段和毕业阶段。准备阶段需要做的事情有找到愿意帮助孵化的导师向 Apache 提交进入孵化的申请经过导师们讨论并投票如果通过的话就可以进入孵化。孵化阶段分为两大环节第一个环节是公司和个人签署协议向 Apache 移交代码和知识产权目前 Dubbo 已经完成了第一个环节。之后就是在导师的指导下按照 Apache 的规范 做版本迭代、运营社区、发展更多的 Committer如果最终通过了成熟度评估就可以顺利毕业成为 Apache 的顶级项目。开源现状Dubbo 开源的现状我打算从数据、用户、项目 三个维度分别阐述。数据方面是这样从去年七月份重启开源到目前为止Dubbo 在 Github 上的 Star 数增长了 115% 达到了 1.9 万目前在 Github Java 类项目中排名第 7 位在去年开源中国举办的 2017 最受欢迎的开源项目中 Dubbo 和阿里巴巴其他三款软件 FastJson、Druid、RocketMQ 共同入选。用户方面 Dubbo 的用户主要分为三类第一类是以阿里巴巴、滴滴、当当为代表的互联网企业第二类是向互联网转型的大型企业如中国工商银行、中国电信和中国人寿等第三类是使用 Dubbo 作为服务化方案的 ISV包括亚信和文思。在这些企业中有些维护着自己的私有分支有些企业的员工积极参与 Dubbo 的建设在这次进入 Apache 孵化的过程中我们邀请了当当、去哪儿、微店的员工成为初始成员6月份刚刚发展了有赞的一位开发者成为 Dubbo Committer。今年我们打算在北上广深、以及杭州等地举办几次 Dubbo 开发者沙龙这是第二站。沙龙的主题是面向工程师的包括架构分析、源码解读、未来规划、案例分析等内容没能来到现场的也没有关系整个沙龙会全程通过网络直播。这几个月我们在 Dubbo 上的工作 围绕一个目标 进行的就是如何才能重新赢得社区的信任。为此我们首先要打好基础包括重新建设了网页和文档全面更新了三方的依赖在打好基础的前提下我们又确立了版本发布策略采取特性版本和维护版本并行每个月至少发布一个版本的节奏迄今为止我们已经发布了 7 个维护版本和 2 个特性版本。在这些版本中我们重点考虑了社区呼声最高的特性其中就有 Spring Boot 的支持和对 REST 服务的支持。下面这些事情是我们已经在进行中的绝大多数都是我们后面要讲的规划中的事项比如核心增强中的异步 API、Metrics、熔断生态中的多语言客户端、Dubbo Mesh还有对 Dubbo OPS 的增强这里特别提一下 Dubbo OPS现在我们已经将 OPS 中对 WebX 的依赖去除并基于 Spring Boot 2.0 进行了重新适配代码已经合并到主干接下来还会将原先 Dubbo Admin 以及 Dubbo Monitor 进行合并同时会适配更多的注册中心 Registry另外我们在社区发起了关于全新 Logo 及官网的讨论目的是想通过全新官网的建设更好的将文档、博客、活动等信息呈现给社区和开发者新的官网在设计开发中接下来会上线请大家保持关注。最后总结一下Dubbo 重启开源的这几个月总的来说是成功的背后主要有两点原因一是公司层面的支持其中有工程师团队的努力也有宣传运营上的投入二是依托Dubbo 的群众基础我们这几个月的工作重新赢得了社区的信任大家也开始关注 Dubbo 的发展。下面我会从核心和生态两部分谈下 Dubbo 未来规划的 思考。未来规划首先聊下规划的 整体思路。Dubbo 后续的规划主要是要 解决好两个问题。第一个问题是未来出现的技术趋势哪些是和 Dubbo 紧密相关的如果 Dubbo 不跟随就有可能在未来被淘汰的问题第二个问题是 Dubbo 本身定位的问题也就是只做框架够不够的问题。关于第一个问题我们看到的是越来越多的应用从单体架构转向微服务架构微服务的理念也深入人心还有就是各大云厂商开始宣传云原生的概念一些应用也开始向云上迁移我们认为 微服务和 云原生 这两个技术趋势上值得 Dubbo 关注的。第二个问题 Dubbo 自身的定位Dubbo 核心要保持技术上的领先性我们会重点关注性能、大流量、大规模集群领域的挑战但是光有这样是远远不够的在保持核心演进的同时我们还需要围绕 Dubbo 核心发展生态将 Dubbo 做成一个服务化改造的整体方案。Dubbo 核心的规划又 分为三块第一块包括模块化和元数据通过这两块的优化来解决适应未来技术方向的问题也就是微服务和云原生具体来说目前 Dubbo 服务治理与网络传输耦合严重通过进一步的模块化工作可以为 Dubbo 成为服务网格中的数据面板做好准备元数据目前既包含服务注册信息也包含服务配置信息将两者分离可以更清晰的分开注册层和配置层为适配微服务的注册中心和配置中心 打好基础。第二块是关于我们如何把阿里在服务治理方面的经验回馈给社区其中包括了这里的路由策略、大流量和大规模在路由策略中我们打算引入多机房路由、参数路由、灰度路由等策略在大流量方面 重点考虑 熔断、限流、隔离的支持在大规模集群方面需要解决超大规模地址列表对 CPU、内存带来的压力最后一块是进一步的增强异步化包括对 CompletableFuture 的支持以及跨进程 Reactive Stream 的预研目前 Reactive Stream 在内部 Dubbo 3.0 中正在孵化压测表明这项技术对于提升 CPU 利用率和系统的吞吐率很有帮助。回想一下刚才的架构图除了上面的两层下面的七层都是可扩展的。Dubbo 生态的建设我们的思路是利用核心的扩展能力尽可能多的提供开箱即用的扩展实现。这里我们按照架构图中的层次划分归纳了每一层可能提供的扩展实现。其中蓝黑色的代表 Dubbo 框架已经支持的绿色部分代表这次重启开源之后新加入以及正在进行中的而橙色的部分代表我们计划在未来加入的。从下往上我们看下未来会加入的支持我们在序列化层计划加入对 Protobuf 的支持在 Transport 层加入对 Http2 的支持在 Protocol 层加入对 gRPC 的支持在 Cluster、Router、Load Balance 代表的服务治理层计划加入阿里对服务治理方面的实践其中包括了熔断、多机房路由、灰度路由以及更丰富的负载均衡策略。再往上通过元数据的优化我们可以更清晰的分开注册层和配置层从而可以在注册层加入更多的对微服务注册中心的支持比如 EurekaConsul在配置层也可以开始支持配置的动态推送当然在这两层我们也会提供对阿里体系中的注册中心 Config Server、配置中心 Diamond 的支持这两个产品就是后续郭平老师给大家分享的 Nacos。最顶上是对 API 的支持我们会做对 Spring Cloud 的适配。我们有了不断向前演进的核心丰富的扩展生态我们还需要解决 Dubbo 服务与外界互通的问题。这里的互通有两方面的含义。第一是 Dubbo 服务与外围系统互通第二是异构系统如何调用 Dubbo 服务的问题。首先说下外围系统对接的问题外围系统也分为两类图中草绿色部分包括了 Dubbo OPS、Test Server、Mock Server、 Swagger Server无非就是解决服务如何查询服务治理规则如何配置如何测试服务开发阶段如何解决上下游依赖服务的 API 支持等问题这些问题与 Dubbo 服务紧密相关我们计划自己来提供这方面的支持。再看图中橙色的部分包括了服务注册中心、配置中心、鉴权中心链路追踪和监控中心这些系统外面有很多开源和商业的选择我们的思路是尽可能多的提供与他们的适配为用户带来开箱急用的体验。值得一提的是这一块的建设是双向的目前 Spring Cloud Sleuth 主动支持了 Dubbo。谈到异构系统如何调用 Dubbo 服务本质上是多语言支持的问题。要解决多语言调用无非有两种做法一种是通过代理方式来调用代理根据部署形式的不同又分为中心化的 API Gateway 方式和本地部署的 Sidecar 方式Sidecar 方式我们在下张片子里进一步讨论对于 API Gateway 方式只需要 Dubbo 服务可以按照 Json-RPC 或者 REST 的方式暴露服务就好。另一种调用方式就是原生语言客户端要支持的语言包括了常用的 PythonNodePhpGo 等等这一块的挑战和工作量都很大我们的思路是和社区共建。目前千米网的同学已经开始把他们的 Node 和 Python 的客户端贡献给社区。Go 和 Php 的版本也会很快提供。规划的最后部分我想聊聊 Dubbo Mesh刚才谈到互通问题的时候解决多语言调用的一种方式是通过 Sidecar谈到 Sidecar 就不得不从云原生讲起。目前各大云计算厂商开始定义云原生鼓励用户将应用往云上迁移。云原生的定义每家都不太一样但是其中可以看到有这么两个趋势。一个是云计算场景里多语言支持是强诉求基于单一语言的架构和方案会有很大的局限性另一个是原来与应用共生的服务治理能力开始从应用中解耦出来并下沉为平台的基础能力这样做的好处是应用开发更简单、应用更轻、多语言支持也变得容易服务治理能力可以透明升级。这一块就是 Linkerd 率先提出的服务网格的概念。Dubbo 通过进一步的模块化工作可以把服务治理能力单独剥离出来独立部署成为服务网格中的数据面版我们称之为 Dubbo Mesh它负责接管由本地所有 RPC 流量并负责与外围的注册中心、配置中心对接。在服务网格下一次 RPC 调用就会变成左边草绿色的 Dubbo RPC 发起一次调用请求会发给和他部署在一起的 Dubbo MeshDubbo Mesh 又会把这个 RPC 请求转发到对端的 Dubbo Mesh对端的 Dubbo Mesh 又会将收到的请求发给和他部署在一起的 Dubbo RPC, 也就是图中右边的橙色部分。服务网格上我们非常关注的一个方向目前我们正在做技术选型相信很快就会有大家见面。最后总结一下通过核心、扩展、互通三方面的建设我们相信 Dubbo 体系可以成为服务化改造的国内首选方案并且能够很好的适应微服务和云原生这两个技术趋势。原文链接本文为云栖社区原创内容未经允许不得转载。
