Dubbo Ecosystem - 从微服务框架到微服务生态

时间 2019-12-05

原文原文链接

从微服务框架到微服务生态，这是微服务发展的必然趋势，也是Dubbo社区知足开发者更高效的构建微服务体系指望的使命和担当。git

近期，Apache Dubbo PPMC 望陶（社区昵称：ralf0131）作了主题为《首次直播揭秘 Apache Dubbo Ecosystem：从微服务框架到微服务生态》的直播分享。本文整理自这次分享，经过该内容，您将了解到Apache Dubbo Ecosystem的：github

产生背景
生态定位和组件选择原则
体系总览和层次结构
和Spring Cloud之间的联系
直播问答精选

产生背景

微服务的流行，使得愈来愈多的用户选择从单体应用向分布式应用进行转型。在这个过程当中，有许多企业选择了Dubbo做为分布式应用开发的基础组件。可是随着微服务化的逐渐深刻，咱们也发现，Dubbo目前提供的能力逐渐的没法知足开发者构建完整微服务的需求。开发者缺乏一套完整的围绕Dubbo的微服务解决方案，例如API gateway、熔断限流、分布式监控和分布式事务等方面。开发者须要自研，或者调研各种开源的框架。这耗费了大量的时间和精力，且在整合的过程当中，各种兼容和适配问题也影响到微服务的落地。spring

所以，咱们决定围绕Dubbo打造一整套微服务的解决方案，涵盖微服务开发过程当中的各方面。这里面的项目都是会通过Dubbo社区共同评估，和Dubbo高度集成，且在生产中获得过验证的项目(这里的项目不只仅是阿里巴巴开源的)，咱们把这个生态称之为Apache Dubbo Ecosystem。但愿经过这个生态帮助用户下降微服务实施的难度，加快业务创新进程。apache

Dubbo做为一款高性能RPC框架，经过良好的扩展机制，已经造成了丰富的核心RPC生态。编程

从上图中能够看到，图中黑色部分为Dubbo重启以前的RPC生态，绿色表明重启维护以来新增的生态，红色是将来计划添加的模块。这里面主要包括：架构

编程模型支持Spring-boot方式
服务注册中心发现支持Nacos，etcd
配置中心支持Apollo，Nacos
系统高可用支持Sentinel，Hystrix
负载均衡支持一致性Hash
路由规则支持标签路由
协议层支持REST, JsonRPC, Avro, Thrift
序列化层支持fst, kyro
传输层支持Netty4

但这里面有一些问题，开发者只接触到API，以及服务注册和配置这一层，接触不到大部分底层生态的组件，所以没法直接享受到这些底层组件的技术能力。负载均衡

可是，开发者在实际的微服务开发过程当中，须要的不只仅是RPC和服务注册发现，而是须要一整套的微服务能力，例如API gateway、熔断限流、分布式监控和分布式事务等。但在这些方面，开发者因为没有事实上的推荐方案，调研和选型都比较痛苦，甚至会遇到个别开源项目再也不继续维护给现有架构带来影响的窘境。因此如何经过Dubbo把这些微服务领域的其余能力整合起来，造成一套完整的解决方案，成为Dubbo社区一个亟待解决的问题。框架

生态定位和组件选择原则

起初，Dubbo这个品牌咱们定义为一款RPC框架，而事实上，从业界开发者的反馈和调研来看，Dubbo的使用者早已脱离了单纯的RPC层面，而是将其做为一个微服务的架构基础来对待。运维

所以，咱们对Dubbo的定位作过一次更新，Dubbo is more than a RPC framwork. Dubbo不只仅是RPC框架，而是一个微服务框架，以帮助开发者快速构建高性能的微服务应用。socket

在此基础之上，咱们作了进一步的演进，即从微服务框架演进到微服务生态。但Dubob不可能把微服务领域的全部能力从新再实现一遍，一是资源上没法保证，二是即使完成了，开发者也不必定会采用。最重要的是Dubbo已经社区化，Dubbo Ecosystem也应该由社区的方式来实现。所以，经过和开源的成熟方案作集成，造成一套完成的微服务领域生态，组成Dubbo Ecosystem，开发者无需为现有的系统作出过的的修改，就能快速开发微服务应用。

关于组件选择的原则，和哪些组件进行集成，并非大而全的照单全收，而是通过社区挑选，符合如下三点：

已经具有很好的开发者群体和影响力的组件
在生产领域下获得过验证的组件
在某一方面成为标准或者事实标准的组件

只有知足上述条件，才会被归入Dubbo Ecosystem。一方面用于减小用户选型的成本，另外一方面Dubbo Ecosystem的组件也不会由于太过庞大而失去意义。总而言之，Apache Dubbo Ecosystem 是围绕 Apache Dubbo 打造的微服务生态，是通过生产验证的微服务的最佳实践组合。

体系总览和层级结构

