Dubbo Cloud Native 之路的实践与思考

摘要： Cloud Native 应用架构随着云技术的发展受到业界特别重视和关注，尤为是 CNCF（Cloud Native Computing Foundation）项目蓬勃发展之际。Dubbo 做为服务治理的标志性项目，天然紧跟业界的潮流，拥抱技术的变化。

Dubbo Cloud Native 实践与思考

Cloud Native 应用架构随着云技术的发展受到业界特别重视和关注，尤为是 CNCF（Cloud Native Computing Foundation）项目蓬勃发展之际。Dubbo 做为服务治理的标志性项目，天然紧跟业界的潮流，拥抱技术的变化。本次分享的议题包括介绍 Apache 孵化项目Dubbo Spring Boot Project 以及汇报 Dubbo 与 Cloud Native 整合过程当中的一些实践与思考，如适配 Spring Cloud 、服务发现、服务网关、服务跟踪以及监控等。

注：为了读者的阅读方便和习惯，本文字稿将在演讲内容的基础上作出适当的调整。

自我介绍
马昕曦（小马哥），阿里巴巴中间件技术专家，十余年 Java EE 从业经验，Dubbo 维护者、架构师以及微服务布道师。目前主要负责阿里巴巴集团微服务技术实施、架构衍进、基础设施构建等。重点关注云计算、微服务以及软件架构等领域。经过 SUN Java（SCJP、SCWCD、SCBCD）以及 Oracle OCA 等的认证。

主要议程
今天我很是荣幸地与你们一块儿讨论关于 Dubbo Cloud Native 相关议题，本次议题紧扣“实践与思考“两个关键字，主要的议程包括：

Cloud Native 基础设施
Cloud Native 架构选型
Dubbo Cloud Native 准备
Cloud Native 基础设施
关于 Cloud Native 的定义，不一样的云平台可能给出的内容存在差别。此处，我向你们介绍目前最热门的 CNCF 的定义：

”CNCF Cloud Native Definition v1.0“ 中的描述：

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

相对于其余学术流派，CNCF 的 Cloud Native 定义更为具体，偏向于软件技术。这一点咱们从文中的一些关键字可以明显地体会到，如关键字 "Containers（容器）"、"service meshes"、”microservices（微服务）“等。一般，开发人员较为关注的 Cloud Native 基础设施为：“服务发现”、“负载均衡”、“服务网关”、“分布式配置”、“服务熔断”以及“跟踪监控”，如图所示：

因为 PPT 格式的限制，此处我将“链路跟踪”与“服务监控” 并陈为“跟踪监控”。接下来，咱们进入“服务发现”的讨论。

服务发现（Service Discovery ）

随着微服务架构（MSA）受到不一样规模企业的青睐，服务治理的实施逐渐被提上基础设施改造的议程。尽管这些概念在 SOA 时代已经提出，然而引发业界普遍关注应归功于微服务。服务发现（Service Discovery ）做为服务治理的核心特性，一般也将服务注册（Service Registration）一并讨论。不管是服务发现，仍是服务注册，在具体落地实施时，它们必须面对技术选型的问题。在座的各位，包括我，大多数是 Java 程序员，天然关心 Java 的技术方案。目前，Java 社区最为津津乐道的方案莫过于 Spring Cloud，搭配 Netflix OSS 组件 Eureka，帮助 Spring Boot 应用快速搭建服务发现体系。其中，Eureka Server 做为注册中心服务器，Spring Boot 应用整合 Eureka Client 向 Eureka Server 注册。实际上，Spring Cloud 除了整合 Netflix Eureka 做为服务发现以外，还提供了 Apache Zookeeper 和 HachiCorp Consul 的实现，因此这三种方案出如今当前页面：

其中还包括 Redis 和 Apache Curator，前者是 Dubbo 的服务发现实现方案之一，然而小马哥并不建议使用 Redis 做为注册中心，仍是保持它缓存中间件的单纯性较好。而 Curator 做为 Zookeeper Java 客户端类库，它不但可用在 Dubbo，并且其扩展项目 Curator Service Discovery 也是 Spring Cloud 整合 Zookeeper 做为服务发现的关键基础设施。或许你们思考以上方案应该如何选型的问题。