做为一个微服务生态，它须要各个方面的组件共同组成。首先，咱们须要明确一个微服务生态包含哪些组件才能称得上生态，以及各自的分工和重要程度。通过梳理，有了如下的Dubbo Ecosystem的层级结构图，包含从L0、L一、L2和L3的4个层级。

L0层包括了Dubbo的核心RPC和Service Mesh的能力。

RPC的核心能力方面，主要的演进方向是支持Reative，提供响应式编程的能力，提高系统总体的吞吐率，并基于一些先进的框架，例如RSocket来实现。

Service Mesh在解决多语言开发维护成本方面具备很大的优点，另外经过把通用逻辑下沉，把业务逻辑作薄作轻，开发者将释放更多精力专一到微服务业务逻辑开发中，而且不被语言所限制，所以Service Mesh也是L0层须要支持的一个重点。Dubbo Mesh最新的进展是data plane基于Envoy进行了扩展，已经可以识别到Dubbo的调用数据，而且可以上报Istio，而后基于这些数据执行后续一系列的动做，例如经过K8S进行自动扩容。

L1层包含了服务的注册发现、配置管理、系统高可用Reliability和Metrics的数据统计。

在服务注册发现层面，ZooKeeper一直是默认的配置，可是咱们也发现，Dubbo目前的URL设计使得注册到ZooKeeper上的信息愈来愈多，里面有很是多的重复，随着集群规模的扩大，ZooKeeper逐渐成为瓶颈。在Dubbo 2.7中，已经支持了注册中心和配置中心的分离，使得Dubbo拥有了支持主流注册中心和配置中心的能力，注册中心的支持列表包括ZooKeeper、Nacos和Etcd，配置中心的支持列表包括Apollo和Nacos，后续还将对接更多主流的注册发现和配置管理产品。

在系统高可用Reliability层面，阿里巴巴开源的熔断限流组件Sentinel已经在阿里内部普遍使用多年，在熔断限流，流量控制，过载保护等都有很是优秀的表现，而且已经和Dubbo有了很是好的集成。同时，也支持Hystrix。

在Metrics层面，当前Dubbo的统计数据，尚未标准化，这块迫切须要一个标准Metrics统计实现。据了解，阿里巴巴内部流行的Metrics度量库（内部名称：Ali-Metrics）将会在2019年对外开源，做为集团Java应用埋点的事实标准，已经支持的集团内部业务包括：Sunfire监控、流量调度、Ali360、应用中心、菜鸟棱镜和无人值守发布等项目，待经过评估，它将成为Dubbo默认的Metrics度量实现。有了标准的Metrics实现，Dubbo接下来还会对接主流的开源监控系统，例如Prometheus。

若是说L0和L1是RPC领域的核心组件，那么L2层开始则更加贴近微服务领域。L2层包含API Gateway、分布式跟踪Tracing、分布式诊断Diagnosis和分布式事务Transaction等。

API Gateway：协议转换是Dubbo做为一个微服务框架最被诟病的地方。API Gateway除了负载均衡和熔断限流等能力外，其最核心的能力是协议转换。例如，一个客户端如何经过HTTP可以请求一个Dubbo服务。不管是在内部服务迁移、跨语言调用，仍是开发给外部第三方接口等场景，这都是比较明显的需求。业界有Spring Cloud Gateway、Zuul2和Kong等方案，目前倾向于和主流的方案进行集成。
分布式跟踪：如今已经支持的系统有Zipkin、Spring Cloud Sleuth和Skywalking等，后续会向业内标准靠拢，支持OpenTracing。
分布式诊断：将来会结合Arthas+Tracing的能力，进行分布式应用的快速问题诊断，经过分布式追踪系统，快速定位到某台单机，而后结合Arthas的能力对单点问题进行快速诊断。另外，Arthas 4.0将会演进到一个字节码框架，为第三方系统提供无侵入的、自定义埋点的能力。

总的来讲，L2层的组件的思路将是由Dubbo社区主导，联合其余社区共建。

L3层的组件则更加开放一些。Scheduling、Event Driven、Authenthentication和Function等方面都尚未特别明确的方案出来，将会由第三方社区主导，造成开放生态。以Event Driven为例，社区主导使用的是RocketMQ，RocketMQ已经发布了C、C++、Python和Go客户端，并支持在Spring Boot中快速集成RocketMQ，同时支持Spring Message规范，方便开发者从其它MQ快速切换到RocketMQ。

在运维侧，Dubbo Ecosystem的数据会互相打通，各组件统一暴露Observability能力，最终经过Dubbo OPS进行展现和管控。例如，能够经过Dubbo OPS看到Dubbo Ecosystem中的熔断限流组件提供的熔断和限流数据，并对限流阈值进行管控等。

在开发侧，经过深度融入当前流行的编程模型，例如Spring Cloud/Spring Boot，帮助开发者快速上手，进行微服务开发。同时考虑提供IDE插件等，轻松构建脚手架，进一步优化开发体验。