如何选择
Eureka
当服务发现选型时，Netflix Eureka 或许是在开发人员脑海中复现的首选方案。然而 Eureka 在阿里大规模实践时，它的表现并不理想，当 Eureka 客户端服务实例数量达到必定时，Eureka Server 时常会出现服务不可用的状况，主要的问题集中在更新（Update）机制、复制（Replication）机制以及内存型存储。因为时间的关系，此处我不加详细说明，部分答案在 Eureka Wiki Eureka 2.0 Motivations 中也有描述：

Why Eureka 2.0?

Only support homogenous client views
Only supports scheduled updates
Replication algorithm limits scalability
注：以上具体内容在分享现场并无具体说起，此处特地为读者补充。

以上问题 Netflix 早在 2015 年已意识到，然而 Eureka 2.0 的发布遥遥无期。后来，我托朋友联系上了 Netflix 的工程师，咨询他们关于 Eureka 1 在自身生产环境的使用状况。他们的回复是部分场景在使用。这样的答复值得玩味，再细问其覆盖比重，对方三缄其口。这不得不让我对 Eureka 的成熟度产生了质疑，因此我不建议你们在数以千计的应用实例场景中使用。

Consul
Consul 一样做为 Spring Cloud 服务中心，基于 GO 语言开发，其数据一致性采用 Raft 算法，低内存，集群支持。曾一度成为我理想的替换 Eureka 的方案，不过本人并不具有 Consul 的大规模运用，为此还特地请教永辉云创的架构师翟永超（《Spring Cloud 微服务实战》的做者）。他告知 Consul 表现不错，并在跨 DC（数据中心）方面也比较稳定：

他的答复让我加强了 Consul 的信心，稍显遗憾的是其 Consul 应用节点略少。后来，我据说 B 站的哥们自研服务发现中间件 discovery，他们应该也对 Consul 作过调研和评估，他们的见解是：

Github 开源地址：https://github.com/Bilibili/d...

discovery 在 B 站 K8S 上的使用状况：

综合两家公司的评估，尽管没有通过本人实际操做，而且二者没有提供具体的数据指标，然而在必定程度上说明 Consul 做为注册中心的实例节点规模大概在 2k 之内。换言之，它比较适合中小型企业。

Zookeeper
Zookeeper 便可是 Spring Cloud 注册中心，又能做为 Dubbo 注册中心，与 Eureka 不一样，它属于 CP 分布式策略，然后者属于 AP。二者的共同点在于均属于内存型注册中心，在大规模集群场景，也会遇到 Eureka 相似的问题。不过从运维的角度，相较于 Eureka 而言，熟悉 Zookeeper 运维朋友更多。在生态性方面，Zookeeper 周边的生态更丰富，如 Zookeeper C API，尽管 Eureka 提供了语言无关性的 REST 接口。同时，Zookeeper 还从当配置服务器的角色，下降了学习的成本。综上结论，我推荐使用 Zookeeper 做为服务发现基础设施，不管您选择 Dubbo 方案，仍是使用 Spring Cloud。尽管它在大规模集群时也出现 Zookeeper 间歇性卡顿等问题。

负载均衡

负载均衡是第二个重要 Cloud Native 基础设施，熟悉 Spring Cloud 的朋友必定对右侧的蝴蝶结有印象，它就是 Netflix OSS 负载均衡组件 Ribbon，框架层面提供了多种负载均衡规则，如：

随机 - RandomRule
轮循 - RoundRobinRule
权重响应时间 - WeightedResponseTimeRule
WeightedResponseTimeRule 以外，其余的 Ribbon 负载均衡实现均没有提供权重因子，而权重因子对于蓝绿发布、服务预热等方面的帮助是相当重要的。所以，权重因子在 Dubbo “随机“、”轮询“ 以及 ”最少活跃调用数“ 负载均衡算法中均体现。

以上讨论的两种框架均属于 Java 实现，而中间的 Kong 则是更为通用的实现，一般它做为 API 服务网关，后面咱们将继续讨论。可简单地认为它是 Nginx + Lua 的扩展，负载均衡天然成为不可或缺的特性。其默认的负载均衡算法为具有权重的轮询（weighted-round-robin），同时一致性 Hash 算法做为可选方案。

服务网关

谈及服务网关，Java 工程师最容易想到的是 Spring Cloud Zuul。Zuul 是 Netflix 基于 Servlet API 开发的 Web 服务代理组件，在 Spring Cloud 使用场景中，它与 Eureka 和 Ribbon 整合，打造具有服务动态更新和负载均衡能力的服务网关。

最近，随着 Spring Cloud Finchley 的发布，Spring Cloud Zuul 的替代方案 Spring Cloud Gateway 孕育而生，不过官方的描述仍是比较谦虚谨慎，并无一刀切地引导开发人员从 Zuul 迁移到 Gateway 上来：

API Gateway built on top of the Spring Ecosystem, including: Spring 5, Spring Boot 2 and Project Reactor. Spring Cloud Gateway aims to provide a simple, yet effective way to route to APIs and provide cross cutting concerns to them such as: security, monitoring/metrics, and resiliency.

二者不一样点在于，Zuul 运行在 Servlet 容器中，而 Gateway 并不像 Spring WebFlux 可以兼容 Servlet 3.1 运行时，而是必须依赖 Netty 的运行时，以及整合 Reactive 框架 Reactor，实现异步非阻塞网关。因为近期对于 Spring 5 WebFlux 可以大幅提高应用性能的观点甚嚣尘上，实际上，没有任何直接性能基准测试证实 WebFlux 可以加快程序执行速度，或许你们认为个人观点与主流格格不入，但是我要告诉你们的是，这个问题我在同事间验证过不少次，大多数状况，Reactive 并不没有提高性能。就连 Spring 官方也认可这个观点：

1.1.7. Performance vs scale

Performance has many characteristics and meanings. Reactive and non-blocking generally do not make applications run faster. They can, in some cases, for example if using the WebClient to execute remote calls in parallel. On the whole it requires more work to do things the non-blocking way and that can increase slightly the required processing time.

资源地址：https://docs.spring.io/spring...

同时，这里提供一篇 Spring 5 WebFlux: Performance tests 的文章，在结尾部分给出告终论，做者坦言在速度上没有明显的提高，甚至从结果来看，速度稍微更糟糕：

No improvement in speed was observed with our reactive apps (the Gatling results are even slightly worse).
以上测试工程和结论是由开源项目 JHipster 的工程师给出，具有必定的客观性和可信度。

资源地址：https://blog.ippon.tech/sprin...

换言之，基于 Reactor 开发的 Gateway 在性能可能并无明显的提高。所以，Zuul 和 Gateway 的性能对比则演变为 Servlet 容器和 Netty Web 容器的比较，感兴趣的朋友能够去网上寻找一些比较数据，二者的性能在伯仲间。

固然，我和在座的各位同样，对 Java 的实现方案天然是情有独钟。然而我想说的是，身为 Java 工程师，眼中不免有 Java，可是眼中不要只有 Java。Nginx 做为当年著名 “C10K” 问题的解决方案，不管从链接数量，仍是资源消耗方面均优于 Java 实现。做为技术人，应该具备更为宽广的胸怀，接纳非我族类的气魄，该放手的时候就放手。Nginx 做为服务网关不失为一种好的方案，然而它的动态性略为不足，须要结合 Lua 脚本辅助完成，所以，OpenResty 和 Kong 这类方案脱颖而出。若是就 HTTP API 网关而言，我的认为 Kong 的方案更佳，由于它提供完整的解决方案，包括前面讨论的负载均衡（权重）、服务熔断以及服务发现等特性。相似的特性在 CNCF 项目 Envoy 也有体现，它是另外一种高性能代理的方案，提供服务发现、健康和负载均衡。在协议上，自然支持 HTTP 和 HTTP/2，而通信协议支持 gRPC，建议你们予以高度关注。

值得一提的是，HTTP API 网关一般须要支持 sidecar，换言之，支撑网关服务的基础设施必须提供服务发现的能力，就功能性而言，Zuul 和 Gateway 自身并不具有这样的特性，须要搭配 Eureka 这样组件，它们更像服务路由器的角色。

分布式配置