经过上述层次结构的拆解，叠加上开发和运维侧提供的能力，逐步造成了一套完善的微服务体系。

在微服务开发中，多语言共存是一个常态，Dubbo社区一直重视多语言客户端的支持，目前已经实现了Node.js、PHP、Python和Go 4类语言，详细的支持列表能够参照上图。在Dubbo Ecosystem中，除了支持Java 微服务开发外，其余语言会继续由社区来主导建设。为了评估多语言实现的成熟度，咱们计划提供一个多语言成熟度评估能力矩阵，经过标准的TCK测试用例，来对各类语言的能力进行验证，经过TCK意味着已经达到了必定成熟度，能够放心的使用。

和Spring Cloud之间的关系

常常会有开发者会拿Dubbo和Spring Cloud进行对比，在这里咱们再次强调一下两者以前并无竞争关系。Dubbo能够经过纯API、Spring容器启动（XML）和Spring-boot启动（注解）等多种方式启动，从Dubbo开源以来，和Spring一直有着紧密的集成。Spring Cloud也是开发者们赖以进行微服务开发的编程方式，帮助开发者快速搭建微服务应用是Dubbo的宗旨，所以Dubbo会尽量的集成到Spring Cloud开发模式当中，开发者可使用Spring Cloud轻松开发Dubbo微服务应用。

具体而言，阿里巴巴的开源套件将以Spring Cloud Alibaba的形式和Spring Cloud编程模型进行深度对接，而Dubbo的RPC将做为核心RPC组件被集成，同时，Dubbo Ecosystem中的组件包括服务发现和配置Nacos、熔断限流Sentinel和消息组件RocketMQ等都会被集成进Spring Cloud Alibaba中。另外一方面，Spring Cloud Alibaba支持对接阿里云上的服务例如OSS、ACM和SchedulerX等等。

这里的深度集成主要包括两个方面，一方面Dubbo自身的服务经过REST协议暴露，自动和Spring Cloud中的组件，例如Feign和Ribbon等的集成。另外一方面，Dubbo框架中的组件能够被进一步抽象，变成Spring Cloud生态中的一环，例如Dubbo的load balance组件能够单独抽出来，提供相似Ribbon负载均衡一样的能力。

总结

一、Apache Dubbo Ecosystem 是围绕 Apache Dubbo 打造的微服务生态，是通过生产验证的微服务的最佳实践组合，将把微服务领域中具有很好影响力的，在生产领域下获得过验证的，或在某一方面成为事实标准的组件归入生态。

二、Apache Dubbo Ecosystem将围绕Dubbo打造4层体系，L0和L1专一RPC核心，L2专一微服务核心，L3围绕微服务周边打造丰富生态。

三、Apache Dubbo和Spring Cloud没有竞争关系，Apache Dubbo Ecosystem中的组件将以Spring Cloud Alibaba的形态深度集成到Spring Cloud体系当中，帮助用户提高微服务开发体验。

直播问答精选
Q1：Dubbo Ecosystem会有独立的官网么？

A1：Dubbo Ecosystem目前不会单独设立官网，咱们会在 dubbo.apache.org 上线一个入口，介绍Dubbo Ecosystem的全部组件、各自的关系及推荐的整合方案。

Q2：请介绍下Dubbo Ecosystem的roadmap？

A2：Dubbo Ecosystem的发展将分为4个阶段，第一阶段是补全生态内的组件、Spring Cloud Alibaba对Dubbo 的支持、在官网创建入口、创建Dubbo OPS对微服务进行统一管控，第二阶段支持云原生，第三阶段引入Rsocket框架，第四阶段支持更多语言，不只在RPC层提供多语言的支持，也会在整个微服务层提供多语言支持。

Q3：Dubbo2.7何时发布，Dubbo2.7是否兼容2.6和Dubbox（2.8.4），Dubbo3.0什么会有预览版？

A3：Dubbo2.7目前还在测试中，测试经过后会发到社区进行讨论和投票，而后再发布，预计1月会发布。Dubbo2.7会对2.6进行兼容，Dubbox已经合并到Dubbo，因此也是兼容的。在Github社区，Dubbo3.0的分支已经开出来了，Dubbo3.0会聚焦在Reative的实现，目前在调研的是RSocket框架，如今尚未肯定的发布计划。

Q4：Dubbo in Action的书何时出版？

A4：这个问题是社区的issue之一，并被置顶。该书的章节已经肯定了，但各章节的内容还没写完，咱们但愿社区的同窗能够参与进来一块儿来写，认领相关的章节，提交PR，成为该书的做者之一。该书的出版目的是为了帮助开发者更好的使用Dubbo来构建微服务体系。

直播嘉宾：望陶，社区昵称ralf0131，Apache Dubbo PPMC Member，Apache Tomcat PMCMember，阿里巴巴技术专家，同时做为2018双11中间件队长及稳定性负责人参与了今年的双11的全程支持，平时会关注大规模分布式系统、RPC框架和微服务领域。