左边和中间的四种技术均为 Spring Cloud 分布式配置的底层存储，其中 Git 为版本式配置，而 JDBC 是从 Spring Cloud Edgware 版本开始支持，提供更为通用和动态的配置源。这里咱们又见到 Zookeeper 的声影，从简化运维的角度，能够利用 Zookeeper 即承担服务发现，也做为分布式配置的基础设施。而最右边的 etcd 是最近很是火的 Kubernetes 分布式配置的 key-value 存储，提供快速、简单、安全和可高的解决方案。

服务熔断

服务熔断也很是让开发人员联想到 Spring Cloud Hystrix 技术，不过 Hystrix 并不是与 Spring Cloud 强耦合，固然 Dubbo 也能结合 Netflix Hystrix 框架提供服务熔断的能力，后面部分将介绍 Dubbo 与 Hystrix 整合，提高 Dubbo 服务熔断的能力。确切地说，Dubbo 所提供的能力是集群容错，包括 Failover 等模式。 Kong 也自然地支持服务熔断的能力，因此它做为 API 网关的特性是全面的。

链路跟踪

以上链路跟踪的基础设施从左至右，分别为 Zipkin、OpenTracing 以及 Jaeger，三者的灵感均来自于 Google 论文 Dapper。相对而言，Java 程序员可能更为熟悉 Zipkin，由于它是 Spring Cloud Sleuth 首选方案，提供客户端上报以及服务端聚合和 Dashboard 等功能。而 OpenTracing 和 Jaeger 是 CNCF 孵化项目，前者属于开放的标准，提供多语言的适配实现，后者则由 Uber（优步）公司开发并开源的链路跟踪项目，功能上与 Zipkin 相似，不过它基于 GO 语言开发，同时也提供 Java 客户端。

OpenTracing 官网：http://opentracing.io/
jaeger 官网：https://www.jaegertracing.io/

服务监控

服务监控与链路跟踪有所区别，主要用于监控应用系统或业务的指标数据，多是健康阈值，如 CPU 或 内存使用率，也能够是业务指标，如最近一小时的用户登陆量。一般采用 Metrics 方式暴露，可以使用客户端推送或服务端拉取的方式传输 Metrics 信息到数据中心。一般 Metrics 数据与时间是存在对应关系，所以，基本上采用时序型数据库来存储，如图中的 OpenTSDB。一般，Java 微服务应用会选择 Spring Boot 框架做为基础设施，如我以前设计的监控架构就采用了 Spring Boot + OpenTSDB ，后端存储基于 HBase。当时 Spring Boot Actuator Metrics 仅为简单的 Key Value 形式，天然 OpenTSDB 是理想的选择。随着 Spring Boot 2.0 开始支持 Micrometer 以后，使得 Spring Boot 的应用可以整合更多的 Micrometer 适配方案，其中名气较大的就是图中间的 Prometheus，它一样也是 CNCF 的孵化项目。

固然服务监控不仅是 Metrics 方式，我所知道国内很多的公司采用了日志收集的方案，并搭配 ELK（Elasticsearch, Logstash, Kibana） 架构，减小运维成本。假设您没有使用该方案，或者仅使用了 Elasticsearch 的话，不管哪一种方案，图形化界面的监控是必不可少的，所以我推荐 Grafana，该项目可以支持多种数据源，包括前文提到的 OpenTSDB、Prometheus 以及 ElasticSearch 等。由此，从数据采集、上报、聚合以及展现的特性上，这些基础设施帮助 Cloud Native 应用构建服务监控的闭环。

本议程介绍了一些 Cloud Native 技术设施，接下里咱们继续讨论 Cloud Native 架构选型。

Cloud Native 架构选型
CNCF 架构体系

CNCF 体系做为目前最热门的架构选型之一，基本上围绕着 Kubernetes 为中心而构建。我的认为，Java 业界和 CNCF 体系并无达成共识，如服务网关，CNCF 主打 Envoy，而 Java 主要的方案为 Zuul 和 Spring Cloud Gateway。所以，我的建议是密切的关注 CNCF 的发展，不过个别孵化项目能够先行，如 Prometheus 和 Jaeger 等。 至于 CNCF 与 Java 生态的整合和落地，还得有待时日。

原文连接