Mercy Ma

《深入理解 spring cloud 与实战》序

Wed, 28 Oct 2020 00:00:00 +0000

《深入理解 Spring Cloud 与实战》序

2017 年，我与作者在国内开源社区相识，那时给人的印象是，他是一名乐于分享并且积极上进的青年。后来，得知他入职阿里巴巴中间件部门，并一同参与了 Spring Cloud 与阿里巴巴以及阿里云的技术整合项目，也就是后来的 Spring Cloud Alibaba。

作为一名资深开发人员，作者的职业素养具备专业、严谨、热情和强烈的责任心。记得 2018 年 11 月，我们一起参加 Spring One Tour 2018 北京峰会。会后，作者给 Spring Cloud Leader Spencer 提出了不少关于 Spring Cloud 实现上的建议。有趣的是，刚走出会议大厅，作者又接到来自社区贡献者军哥（nepxion.com 项目发起人）的电话，反馈 Spring Cloud Alibaba 孵化版本中的问题。经过技术排查，问题的确存在。数次电话沟通中，作者面漏歉意，并承诺尽快将问题修复。我想，大多数工程师都经历过这种情况。晚间，我们来到 Josh Long（Spring Developer Advocate）下塔的酒店，作者向对方演示 Spring Cloud Alibaba RocketMQ 在本地和阿里云环境的操作。时间不知不觉已是凌晨四点。后来，Josh 录制了相关的视频，分享在 YouTube 上。

作为一名 Spring Cloud Alibaba 项目负责人，作者除了代码贡献之外，更多的精力投入在社区运营、维护与 Spring 官方沟通上，进过一年多的不懈地努力，2019 月 7 月 24 日，Spring 官方宣布 Spring Cloud Alibaba 毕业，仓库迁移至 Alibaba Github OSS 下。这意味着 Spring Cloud Alibaba 是国内首个进入 Spring 社区的开源项目。

作为一名技术布道者，作者身体力行，2018 至 2019 年，走遍全国 IT 重镇，分享 Spring Cloud 以及 Spring Cloud Alibaba 等技术。几乎每场分享过后，将自己的技术心得和体会以博文的方式发布。尽管网上已有不少的相关技术文章，然而作者文章的技术深度和广度是有过之而无不及的。同时，作者意识到单凭技术文章很难系统性的探讨技术细节，由此萌生了写书的念头。于是，作者与我讨论写书一些技巧和注意事项。

写书的过程必然是漫长而曲折的，尤其需要在繁忙的日常工作中整合零散的时间。更棘手的是，写作期间 Spring Cloud 的内核也在不断的变化，这也给内容增添的难度，不得不与时俱进，及时作出调整，时间轴被迫拉长。不过，个人认为这样的等待是值得的，尽管作者是 Spring Cloud Alibaba 的核心开发人员，然而本书并非专题讨论 Spring Cloud Alibaba，并且本书也不是单纯地指导读者如何使用 Spring Cloud，而是从宏观和微观的视角，深入地讨论 Spring Cloud 架构发展，以及各个组件之间的特性和联系。所以，本书不仅适合 Spring Cloud 初探者，也为资深从业人员提供参考，并且本书的行文通俗，章节之间的关联紧密，阅读体验友好，故推荐之。

正值中美全面竞争的时代，个人认为，彼此在软件技术的差距虽在不断缩小，但绝对值仍旧存在。全球化的进程开阔了我们的视野，然而商业化的运作却使得行业进程迟缓。尽管中国式的互联网是我们常引以为傲的话题，然而大多数场景还停留在技术运用的阶段，中间偶尔出现一些技术创新，还谈不上技术创造。许多从业人员理想的职位是软件架构师或者 CTO，难免过多地关注于软件架构，而忽视了设计思想和代码实现的重要性。我想，任何基础学科的积累都是枯燥和繁琐的，时代的特殊性，导致了行业的局限性。或许本书不是尽善尽美之物，个人希望读者在阅读后，意识到细节的力量。同时，也期盼更多的同仁志士积极参与开源建设，群策群力，促进行业良性循环。

小马哥（mercyblitz）

2020 年 10 月 28 日

Apache dubbo 服务自省架构设计

Mon, 11 May 2020 00:00:00 +0000

背景

随着微服务架构的推广和普及，服务之间的耦合度在逐步降低。在演化的过程中，伴随着应用组织架构的变化以及基础设施的衍进，服务和应用之间的边界变得更为模糊。Java 作为一门面向对象的编程语言，Java 接口（interface）作为服务之间通讯的一等公民，配合文档（JavaDoc）便于开发人员理解和维护。基于相同的编程哲学，Apache Dubbo 作为传统的 RPC 服务治理框架，通过接口实现分布式服务。然而对于微服务治理而言，应用（或“服务”）才是基础设施的核心要素。面对云原生（Cloud Native）技术的兴起，传统的 Dubbo 架构不断地面临着新的的挑战。下面内容将以 Apache Dubbo 2.7.5 为基础，介绍全新架构 - Apache Dubbo 服务自省（后文简称“服务自省”），了解 Dubbo 传统架构所面临的现实挑战，以及服务自省架构的设计和解决之道。

术语约定

Service：SOA 或微服务中的“服务”，或称之为“应用”，具有全局唯一的名称
Service Name: 服务名称，或应用名称
Servce Instance：服务实例，或称为应用实例（Application Instance），表示单个 Dubbo 应用进程
Registry：注册中心
Dubbo 服务：又称之为“Dubbo 业务服务”，包含 Java 接口、通讯协议，版本（version）和分组（group）等元信息
Dubbo 服务 ID：唯一鉴定 Dubbo 服务的元数据，用于 Dubbo 服务暴露（发布）和订阅
Provider：Dubbo 服务提供方
Consumer：Dubbo 服务消费方
Dubbo 服务暴露：也称之为 Dubbo 服务发布，或英文中的“export”、”exported”
Dubbo 应用服务：也称之为 Dubbo 业务服务，或业务 Dubbo 服务

使用场景

服务自省是 Dubbo 应用在运行时处理和分析 Dubbo 服务元信息（Metadata）的过程，如当前应用暴露的Dubbo 服务以及各自的通讯协议等。期间会伴随着事件的广播和处理，如服务暴露事件。Dubbo 服务自省架构是其传统架的一种补充，更是未来 Dubbo 架构，它更适合以下使用场景：

超大规模 Dubbo 服务治理场景
微服务架构和元原生应用
Dubbo 元数据架构的基石

超大规模 Dubbo 服务治理场景

如果 Dubbo 集群规模超过一千以上，或者集群扩缩容已无法自如地执行，如 Zookeeper 管理数万 Dubbo 服务，服务自省可极大化减轻注册中心的压力，尤其在内存足迹、网络传输以及变更通知上体现。

微服务架构和元原生应用

如果想要 Dubbo 应用更好地微服务化，或者更接近于云原生应用，那么服务自省是一种不错的选择，它能够提供已应用为粒度的服务注册与发现模型，全面地支持最流行的 Spring Cloud 和 Kubernetes 注册中心，并且能与 Spring Cloud 或 Spring Boot 应用交互。

Dubbo 元数据架构的基石

Dubbo 元数据架构是围绕 Dubbo DevOps 而引入，包括 Dubbo 配置元数据（如：属性配置、路由规则等）和结构元数据（如：Java 注解、接口和文档等）。服务自省作为 Dubbo 元数据的基础设施，不仅支持所有元数据的存储和平滑升级，而且不会对注册中心、配置中心和元数据中心产生额外的负担。

传统架构

Apache Dubbo 是一款面向接口代理的高性能 RPC 框架，提供服务注册与发现的特性，其基础架构如下图所示：

(图 1）

Provider 为服务提供方，提供 Java 服务接口的实现，并将其元信息注册到 Dubbo 注册中心（过程 1.register 所示）
Consumer 为服务消费端，从 Dubbo 注册中心检索订阅的 Java 服务接口的元信息（过程 2.subscribe 所示），通过框架处理后，生成代理程序执行远程方法调用（过程 4.invoke 所示）
Registry 为注册中心，属于注册元信息中心化基础设施（如 Apache Zookeeper 或 Alibaba Nacos），为 Provider 提供注册通道，为 Cosumer 提供订阅渠道。同时，注册中心支持注册元信息变更通知，通知 Consumer 上游 Provider 节点的变化（如扩容或缩容）。而注册元信息均以 Dubbo URL 的形式存储
Monitor 为服务治理平台，提供开发和运维人员服务查询、路由规则、服务 Mock 和测试等治理能力

综上所述，Dubbo 注册与发现的对象是 Dubbo 服务（Java 接口），而其载体为注册元信息，即 Dubbo URL，如：dubbo://192.168.1.2:20880/com.foo.BarService?version=1.0.0&group=default，通常包含必须信息，如服务提供方 IP 和端口、 Java 接口，可选包含版本（version）和分组（group）等。服务 URL 所包含的信息能够唯一界别服务提供方的进程。

现实挑战

为了更好地符合 Java 开发人员的编程习惯，Dubbo 以 Java 服务接口作为注册对象，所面临的现实挑战主要有：

如何解决或缓解注册中心压力过载
如何支持以应用为粒度的服务注册与发现
如何精简 Dubbo URL 元数据

如何解决或缓解注册中心压力过载

注册中心内存压力

Dubbo 注册中心是中心化的基础设施，大多数注册中心的实现为内存型存储，比如 Zookeeper、Nacos 或 Consul、Eureka。注册中心的内存消耗与 Dubbo 服务注册的数量成正比，任一 Dubbo Provider 允许注册 N 个 Dubbo 服务接口，当 N 越大，注册中心的负载越重。根据不完全统计，Dubbo 核心 Provider 用通常会暴露 20 ~ 50 个服务接口。注册中心是中心化的基础设施，其稳定性面临严峻考验。尽管微服务架构不断地深化，然而现实情况是，更多开发者仍旧愿意在单一 Provider 上不断地增加 Dubbo 服务接口，而非更细粒度的 Dubbo Provider 组织。

注册中心网络压力

为了避免单点故障，主流的注册中心均提供高可用方案。为解决集群环境数据同步的难题，内建一致性协议，如 Zookeeper 使用的 Zab 协议，Consul 采用的 Raft 协议。无论哪种方式，当 Dubbo URL 数量变化频繁时，网络和 CPU 压力也会面临考验。如果注册中心与客户端之间维持长连接状态的话，如 Zookeeper，注册中心的网络负担会更大。

注册中心通知压力

假设某个 Dubbo Provider 注册了 N 个 Dubbo 服务接口，当它扩容或缩容 M 个实例（节点）时，N 数量越大，注册中心至少有 M * N 个 Dubbo URL 注册或移除。同时，大多数注册中心实现支持注册变化通知，如 Zookeeper 节点变化通知。当 Dubbo Consumer 订阅该 Provider 的 Dubbo 服务接口数为 X 时，X 数值越大，通知的次数也就越多。实际上，对于来自同一 Provider 的服务接口集合而言，X-1 次通知是重复和无价值的。

如果 Dubbo 注册实体不再是服务 URL，而是 Dubbo Provider 节点的话，那么上述情况所描述的注册中心压力将得到很大程度的缓解。（负载只有过去的 1/N 甚至更少），然而 Dubbo 如何以应用为粒度来注册又是一个新的挑战。

如何支持以应用为粒度的服务注册与发现

尽管 Dubbo 也存在应用（Application）的概念，不过传统的使用场景并非核心要素，仅在 Dubbo Monitor 或 Dubbo Admin 场景下做辨识之用。随着微服务架构和云原生技术的兴起，以应用为粒度的注册模型已是大势所趋，如 Spring Cloud 和 Kubernetes 服务注册与发现模型。注册中心所管理的对象通常与业务无关，甚至不具备 RPC 的语义。在术语上，微服务架构中的“服务”（Services）与云原生中“应用”（Applications）是相同的概念，属于逻辑名称，而它们的成员则以服务实例（Service Instances）体现，服务和服务实例的数量关系为 1:N。

单个服务实例代表一个服务进程，而多个 Dubbo 服务 URL 可隶属一个 Dubbo Provider 进程，因此，Dubbo URL 与服务实例的数量关系是 N : 1。假设一个 Dubbo Provider 进程仅提供一个 Dubbo 服务（接口）的话，即 N = 1 的情况，虽然以应用为粒度的服务注册与发现能够基于 Dubbo 传统的 Registry SPI 实现，不过对于现有 Dubbo 应用而言，将存在巨大的应用微服务化工作。

支持 Spring Cloud 服务注册与发现模型

Spring Cloud 是 VMware 公司（前为 Pivotal）推出的，一套以 Spring 为技术栈的云原生（Cloud-Native）解决方案，在 Java 微服务领域具备得天独厚的优势，拥有超大规模的全球用户。Spring Cloud 官方支持三种注册中心实现，包括：Eureka、Zookeeper 和 Consul，Spring Cloud Alibaba 扩展了 Nacos 注册中心实现。尽管 Zookeeper、Consul 和 Nacos 也被 Apache Dubbo 官方支持，然而两者的服务注册与发现的机制不尽相同。

若要 Dubbo 支持 Spring Cloud 服务注册与发现模型，Dubbo 则需基于 Dubbo Registry SPI 实现，否则底层的变化和兼容性存在风险。

支持 Kubernetes 服务注册与发现模型

Kubernetes 源自 Google 15 年生产环境的运维经验，是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务。Kubernetes 原生服务发现手段主要包括：DNS 和 API Server。DNS 服务发现是一种服务地址的通用方案，不过对于相对复杂 Dubbo 元数据而言，这种服务发现机制或许无法直接被 Dubbo Registry SPI 适配。相反，API Server 所支持相对更便利，毕竟 Spring Cloud Kubernetes 同样基于此机制实现，并已在生产环境得到验证。换言之，只要 Dubbo 支持 Spring Cloud 服务注册与发现模型，那么基于 Kubernetes API Server 的支持也能实现。

兼容 Dubbo 传统服务注册与发现模型

所谓兼容 Dubbo 传统服务注册与发现模型，包含两层含义：

基于 Dubbo Registry SPI 同时支持 Spring Cloud 和 Kubernetes 服务注册与发现模型
传统和新的 Dubbo 服务注册与发现模型之间能够相互发现

如何精简 Dubbo URL 元数据

Dubbo 从 2.7.0 开始增加了简化 URL 元数据的特性，被“简化”的数据存放至元数据中心。由于 Dubbo 传统服务注册与发现模型并未减少 Dubbo 服务 URL 注册数量。因此，精简后的 URL 并未明显地减少注册中心所承受的压力。同时，Dubbo URL 元数据精简模式存在一定的限制，即所有的 Dubbo Provider 节点必须是无状态的，每个节点中的 URL 元信息均是一致的，现实中，这个要求非常难以保证，尤其在同一 Provider 节点存在不同的版本或配置的情况下。综上所述，Dubbo URL 元数据需要进一步精简，至少压力应该避免聚集在注册中心之上。

架构设计

架构上，Dubbo 服务自省不仅要解决上述挑战，而且实际场景则更为复杂，因此，架构细节也将循序渐进地展开讨论，整体架构可由以下子架构组成：

服务注册与发现架构
元数据服务架构
事件驱动架构

服务注册与发现架构

Dubbo 服务自省首要需求是减轻注册中心的承载的压力，同时，以应用为粒度的服务注册与发现模型不但能够最大化的减少 Dubbo 服务元信息注册数量，而且还能支持 Spring Cloud 和 Kubernetes 环境，可谓是一举两得，架构图如下所示：

(图 2）

注册实体

图中所示，从 Provider 和 Consumer 向注册中心注册的实体不再是 Dubbo URL，而是服务实例（Service Instance），一个服务实例代表一个 Provider 或 Consumer Dubbo 应用进程。服务实例属性包括：

服务名（Service Name）：该名称必须在注册中心全局唯一

注：名称规则架构上不做约束，不过不同注册中心的规则存在差异

主机地址（Host/IP）：能够被解析的主机名或者 TCP IP 地址
服务端口（Port）：应用进程所暴露的 Dubbo 协议端口，如 Dubbo 默认端口 20880

注：如果应用进程暴露多个 Dubbo 协议端口，如 dubbo 和 rest，那么，服务端口随机挑选其一，架构上不强制检验端口是否可用

元数据（Metadata）：服务实例的附加信息，用于存储 Dubbo 元信息，类似于通讯协议头或附件
激活状态（Enabled）：用于标记当前实例是否对外提供服务

上述服务实例模型的支持依赖于注册中心的实现。换言之，并非所有注册中心实现满足服务自省架构的要求。

注册中心

除了满足服务实例模型的要求之外，注册中心还得具备以下能力：

服务实例变化通知（Notification）：如上图步骤 4 所示，当 Consumer 订阅的 Provider 的服务实例发生变化时，注册中心能够实时地通知 Consumer
心跳检测（Heartbeats）：注册中心能够检测失效的服务实例，并且合理地移除它们

业界主流的注册中心中满足上述要求的有：

Apache Zookeeper
HashiCorp Consul
Netflix Eureka
Alibaba Nacos
Kubernetes API Server

总之，Spring Cloud 与 Kubernetes 注册中心均符合服务自省对注册中心的要求。不过，在 Dubbo 传统 RPC 使用场景中，Provider 和 Consumer 关注的是 Dubbo 服务接口，而非 Service 或服务实例。假设需要将现有的 Dubbo 应用迁移至服务自省架构，Provider 和 Consumer 做大量的代码调整是不现实的。理想的情况下，两端实现代码均无变化，仅修改少量配置，就能达到迁移的效果。那么，Dubbo 服务接口是如何与 Service 进行映射的呢？

Dubbo 服务与 Service 映射

前文曾讨论，单个 Dubbo Service 能够发布多个 Dubbo 服务，所以，Dubbo 服务与 Service 的数量关系是 N 对 1。不过，Dubbo 服务与 Dubbo Service 之间并不存在强绑定关系，换言之，某个 Dubbo 服务也能部署在多个 Dubbo Services 中，因此，Dubbo 服务与 Service 数量关系是 N 对 M（N, M >= 1），如下图所示：

(图 3）

上图中 P1 Service 到 P3 Service 为 Dubbo Service，com.acme.Interface1 到 com.acme.InterfaceN 则为 Dubbo 服务接口全称限定名（QFN）。值得注意的是，Dubbo 服务的 Java 接口（interface）允许不同的版本（version）或分组（group），所以仅凭 Java 接口无法唯一标识某个 Dubbo 服务，还需要增加通讯协议（protocol）方可，映射关系更新如下：

(图 4）

Dubbo 服务 ID 字符表达模式为： ${protocol}:${interface}:${version}:${group} , 其中，版本（version）或分组（group）是可选的。当 Dubbo Consumer 订阅 Dubbo 服务时，构建对应 ID，通过这个 ID 来查询 Dubbo Provider 的 Service 名称列表。

由于 Dubbo 服务与 Service 的映射关系取决于业务场景，架构层面无从预判。因此，这种映射关系只能在 Dubbo 服务暴露时（运行时）才能确定，否则，Dubbo 服务能被多个 Consumer 应用订阅时，Consumer 无法定位 Provider Service 名称，进而无法完成服务发现。同时，映射关系的数据通常采用配置的方式来存储，服务自省提供两种配置实现，即 “中心化映射配置” 和 “本地化映射配置”。

中心化映射配置

明显地，注册中心来扮演动态映射配置的角色并不适合，不然，Dubbo Service 与映射关系在注册中心是平级的，无论在理解上，还是设计上是混乱的。结合 Dubbo 现有基础设施分析，这个存储设施可由 Dubbo 配置中心承担。

其中 Dubbo 2.7.5 动态配置 API（DynamicConfiguration ）支持二级结构，即：group 和 key，其中，group 存储 Dubbo 服务 ID，而 key 则关联对应的 Dubbo Service 名称，对应的 “图 4” 的数据结构则是：

(图 5）

如此设计的原因如下：

获取 Dubbo 服务对应 Services

利用 DynamicConfiguration#getConfigKeys(String group) 方法，能够轻松地通过 Dubbo 服务 ID 获取其发布的所有 Dubbo Services，结合服务发现接口获取服务所部署的 Service 实例集合，最终转化为 Dubbo URL 列表。

避免 Dubbo Services 配置相互覆盖

以 Dubbo 服务 ID dubbo:com.acme.Interface1:default 为例，它的提供者 Dubbo Services 分别：P1 Service 和 P2 Service。假设配置 Group 为 “default”（任意名字均可）， Key 为 “dubbo:com.acme.Interface1:default”，而内容则是 Dubbo Service 名称的话。当 P1 Service 和 P2 Service 同时启动时，无论哪个 Services 最后完成 Dubbo 服务暴露，那么，该配置内容必然是二选其一，无论配置中心是否支持原子操作。即使配置中心支持内容追加的特性，由于两个 Service 服务实例过程不确定，配置内容可能会出现重复，如：“P1 Service,P2 Service,P1 Service”。

获取 Dubbo 服务发布的 timestamp

配置中心潜在的压力

假设当 P1 Service 存在 5 个服务实例，当 Dubbo 服务 dubbo:com.acme.Interface1:default（ID）发布时，配置所关联的 key 就是当前 Dubbo Service 名称，即（P1 Service），而内容则是最后发布该 Dubbo 服务的时间戳（timestamp）。当服务实例越多时，配置中心和网络传输所承受的写入压力也就越大。当然架构设计上，服务自省也希望避免重复推送配置，比如在 DynamicConfiguration API 增加类似于 publishConfigIfAbsent 这样的方法，不过目前大多数配置中心产品（如：Nacos、Consul）不支持这样的操作，所以未来服务自省架构会有针对性的提供支持（如：Zookeeper）。

注册中心作为配置中心

由于服务自省架构必须依赖注册中心，同时动态映射配置又依赖配置中心的话，应用的架构复杂度和维护成本均有所提升，不过 Apache Dubbo 所支持的部分注册中心也可作为配置中心使用，情况如下所示：

基础软件	注册中心	配置中心
Apache Zookeeper	✅	✅
HashiCorp Consul	✅	✅
Alibaba Nacos	✅	✅
Netflix Eureka	✅	❌
Kubernetes API Server	✅	❌

其中，Zookeeper、Consul 和 Nacos 是目前业界流行的注册中心，这对于大多数选择开源产品的应用无疑是一个福音。

本地化映射配置

如果开发人员认为配置中心的引入增加了架构的复杂性，那么，静态映射配置或许是一种解决方案。

该特性并未在最新 Dubbo 2.7.6 全面发布，部分特性已在 Dubbo Spring Cloud 中发布

接口映射配置

在 Dubbo 传统的编程模型中，常以 Java 注解 @Reference 或 XML 元素 `` 订阅目标 Dubbo 服务。服务自省架构在此基础上增加 service 属性的映射一个或多个 Dubbo Service 名称，如：

<reference services="P1 Service,P2 Service" interface="com.acme.Interface1" />

或

@Reference(services="P1 Service,P2 Service") 
private com.acme.Interface1 interface1;

如此配置后，Dubbo 服务 com.acme.Interface1 将向 p1-service 和 p2-service 订阅服务。如果开发人员认为这种方式会侵入到代码，服务自省还提供外部化配置方式配置映射。

外部化映射配置

服务自省架构支持外部化配置的方式声明“Dubbo 服务与 Service 映射”，配置格式为 Properties ，以图 4 为例，内容如下：

dubbo\:com.acme.Interface1\:default = P1 Service,P2 Service
thirft\:com.acme.InterfaceX = P1 Service,P3 Service
rest\:com.acme.interfaceN = P1 Service

应用级别映射配置

除此之外，Dubbo Spring Cloud 提供应用级别的 Dubbo 服务映射配置，即 dubbo.cloud.subscribed-services ，例如：

dubbo:
    cloud:
    subscribed-services: P1 Service,P3 Service

总之，无论是映射配置的方式是中心化还是本地化，服务 Consumer 依赖这些数据来定位 Dubbo Provider Services，再通过服务发现 API 结合 Service 名称（列表）获取服务实例集合，为合成 Dubbo URL 做准备：

(图 6）

不过，映射关系并非是一种强约束，Dubbo Provider 的服务是否可用的检验方法是探测目标 Dubbo Service 是否存在，并需确认订阅的 Dubbo 服务在目标 Services 是否真实暴露，因此，服务自省引入了 Dubbo 元数据服务架构，来完成 Dubbo 服务 URL 的存储。

元数据服务架构

Dubbo 元数据服务是一个常规的 Dubbo 服务，为服务订阅端提供 Dubbo 元数据的服务目录，类似于 WebServices 中的 WDSL 或 REST 中的 HATEOAS，帮助 Dubbo Consumer 获取订阅的 Dubbo 服务的 URL 列表。元数据服务架构无法独立于服务注册与发现架构而存在，下面通过“整体架构”的讨论，了解两者之间的关系。

整体架构

架构上，无论 Dubbo Service 属于 Provider 还是 Consumer，甚至是两者的混合，每个 Dubbo （Service）服务实例有且仅有一个 Dubbo 元数据服务。换言之，Dubbo Service 不存在纯粹的 Consumer，即使它不暴露任何业务服务，那么它也可能是 Dubbo 运维平台（如 Dubbo Admin）的 Provider。不过出于行文的习惯，Consumer 仍旧被定义为 Dubbo 服务消费者（应用）。由于每个 Dubbo Service 均发布自身的 Dubbo 元数据服务，那么，架构不会为不同的 Dubbo Service 设计独立的元数据服务接口（Java）。换言之，所有的 Dubbo Service 元数据服务接口是统一的，命名为 MetadataService 。

微观架构

从 Dubbo 服务（URL）注册与发现的视角， MetadataService 扮演着传统 Dubbo 注册中心的角色。综合服务注册与发现架构（Dubbo Service 级别），微观架构如下图所示：

(图 7）

** **

对于 Provider（服务提供者）而言，Dubbo 应用服务暴露与传统方式无异，而 MetadataService 的暴露时机必须在它们完成后，同时， MetadataService 需要收集这些 Dubbo 服务的 URL（存储细节将在“元数据服务存储模式“ 小节讨论）。假设某个 Provider 的 Dubbo 应用服务暴露数量为 N，那么，它所有的 Dubbo 服务暴露数量为 N + 1。

对于 Consumer（服务消费者）而言，获 Dubbo 应用服务订阅 URL 列表后，Dubbo 服务调用的方式与传统方式是相同的。不过在此之前，Consumer 需要通过 MetadataService 合成订阅 Dubbo 服务的 URL。该过程之所以称之为“合成”，而非“获取，是因为一次 MetadataService 服务调用仅在其 Provider 中的一台服务实例上执行，而该 Provider 可能部署了 N 个服务实例。具体“合成”的细节需要结合“宏观架构”来说明。

宏观架构

元数据服务的宏观架构依赖于服务注册与发现架构，如下图所示：

(图 8）

图 8 中 p 和 c 分别代表 Provider 和 Consumer 的执行动作，后面紧跟的数字表示动作的次序，从 0 开始计数。执行动作是串行的，并属于 Fast-Fail 设计，如果前阶段执行失败，后续动作将不会发生。之所以如此安排是为了确保 MetadataService 能够暴露和消费。首先从 Provider 执行流程开始说明。

Provider 执行流程

p0：发布所有的 Dubbo 应用服务，声明和定义方式与传统方式完全相同。
p1：暴露 MetadataService ，该步骤完全由框架自行处理，无论是否 p0 是否暴露 Dubbo 服务
p2：在服务实例注册之前，框架将触发并处理事件（Event），将 MetadataService 的元数据先同步到服务实例（Service Instance）的元数据。随后，执行服务实例注册
p3：建立所有的 Dubbo 应用服务与当前 Dubbo Service 名称的映射，并同步到配置源（抽象）

Consumer 执行流程

c0：注册当前 Dubbo Service 的服务实例，可选步骤，架构允许 Consumer 不进行服务注册
c1：通过订阅 Dubbo 服务元信息查找配置源，获取对应 Dubbo Services 名称（列表）
c2：利用已有 Dubbo Service 名称（可能存在多个），通过服务发现 API 获取 Provider 服务实例集合。假设 Service 名称 P，服务实例数量为 N
c3：

1. 随机选择 Provider 一台服务实例 Px，从中获取 MetadataService 的元数据
2. 将元数据组装 MetadataService Dubbo 调用客户端（代理）
3. 发起 MetadataService Dubbo 调用，获取该服务实例 Px 所暴露的 Dubbo 应用服务 URL 列表
4. 从 Dubbo 应用服务 URL 列表过滤出当前订阅 Dubbo 应用服务的 URL
5. 理论上，步骤 c 和 d 还需要执行 N-1 次才能获取 P 所有服务实例的 Dubbo URL 列表。为了减少调用次数，步骤 d 的结果作为模板，克隆其他 N-1 台服务实例 URL 列表
6. 将所有订阅 Dubbo 应用服务的 URL 同步到 Dubbo 客户端（与传统方式是相同的）

c4：发起 Dubbo 应用服务调用（与传统方式是相同的）

不难看出，上述架构以及流程结合了“服务注册与发现”与“元数据服务”双架构，步骤之间会触发相关 Dubbo 事件，如“服务实例注册前事件”等。换言之，三种架构综合体也就是服务自省架构。

至此，关于 Dubbo 服务自省架构设计方面，还存在一些细节亟待说明，比如：

不同的 Dubbo Service 的 MetadataService 怎样体现差异呢？
MetadataService 作为一个常规的 Dubbo 服务，它的注册元信息存放在何处？
MetadataService 作为服务目录，它管理的 Dubbo 应用服务 URL 是如何存储的？
在 Consumer 执行流程的 c3.e 中，克隆 N - 1 条 URL 的前提是该 Provider 的所有服务实例均部署了相同 Dubbo 应用服务。如果 Provider 处于升级的部署过程，同一 Dubbo 应用服务接口在不同的服务实例上存在差异，那么该服务的 URL 应该如何获取？
除了 Dubbo 服务 URL 发现之外，元数据服务还支持哪些元数据类型呢？

元数据服务 Metadata

元数据服务 Metadata，称之为“元数据服务的元数据”，主要包括：

inteface：Dubbo 元数据服务所暴露的接口，即 MetadataService
serviceName : 当前 MetadataService 所部署的 Dubbo Service 名称，作为 MetadataService 分组信息
group：当前 MetadataService 分组，数据使用 serviceName
version：当前 MetadataService 的版本，版本号通常在接口层面声明，不同的 Dubbo 发行版本 version 可能相同，比如 Dubbo 2.7.5 和 2.7.6 中的 version 均为 1.0.0。理论上，version 版本越高，支持元信息类型更丰富
protocol： MetadataService 所暴露协议，为了确保 Provider 和 Consumer 通讯兼容性，默认协议为：“dubbo”，也可以支持其他协议。
port：协议所使用的网络端口
host：当前 MetadataService 所在的服务实例主机或 IP
params：当前 MetadataService 暴露后 URL 中的参数信息

不难得出，凭借以上元数据服务的 Metadata，可将元数据服务的 Dubbo 服务 ID 确定，辅助 Provider 服务暴露和 Consumer 服务订阅 MetadataService 。不过对于 Provider，这些元信息都是已知的，而对 Consumer 而言，它们直接能获取的元信息仅有：

serviceName：通过“Dubbo 接口与 Service 映射”关系，可得到 Provider Service 名称
interface：即 MetadataService ，因为 Provider 和 Consumer 公用 MetadataService 接口
group：即 serviceName

不过 Consumer 合成 MetadataService Dubbo URL 还需获取 version、host、port、protocol 以及 params：

version：尽管 MetadataService 接口是统一接口，然而 Provider 和 Consumer 可能引入的 Dubbo 版本不同，从而它们使用的 MetadataService version 也会不同，所以这个信息需要 Provider 在暴露MetadataService 时，同步到服务实例的 Metadata 中，方便 Consumer 从 Metadata 中获取
host：由于 Consumer 已得到 serviceName，可通过服务发现 API 获取服务实例对象，该对象包含 host 属性，直接被 Consumer 获取即可。
port：与 version 类似，从 Provider 服务实例中的 Metadata 中获取
params：同上

通过元数据服务 Metadata 的描述，解释了不同 Dubbo Services 是怎样体现差异性的，并且说明了 MetadataService 元信息的存储介质，这也就是服务自省架构为什么强依赖支持 Metadata 的注册中心的原因。下个小节将讨论 MetadataService 所存储 Dubbo 应用服务 URL 存放在何处。

元数据服务存储模式

Dubbo 2.7.5 在引入 MetadataService 的同时，也为其设计了两种存储方式，适用于不同的场景，即“本地存储模式”和“远程存储模式”。其中，本地存储模式是默认选项。

元数据服务本地存储模式

本地存储模式又称之为内存存储模式（In-Memory），如 Dubbo 应用服务发现和注册场景中，暴露和订阅的 URL 直接存储在内存中。架构上，本地存储模式的 MetadataService 相当于去中心化的 Dubbo 应用服务的注册中心。

元数据服务远程存储模式

远程存储模式，与去中心化的本地存储模式相反，采用 Dubbo 元数据中心来管理 Dubbo 元信息，又称之为元中心化存储模式（Metadata Center)。

选择存储模式

为了减少负载压力和维护成本，服务自省中的元数据服务推荐使用“本地存储模式”。

回顾前文“Consumer 执行流程”中的步骤 c3.e，为了减少 MetadataService 调用次数，服务自省将第一次的调用结果作为模板，再结合其他 N-1 服务实例的元信息，合成完整的 N 台服务实例的 Dubbo 元信息。假设，Dubbo Service 服务实例中部署的 Dubbo 服务数量和内容不同，那么，c3.e 的执行步骤是存在问题的。因此，服务自省引入“Dubbo 服务修订版本”的机制来解决不对等部署的问题。

尽管“Dubbo 服务修订版本”机制能够介绍 MetadataService 整体消费次数，然而当新修订版本的服务实例过少，并且 Consumer 过多时，如新的版本 Provider 应用分批部署，每批的服务实例为 1 台，而其 Consumer 服务实例成千上万。为了确保这类场景的稳定性，Provider 和 Consumer 的 MetadataService 可选择“远程存储模式”，避免消费热点的发生。

Dubbo 服务修订版本

当业务出现变化时，Dubbo Service 的 Dubbo 服务也会随之升级。通常，Provider 先行升级，Consumer 随后跟进。

考虑以下场景，Provider “P1” 线上已发布 interface 为 com.acme.Interface1，group 为 group , version 为 v1 ，即 Dubbo 服务 ID 为：dubbo:com.acme.Interface1:v1:default 。P1 可能出现升级的情况有：

Dubbo 服务 interface 升级

由于 Dubbo 基于 Java 接口来暴露服务，同时 Java 接口通常在 Dubbo 微服务中又是唯一的。如果 interface 的全类名调整的话，那么，相当于 com.acme.Interface1 做下线处理，Consumer 将无法消费到该 Dubbo 服务，这种情况不予考虑。如果是 Provider 新增服务接口的话，那么 com.acme.Interface1 则并没有变化，也无需考虑。所以，有且仅有一种情况考虑，即“Dubbo interface 方法声明升级”，包括：

增加服务方法
删除服务方法
修改方法签名

Dubbo 服务 group、version 和 protocol 升级

假设 P1 在升级过程中，新的服务实例部署仅存在调整 group 后的 Dubbo 服务，如 dubbo:com.acme.Interface1:v1:test ，那么这种升级就是不兼容升级，在新老交替过程中，Consumer 仅能消费到老版本的 Dubbo 服务。当新版本完全部署完成后，Consumer 将无法正常服务调用。如果，新版本中 P1 同时部署了 dubbo:com.acme.Interface1:v1:default

和 dubbo:com.acme.Interface1:v1:test 的话，相当于 group 并无变化。同理，version 和 protocol 变化，相当于 Dubbo 服务 ID 变化，这类情况无需处理。

Dubbo 服务元数据升级

这是一种比较特殊的升级方法，即 Provider 所有服务实例 Dubbo 服务 ID 相同，然而 Dubbo 服务的参数在不同版本服务实例存在差异，假设 Dubbo Service P1 部署 5 台服务，其中 3 台服务实例设置 timeout 为 1000 ms，其余 2 台 timeout 为 3000 ms。换言之，P1 拥有两个版本（状态）的 MetadataService 。

综上所述，无论是 Dubbo interface 方法声明升级，还是 Dubbo 服务元数据升级，均可认为是 Dubbo 服务升级的因子，这些因子所计算出来的数值称之为“Dubbo 服务修订版本”，服务自省架构将其命名为“revision”。架构设设计上，当 Dubbo Service 增加或删除服务方法、修改方法签名以及调整 Dubbo 服务元数据，revision 也会随之变化，revision 数据将存放在其 Dubbo 服务实例的 metadata 中。当 Consumer 订阅 Provider Dubbo 服务元信息时，MetadataService 远程调用的次数取决于服务实例列表中出现 revision 的个数，整体执行流程如下图所示：

(图 9）

Consumer 通过服务发现 API 向注册中心获取 Provider 服务实例列表
注册中心返回 6 台服务实例，其中 revision 为 1 的服务实例为 Instance 1 到 3, revision 为 2 的服务实例是 Instance 4 和 Instance 5，revision 为 3 的服务实例仅有 Instance 6
Consumer 在这 6 台服务实例中随机选择一台，如图中 Instance 3
Consumer 向 Instance 3 发起 MetadataService 的远程调用，获得 Dubbo URL 列表，并建立 revision 为 1 的 URL 列表缓存，用 cache = { 1:urls(r1) } 表示
（重复步骤 4）Consumer 再从剩余的 5 台服务实例中随机选择一台，如图中的 Instance 5，由于 Instance 5 与 Instance 3 的 revision 分为为 2 和 1，此时缓存 cache = { 1:urls(r1) } 未命中，所以 Consumer 将再次发起远程调用，获取新的 Dubbo URL 列表，并更新缓存，即 cache = { 1:urls(r1) , 2:urls(r2) }
（重复步骤 4）Consumer 再从剩余的 4 台服务实例中随机选择一台，假设服务实例是 Instance 6，由于此时 revision 为3，所以缓存 cache = { 1:urls(r1) , 2:urls(r2) } 再次未命中，再次发起远程调用，并更新缓存 cache = { 1:urls(r1) , 2:urls(r2) , 3:urls(r3) }
（重复步骤 4）由于缓存 cache = { 1:urls(r1) , 2:urls(r2) , 3:urls(r3) } 已覆盖三个 revision 场景，如果该步骤选择服务实例落在 revision 为 1 的子集中，只需克隆 urls(r1)，并根据具体服务实例替换部分 host 和 port 等少量元信息即可，组成成新的 Dubbo URL 列表，依次类推，计算直到剩余服务实例为 0。

大多数情况，revision 的数量不会超过 2，换言之，Consumer 发起 MetadataService 的远程调用不会超过 2次。无论 revision 数量的大小，架构能够保证获取 Dubbo 元信息的正确性。

当然 MetadataService 并非仅支持 Dubbo URL 元数据，还有其他类型的支持。

元数据类型

架构上，元数据服务（MetadataService）未来将逐步替代 Dubbo 2.7.0 元数据中心，并随着 Dubbo 版本的更迭，所支持的元数据类型也将有所变化，比如 Dubbo 2.7.5 元数据服务支持的类型包括：

Dubbo 暴露的服务 URL 列表
Dubbo 订阅的服务 URL 列表
Dubbo 服务定义

Dubbo 暴露的服务 URL 列表

当前 Dubbo Service 暴露或发布 Dubbo 服务 URL 集合，如：[ dubbo://192.168.1.2:20880/com.acme.Interface1?group=default&version=v1 , thirft://192.168.1.2:20881/com.acme.InterfaceX , rest://192.168.1.2:20882/com.acme.interfaceN ]

Dubbo 订阅的服务 URL 列表

当前 Dubbo Service 所有订阅的 Dubbo 服务 URL 集合，该元数据主要被 Dubbo 运维平台来收集。

Dubbo 服务定义

Dubbo 服务提供方（Provider）在服务暴露的过程中，将元信息以 JSON 的格式同步到注册中心，包括服务配置的全部参数，以及服务的方法信息（方法名，入参出参的格式）。在服务自省引入之前，该元数据被 Dubbo 2.7.0 元数据中心存储，如：

{
 "parameters": {
  "side": "provider",
  "methods": "sayHello",
  "dubbo": "2.0.2",
  "threads": "100",
  "interface": "org.apache.dubbo.samples.metadatareport.configcenter.api.AnnotationService",
  "threadpool": "fixed",
  "version": "1.1.1",
  "generic": "false",
  "revision": "1.1.1",
  "valid": "true",
  "application": "metadatareport-configcenter-provider",
  "default.timeout": "5000",
  "group": "d-test",
  "anyhost": "true"
 },
 "canonicalName": "org.apache.dubbo.samples.metadatareport.configcenter.api.AnnotationService",
 "codeSource": "file:/../dubbo-samples/dubbo-samples-metadata-report/dubbo-samples-metadata-report-configcenter/target/classes/",
 "methods": [{
  "name": "sayHello",
  "parameterTypes": ["java.lang.String"],
  "returnType": "java.lang.String"
 }],
 "types": [{
  "type": "java.lang.String",
  "properties": {
   "value": {
    "type": "char[]"
   },
   "hash": {
    "type": "int"
   }
  }
 }, {
  "type": "int"
 }, {
  "type": "char"
 }]
}

元数据服务升级

考虑到 Dubbo Provider 和 Consumer 可能依赖不同发行版本的 MetadataService ，因此，Provider 提供的和 Consumer 所需要的元数据类型并不对等，如 Provider 使用 Dubbo 版本为 2.7.5，该发行版本仅支持“Dubbo 暴露的服务 URL 列表”，“Dubbo 订阅的服务 URL 列表”和“Dubbo 服务定义”，这三种元数据分别来源于接口的三个方法。当 Consumer 使用了更高的 Dubbo 版本，并需要获取“Dubbo 服务 REST 元信息”时，自然无法从 Provider 端获取。假设 MetadataService 为其新增一个方法，那么，当 Consumer 发起调用时，那么这个调用自然会失败。即使两端使用的版本相同，那么 Provider 仍有可能选择性支持特定的元数据类型。为了确保元数据接口的兼容性，MetadataService 应具备元数据类型支持的判断。如此设计，MetadataService 在元数据类型上支持更具有弹性。

事件驱动架构

相较于传统的 Dubbo 架构，服务自省架构的执行流程更为复杂，执行动作之间的关联非常紧密，如 Dubbo Service 服务实例注册前需要完成 Dubbo 服务 revision 的计算，并将其添加至服务实例的 metadata 中。又如当 Dubbo Service 服务实例出现变化时，Consumer 元数据需要重新计算。这些动作被 “事件”（Event）驱动，驱动者被定义为“事件分发器”（ EventDispatcher ），而动作的处理则由“事件监听器”（EventListener）执行，三者均为 “Dubbo 事件“的核心组件，同样由 Dubbo 2.7.5 引入。不过，Dubbo 事件是相对独立的架构，不过被服务自省中的“服务注册与发现架构”和“元数据服务架构”依赖。

Dubbo 内建事件

Dubbo 内建事件可归纳为以下类型：

Dubbo 服务类型事件
Dubbo Service 类型事件
Dubbo 服务实例类型事件
Dubbo 服务注册和发现类型事件

Dubbo 服务类型事件

事件类型	事件触发时机
`ServiceConfigExportedEvent`	当 Dubbo 服务暴露完成时
`ServiceConfigUnexportedEvent`	当 Dubbo 服务下线后
`ReferenceConfigInitializedEvent`	当 Dubbo 服务引用初始化后
`ReferenceConfigDestroyedEvent`	当 Dubbo 服务引用销毁后

Dubbo Service 类型事件

事件类型	事件触发时机
`DubboShutdownHookRegisteredEvent`	当 Dubbo ShutdownHook 注册后
`DubboShutdownHookUnregisteredEvent`	当 Dubbo ShutdownHook 注销后
`DubboServiceDestroyedEvent`	当 Dubbo 进程销毁后

Dubbo 服务实例类型事件

事件类型	事件触发时机
`ServiceInstancePreRegisteredEvent`	当 Dubbo 服务实例注册前
`ServiceInstanceRegisteredEvent`	当 Dubbo 服务实例注册后
`ServiceInstancePreUnregisteredEvent`	当 Dubbo 服务实例注销前
`ServiceInstanceUnregisteredEvent`	当 Dubbo 服务实例注销后
`ServiceInstancesChangedEvent`	当某个 Dubbo Service 下的服务实例列表变更时

Dubbo 服务注册和发现类型事件

事件类型	事件触发时机
`ServiceDiscoveryInitializingEvent`	当 Dubbo 服务注册与发现组件初始化中
`ServiceDiscoveryInitializedEvent`	当 Dubbo 服务注册与发现组件初始化后
`ServiceDiscoveryExceptionEvent`	当 Dubbo 服务注册与发现组件异常发生时
`ServiceDiscoveryDestroyingEvent`	当 Dubbo 服务注册与发现组件销毁中
`ServiceDiscoveryDestroyedEvent`	当 Dubbo 服务注册与发现组件销毁后

结束语

What’s the next?

2019 java 趋势报告 infoq 采访稿（小马哥部分）

Thu, 05 Sep 2019 00:00:00 +0000

趋势报告框架

第一部分：Java的技术采用生命周期

这部分采用与英文站同样的标准划分：

创新者
早期采用者
早期大众
晚期大众

技术采用生命周期是美国高科技营销大师杰弗里·摩尔在自己的书《跨越鸿沟》里提出的概念。技术采用生命周期是一个用来衡量用户对某项新技术接受程度的模型，它认为一个新的技术，从一开始出现到最后走向成熟，必然会经历创新者、早期采用者、早期大众、晚期大众的阶段。

虽然每个人群间都会有裂缝，但是早期采用者和早期大众之间的那条裂缝最大，这条裂缝就是传说中的“鸿沟”，只有跨越过这条鸿沟，渗透到早期大众这个人群，产品才等于是进入了主流市场。

希望您结合国内使用和发展情况，把以下技术对应到技术采用生命周期相应的不同阶段中：

Java/JVM
- Java版本（8～13）；
- OpenJDK定制版或者公开发行版，Oracle JDK, OpenJDK by Oracle/Redhat/Azul/Alibaba/Amazon, 或者其他；
- 非Hotspot JDK生产实践，如GraalVM、IBM OpenJ9；
- 语法与特性，例如：Lambda /Stream、Vector API等（可以从是否有哪些特性带来了突出甚至不可替代的生产价值的角度，评判他们在技术采用生命周期中的位置）；
- JVM语言，Kotlin、Scala、Groovy、其他；
不同层次的主流框架：Java EE（Jakarta EE）、Spring Framework、RxJava 、Vert.x、Netty；
微服务领域：Spring Boot/Cloud、Dubbo、TarsJava、ServiceComb、其他

小马哥（@mercyblitz）：

创新者早期采用者早期大众晚期大众

Java 13 Java 11 OpenJDK Java 8

Jakarta EE GraalVM Reactive Streams Lambda/Stream

Apache Dubbo (ECO System) Vert.x Kotlin Scala、Groovy

TarsJava RxJava/Reactor Java EE（Jakarta EE）、Netty

ServiceComb Spring Framework

Spring Boot/Cloud

Apache Dubbo

创新者	早期采用者	早期大众	晚期大众
Java 13	Java 11	OpenJDK	Java 8
Jakarta EE	GraalVM	Reactive Streams	Lambda/Stream
Apache Dubbo (ECO System)	Vert.x	Kotlin	Scala、Groovy
	TarsJava	RxJava/Reactor	Java EE（Jakarta EE）、Netty
	ServiceComb		Spring Framework
			Spring Boot/Cloud
			Apache Dubbo

InfoQ英文站结果供参考

第二部分：Java趋势点评

对第一部分中您所归类的处于不同阶段的技术，请您逐一做出如下点评问题包括：

某个技术为什么要被划在这个技术采用生命周期内？这个技术在国内的发展情况以及机遇和挑战是什么？

小马哥（@mercyblitz）：

Java / JVM 语言 - Java 8 已被业界普遍接受，无论像 Spring Framework、Spring Boot，以及 Spring Cloud 这样的现代 Java 框架，还是类似于 Vert.x、RxJava 或 Reactor 这类小众框架，均已构建在 Java 8 以及更高的版本之上。同时，Lambda 语法以及 Stream API 也在开发人员的日常工作中广泛地运用，并且没有看到语法回退的趋势。因此，Java 8 和 Lambda/Stream 可归类为“晚期大众”。 JVM 语言 Scala 和 Groovy 已快成为明日黄花，往昔的光芒逐渐地被后期之秀 Kotlin 替代，故 Scala 和 Groovy 属于“晚期大众”，而 Kotlin 则纳入”早期大众“ 之流。然而 Java 9 的被接受程度则没有那么幸运，尽管我们等待它的到来已有数年。 Java 模块化作为 Java 9 核心的特性，就我个人而言，完全能够理解和接受它的设计。虽然模块化增强了模块的隔离性，减少了内存的 Footprint，然而，它更强的封装性无形之中增加了管理依赖的成本。所谓曲高和寡，夸张地说，模块化形同虚设。因此，应用升级 Java 9 的效果相当于 Java API 以及 JVM 的更新。同时，Oracle 宣布从 Java 9 开始，每半年将更新一个 Java 大版本。那么，更多的人会选择 Java 11 这样的长期支持（Long-Term -Support, LTS）版本，换言之，Java 9/10 则成了过渡版本（non‑LTS）¹。因此，Java 11 将是未来 Java 用户的最可能选项，将其列为“早期采用者”。至于 Java 13，最近有注意到该本版在新 GC 算法的提升以及 Socket 实现上的变化²，还是非常令人期待的，故排在“创新者” 之列。除了模块化之外，Java 9 还有大量的 API 更新，在偏开发侧的部分，Flow API 可能是最有吸引力的，提供了 Reactive Streams³ 标准接口以及实现，并且内建了 HTTP Client Reactive 实现。尽管 Spring 和 Eclipse 社区大力的推广，并且 Java Lambda 以及 Stream API 也流行开来，不过对开发者而言，Reactive Streams 技术还是相对陌生，将其放在 “早期大众“。同理，Spring 引入的 Reactor 框架也属于“早期大众” 阶段。虽然 RxJava 并非 Reactive Streams 的实现，但是相较于前两者而言，它在 Reactive 编程中的地位必然是有过之而无不及的，故也在 “早期大众“ 之中。

OpenJDK - 由于 Oracle 宣布 2019 年伊始，Oracle JDK 8 以及更高版本在服务器端部署不再免费，OpenJDK 则成为大多数 Java 用户的选项。尽管 Oracle JDK 与 OpenJDK 几乎出至于同一家之手，不过OpenJDK 很可能被认为是一种退而求其次的选择。对于具备自主研发的企业，它们可能选择在 OpenJDK 的基础上，自定义分支继续开发。在一定程度上，Java 的发展方向出现了裂痕，所以未来仍存在着不确定性，故将其放置于 “早期大众“

非Hotspot JDK生产实践 - 按照 GraalVM 官方的描述，GraalVM 将会是下一代的 JVM 基础设施，也是 Oracle 的重点项目，能够将传统的 JVM 进程 native 化，那么未来 Java 的性能提升以及快速启停则不再遥远，不够目前还尚不可知其兼容性情况以及明确的商业化条款，列为“早期采用者 应该是合理的

不同层次的主流框架

Java EE - 在 Java 生态中，绝大多数应用直接或间接地使用了 Spring Framework，这个曾经以轻量级著称的框架，目前显然“名不副实”，不过巨大的用户基础，早已进入“晚期大众”的行列。相反，Java EE 规范或者重组后的 Jakarta EE⁴ 则寂寥许多。实际上，作为 J2EE 或 Java EE 的模仿者，尽管 Spring Framework 多半的特性和实现向 JSR⁵ 参考。一定程度上，Spring Framework 的流行“压缩”了 Java EE 以及 JSR 的认知空间，因此不少的开发人员不知道 Java EE API 或者 JSR 的存在，尤其是年轻的国内从业人员。当然，Spring 也反哺了少量标准给 Java EE，比如 JSR 330⁶，因此，将 Java EE 列为 “晚期大众” 是毋容置疑的。值得一提的是，Jakarta EE 在 Eclipse 基金会⁷的带领下能否再次“伟大” 值得期待，后续未来 Jakarta EE 将是“创新者”成员

网络框架 - Java 的网络框架只有两种，其一是 Netty，其二则是其他。如此描述也丝毫不夸张，毕竟大多数与网络相关的框架或中间件都和 Netty 多少存在关联，如 Apache Dubbo、Spring 5 Web Server、Jersey 等，所以“晚期大众”的排行众望所归。

微服务框架 - Java 微服务框架的王者非 Spring Boot 和 Spring Cloud 莫属，进过数年的生产使用，两者早已属于“晚期大众” 的技术栈。相对应地，Apache Dubbo 出现和开源的时间比 Spring Cloud 早不少，无论是性能还是稳定性，相对于后者要优秀不少，因此，Apache Dubbo 也属于 “晚期大众” 框架。不过，最新的 Apache Dubbo ECO System（生态系统）则基于 Apache Dubbo 衍进的 Cloud Native 解决方案，目前尚未枝叶茂盛，处于 “创新者” 阵营。而小众的 Vert.x 则由于编程模型以及 API 熟悉度等客观条件所限，它不得不仍处于 ”早期采用者”。类似，TarsJava 以及 ServiceComb 最近才出现，用户的认可度和稳定性稍微成熟，同样处于 ”早期采用者”。

国内是否在某个相对完整的领域，形成甚至开始引领技术趋势？

小马哥（@mercyblitz）：

在国内的开源软件中，Apache Dubbo（后文简称 Dubbo）常年受到业界的青睐，并荣获多次殊荣。个人认为 Dubbo 有机会引领技术趋势。Dubbo 从过去的高性能 RPC 框架，正在走向 Cloud Native 的生态系统（后文简称 Dubbo ECO System）。具体执行的步骤也是 Dubbo 社区对 Cloud Native 的发展趋势研判，首要场景是 Dubbo 在 Spring Cloud 之间的整合。这部分工作已在 Spring Cloud Alibaba 项目中完成，作为项目中的核心成员，Dubbo Spring Cloud 可无缝地替换过传统 Spring Cloud OpenFeign，不仅提供更好的性能，并且具备更多的负载均衡策略和熔断等特性。同时，灵活的扩展点和内建实现帮助 Dubbo 适应不同语言、环境和基础设施。随着 Dubbo 内核即将发布 Cloud Native（即将发布）特性，能够将 Dubbo 帮助独立于任意的基础设施，实现 Dubbo（原生）与 Spring Cloud（原生）调用互通，甚至在 K8S 场景下。无论 Dubbo 身处何处，统一的编程模型帮助开发人员快速和高效地实现业务逻辑，达成 “Write Once, Run Anywhere” 的目的。后续，Dubbo 在多语言、Mesh 化以及 Istio 的建树将逐一呈现。

第三部分：应用实践

请您尽可能详细地回答以下问题，这些问题的回答除了作为趋势报告的一部分之外，还可以作为您所在企业的技术实践，单独成文（InfoQ记者将针对每位嘉宾所在企业和技术实践，补充个性化问题）：

Java相关：

您的企业使用的JDK版本情况，是否采用了某个OpenJDK 发行版？您如何看待OpenJDK 在国内的发展？（如果没有采用，原因以及后续计划？）

小马哥（@mercyblitz）：

在开源方面， OpenJDK 的选择仅为 Oracle 官方提供。如果是公司内部的话，则是 OpenJDK Alibaba 的分支。OpenJDK 在国内直接拿去使用的多，有能力围之扩展的公司凤毛菱角。可能随着 OpenJDK 不同分支的成熟，未来国内公司选择面将会更广
您的企业目前在支持Java技术栈方面的策略是什么？计划和目标是什么？相关的核心痛点或者业务需求是什么？

小马哥（@mercyblitz）：

关于公司在战略层面的设定，个人是不是非常清楚的。不过，作为一名基础设施的研发人员，自身遇到和周遭听到同事抱怨的痛点还是存在的。比如，Java 9 之后的版本更新问题。 Reactive Streams 推广和落地时的阻碍，毕竟大多数开发人员从事业务开发，业务系统的稳定性是他们核心 KPI 之一，他们缺少足够的勇气和动力蒸腾新技术的引进、也没有时间和精力关注其中细节，尤其当没有明显特性变化的基础设施和 API 升级时。对于本人而言，我比较关心 JVM 中的变化，包括 GC 算法和性能提升，比如 C1 和 C2 编译所导致的延迟和资源开销，如何帮助 JVM 快速启停，因为这些会限制 Java 作为编程语言在云原生时代的想象空间
对于当前Java的整体发展情况，您有什么感想？

小马哥（@mercyblitz）：

Java 目前仍具在编程语言排行榜上夺魁，不过在整体比重上微幅下滑。个人看来，未来这个趋势还将持续。究其原因，一方面是由于新语种出现的中短期效应，一方面是 Java 的编程复杂度并没有明显的降低，比如 I/O 处理、并发/并行计算，以及类加载等等。再者是 Java 与操作系统之间的交互仍不够充分，尽管 Java 9 开始提供了不少的 API，然而了解和使用的群体不足。Java 在这方面明显不及 GO 语言。

从语言层面来看，Java 正在向主流非 Java 语言融合，解决其中鸿沟的起手式就是语法的变化，比如 Java 8 的 Lambda 表达式和 Java 10 的局部变量类型（var ）等。个人认为这是一件好事，未来前后端不分家，相互渗透，对于彼此语言都是良性发展。

除此之外，个人比较期待的是 GraalVM 对 Java 的改变，传统 Java 应用必须依赖 JVM 进程加载字节码后解释执行，无法保证所有的代码能够在运行期编程完成，不免有运行时编译所带来的性能开销，从而影响 JVM 的启停时间，简单地说，这种方式不够 Native，对于云原生或许不够友好。如果未来 GraalVM 的社区版也能够像 OpenJDK 那般“亲民”，那么，Java 的变化将是颠覆性的

微服务相关：

请介绍您的企业是否进行了微服务实践？如果是，在整体系统架构中的比例是多少？如果不是，是否有相关计划？

小马哥（@mercyblitz）：

大多数应用已实施微服务架构，微服务应用的比重高达8成以上
您所采用的主要微服务框架是什么？如何判断国内该领域的技术发展情况？您认为微服务主流框架的争夺是否尘埃落定？

小马哥（@mercyblitz）：

采用的微服务架构主要以 Spring Boot/Cloud 以及 Apache Dubbo 为主，同时这也是国内大多数公司作为微服务框架的选择。不过，在国内，一直都有 Spring Cloud 与 Apache Dubbo 的优劣之争，然而这个争端似乎没有持续太长的时间，因为随着 Dubbo Spring Cloud（作为 Spring Cloud Alibaba 的一部分）发布之后，强强联合，互补互助
您如何看待Service Mesh在国内的发展现状和发展前景？

小马哥（@mercyblitz）：

个人对 Service Mesh 的看法是乐观偏谨慎的，一方面，作为从业人员，对于技术总有猎奇的心态。另外一方面，这个技术在设计上存在一些理想主义，比如，性能损耗以及稳定性，并且分布式场景中的典型问题并没有得到解决和改善，比如数据一致性、分布式事务等。据我所知，国内不少的互联网公司，如阿里巴巴、蚂蚁金服以及美团等已经开始在生产环境试点 Service Mesh，听起来这是一件好事。前沿的技术总有有人去探险。如果成功，前人栽树，后人乘凉。至于它能否成功，主要看市场是否愿意买单

参与专家：

小马哥（@mercyblitz），《Spring Boot 编程思想》作者、Apache Dubbo PMC 和 Spring-Cloud-Alibaba Architect

Oracle Java SE Support Roadmap - https://www.oracle.com/technetwork/java/java-se-support-roadmap.html ↩
Java Performance Tuning News August 2019 - http://www.javaperformancetuning.com/news/news225.shtml ↩
Reactive Streams JVM - https://github.com/reactive-streams/reactive-streams-jvm ↩
Jakarta EE - https://jakarta.ee/ ↩
Java Community Process - https://jcp.org/en/home/index ↩
JSR 330: Dependency Injection for Java - https://jcp.org/en/jsr/detail?id=330 ↩
Eclipse Foundation - https://www.eclipse.org/org/foundation/ ↩

Service mesh 时代，dubbo 架构该怎么跟进？

Tue, 18 Jun 2019 00:00:00 +0000

原文链接：Service Mesh 时代，Dubbo 架构该怎么跟进？，来自于微信公众号：次灵均阁

导读：6月21-23日，2019 GIAC全球互联网架构大会将于深圳举行。GIAC是面向架构师、技术负责人及高端技术从业人员的年度技术架构大会，是中国地区规模最大的技术会议之一。今年GIAC邀请到了众多布道师、明星讲师以及105位来自Google、微软、Oracle、eBay、百度、阿里、腾讯、商汤、图森、字节跳动、新浪、美团点评等公司专家出席。

在大会前夕，高可用架构采访了本届 GIAC Java分论坛讲师小马哥，就目前大家广泛关注的Dubbo/微服务相关的问题进行了访谈。

作为 Duboo 核心开发者，请先简单介绍下自己

答：大家好，我是小马哥（mercyblitz），一名学习当爸爸的父亲，Java 劝退师，Apache Dubbo PMC、Spring Cloud Alibaba项目架构师，《Spring Boot 编程思想》的作者。目前主要负责集团中间件开源项目、微服务技术实施、架构衍进、基础设施构建等。

Spring Cloud 和 Duboo 在微服务方面的优劣分别是什么？

答：在 Java 生态中，Spring Cloud 和 Dubbo 都是微服务框架。前者被业界常作为 Java 微服务的首选框架，而后者有时被错误地解读为服务治理的 RPC 框架。实际上，两者在微服务架构中并没有本质的差异，均是分布式应用服务治理的框架。

在开发体验方面，Spring Cloud 开箱即用的组件让人印象深刻。在 API 抽象和设计方面，流淌着 Spring 家族血液的 Spring Cloud 延续了父辈的荣耀。由此观之，Dubbo 与其存在差距。

然而随着实践的不断深入，Spring Cloud 功能的稳定性以及版本的兼容性等问题较为突出。当应用集群达到一定规模时，其分布式经验上的短板也随之暴露，尤其是 Spring Cloud Netflix 套件，比如 Eureka 与 Ribbon 之间的 90 秒延迟会影响服务调用的成功率，以及负载均衡算法缺少权重无法帮助 JVM 预热。简言之，在服务治理方面，Spring Cloud 相较于 Dubbo 而言，并不算太成熟。如果大家有兴趣了解更多的话，可参考「小马哥技术周报」。

总之，Spring Cloud 和 Dubbo 各有特色，过度地关注彼此优劣并不可取。为此，Spring Cloud Alibaba 项目综合两家之长，提供了一套名为 Dubbo Spring Cloud 的整容实现，使得 Dubbo 与 Spring Cloud 不再是互斥性选项。

请介绍下 Duboo 的现状？

答：2019年5月16日，Apache 软件基金会董事会决议通过了 Apache Dubbo 的毕业申请，这意味着 Apache Dubbo 正式成为 Apache 的顶级项目。Apache Dubbo 项目在 Github 上的 star 数已超过 2.7 万，contributors 人数达到 202，Commiters 人数也升至 32 人，借此机会感谢所有关系和参与 Apache Dubbo 建设的小伙伴。目前，项目主要包含三大核心的分支，均在并行开发。其中，2.6.x 处于维护状态；2.7.x 聚焦云原生微服务方向，3.0.x 则指定未来标准和技术走向。简言之，Dubbo 不再是纯粹的 Java 服务治理 RPC 框架，已经逐渐成为多语种 Cloud Native 基础设施的中坚力量。

Duboo在成为Apache顶级项目的过程中，背后有哪些不为人知的故事？

答：Dubbo 在 Apache 从孵化到毕业，期间的确有太多不为人知的故事，这里我简单地介绍一下其中孵化过程：

筹备期（2017.12-2018.2）：最主要的工作是准备进入孵化器相关的材料，比如寻找合适的导师，编写加入孵化器的提案等。
初始期（2018.2-2018.5）：主要完成的工作主要是完成知识产权的清理，邮件列表的创建，代码迁移等工作。
首次 Release：Apache孵化项目第一个重要的里程碑，第一次Release非常关键，除了确保功能的稳定以外，最重要的就是需要确保引入的代码的许可证符合Apache的政策，Apache对于许可证有着明确的规定。
社区发展（Community Building）：也是作为一个Apache项目非常看重的一环。最不愿意看到的就是一家公司独大，控制整个项目，对于Dubbo来说，经过这么多年的发展，在国内已经具备了一定的渗透率，有了不少用户，但是他们就像花粉一样散落在各个角落里面，需要做的事情就是把他们都聚集起来。

在未来一年，Duboo的新特性路线图可以简单介绍下吗？

答：由于 Dubbo 2.6.x 处于维护状态，不会新增明显的功能特性。

本年度主要的发力点在 Dubbo 2.7 这个版本上，该版本致力于 Cloud Native 以及微服务领域，大致的路线计划为

2.7.2 - Metrics、etcd 元数据、nacos 配置与元数据以及 2.6 兼容
2.7.3 - Cloud Native 注册机制、服务自省以及 Dubbo Proxy
2.7.4 - K8s 原生支持（服务发现、元数据存储和配置推送）、Dubbo GO 以及 gRPC 集成
2.7.5 - 服务治理规则支持 Pilot CRD
2.7.6 - 控制面 xDS API 对接

Dubbo 3.0.0 M1 版本的核心特性围绕在 RSocket、Reactive 以及异步化上的支持。 M2 版本计划将在 8 月发布，主要提供对 HTTP/2 的支持和性能调优。接下来的 M3 版本将通过 HTTP/2 支持 gPRC 以及 Rocket 通讯协议。3.0.0 正式的发布将安排在 2020 年的 2 月。

Duboo 开源以来，代码贡献者中阿里本身的开发者占绝大多数，这是否意味着来自阿里的需求会起主导作用？在后续的发展过程中，计划如何引入阿里之外的开发者？

答：尽管目前 Apache Duboo 代码贡献者主要来自于阿里的开发人员，不过这个比重正在迅速地变小，一方面说明 Dubbo 用户人数在逐渐变大，专业程度在不断地变深，同时，也说明有意主导并且贡献的小伙伴越来越活跃。这无论对社区的发展，还是从业人员的职业技能均有裨益。因此，需求的来源不再已阿里为绝对主导，社区共建和共制的发展模式已成事实。

Service Mesh 时代，需要什么样的微服务框架？

答：哈哈，需要 Dubbo 这样的框架（玩笑）。首先，个人并不是 Service Mesh 方面的专家，就目前所得到掌握的信息，Service Mesh 并不算成熟的技术，换言之，目前还不是 Service Mesh 的时代，甚至我听到不少的朋友由于性能和稳定性方面的原因，从该架构中退化，这也是 Dubbo 在 Service Mesh 方面的衍进相对缓慢的原因之一。当然，技术的发展总会是在掌声伴随着嘘声中前进，因此，个人对于 Service Mesh 的看法是谨慎乐观的。

对于公司内部定制Dubbo而言，你有什么建议吗？

答：流水不腐户枢不蠹，我希望这些公司能够积极参与 Dubbo 社区的共建，或许这些定制化的场景也可以服务其他场景。大家互通有无，实现共同进步。

对于初级开发者而言，学习Duboo应该如何入手？对于资深开发者而言，怎样研究Dubbo的源代码更加高效？

答：对于初级开发者，我的建议是首先从 Apache Dubbo 官网（https://dubbo.apache.org）学习《用户文档》，初步了解了 Dubbo 架构和特性后，再结合 Dubbo 官方样例（https://github.com/apache/dubbo-samples）全面掌握 Dubbo 功能和最佳实践。最后，参考官方博客（http://dubbo.apache.org/zh-cn/blog/index.html），深度理解 Dubbo。

对于资深开发者，尤其是那些致力于贡献的小伙伴，我建议参考《开发者文档》，掌握 Dubbo 设计和实现，并且结合 Dubbo 的源码巩固学习，最好直接贡献代码（在 GitHub Pull Request），战胜心中一切的畏惧。如果仍不满足于此，强烈推荐参考 Apache Dubbo PMC 商宗海（花名：诣极）编写并即将出版的书籍 - 《深入理解 Apache Dubbo 与实战》，从中本人也受益匪浅，建议小伙们入手。

你作为讲师参加GIAC，对本次GIAC大会有何寄语？

答：非常感谢 GIAC 的主办方给本人这次机会分享 Dubbo 相关的的议程，这也是我本人第二次在 GIAC 分享该主题了。我衷心地祝福 GIAC 影响力越做越大，希望能够走出国门，成为具有国际化影响力的技术组织，向世界传播技术和力量。

作为Duboo的开发者，你最喜欢的Java（Java8以后）特性是什么？你最希望加入的Java特性是什么？

答：Java 8 是 Dubbo 2.7 默认的语言级别，其中 Lambda 表达式以及 Stream API 被广泛地使用。除此之外，本人同样偏好使用 CompletableFuture 作为并行编程的 API。我最希望 Java 增加 JVM 级别的协程支持。

简单介绍下你自己的从业经历？

答：今年是我从业的第十二个年头，这些年一直在从事 Java 研发。首个雇主是一家外企公司，为其服务了三年。外企的工作相对轻松，拥有充分的自主时间提升技能，同时也有机会提升英语水平。期间通过了 SUN Java（SCJP、SCWCD、SCBCD）以及 Oracle OCA 等的认证，尽管这些证书并没有受到国内雇主的重视，不过对我后续的职业产生了深远的影响。当然，事情并不是总是积极正面，东西方文化差异，以及部分外籍同事的傲慢与偏见着实让本人对西方的技术和文化重新开始审视。既然无法改变，那么离开并继续深造或许是必然的选择，希望有一天能够通过共同的努力，让世界看到中华的进步。于是，我的第一份工作就在 2010 年 10 月 1 号画上了句点。迎接我的是第二份工作，至今也快九个年头。这几年，我经历了很多、学到了很多，也成长了很多，岂能尽如人意，但求无愧我心。不可否认的是，儒家思想对我的影响最为深刻，它让我学会独立、理性以及辩证的思考，培养我处变不惊的人生态度，直接或间接地提升了专业素质。经过数年的沉寂，我也明确了自己的方向，辗转投入开源社区的建设。不过，纵使浑身是铁能打几根钉，开源社区的发展需要更多的能人参与，知之者不如好之者，好之者不如乐之者。然而现实的情况又有些残酷，不少的年轻人在经济的压力下，逐渐失去对技术的追求。于是从 2016 年开始，我便尝试做一些技术分享，希望能够帮助到部分年轻从业人员，使他们对技术产生兴趣。随后，我又着手编写《Spring Boot 编程思想》，希望读者能够理解规范和基础的重要性，如果读者从中能够培养自己系统化的知识体系或者思维方式，那就善莫大焉了。我也时常鼓励更多的小伙伴多多分享，无论是免费，还是收费。同时，注重知识产权的保护，树立良好的生态环境。当然，我的第二份职业尚未告一段落，或许等它结束之际，方可“盖棺定论“。总之，但行好事，莫问前程。

书籍推荐

-《Spring Boot 编程思想（核⼼心篇）》 https://item.jd.com/12570242.html

本书全名为《Spring Boot 编程思想》，是以 Spring Boot 2.0 为讨论的主线，讨论的范围将涵盖 Spring Boot 1.x 的所有版本，以及所关联的 Spring Framework 版本，致力于：

场景分析：掌握技术选型

系统学习：拒绝浅尝辄止

重视规范：了解发展趋势

源码解读：理解设计思想

实战演练：巩固学习成果

Dubbo spring cloud 重塑微服务治理

Fri, 26 Apr 2019 00:00:00 +0000

原文链接：Dubbo Spring Cloud 重塑微服务治理，来自于微信公众号：次灵均阁

摘要

在 Java 微服务生态中，Spring Cloud¹ 成为了开发人员的首选技术栈，然而随着实践的深入和运用规模的扩大，大家逐渐意识到 Spring Cloud 的局限性。在服务治理方面，相较于 Dubbo² 而言，Spring Cloud 并不成熟。遗憾的是，Dubbo 往往被部分开发者片面地视作服务治理的 RPC 框架，而非微服务基础设施。即使是那些有意将 Spring Cloud 迁移至 Dubbo 的小伙伴，当面对其中迁移和改造的成本时，难免望而却步。庆幸的是，Dubbo 生态体系已发生巨大变化，Dubbo Spring Cloud 作为 Spring Cloud Alibaba³ 的最核心组件，完全地拥抱 Spring Cloud 技术栈，不但无缝地整合 Spring Cloud 注册中心，包括 Nacos⁴、Eureka⁵、Zookeeper⁶ 以及 Consul⁷，而且完全地兼容 Spring Cloud Open Feign⁸ 以及 @LoadBalanced RestTemplate，本文将讨论 Dubbo Spring Cloud 对 Spring Cloud 技术栈所带来的革命性变化。

注：由于 Spring Cloud 技术栈涵盖的特性众多，因此本文讨论的范围仅限于服务治理部分。

简介

Dubbo Spring Cloud 基于 Dubbo Spring Boot 2.7.1⁹ 和 Spring Cloud 2.x 开发，无论开发人员是 Dubbo 用户还是 Spring Cloud 用户，都能轻松地驾驭，并以接近“零”成本的代价使应用向上迁移。Dubbo Spring Cloud 致力于简化 Cloud Native 开发成本，提高研发效能以及提升应用性能等目的。

2019年4月19日，Dubbo Spring Cloud 首个 Preview Release，随同 Spring Cloud Alibaba 0.2.2.RELEASE 和 0.9.0.RELEASE 一同发布¹⁰，分别对应 Spring Cloud Finchley¹¹ 与 Greenwich¹² (下文分别简称为 “F” 版和 “G” 版) 。

版本支持

由于 Spring 官方宣布 Spring Cloud Edgware(下文简称为 “E” 版) 将在 2019 年 8 月 1 号后停止维护13，因此，目前 Dubbo Spring Cloud 发布版本并未对 “E” 版提供支持，仅为 “F” 版和 “G” 版开发，同时也建议和鼓励 Spring Cloud 用户更新至 “F” 版或 “G” 版。

同时，Dubbo Spring Cloud 基于 Apache Dubbo Spring Boot 2.7.1 开发（最低 Java 版本为 1.8），提供完整的 Dubbo 注解驱动、外部化配置以及 Production-Ready 的特性，详情请参考：https://github.com/apache/incubator-dubbo-spring-boot-project

以下表格将说明 Dubbo Spring Cloud 版本关系映射关系：

Spring Cloud	Spring Cloud Alibaba	Spring Boot	Dubbo Spring Boot
Finchley	`0.2.2.RELEASE`	`2.0.x`	`2.7.1`
Greenwich	`0.9.0.RELEASE`	`2.1.x`	`2.7.1`
Edgware	`0.1.2.RELEASE`	`1.5.x`	:x: Dubbo Spring Cloud 不支持该版本

功能特性

由于 Dubbo Spring Cloud 构建在原生的 Spring Cloud 之上，其服务治理方面的能力可认为是 Spring Cloud Plus，不仅完全覆盖 Spring Cloud 原生特性¹³，而且提供更为稳定和成熟的实现，特性比对如下表所示：

功能组件	Spring Cloud	Dubbo Spring Cloud
分布式配置（Distributed configuration）	Git、Zookeeper、Consul、JDBC	Spring Cloud 分布式配置 + Dubbo 配置中心¹⁴
服务注册与发现（Service registration and discovery）	Eureka、Zookeeper、Consul	Spring Cloud 原生注册中心¹⁵ + Dubbo 原生注册中心¹⁶
负载均衡（Load balancing）	Ribbon（随机、轮询等算法）	Dubbo 内建实现（随机、轮询等算法 + 权重等特性）
服务熔断（Circuit Breakers）	Spring Cloud Hystrix	Spring Cloud Hystrix + Alibaba Sentinel¹⁷ 等
服务调用（Service-to-service calls）	Open Feign、`RestTemplate`	Spring Cloud 服务调用 + Dubbo `@Reference`
链路跟踪（Tracing）	Spring Cloud Sleuth¹⁸ + Zipkin¹⁹	Zipkin、opentracing 等

高亮特性

1. Dubbo 使用 Spring Cloud 服务注册与发现

Dubbo Spring Cloud 基于 Spring Cloud Commons 抽象实现 Dubbo 服务注册与发现，应用只需增添外部化配置属性 “dubbo.registry.address = spring-cloud://localhost”，就能轻松地桥接到所有原生 Spring Cloud 注册中心，包括：

Nacos
Eureka
Zookeeper
Consul

Dubbo Spring Cloud 将在下个版本支持 Spring Cloud 注册中心与 Dubbo 注册中心并存，提供双注册机制，实现无缝迁移。

2. Dubbo 作为 Spring Cloud 服务调用

默认情况，Spring Cloud Open Feign 以及 @LoadBalanced RestTemplate 作为 Spring Cloud 的两种服务调用方式。Dubbo Spring Cloud 为其提供了第三种选择，即 Dubbo 服务将作为 Spring Cloud 服务调用的同等公民出现，应用可通过 Apache Dubbo 注解 @Service和 @Reference 暴露和引用 Dubbo 服务，实现服务间多种协议的通讯。同时，也可以利用 Dubbo 泛化接口轻松实现服务网关。

3. Dubbo 服务自省

Dubbo Spring Cloud 引入了全新的服务治理特性 - 服务自省（Service Introspection），其设计目的在于最大化减轻注册中心负载，去 Dubbo 注册元信息中心化。假设一个 Spring Cloud 应用引入 Dubbo Spring Boot Starter，并暴露 N 个 Dubbo 服务，以 Dubbo Nacos 注册中心为例，当前应用将注册 N+1 个 Nacos 应用，除 Spring Cloud 应用本身之前，其余 N 个应用均来自于 Dubbo 服务，当 N 越大时，注册中心负载越重。因此，Dubbo Spring Cloud 应用对注册中心的负载相当于传统 Dubbo 的 N 分之一，在不增加基础设施投入的前提下，理论上，使其集群规模扩大 N 倍。当然，未来的 Dubbo 也将提供服务自省的能力。

4. Dubbo 迁移 Spring Cloud 服务调用

尽管 Dubbo Spring Cloud 完全地保留了原生 Spring Cloud 服务调用特性，不过 Dubbo 服务治理的能力是 Spring Cloud Open Feign 所不及的，如高性能、高可用以及负载均衡稳定性等方面。因此，建议开发人员将 Spring Cloud Open Feign 或者 @LoadBalanced RestTemplate 迁移为 Dubbo 服务。考虑到迁移过程并非一蹴而就，因此，Dubbo Spring Cloud 提供了方案，即 @DubboTransported 注解。该注解能够帮助服务消费端的 Spring Cloud Open Feign 接口以及 @LoadBalanced RestTemplate Bean 底层走 Dubbo 调用（可切换 Dubbo 支持的协议），而服务提供方则只需在原有 @RestController 类上追加 Dubbo @Servce 注解（需要抽取接口）即可，换言之，在不调整 Feign 接口以及 RestTemplate URL 的前提下，实现无缝迁移。如果迁移时间充分的话，建议使用 Dubbo 服务重构系统中的原生 Spring Cloud 服务的定义。

简单示例

开发 Dubbo Spring Cloud 应用的方法与传统 Dubbo 或 Spring Cloud 应用类似，按照以下步骤就能完整地实现Dubbo 服务提供方和消费方的应用，完整的示例代码请访问一下资源：

Dubbo 服务提供方应用 - https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-examples/spring-cloud-alibaba-dubbo-examples/spring-cloud-dubbo-server-sample
Dubbo 服务消费方应用 - https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-examples/spring-cloud-alibaba-dubbo-examples/spring-cloud-dubbo-client-sample

定义 Dubbo 服务接口

Dubbo 服务接口是服务提供方与消费方的远程通讯契约，通常由普通的 Java 接口（interface）来声明，如 EchoService 接口：

public interface EchoService {

    String echo(String message);
}

为了确保契约的一致性，推荐的做法是将 Dubbo 服务接口打包在第二方或者第三方的 artifact（jar）中，如以上接口就存放在 artifact spring-cloud-dubbo-sample-api 之中。

对于服务提供方而言，不仅通过依赖 artifact 的形式引入 Dubbo 服务接口，而且需要将其实现。对应的服务消费端，同样地需要依赖该 artifact，并以接口调用的方式执行远程方法。接下来进一步讨论怎样实现 Dubbo 服务提供方和消费方。

实现 Dubbo 服务提供方

初始化 `spring-cloud-dubbo-server-sample` Maven 工程

首先，创建 artifactId 名为 spring-cloud-dubbo-server-sample 的 Maven 工程，并在其 pom.xml 文件中增添 Dubbo Spring Cloud 必要的依赖：

<dependencies>
    <!-- Sample API -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dubbo-sample-api</artifactId>
        <version>${project.version}</version>
    </dependency>

    <!-- Spring Boot dependencies -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-actuator</artifactId>
    </dependency>

    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>

    <!-- Spring Cloud Nacos Service Discovery -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

以上依赖 artifact 说明如下：

spring-cloud-dubbo-sample-api : 提供 EchoService 接口的 artifact
spring-boot-actuator : Spring Boot Production-Ready artifact，间接引入 spring-boot artifact
spring-cloud-starter-dubbo : Dubbo Spring Cloud Starter artifact，间接引入 dubbo-spring-boot-starter 等 artifact
spring-cloud-starter-alibaba-nacos-discovery : Nacos Spring Cloud 服务注册与发现 artifact

值得注意的是，以上 artifact 未指定版本(version)，因此，还需显示地声明 <dependencyManagement> :

<dependencyManagement>
    <dependencies>
        <!-- Spring Cloud Alibaba dependencies -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>0.9.0.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

以上完整的 Maven 依赖配置，请参考 spring-cloud-dubbo-server-sample pom.xml 文件

完成以上步骤之后，下一步则是实现 Dubbo 服务

实现 Dubbo 服务

EchoService 作为暴露的 Dubbo 服务接口，服务提供方 spring-cloud-dubbo-server-sample 需要将其实现：

@org.apache.dubbo.config.annotation.Service
class EchoServiceImpl implements EchoService {

    @Override
    public String echo(String message) {
        return "[echo] Hello, " + message;
    }
}

其中，@org.apache.dubbo.config.annotation.Service 是 Dubbo 服务注解，仅声明该 Java 服务（本地）实现为 Dubbo 服务。因此，下一步需要将其配置 Dubbo 服务（远程）。

配置 Dubbo 服务提供方

在暴露 Dubbo 服务方面，推荐开发人员外部化配置的方式，即指定 Java 服务实现类的扫描基准包。

Dubbo Spring Cloud 继承了 Dubbo Spring Boot 的外部化配置特性，也可以通过标注 @DubboComponentScan 来实现基准包扫描。

同时，Dubbo 远程服务需要暴露网络端口，并设定通讯协议，完整的 YAML 配置如下所示：

dubbo:
  scan:
    # dubbo 服务扫描基准包
    base-packages: org.springframework.cloud.alibaba.dubbo.bootstrap
  protocol:
    # dubbo 协议
    name: dubbo
    # dubbo 协议端口（ -1 表示自增端口，从 20880 开始）
    port: -1
  registry:
    # 挂载到 Spring Cloud 注册中心
    address: spring-cloud://localhost
    
spring:
  application:
    # Dubbo 应用名称
    name: spring-cloud-alibaba-dubbo-server
  main:
    # Spring Boot 2.1 需要设定
    allow-bean-definition-overriding: true
  cloud:
    nacos:
      # Nacos 服务发现与注册配置
      discovery:
        server-addr: 127.0.0.1:8848

以上 YAML 内容，上半部分为 Dubbo 的配置：

dubbo.scan.base-packages : 指定 Dubbo 服务实现类的扫描基准包
dubbo.protocol : Dubbo 服务暴露的协议配置，其中子属性 name 为协议名称，port 为协议端口（ -1 表示自增端口，从 20880 开始）
dubbo.registry : Dubbo 服务注册中心配置，其中子属性 address 的值 “spring-cloud://localhost”，说明挂载到 Spring Cloud 注册中心

当前 Dubbo Spring Cloud 实现必须配置 dubbo.registry.address = spring-cloud://localhost，下一个版本将其配置变为可选（参考 issue #592），并且支持传统 Dubbo 协议的支持（参考 issue #588）

下半部分则是 Spring Cloud 相关配置：

spring.application.name : Spring 应用名称，用于 Spring Cloud 服务注册和发现。

该值在 Dubbo Spring Cloud 加持下被视作 dubbo.application.name，因此，无需再显示地配置 dubbo.application.name
spring.main.allow-bean-definition-overriding : 在 Spring Boot 2.1 以及更高的版本增加该设定，因为 Spring Boot 默认调整了 Bean 定义覆盖行为。（推荐一个好的 Dubbo 讨论 issue #3193）
spring.cloud.nacos.discovery : Nacos 服务发现与注册配置，其中子属性 server-addr 指定 Nacos 服务器主机和端口

以上完整的 YAML 配置文件，请参考 spring-cloud-dubbo-server-sample bootstrap.yaml 文件

完成以上步骤后，还需编写一个 Dubbo Spring Cloud 引导类。

引导 Dubbo Spring Cloud 服务提供方应用

Dubbo Spring Cloud 引导类与普通 Spring Cloud 应用并无差别，如下所示：

@EnableDiscoveryClient
@EnableAutoConfiguration
public class DubboSpringCloudServerBootstrap {

    public static void main(String[] args) {
        SpringApplication.run(DubboSpringCloudServerBootstrap.class);
    }
}

在引导 DubboSpringCloudServerBootstrap 之前，请提前启动 Nacos 服务器。当 DubboSpringCloudServerBootstrap 启动后，将应用 spring-cloud-dubbo-server-sample 将出现在 Nacos 控制台界面。

当 Dubbo 服务提供方启动后，下一步实现一个 Dubbo 服务消费方。

实现 Dubbo 服务消费方

由于 Java 服务就 EchoService、服务提供方应用 spring-cloud-dubbo-server-sample 以及 Nacos 服务器均已准备完毕。Dubbo 服务消费方只需初始化服务消费方 Maven 工程 spring-cloud-dubbo-client-sample 以及消费 Dubbo 服务。

初始化 `spring-cloud-dubbo-client-sample` Maven 工程

与服务提供方 Maven 工程类，需添加相关 Maven 依赖：

<dependencyManagement>
    <dependencies>
        <!-- Spring Cloud Alibaba dependencies -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>0.9.0.RELEASE</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<dependencies>
    <!-- Sample API -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-dubbo-sample-api</artifactId>
        <version>${project.version}</version>
    </dependency>

    <!-- Spring Boot dependencies -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-actuator</artifactId>
    </dependency>

    <!-- Dubbo Spring Cloud Starter -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-dubbo</artifactId>
    </dependency>

    <!-- Spring Cloud Nacos Service Discovery -->
    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
    </dependency>
</dependencies>

与应用 spring-cloud-dubbo-server-sample 不同的是，当前应用依赖 spring-boot-starter-web，表明它属于 Web Servlet 应用。

以上完整的 Maven 依赖配置，请参考 spring-cloud-dubbo-client-sample pom.xml 文件

配置 Dubbo 服务消费方

Dubbo 服务消费方配置与服务提供方类似，当前应用 spring-cloud-dubbo-client-sample 属于纯服务消费方，因此，所需的外部化配置更精简：

dubbo:
  registry:
    # 挂载到 Spring Cloud 注册中心
    address: spring-cloud://localhost
  cloud:
    subscribed-services: spring-cloud-alibaba-dubbo-server
    
spring:
  application:
    # Dubbo 应用名称
    name: spring-cloud-alibaba-dubbo-client
  main:
    # Spring Boot 2.1 需要设定
    allow-bean-definition-overriding: true
  cloud:
    nacos:
      # Nacos 服务发现与注册配置
      discovery:
        server-addr: 127.0.0.1:8848

对比应用 spring-cloud-dubbo-server-sample，除应用名称 spring.application.name 存在差异外，spring-cloud-dubbo-client-sample 新增了属性 dubbo.cloud.subscribed-services 的设置。并且该值为服务提供方应用 “spring-cloud-dubbo-server-sample”。

dubbo.cloud.subscribed-services : 用于服务消费方订阅服务提供方的应用名称的列表，若需订阅多应用，使用 “,” 分割。不推荐使用默认值为 “*“，它将订阅所有应用。

当应用使用属性 dubbo.cloud.subscribed-services 默认值时，日志中将会输出一行警告：

Current application will subscribe all services(size:x) in registry, a lot of memory and CPU cycles may be used, thus it’s strongly recommend you using the externalized property ‘dubbo.cloud.subscribed-services’ to specify the services

由于当前应用属于 Web 应用，它会默认地使用 8080 作为 Web 服务端口，如果需要自定义，可通过属性 server.port 调整。

以上完整的 YAML 配置文件，请参考 spring-cloud-dubbo-client-sample bootstrap.yaml 文件

引导 Dubbo Spring Cloud 服务消费方应用

为了减少实现步骤，以下引导类将 Dubbo 服务消费以及引导功能合二为一：

@EnableDiscoveryClient
@EnableAutoConfiguration
@RestController
public class DubboSpringCloudClientBootstrap {

    @Reference
    private EchoService echoService;

    @GetMapping("/echo")
    public String echo(String message) {
        return echoService.echo(message);
    }

    public static void main(String[] args) {
        SpringApplication.run(DubboSpringCloudClientBootstrap.class);
    }
}

不仅如此，DubboSpringCloudClientBootstrap 也作为 REST Endpoint，通过暴露 /echo Web 服务，消费 Dubbo EchoService 服务。因此，可通过 curl 命令执行 HTTP GET 方法：

$ curl http://127.0.0.1:8080/echo?message=%E5%B0%8F%E9%A9%AC%E5%93%A5%EF%BC%88mercyblitz%EF%BC%89

HTTP 响应为：

[echo] Hello, 小马哥（mercyblitz）

以上结果说明应用 spring-cloud-dubbo-client-sample 通过消费 Dubbo 服务，返回服务提供方 spring-cloud-dubbo-server-sample 运算后的内容。

高阶示例

如果您需要进一步了解 Dubbo Spring Cloud 使用细节，可参考官方 Samples：https://github.com/spring-cloud-incubator/spring-cloud-alibaba/tree/master/spring-cloud-alibaba-examples/spring-cloud-alibaba-dubbo-examples

其子模块说明如下：

spring-cloud-dubbo-sample-api：API 模块，存放 Dubbo 服务接口和模型定义
spring-cloud-dubbo-provider-web-sample：Dubbo Spring Cloud 服务提供方示例（Web 应用）
spring-cloud-dubbo-provider-sample：Dubbo Spring Cloud 服务提供方示例（非 Web 应用）
spring-cloud-dubbo-consumer-sample：Dubbo Spring Cloud 服务消费方示例
spring-cloud-dubbo-servlet-gateway-sample：Dubbo Spring Cloud Servlet 网关简易实现示例

问题反馈

如果您在使用 Dubbo Spring Cloud 的过程中遇到任何问题，请内容反馈至 https://github.com/spring-cloud-incubator/spring-cloud-alibaba/issues

进阶阅读

关于更多的 Dubbo Spring Cloud 特性以及设计细节，请关注

Spring Cloud Alibaba wiki - https://github.com/spring-cloud-incubator/spring-cloud-alibaba/wiki
Dubbo 的博客：http://dubbo.apache.org/zh-cn/blog/index.html

下篇预告

接下的文章将会介绍 Dubbo Spring Cloud 高阶示例的运用和实现，敬请关注小马哥微信公众号：次灵均阁

获得最新 Dubbo Spring Cloud 相关资讯。

新书推荐

本书全名为《Spring Boot 编程思想》，是以 Spring Boot 2.0 为讨论的主线，讨论的范围将涵盖 Spring Boot 1.x 的所有版本，以及所关联的 Spring Framework 版本，致力于：

场景分析：掌握技术选型
系统学习：拒绝浅尝辄止
重视规范：了解发展趋势
源码解读：理解设计思想
实战演练：巩固学习成果

欢迎小伙伴在京东或当当订购京东存有少量现货（随机发送签名版），可先睹为快：http://t.cn/ExjBU2M 当当价格优惠，需要五月初发货：http://t.cn/EX0QteF

分享推荐

免费分享

收费分享

「小马哥 Java 知识星球」

深入探讨 Java 相关技术，包括行业动态，架构设计，设计模式，框架使用，源码分析等。
SegmentFault 直播
- 《Java 微服务实践 - Spring Boot / Spring Cloud》
- 《一入 Java 深似海》
慕课视频
- 《Spring Boot 2.0深度实践之核心技术篇》
慕课网
- Spring Boot 2.0深度实践之核心技术篇
- Spring Boot 2.0深度实践之生态整合篇（即将上线…）

关于作者

小马哥，Java 劝退师，Apache 和 Spring Cloud 等知名开源架构成员，点击查看详情。

Spring Cloud provides tools for developers to quickly build some of the common patterns in distributed systems (e.g. configuration management, service discovery, circuit breakers, intelligent routing, micro-proxy, control bus, one-time tokens, global locks, leadership election, distributed sessions, cluster state). - https://spring.io/projects/spring-cloud ↩

Apache Dubbo (incubating)

ˈdʌbəʊ

is a high-performance, light weight, java based RPC framework. - https://dubbo.apache.org

↩

Spring Cloud Alibaba provides a one-stop solution for distributed application development. - https://github.com/spring-cloud-incubator/spring-cloud-alibaba ↩
Nacos is an easy-to-use dynamic service discovery, configuration and service management platform for building cloud native applications - https://nacos.io/ ↩
Eureka is a REST (Representational State Transfer) based service that is primarily used in the AWS cloud for locating services for the purpose of load balancing and failover of middle-tier servers. - https://github.com/Netflix/eureka ↩
ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. - https://zookeeper.apache.org ↩
Consul is a distributed service mesh to connect, secure, and configure services across any runtime platform and public or private cloud - https://www.consul.io/ ↩
Spring Cloud Open Feign - https://github.com/spring-cloud/spring-cloud-openfeign ↩
从 2.7.0 开始，Dubbo Spring Boot 与 Dubbo 在版本上保持一致 ↩
Preview releases of Spring Cloud Alibaba are available: 0.9.0, 0.2.2, and 0.1.2 - https://spring.io/blog/2019/04/19/preview-releases-of-spring-cloud-alibaba-are-available-0-9-0-0-2-2-and-0-1-2 ↩
目前最新的 Spring Cloud “F” 版的版本为：Finchley.SR2 - https://cloud.spring.io/spring-cloud-static/Finchley.SR2/single/spring-cloud.html ↩
当前Spring Cloud “G” 版为 Greenwich.RELEASE ↩
Spring Cloud 特性列表 - https://cloud.spring.io/spring-cloud-static/Greenwich.RELEASE/single/spring-cloud.html#_features ↩
Dubbo 2.7 开始支持配置中心，可自定义适配 - http://dubbo.apache.org/zh-cn/docs/user/configuration/config-center.html ↩
Spring Cloud 原生注册中心，除 Eureka、Zookeeper、Consul 之外，还包括 Spring Cloud Alibaba 中的 Nacos ↩
Dubbo 原生注册中心 - http://dubbo.apache.org/zh-cn/docs/user/references/registry/introduction.html ↩
Alibaba Sentinel：Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性 - https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D，目前 Sentinel 已被 Spring Cloud 项目纳为 Circuit Breaker 的候选实现 - https://spring.io/blog/2019/04/16/introducing-spring-cloud-circuit-breaker ↩
Spring Cloud Sleuth - https://spring.io/projects/spring-cloud-sleuth ↩
Zipkin - https://github.com/apache/incubator-zipkin ↩

《java编程方法论响应式之rxjava篇》序

Tue, 05 Mar 2019 00:00:00 +0000

《Java编程方法论响应式之Rxjava篇》序

在《2019 一月的InfoQ 架构和设计趋势报告》¹中，响应式编程（Reactive Programming）和函数式（Functional Programing）仍旧编列在第一季度（Q1）的 Early Adopters（早期采纳者）中。尽管这仅是一家之言，然而不少的开发人员逐渐意识到 Reactive 之风俨然吹起。也许您的生产系统尚未出现 Reactive 的身影，不过您可能听说过 Spring WebFlux 或 Netflix Hystrix 等开源框架。笔者曾请教过 Pivotal（Spring 母公司）布道师 Josh Long²：”Spring 技术栈未来的重心是否要布局在 Reactive 之上？“。对方的答复是：”没错，Reactive 是未来趋势。“。同时，越来越多的开源项目开始签署 Reactive 宣言（The Reactive Manifesto）³，并喊出 ”Web Are Reactive“ 的口号。

或许开源界的种种举动无法说服您向 Reactive 的”港湾“中停靠，不过 Java 9 Flow API⁴ 的引入，又给业界注入了一剂强心针。不难看出，无论是 Java API，还是 Java 框架均走向了 Reactive 编程模型的道路，这并非是一种巧合。

通常，人们谈到的 Reactive 可与 Reactive 编程划上等号，以”非阻塞（Non-Blocking）“和”异步（Asynchronous）“的特性并述，数据结构与操作相辅相成。Reactive 涉及函数式和并发两种编程模型，前者关注语法特性，后者强调执行效率。简言之，Reactive 编程的意图在于 ”Less Code，More Efficient“。除此之外，个人认为 Reactive 更大的价值在于统一 Java 并发编程模型，使得同步和异步的实现代码无异，同时做到 Java 编程风格与其他编程语言更好地融合，或许您也发现 Java 与 JS 在 Reactive 方面并不存在本质区别。纵观 Java 在 Reactive 编程上的发展而看，其特性更新可谓是步步为营，如履薄冰。尽管 Java 线程 API Thread 与 Runnable 就已具备异步以及非阻塞的能力，然而同步和异步编程的模式并不统一，并且理解 Thread API 的细节和管理线程生命周期的成本均由开发人员概括承受。虽然 Java 5 引入 J.U.C 框架（Java 并发框架）之后， ExecutorService 实现减轻了以上负担。不过开发人员仍需关注 ExecutorService 实现细节，比如怎样合理地设置线程池空间以及阻塞队列又成为新的挑战。为此，Java 7 又引入 ForkJoinPool API，不过此时的J.U.C 框架与 Reactive 理念仍存在距离，即使是线程安全的数据结构，也并不具备并行计算的能力，如：集合并行排序，同时操作集合的手段也相当的贫瘠，缺少类似 Map/Reduce 等操作。不过这些困难只是暂时的，终究被 Java 8 ”救赎“。Stream API 的出现不但具备数据操作在串行和并行间自由切换的能力，如 sequential() 以及 parallel() 方法，而且淡化了并发的特性，如 sorted() 方法即可能是传统排序，亦或是并行排序。相同的设计哲学也体现在 Java Reactive 实现框架中，如同书中提及的 RxJava⁵ API io.reactivex.Observable 。统一编程模型只是 Stream 其中设计目标之一，它结合 Lambda 语法特性，虽然提供了数量可观的操作方法，如 flatMap() 等，然而无论对比 RxJava，还是 Reactor⁶ ，Stream 操作方法却又相形见绌。值得一提的是，这些操作方法在 Reactive 的术语中称之为操作符（Operators）。当然框架内建的操作符的多与寡，并非判断其是否为 Reactive 实现的依据。其中决定性因素在于数据必须来源于发布方（生产者）的”推送（Push）“，而非消费端的”拉取（Pull）“。显然，Stream 属于消费端已就绪（Ready）的数据集合，并不存在其他数据推送源。不过 JVM 语言早期的 Reactive 定义处于模糊地带，如 RxJava API 属于观察者模式（Observer Pattern）⁷的扩展，而非迭代器（Iterator Pattern）模式⁸的实现。而 Reactor 的实现则拥抱 Reactive Streams 规范⁹ ，该规范消费端对于数据的操作是被动的处理，而非主动的索。换言之，数据的到达存在着不确定性¹⁰。当推送的数据无法得到消费端及时效应时，Reactive 框架必须提供背压（Backpressure）¹¹实现，确保消费端拥有”拒绝的权利（cancel）”。在此理论基础上，Reactive Streams 规范定义了一套抽象的 API，作为 Java 9 java.util.concurrent.Flow API 的顶层设计。不过关于操作符的部分，该规范似乎不太关心，这也是为什么 RxJava 和 Reactor 均称自身为 Reactive 扩展框架的原因，同时两者在 API 级别提供多种调度器（Schedulers）¹²实现，适配不同并发场景提供。尽管 Reactive 定义在不同的阵营之间存在差异，援引本人在《Reactive-Programming-一种技术-各自表述》¹³文中的总结：

Reactive Programming 作为观察者模式（Observer）的延伸，不同于传统的命令编程方式（ Imperative programming）同步拉取数据的方式，如迭代器模式（Iterator）。而是采用数据发布者同步或异步地推送到数据流（Data Streams）的方案。当该数据流（Data Steams）订阅者监听到传播变化时，立即作出响应动作。在实现层面上，Reactive Programming 可结合函数式编程简化面向对象语言语法的臃肿性，屏蔽并发实现的复杂细节，提供数据流的有序操作，从而达到提升代码的可读性，以及减少 Bugs 出现的目的。同时，Reactive Programming 结合背压（Backpressure）的技术解决发布端生成数据的速率高于订阅端消费的问题。

不难看出，Reactive 是一门综合的编程艺术，在实现框架的加持下，相同的代码逻辑实现同步和异步非阻塞功能，从而达到提升应用整体性能的目的。不过现实的情况或许没有那么理想，Spring 官方文档在《Web on Reactive Stack》章节中提到，”Reactive 和非阻塞通常并不是让应用运行的更快”¹⁴：

Reactive and non-blocking generally do not make applications run faster.

为此，JHipster¹⁵ 给出了一份《 Spring 5 WebFlux 性能测试报告》¹⁶，其中一条结论是，”Reactive 应用并没有表现出速度提升（甚至是变得更差）“：

No improvement in speed was observed with our reactive apps (the Gatling results are even slightly worse).

数月后，看似相反的结论却在DZone¹⁷一篇名为《Raw Performance Numbers - Spring Boot 2 Webflux vs. Spring Boot 1》¹⁸的文中出现，测试结果是 Spring Boot 2 WebFlux在高并发下响应时间更为平稳。实际上，这个测试结论有些”关公战秦琼“的味道，毕竟 Spring Boot 2.0 下的 WebFlux 和 Spring Boot 1.0 中的 Servlet 容器所使用线程模型是不同的，并且 Servlet 3.0 异步以及非阻塞特性缺省是关闭的。不过以上两篇的结论并不矛盾，前者关注于响应速度，后者则强调吞吐量，都是性能的核心指标。遗憾的是，两篇文章均未对各自的测试用例做出调优，因此以上结论都存在一定的局限性，这也是本人对 Reactive 技术能否提升性能提出质疑的地方。

如果本人是国内提出 Reactive 问题的第一人的话，那么知秋¹⁹就是国内第一个解决问题的人。作为国内为数不多的 Reactive 以及 NIO 方面的专家，在技术研究上，他追求格物致知，不轻忽技术细节。在知识分享上，他可谓是知无不言，言无不尽，不仅在社交群中答疑解惑，而且录制免费视频，发布在 B 站²⁰以及 YouTube 频道²¹，并得到 Josh Long 等大佬的推文(Twitter)。或许以上方式还不足以完整地讨论 Java Reactive 技术，知秋选择了漫长而又艰苦的著书之路，尽管他是本人的朋友，然而 ”内举不避亲“，笔者推荐给读者朋友，首先是因为这是大陆地区第一本全面解读 Java Reactive 技术的书籍，除作者的雄厚技术积累背书之外，书中的知识脉络是循序渐进的。同时，这也是一本引人深思的书，本书在导读源码的同时，也引导读者对于代码设计上的思考。再者，这又是一本知识苦旅的书，因为它涉及面较广，读者不仅需要具备一定的 Java 并发以及面向对象设计，而且需要读者付出较多的时间去反复推敲。正所谓”夫夷以近，则游者众；险以远，则至者少“²²，笔者希望读者在购买此书后，不轻言放弃，当您面临挑战时，那才是成长的开始。同时，也期盼读者将 Reactive 技术付之于实践，提早触碰未来。

小马哥（mercyblitz)²³

2019 年 3 月 5 日

Architecture and Design InfoQ Trends Report - January 2019 - https://www.infoq.com/articles/architecture-trends-2019 ↩
Josh (@starbuxman) is the Spring Developer Advocate at Pivotal and a Java Champion - https://spring.io/team/jlong ↩
The Reactive Manifesto - https://www.reactivemanifesto.org ↩
https://docs.oracle.com/javase/9/docs/api/java/util/concurrent/Flow.html ↩
RxJava: Reactive Extensions for the JVM - https://github.com/ReactiveX/RxJava6 ↩
Reactor is a fully non-blocking reactive programming foundation for the JVM, with efficient demand management (in the form of managing “backpressure”). - https://github.com/reactor/reactor-core ↩
Observer Pattern - http://en.wikipedia.org/wiki/observer_pattern ↩
Iterator Pattern - https://en.wikipedia.org/wiki/Iterator_pattern ↩
Reactive Streams is an initiative to provide a standard for asynchronous stream processing with non-blocking back pressure. - https://www.reactive-streams.org/ ↩
Handling streams of data—especially “live” data whose volume is not predetermined - https://github.com/reactive-streams/reactive-streams-jvm#goals-design-and-scope ↩
Backpressure is an integral part of this model in order to allow the queues which mediate between threads to be bounded. The benefits of asynchronous processing would be negated if the backpressure signals were synchronous (see also the Reactive Manifesto), therefore care has been taken to mandate fully non-blocking and asynchronous behavior of all aspects of a Reactive Streams implementation. - https://github.com/reactive-streams/reactive-streams-jvm#goals-design-and-scope ↩
RxJava Scheduler - http://reactivex.io/documentation/scheduler.html, Reactor Schedulers : https://projectreactor.io/docs/core/release/reference/#schedulers ↩
《Reactive Programming 一种技术，各自表述》：https://mercyblitz.github.io/2018/07/25/Reactive-Programming-一种技术-各自表述 ↩
1.1.6. Performance - https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-performance ↩
JHipster -https://www.jhipster.tech/ ↩
《Spring 5 WebFlux: Performance tests》- https://blog.ippon.tech/spring-5-webflux-performance-tests ↩
DZone : https://dzone.com ↩
《Raw Performance Numbers - Spring Boot 2 Webflux vs. Spring Boot 1》 - https://dzone.com/articles/raw-performance-numbers-spring-boot-2-webflux-vs-s ↩
知秋，本书的作者笔名 ↩
https://space.bilibili.com/2494318 ↩
https://www.youtube.com/channel/UCmxVT2rkFwDX1tPpVDPJQaQ ↩
《游褒禅山记》，王安石 ↩
小马哥，Java 劝退师，Apache Dubbo PPMC、Spring Cloud Alibaba 项目架构师 - https://mercyblitz.github.io/about/ ↩

Reactive programming 一种技术各自表述

Wed, 25 Jul 2018 00:00:00 +0000

Reactive Programming 一种技术，各自表述

前言

作为一名 Java 开发人员，尤其是 Java 服务端工程师，对于 Reactive Programming 的概念似乎相对陌生。随着 Java 9 以及 Spring Framework 5 的相继发布，Reactive 技术逐渐开始被广大从业人员所注意，笔者作为其中一员，更渴望如何理解 Reactive Programming，以及它所带来的哪些显著的编程变化，更为重要的是，怎么将其用于实际生产环境，解决当前面临的问题。然而，随着时间的推移和了解的深入，笔者对 Reactive Programming 的热情逐渐被浇息，对它的未来保持谨慎乐观的态度。

本文从理解 Reactive Programming 的角度出发，尽可能地保持理性和中立的态度，讨论 Reactive Programming 的实质。

初识 Reactive

笔者第一次接触 Reactive 技术的时间还要回溯到 2015年末，当时部分应用正使用 Hystrix 实现服务熔断，而 Hystrix 底层依赖是 RxJava 1.x，RxJava 是 Reactive 在 Java 编程语言的扩展框架。当时接触 Reactive 只能算上一种间接的接触，根据 Hystrix 特性来理解 Reactive 技术，感觉上，Hystrix 超时和信号量等特性与 Java 并发框架（J.U.C）的关系密切，进而认为 Reactive 是 J.U.C 的扩展。随后，笔者便参考了两本关于 Reactive Java 编程方面的书：《Reactive Java Programming》和《Reactive Programming with RxJava》。遗憾的是，两者尽管详细地描述 RxJava 的使用方法，然而却没有把 Reactive 使用场景讨论到要点上，如《Reactive Programming with RxJava》所给出的使用场景说明：

When You Need Reactive Programming

Reactive programming is useful in scenarios such as the following:

Processing user events such as mouse movement and clicks, keyboard typing,GPS signals changing over time as users move with their device, device gyroscope signals, touch events, and so on.

Responding to and processing any and all latency-bound IO events from disk or network, given that IO is inherently asynchronous …

Handling events or data pushed at an application by a producer it cannot control …

实际上，以上三种使用场景早已在 Java 生态中完全地实现并充分地实践，它们对应的技术分别是 Java AWT/Swing、NIO/AIO 以及 JMS（Java 消息服务）。那么，再谈 RxJava 的价值又在哪里呢？如果读者是初学者，或许还能蒙混过关。好奇心促使笔者重新开始踏上探索 Reactive 之旅。

理解 Reactive

2017年 Java 技术生态中，最有影响力的发布莫过于 Java 9 和 Spring 5，前者主要支持模块化，次要地提供了 Flow API 的支持，后者则将”身家性命“压在 Reactive 上面，认为 Reactive 是未来的趋势，它以 Reactive 框架 Reactor 为基础，逐步构建一套完整的 Reactive 技术栈，其中以 WebFlux 技术为最引人关注，作为替代 Servlet Web 技术栈的核心特性，承载了多年 Spring 逆转 Java EE 的初心。于是，业界开始大力地推广 Reactive 技术，于是笔者又接触到一些关于 Reactive 的讲法。

关于 Reactive 的一些讲法

其中笔者挑选了以下三种出镜率最高的讲法：

Reactive 是异步非阻塞编程
Reactive 能够提升程序性能
Reactive 解决传统编程模型遇到的困境

第一种说法描述了功能特性，第二种说法表达了性能收效，第三种说法说明了终极目地。下面的讨论将围绕着这三种讲法而展开，深入地探讨 Reactive Programming 的实质，并且理解为什么说 Reactive Programming 是”一种技术，各自表述“。

同时，讨论的方式也一反常态，并不会直奔主题地解释什么 Reactive Programming，而是从问题的角度出发，从 Reactive 规范和框架的论点，了解传统编程模型中所遇到的困境，逐步地揭开 Reactive 神秘的面纱。其中 Reactive 规范是 JVM Reactive 扩展规范 Reactive Streams JVM，而 Reactive 实现框架则是最典型的实现：

Java 9 Flow API
RxJava
Reactor

传统编程模型中的某些困境

Reactor 认为阻塞可能是浪费的

3.1. Blocking Can Be Wasteful

Modern applications can reach huge numbers of concurrent users, and, even though the capabilities of modern hardware have continued to improve, performance of modern software is still a key concern.

There are broadly two ways one can improve a program’s performance:

parallelize: use more threads and more hardware resources.

seek more efficiency in how current resources are used.

Usually, Java developers write programs using blocking code. This practice is fine until there is a performance bottleneck, at which point the time comes to introduce additional threads, running similar blocking code. But this scaling in resource utilization can quickly introduce contention and concurrency problems.

Worse still, blocking wastes resources.

So the parallelization approach is not a silver bullet.

将以上 Reactor 观点归纳如下，它认为：

阻塞导致性能瓶颈和浪费资源
增加线程可能会引起资源竞争和并发问题
并行的方式不是银弹（不能解决所有问题）

第三点基本上是废话，前面两点则较为容易理解，为了减少理解的偏差，以下讨论将结合示例说明。

理解阻塞的弊端

假设有一个数据加载器，分别加载配置、用户信息以及订单信息，如下图所示：

图示

Java 实现

public class DataLoader {

    public final void load() {
        long startTime = System.currentTimeMillis(); // 开始时间
        doLoad(); // 具体执行
        long costTime = System.currentTimeMillis() - startTime; // 消耗时间
        System.out.println("load() 总耗时：" + costTime + " 毫秒");
    }

    protected void doLoad() { // 串行计算
        loadConfigurations();    //  耗时 1s
        loadUsers();                  //  耗时 2s
        loadOrders();                // 耗时 3s
    } // 总耗时 1s + 2s  + 3s  = 6s

    protected final void loadConfigurations() {
        loadMock("loadConfigurations()", 1);
    }

    protected final void loadUsers() {
        loadMock("loadUsers()", 2);
    }

    protected final void loadOrders() {
        loadMock("loadOrders()", 3);
    }

    private void loadMock(String source, int seconds) {
        try {
            long startTime = System.currentTimeMillis();
            long milliseconds = TimeUnit.SECONDS.toMillis(seconds);
            Thread.sleep(milliseconds);
            long costTime = System.currentTimeMillis() - startTime;
            System.out.printf("[线程 : %s] %s 耗时 :  %d 毫秒\n",
                    Thread.currentThread().getName(), source, costTime);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

    public static void main(String[] args) {
        new DataLoader().load();
    }

}

运行结果

[线程 : main] loadConfigurations() 耗时 :  1005 毫秒
[线程 : main] loadUsers() 耗时 :  2002 毫秒
[线程 : main] loadOrders() 耗时 :  3001 毫秒
load() 总耗时：6031 毫秒

结论

由于加载过程串行执行的关系，导致消耗实现线性累加。Blocking 模式即串行执行。

不过 Reactor 也提到，以上问题可通过并行的方式来解决，不过编写并行程序较为复杂，那么其中难点在何处呢？

理解并行的复杂

再将以上示例由串行调整为并行，如下图所示：

图示

Java 代码

public class ParallelDataLoader extends DataLoader {

    protected void doLoad() {  // 并行计算
        ExecutorService executorService = Executors.newFixedThreadPool(3); // 创建线程池
        CompletionService completionService = new ExecutorCompletionService(executorService);
        completionService.submit(super::loadConfigurations, null);      //  耗时 >= 1s
        completionService.submit(super::loadUsers, null);               //  耗时 >= 2s
        completionService.submit(super::loadOrders, null);              //  耗时 >= 3s

        int count = 0;
        while (count < 3) { // 等待三个任务完成
            if (completionService.poll() != null) {
                count++;
            }
        }
        executorService.shutdown();
    }  // 总耗时 max(1s, 2s, 3s)  >= 3s

    public static void main(String[] args) {
        new ParallelDataLoader().load();
    }

}

运行结果

[线程 : pool-1-thread-1] loadConfigurations() 耗时 :  1003 毫秒
[线程 : pool-1-thread-2] loadUsers() 耗时 :  2005 毫秒
[线程 : pool-1-thread-3] loadOrders() 耗时 :  3005 毫秒
load() 总耗时：3068 毫秒

结论

明显地，程序改造为并行加载后，性能和资源利用率得到提升，消耗时间取最大者，即三秒，由于线程池操作的消耗，整体时间将略增一点。不过，以上实现为什么不直接使用 Future#get() 方法强制所有任务执行完毕，然后再统计总耗时？

Reactor 这方面的看法并没有向读者清晰地表达全秒，不过这还不是全部，听听它接下来的说法。

Reactor 认为异步不一定能够救赎

3.2. Asynchronicity to the Rescue?

The second approach (mentioned earlier), seeking more efficiency, can be a solution to the resource wasting problem. By writing asynchronous, non-blocking code, you let the execution switch to another active task using the same underlying resources and later come back to the current process when the asynchronous processing has finished.

Java offers two models of asynchronous programming:

Callbacks: Asynchronous methods do not have a return value but take an extra callback parameter (a lambda or anonymous class) that gets called when the result is available. A well known example is Swing’s EventListenerhierarchy.

Futures: Asynchronous methods return a Future<T> immediately. The asynchronous process computes a T value, but the Future object wraps access to it. The value is not immediately available, and the object can be polled until the value is available. For instance, ExecutorService running Callable<T> tasks use Future objects.

Are these techniques good enough? Not for every use case, and both approaches have limitations.

Callbacks are hard to compose together, quickly leading to code that is difficult to read and maintain (known as “Callback Hell”).

Futures are a bit better than callbacks, but they still do not do well at composition, despite the improvements brought in Java 8 by CompletableFuture.

再次将以上观点归纳，它认为：

Callbacks 是解决非阻塞的方案，然而他们之间很难组合，并且快速地将代码引导至 “Callback Hell” 的不归路
Futures 相对于 Callbacks 好一点，不过还是无法组合，不过 CompletableFuture 能够提升这方面的不足

以上 Reactor 的观点仅给出了结论，没有解释现象，其中场景设定也不再简单直白，从某种程度上，这也侧面地说明，Reactive Programming 实际上是”高端玩家“的游戏。接下来，本文仍通过示例的方式，试图解释”Callback Hell” 问题以及 Future 的限制。

理解 “Callback Hell”

Java GUI 示例

public class JavaGUI {

    public static void main(String[] args) {
        JFrame jFrame = new JFrame("GUI 示例");
        jFrame.setBounds(500, 300, 400, 300);
        LayoutManager layoutManager = new BorderLayout(400, 300);
        jFrame.setLayout(layoutManager);
        jFrame.addMouseListener(new MouseAdapter() { // callback 1
            @Override
            public void mouseClicked(MouseEvent e) {
                System.out.printf("[线程 : %s] 鼠标点击，坐标(X : %d, Y : %d)\n",
                        currentThreadName(), e.getX(), e.getY());
            }
        });
        jFrame.addWindowListener(new WindowAdapter() {  // callback 2
            @Override
            public void windowClosing(WindowEvent e) {
                System.out.printf("[线程 : %s] 清除 jFrame... \n", currentThreadName());
                jFrame.dispose(); // 清除 jFrame
            }

            @Override
            public void windowClosed(WindowEvent e) {
                System.out.printf("[线程 : %s] 退出程序... \n", currentThreadName());
                System.exit(0); // 退出程序
            }
        });
        System.out.println("当前线程：" + currentThreadName());
        jFrame.setVisible(true);
    }

    private static String currentThreadName() { // 当前线程名称
        return Thread.currentThread().getName();
    }
}

运行结果

点击窗体并关闭窗口，控制台输出如下：

当前线程：main
[线程 : AWT-EventQueue-0] 鼠标点击，坐标(X : 180, Y : 121)
[线程 : AWT-EventQueue-0] 鼠标点击，坐标(X : 180, Y : 122)
[线程 : AWT-EventQueue-0] 鼠标点击，坐标(X : 180, Y : 122)
[线程 : AWT-EventQueue-0] 鼠标点击，坐标(X : 180, Y : 122)
[线程 : AWT-EventQueue-0] 鼠标点击，坐标(X : 180, Y : 122)
[线程 : AWT-EventQueue-0] 鼠标点击，坐标(X : 201, Y : 102)
[线程 : AWT-EventQueue-0] 清除 jFrame... 
[线程 : AWT-EventQueue-0] 退出程序...

结论

Java GUI 以及事件/监听模式基本采用匿名内置类实现，即回调实现。从本例可以得出，鼠标的点击确实没有被其他线程给阻塞。不过当监听的维度增多时，Callback 实现也随之增多。Java Swing 事件/监听是一种典型的既符合异步非阻塞，又属于 Callback 实现的场景，其并发模型可为同步或异步。不过，在 Java 8 之前，由于接口无法支持 default 方法，当接口方法过多时，通常采用 Adapter 模式作为缓冲方案，达到按需实现的目的。尤其在 Java GUI 场景中。即使将应用的 Java 版本升级到 8 ，由于这些 Adapter ”遗老遗少“实现的存在，使得开发人员仍不得不面对大量而繁琐的 Callback 折中方案。既然 Reactor 提出了这个问题，那么它或者 Reactive 能否解决这个问题呢？暂时存疑，下一步是如何理解 Future 的限制。

理解 `Future` 的限制

Reactor 的观点仅罗列 Future 的一些限制，并没有将它们解释清楚，接下来用两个例子来说明其中原委。

限制一：`Future` 的阻塞性

在前文示例中，ParallelDataLoader 利用 CompletionService API 实现 load*() 方法的并行加载，如果将其调整为 Future 的实现，可能的实现如下：

Java Future 阻塞式加载示例

public class FutureBlockingDataLoader extends DataLoader {

    protected void doLoad() {
        ExecutorService executorService = Executors.newFixedThreadPool(3); // 创建线程池
        runCompletely(executorService.submit(super::loadConfigurations));  //  耗时 >= 1s
        runCompletely(executorService.submit(super::loadUsers));           //  耗时 >= 2s
        runCompletely(executorService.submit(super::loadOrders));          //  耗时 >= 3s
        executorService.shutdown();
    } // 总耗时 sum(>= 1s, >= 2s, >= 3s)  >= 6s

    private void runCompletely(Future<?> future) {
        try {
            future.get(); // 阻塞等待结果执行
        } catch (Exception e) {
        }
    }

    public static void main(String[] args) {
        new FutureBlockingDataLoader().load();
    }

}

运行结果

[线程 : pool-1-thread-1] loadConfigurations() 耗时 :  1003 毫秒
[线程 : pool-1-thread-2] loadUsers() 耗时 :  2004 毫秒
[线程 : pool-1-thread-3] loadOrders() 耗时 :  3002 毫秒
load() 总耗时：6100 毫秒

结论

ParallelDataLoader 加载耗时为”3068 毫秒“，调整后的 FutureBlockingDataLoader 则比串行的 DataLoader 加载耗时（“6031 毫秒”）还要长。说明Future#get() 方法不得不等待任务执行完成，换言之，如果多个任务提交后，返回的多个 Future 逐一调用 get() 方法时，将会依次 blocking，任务的执行从并行变为串行。这也是之前为什么 ParallelDataLoader 不采取 Future 的解决方案的原因。

限制二：`Future` 不支持链式操作

由于 Future 无法实现异步执行结果链式处理，尽管 FutureBlockingDataLoader 能够解决方法数据依赖以及顺序执行的问题，不过它将并行执行带回了阻塞（串行）执行。所以，它不是一个理想实现。不过 CompletableFuture 可以帮助提升 Future 的限制：

Java CompletableFuture 重构 Future 链式实现

public class FutureChainDataLoader extends DataLoader {

    protected void doLoad() {
        CompletableFuture
                .runAsync(super::loadConfigurations)
                .thenRun(super::loadUsers)
                .thenRun(super::loadOrders)
                .whenComplete((result, throwable) -> { // 完成时回调
                    System.out.println("加载完成");
                })
                .join(); // 等待完成
    }

    public static void main(String[] args) {
        new ChainDataLoader().load();
    }
}

运行结果

[线程 : ForkJoinPool.commonPool-worker-1] loadConfigurations() 耗时 :  1000 毫秒
[线程 : ForkJoinPool.commonPool-worker-1] loadUsers() 耗时 :  2005 毫秒
[线程 : ForkJoinPool.commonPool-worker-1] loadOrders() 耗时 :  3001 毫秒
加载完成
load() 总耗时：6093 毫秒

结论

通过输出日志分析， FutureChainDataLoader 并没有像 FutureBlockingDataLoader 那样使用三个线程分别执行加载任务，仅使用了一个线程，换言之，这三次加载同一线程完成，并且异步于 main 线程，如下所示：

尽管 CompletableFuture 不仅是异步非阻塞操作，而且还能将 Callback 组合执行，也不存在所谓的 ”Callback Hell“ 等问题。如果强制等待结束的话，又回到了阻塞编程的方式。同时，相对于 FutureBlockingDataLoader 实现，重构后的 FutureChainDataLoader 不存在明显性能提升。

稍作解释，CompletableFuture 不仅可以支持 Future 链式操作，而且提供三种生命周期回调，即执行回调（Action）、完成时回调（Complete）、和异常回调（Exception），类似于 Spring 4 ListenableFuture 以及 Guava ListenableFuture。

至此，Reactor 的官方参考文档再没有出现其他有关”传统编程模型中的某些困境“的描述，或许读者老爷和我一样，对 Reactive 充满疑惑，它真能解决以上问题吗？当然，监听则明，偏听则暗，下面我们再来参考 Reactive Streams JVM 的观点。

Reactive Streams JVM 认为异步系统和资源消费需要特殊处理

Handling streams of data—especially “live” data whose volume is not predetermined—requires special care in an asynchronous system. The most prominent issue is that resource consumption needs to be carefully controlled such that a fast data source does not overwhelm the stream destination. Asynchrony is needed in order to enable the parallel use of computing resources, on collaborating network hosts or multiple CPU cores within a single machine.

观点归纳：

流式数据容量难以预判
异步编程复杂
数据源和消费端之间资源消费难以平衡

此观点与 Reactor 相同的部分是，两者均认为异步编程复杂，而前者还提出了数据结构（流式数据）以及数据消费问题。

无论两者的观点孰优谁劣，至少说明一个现象，业界对于 Reactive 所解决的问题并非达到一致，几乎各说各话。那么，到底怎样才算 Reactive Programming 呢？

什么是 Reactive Programming

关于什么是 Reactive Programming，下面给出六种渠道的定义，尝试从不同的角度，了解 Reactive Programming 的意涵。首先了解的是 “The Reactive Manifesto” 中的定义

The Reactive Manifesto 中的定义

Reactive Systems are: Responsive, Resilient, Elastic and Message Driven.

https://www.reactivemanifesto.org/

该组织对 Reactive 的定义非常简单，其特点体现在以下关键字：

响应的（Responsive）
适应性强的（Resilient）
弹性的（Elastic）
消息驱动的（Message Driven）

不过这样的定义侧重于 Reactive 系统，或者说是设计 Reactive 系统的原则。

维基百科中的定义

维基百科作为全世界的权威知识库，其定义的公允性能够得到保证：

Reactive programming is a declarative programming paradigm concerned with data streams and the propagation of change. With this paradigm it is possible to express static (e.g. arrays) or dynamic (e.g. event emitters) data streams with ease, and also communicate that an inferred dependency within the associated execution model exists, which facilitates the automatic propagation of the changed data flow.

参考地址：https://en.wikipedia.org/wiki/Reactive_programming

维基百科认为 Reactive programming 是一种声明式的编程范式，其核心要素是数据流（data streams ）与其传播变化（ propagation of change），前者是关于数据结构的描述，包括静态的数组（arrays）和动态的事件发射器（event emitters）。由此描述，在笔者脑海中浮现出以下技术视图：

数据流：Java 8 Stream
传播变化：Java Observable/Observer
事件/监听：Java EventObject/EventListener

这些技术能够很好地满足维基百科对于 Reactive 的定义，那么， Reactive 框架和规范的存在意义又在何方？或许以上定义过于抽象，还无法诠释 Reactive 的全貌。于是乎，笔者想到了去 Spring 官方找寻答案，正如所愿，在 Spring Framework 5 官方参考文档中找到其中定义。

Spring 5 中的定义

The term “reactive” refers to programming models that are built around reacting to change — network component reacting to I/O events, UI controller reacting to mouse events, etc. In that sense non-blocking is reactive because instead of being blocked we are now in the mode of reacting to notifications as operations complete or data becomes available.

参考地址：https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux-why-reactive

相对于维基百科的定义，Spring 5 WebFlux 章节同样也提到了变化响应（reacting to change ），并且还说明非阻塞（non-blocking）就是 Reactive。同时，其定义的侧重点在响应通知方面，包括操作完成（operations complete）和数据可用（data becomes available）。Spring WebFlux 作为 Reactive Web 框架，天然支持非阻塞，不过早在 Servlet 3.1 规范时代皆以实现以上需求，其中包括 Servlet 3.1 非阻塞 API ReadListener 和WriteListener，以及 Servlet 3.0 所提供的异步上下文 AsyncContext 和事件监听 AsyncListener。这些 Servlet 特性正是为 Spring WebFlux 提供适配的以及，所以 Spring WebFlux 能完全兼容 Servlet 3.1 容器。笔者不禁要怀疑，难道 Reactive 仅是新包装的概念吗？或许就此下结论还为时尚早，不妨在了解一下 ReactiveX 的定义。

ReactiveX 中的定义

广泛使用的 RxJava 作为 ReactiveX 的 Java 实现，对于 Reactive 的定义，ReactiveX 具备相当的权威性：

ReactiveX extends the observer pattern to support sequences of data and/or events and adds operators that allow you to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O.

参考地址：http://reactivex.io/intro.html

不过，ReactiveX 并没有直接给 Reactive 下定义，而是通过技术实现手段说明如何实现 Reactive。ReactiveX 作为观察者模式的扩展，通过操作符（Opeators）对数据/事件序列（Sequences of data and/or events )进行操作，并且屏蔽并发细节（abstracting away…），如线程 API（Exectuor 、Future、Runnable）、同步、线程安全、并发数据结构以及非阻塞 I/O。该定义的侧重点主要关注于实现，包括设计模式、数据结构、数据操作以及并发模型。除设计模式之外，Java 8 Stream API 具备不少的操作符，包括迭代操作 for-each、map/reduce 以及集合操作 Collector等，同时，通过 parallel() 和 sequential() 方法实现并行和串行操作间的切换，同样屏蔽并发的细节。至于数据结构，Stream 和数据流或集合序列可以画上等号。唯独在设计模式上，Stream 是迭代器（Iterator）模式实现，而 ReactiveX 则属于观察者（Observer）模式的实现。对此，Reactor 做了进一步地解释。

Reactor 中的定义

The reactive programming paradigm is often presented in object-oriented languages as an extension of the Observer design pattern. One can also compare the main reactive streams pattern with the familiar Iterator design pattern, as there is a duality to the Iterable-Iterator pair in all of these libraries. One major difference is that, while an Iterator is pull-based, reactive streams are push-based.

http ://projectreactor.io/docs/core/release/reference/#intro-reactive

同样地，Reactor 也提到了观察者模式（Observer pattern ）和迭代器模式（Iterator pattern）。不过它将 Reactive 定义为响应流模式（Reactive streams pattern ），并解释了该模式和迭代器模式在数据读取上的差异，即前者属于推模式（push-based），后者属于拉模式（pull-based）。难道就因为这因素，就要使用 Reactive 吗？这或许有些牵强。个人认为，以上组织均没有坦诚或者简单地向用户表达，都采用一种模糊的描述，多少难免让人觉得故弄玄虚。幸运地是，我从 ReactiveX 官方找到一位前端牛人 André Staltz，他在学习 Reactive 过程中与笔者一样，吃了不少的苦头，在他博文《The introduction to Reactive Programming you’ve been missing》中，他给出了中肯的解释。

André Staltz 给出的定义

Reactive programming is programming with asynchronous data streams.

In a way, this isn’t anything new. Event buses or your typical click events are really an asynchronous event stream, on which you can observe and do some side effects. Reactive is that idea on steroids. You are able to create data streams of anything, not just from click and hover events. Streams are cheap and ubiquitous, anything can be a stream: variables, user inputs, properties, caches, data structures, etc.

“What is Reactive Programming?”

他在文章指出，Reactive Programming 并不是新东西，而是司空见惯的混合物，比如事件总监、鼠标点击事件等。同时，文中也提到异步（asynchronous ）以及数据流（data streams）等关键字。如果说因为 Java 8 Stream 是迭代器模式的缘故，它不属于Reactive Programming 范式的话，那么，Java GUI 事件/监听则就是 Reactive。那么，Java 开发人员学习 RxJava、Reactor、或者 Java 9 Flow API 的必要性又在哪里呢？因此，非常有必要深入探讨 Reactive Programming 的使用场景。

Reactive Programming 使用场景

正如同 Reactive Programming 的定义那样，各个组织各执一词，下面仍采用多方引证的方式，寻求 Reactive Programming 使用场景的“最大公约数”。

Reactive Streams JVM 认为的使用场景

The main goal of Reactive Streams is to govern the exchange of stream data across an asynchronous boundary.

https://github.com/reactive-streams/reactive-streams-jvm

Reactive Streams JVM 认为 Reactive Streams 用于在异步边界（asynchronous boundary）管理流式数据交换（ govern the exchange of stream data）。异步说明其并发模型，流式数据则体现数据结构，管理则强调它们的它们之间的协调。

Spring 5 认为的使用场景

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.

The key expected benefit of reactive and non-blocking is the ability to scale with a small, fixed number of threads and less memory. That makes applications more resilient under load because they scale in a more predictable way.

Spring 认为 Reactive 和非阻塞通常并非让应用运行更快速（generally do not make applications run faster），甚至会增加少量的处理时间，因此，它的使用场景则利用较少的资源，提升应用的伸缩性（scale with a small, fixed number of threads and less memory）。

ReactiveX 认为的使用场景

The ReactiveX Observable model allows you to treat streams of asynchronous events with the same sort of simple, composable operations that you use for collections of data items like arrays. It frees you from tangled webs of callbacks, and thereby makes your code more readable and less prone to bugs.

ReactiveX 所描述的使用场景与 Spring 的不同，它没有从性能入手，而是代码可读性和减少 Bugs 的角度出发，解释了 Reactive Programming 的价值。同时，强调其框架的核心特性：异步（asynchronous）、同顺序（same sort）和组合操作（composable operations）。它也间接地说明了，Java 8 Stream 在组合操作的限制，以及操作符的不足。

Reactor 认为的使用场景

Composability and readability

Data as a flow manipulated with a rich vocabulary of operators

Nothing happens until you subscribe

Backpressure or the ability for the consumer to signal the producer that the rate of emission is too high

High level but high value abstraction that is concurrency-agnostic

Reactor 同样强调结构性和可读性（Composability and readability）和高层次并发抽象（High level abstraction），并明确地表示它提供丰富的数据操作符（ rich vocabulary of operators）弥补 Stream API 的短板，还支持背压（Backpressure）操作，提供数据生产者和消费者的消息机制，协调它们之间的产销失衡的情况。同时，Reactor 采用订阅式数据消费（Nothing happens until you subscribe）的机制，实现 Stream 所不具备的数据推送机制。

至此，讨论接近尾声，最后的部分将 Reactive Programming 内容加以总结。

总结 Reactive Programming

Reactive Programming 作为观察者模式（Observer）的延伸，不同于传统的命令编程方式（ Imperative programming）同步拉取数据的方式，如迭代器模式（Iterator）。而是采用数据发布者同步或异步地推送到数据流（Data Streams）的方案。当该数据流（Data Steams）订阅者监听到传播变化时，立即作出响应动作。在实现层面上，Reactive Programming 可结合函数式编程简化面向对象语言语法的臃肿性，屏蔽并发实现的复杂细节，提供数据流的有序操作，从而达到提升代码的可读性，以及减少 Bugs 出现的目的。同时，Reactive Programming 结合背压（Backpressure）的技术解决发布端生成数据的速率高于订阅端消费的问题。

后记

2005年，李敖大师曾在上海复旦大学做过一次演讲，他在讲到“放弃自由主义，注重务实”的部分时，引述一段故事：

美国有一个报纸，办报的人叫ABBOTT，他晚年的时候写回忆录，他爸爸是一个写儿童书的作家，他爸爸临死前告诉他说，感觉到人间所有的教会的争执90％都是名词之争。这个小ABBOTT老了以后，他回忆这段话，他说我回忆我爸爸告诉我所有人间宗教的争执90％都是名词之争，他说我发现我爸爸数学不好，原来最后那10％也是名词之争。

实际上，名词之争的战场不限于宗教教会，技术领域不也是如此吗？Reactive Programming 实际是一种技术，却被各自表达。有些定义含糊不清，有些定义则空洞无实，还有一些则是夸大其词，只有少数保持客观中立。不免让然唏嘘技术领域的非理性营销。当了解了 Reactive Programming 的本质后，您的热情还能像如初般地高涨吗？

Dubbo cloud native 实践与思考

Thu, 28 Jun 2018 00:00:00 +0000

Dubbo Cloud Native 实践与思考

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/discovery/

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/docs/5.0.7.RELEASE/spring-framework-reference/web-reactive.html#webflux-performance

同时，这里提供一篇 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/spring-5-webflux-performance-tests/

换言之，基于 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 生态的整合和落地，还得有待时日。

Spring Cloud 架构体系

实际上，这个图片并非 Spring Cloud 组件架构，而是将其整合在 Pivotal Cloud Foundry (PCF) 架构中。基本上，Spring Cloud 功能组件均有所体现，包括 Eureka、Hystrix、Ribbon 等。不过值得注意的是，Spring Cloud Stream 是一套较为完整和抽象的流式编程框架，屏蔽了底层传输介质（不仅是消息服务），如 Kafka、RabbitMQ 等。除此之外，其他的组件可圈可点，如 Eureka 在大规模运用中的卡顿问题、Ribbon 缺少权重、Zuul 连接数限制和资源消耗、服务调用受限于 Feign REST 协议限制等。如果在小规模场景使用，以上限制或问题不明显，可以说 Spring Cloud 完全能够适任。

不过，差不多两年前，我曾在不同的公开场合讲过：”Spring Boot 易学难精，Spring Cloud 能用但不成熟“。当时很多人觉得我“离经叛道”，然而这句话并非空穴来风，是我这几年来 Java 微服务架构实施的心得。这两年来，深受 Spring Cloud “折磨”的小伙伴逐渐觉醒，慢慢地开始回到 Dubbo 等技术方案。如 Martin Fowler 在为“微服务”下定义时，提到通讯协议要用轻量级的 REST。假设微服务要做到服务无关的话，那么 Web Services 协议也是可以，尽管它看起来比较重，不过 Web Services 的结构化和强类型，可以省去不少的运行时校验逻辑。在我看来，微服务更大程度应该体现在服务粒度上，诚如 Netflix 前架构师 Adrian Cockcroft 说言：“Fine grain SOA”（微服务就是细粒度的 SOA），就这一点而言，比较容易地和业界达成共识。当我们把 Martin 的话视如圭臬时，我们是否要思考它是否经得起工程检验。这里，我没有兴趣贬低他人，来抬高自己（Dubbo），从而引导让大家放弃 Spring Cloud，而是我们需要给 Spring Cloud 时间，包括未来 Dubbo 也会向 Spring Cloud 靠拢并整合。在阿里的内部，基于 Nacos（马上开源的项目）和 Apache RocketMQ，实现了 Spring Cloud Service Discovery、Config 以及 Stream 等整合和适配，一旦时机成熟，可能会开源与大家共建。

既然谈到了 Dubbo，下面我们再来讨论 Dubbo 的架构体系。

Dubbo 架构体系

编程模型方面，不但支持传统的 Spring XML 配合方式，已经实现注解驱动以及外部化配置，并且全面支持最新的 Spring Boot 2.0，在不久的未来，大家会看到 Dubbo 与 Spring Cloud 的整合，使开发人员无缝地衔接已有的 Spring Cloud 应用。

Dubbo Spring Boot 项目地址：https://github.com/apache/incubator-dubbo-spring-boot-project

注册中心方面，Dubbo 将整合 Eureka、etcd 以及 Consul 基础设施，深度与业界热门方案整合。

熔断机制方面，Dubbo 会在近期发布 Hystrix 整合实现，将编程友好性做得最大化。

通讯协议方面，Dubbo 将会支持 gRPC、Thrift 等热门通讯协议。

至于序列化协议，自然首先考虑的是 Protobuf，因其高层 gRPC 搭配 HTTP/2 快成或已经成为下一代通讯协议的事实标准，使得任何人无法忽视它们的存在。当然其他协议也会陆续支持。

其他方面，我这里就不一一介绍，总之，现在 Dubbo 已不再只是一个单一的 PRC 框架，而是要拥抱业界，形成完整的生态体系，与业界形成最大公约数。

Dubbo Cloud Native 准备

在 Dubbo 架构体系时，我们曾提到编程模型的变化。从 Dubbo 2.5.8 开始，注解驱动和外部化配置均已得到支持。同时，Dubbo 已经合并 Dubbox 代码，Java JAX-RS 标准得到了支持，目前业界事实的 REST 标准 Spring Web MVC 正在同步开发。Reactive 的支持也在同步进行，小马哥还得友好地提醒一下各位，对于 Reactive 的期望不应该过分的关注性能的提升。

Dubbo 注解驱动（Annotation-Driven）

在 Dubbo 2.5.7 之前的版本，Dubbo 提供了两个核心注解 @Service 以及 @Reference，分别用于Dubbo 服务提供和 Dubbo 服务引用。

其中，@Service 作为 XML 元素 <dubbo:service> 的替代注解，与 Spring Framework @org.springframework.stereotype.Service 类似，用于服务提供方 Dubbo 服务暴露。与之相对应的 @Reference，则是替代<dubbo:reference> 元素，类似于 Spring 中的 @Autowired。

2.5.7 之前的Dubbo，与早期的 Spring Framework 2.5 存在类似的不足，即注解支持不够充分。注解需要和 XML 配置文件配合使用，如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
       xmlns="http://www.springframework.org/schema/beans"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
	http://code.alibabatech.com/schema/dubbo http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <dubbo:application name="annotation-provider"/>
    <dubbo:registry address="127.0.0.1:4548"/>
    <dubbo:annotation package="com.alibaba.dubbo.config.spring.annotation.provider"/>

</beans>

不仅如此，当时的版本存在“ @Service Bean 不支持 Spring AOP” 以及 “@Reference 不支持字段继承性” 等问题。

从 2.5.7 开始，Dubbo 开始引入组件扫描 Annotation @DubboComponentScan，借鉴了 Spring Boot 1.3 引入的 @ServletComponentScan。

在职责上，@DubboComponentScan 相对于 Spring Boot @ServletComponentScan 更为繁重，原因在于处理 Dubbo @Service 类暴露 Dubbo 服务外，还有帮助 Spring Bean @Reference字段或者方法注入 Dubbo 服务代理。

在场景上，Spring Framework @ComponentScan 组件扫描逻辑更为复杂。而在 @DubboComponentScan 只需关注 @Service 和 @Reference 处理。

注：更多 Dubbo 注解驱动的详情，请参考《Dubbo 注解驱动（Annotation-Driven）》

`@DubboComponentScan` 服务端示例

假设，服务提供方和服务消费分均依赖服务接口DemoService:

package com.alibaba.dubbo.demo;

public interface DemoService {

    String sayHello(String name);

}

服务提供方实现DemoService - AnnotationDemoService

同时标注 Dubbo @Service ：

package com.alibaba.dubbo.demo.provider;

import com.alibaba.dubbo.config.annotation.Service;
import com.alibaba.dubbo.demo.DemoService;

/**
 * Annotation {@link DemoService} 实现
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
@Service
public class AnnotationDemoService implements DemoService {

    @Override
    public String sayHello(String name) {
        return "Hello , " + name;
    }

}

服务端 @Configuration Class

package com.alibaba.dubbo.demo.config;

import com.alibaba.dubbo.config.ApplicationConfig;
import com.alibaba.dubbo.config.ProtocolConfig;
import com.alibaba.dubbo.config.RegistryConfig;
import com.alibaba.dubbo.config.spring.context.annotation.DubboComponentScan;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * 服务提供方配置
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
@Configuration
@DubboComponentScan("com.alibaba.dubbo.demo.provider") // 扫描 Dubbo 组件
public class ProviderConfiguration {

    /**
     * 当前应用配置
     */
    @Bean("dubbo-annotation-provider")
    public ApplicationConfig applicationConfig() {
        ApplicationConfig applicationConfig = new ApplicationConfig();
        applicationConfig.setName("dubbo-annotation-provider");
        return applicationConfig;
    }

    /**
     * 当前连接注册中心配置
     */
    @Bean("my-registry")
    public RegistryConfig registryConfig() {
        RegistryConfig registryConfig = new RegistryConfig();
        registryConfig.setAddress("N/A");
        return registryConfig;
    }

    /**
     * 当前连接注册中心配置
     */
    @Bean("dubbo")
    public ProtocolConfig protocolConfig() {
        ProtocolConfig protocolConfig = new ProtocolConfig();
        protocolConfig.setName("dubbo");
        protocolConfig.setPort(12345);
        return protocolConfig;
    }
}

服务提供方引导类

package com.alibaba.dubbo.demo.bootstrap;

import com.alibaba.dubbo.demo.DemoService;
import com.alibaba.dubbo.demo.config.ProviderConfiguration;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

/**
 * 服务提供方引导类
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
public class ProviderBootstrap {

    public static void main(String[] args) {
        // 创建 Annotation 配置上下文
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        // 注册配置 Bean
        context.register(ProviderConfiguration.class);
        // 启动上下文
        context.refresh();
        // 获取 DemoService Bean
        DemoService demoService = context.getBean(DemoService.class);
        // 执行 sayHello 方法
        String message = demoService.sayHello("World");
        // 控制台输出信息
        System.out.println(message);
    }
    
}

`@DubboComponentScan` 客户端示例

消费服务 DemoService

package com.alibaba.dubbo.demo.consumer;

import com.alibaba.dubbo.config.annotation.Reference;
import com.alibaba.dubbo.demo.DemoService;

/**
 * Annotation 驱动 {@link DemoService} 消费方
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
public class AnnotationDemoServiceConsumer {

    @Reference(url = "dubbo://127.0.0.1:12345")
    private DemoService demoService;

    public String doSayHell(String name) {
        return demoService.sayHello(name);
    }
}

消费端 @Configuration Class

与服务提供方配置类似，服务消费方也许 Dubbo 相关配置 Bean - ConsumerConfiguration

package com.alibaba.dubbo.demo.config;

import com.alibaba.dubbo.config.ApplicationConfig;
import com.alibaba.dubbo.config.RegistryConfig;
import com.alibaba.dubbo.config.spring.context.annotation.DubboComponentScan;
import com.alibaba.dubbo.demo.consumer.AnnotationDemoServiceConsumer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * 服务消费方配置
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
@Configuration
@DubboComponentScan
public class ConsumerConfiguration {

    /**
     * 当前应用配置
     */
    @Bean
    public ApplicationConfig applicationConfig() {
        ApplicationConfig applicationConfig = new ApplicationConfig();
        applicationConfig.setName("dubbo-annotation-consumer");
        return applicationConfig;
    }

    /**
     * 当前连接注册中心配置
     */
    @Bean
    public RegistryConfig registryConfig() {
        RegistryConfig registryConfig = new RegistryConfig();
        registryConfig.setAddress("N/A");
        return registryConfig;
    }

    /**
     * 注册 AnnotationDemoServiceConsumer，@DubboComponentScan 将处理其中 @Reference 字段。
     * 如果 AnnotationDemoServiceConsumer 非 Spring Bean 的话，
     * 即使 @DubboComponentScan 指定 package 也不会进行处理，与 Spring @Autowired 同理
     */
    @Bean
    public AnnotationDemoServiceConsumer annotationDemoServiceConsumer() {
        return new AnnotationDemoServiceConsumer();
    }

}

服务消费方引导类

package com.alibaba.dubbo.demo.bootstrap;

import com.alibaba.dubbo.demo.config.ConsumerConfiguration;
import com.alibaba.dubbo.demo.config.ProviderConfiguration;
import com.alibaba.dubbo.demo.consumer.AnnotationDemoServiceConsumer;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;

/**
 * 服务消费端引导类
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
public class ConsumerBootstrap {

    public static void main(String[] args) {
        // 启动服务提供方上下文
        startProviderContext();
        // 启动并且返回服务消费方上下文
        ApplicationContext consumerContext = startConsumerContext();
        // 获取 AnnotationDemoServiceConsumer Bean
        AnnotationDemoServiceConsumer consumer = consumerContext.getBean(AnnotationDemoServiceConsumer.class);
        // 执行 doSayHello 方法
        String message = consumer.doSayHello("World");
        // 输出执行结果
        System.out.println(message);
    }

    /**
     * 启动并且返回服务消费方上下文
     *
     * @return AnnotationConfigApplicationContext
     */
    private static ApplicationContext startConsumerContext() {
        // 创建服务消费方 Annotation 配置上下文
        AnnotationConfigApplicationContext consumerContext = new AnnotationConfigApplicationContext();
        // 注册服务消费方配置 Bean
        consumerContext.register(ConsumerConfiguration.class);
        // 启动服务消费方上下文
        consumerContext.refresh();
        // 返回服务消费方 Annotation 配置上下文
        return consumerContext;
    }

    /**
     * 启动服务提供方上下文
     */
    private static void startProviderContext() {
        // 创建 Annotation 配置上下文
        AnnotationConfigApplicationContext providerContext = new AnnotationConfigApplicationContext();
        // 注册配置 Bean
        providerContext.register(ProviderConfiguration.class);
        // 启动服务提供方上下文
        providerContext.refresh();
    }

}

Dubbo 外部化配置（Externalized Configuration）

在Dubbo 注解驱动例子中，无论是服务提供方，还是服务消费方，均需要转配相关配置Bean：

    @Bean
    public ApplicationConfig applicationConfig() {
        ApplicationConfig applicationConfig = new ApplicationConfig();
        applicationConfig.setName("dubbo-annotation-consumer");
        return applicationConfig;
    }

虽然实现类似于ProviderConfiguration 和 ConsumerConfiguration 这样的 Spring @Configuration Bean 成本并不高，不过通过 Java Code 的方式定义配置 Bean，或多或少是一种 Hard Code（硬编码）的行为，缺少弹性。

尽管在 Spring 应用中，可以通过 @Value 或者 Environment 的方式获取外部配置，其代码简洁性以及类型转换灵活性存在明显的不足。因此，Spring Boot 提出了外部化配置（External Configuration）的感念，即通过程序以外的配置源，动态地绑定指定类型。

随着 Spring Boot / Spring Cloud 应用的流行，开发人员逐渐地接受并且使用 Spring Boot 外部化配置（External Configuration），即通过 application.properties 或者 bootstrap.properties 装配配置 Bean。

下列表格记录了 Dubbo 内置配置类：

配置类	标签	用途	解释
`ProtocolConfig`	`<dubbo:protocol/>`	协议配置	用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受
`ApplicationConfig`	`<dubbo:application/>`	应用配置	用于配置当前应用信息，不管该应用是提供者还是消费者
`ModuleConfig`	`<dubbo:module/>`	模块配置	用于配置当前模块信息，可选
`RegistryConfig`	`<dubbo:registry/>`	注册中心配置	用于配置连接注册中心相关信息
`MonitorConfig`	`<dubbo:monitor/>`	监控中心配置	用于配置连接监控中心相关信息，可选
`ProviderConfig`	`<dubbo:provider/>`	提供方配置	当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选
`ConsumerConfig`	`<dubbo:consumer/>`	消费方配置	当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选
`MethodConfig`	`<dubbo:method/>`	方法配置	用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息
`ArgumentConfig`	`<dubbo:argument/>`	参数配置	用于指定方法参数配置

通过申明对应的 Spring 扩展标签，在 Spring 应用上下文中将自动生成相应的配置 Bean。

在 Dubbo 官方用户手册的“属性配置”章节中，dubbo.properties 配置属性能够映射到 ApplicationConfig 、ProtocolConfig 以及 RegistryConfig 的字段。从某种意义上来说，dubbo.properties 也是 Dubbo 的外部化配置。

注：更多外部化配置的详情，请参考《Dubbo 外部化配置（Externalized Configuration）》

现场演示环节

本环境为分享后部分，现在编码 + 演示环境，当前文字仅提供代码实现。

Dubbo 整合 Hystrix 示例

本示例出现在分享议程的代码演示，将其放置此处，方便阅读理解

Dubbo 客户端实现

实现 HystrixCommand

public class ResultHystrixCommand extends HystrixCommand<Result> {

    private final Invoker<?> invoker;

    private final Invocation invocation;

    public ResultHystrixCommand(Invoker<?> invoker, Invocation invocation) {
        super(HystrixCommandGroupKey.Factory.asKey(
                "ResultHystrixCommand"),
                100); // 设置超时时间
        // 关联 Dubbo Invoker 和 Invocation
        this.invoker = invoker;
        this.invocation = invocation;
    }

    @Override
    protected Result run() throws Exception {
        // 远程方法调用执行
        return invoker.invoke(invocation);
    }
}

当目标方法执行时间超过 100 ms 时，触发熔断，并抛出 new UnsupportedOperationException("No fallback available.")。

Dubbo Filter 整合 ResultHystrixCommand

@Activate(group = Constants.CONSUMER, value = "hystrix") // 命名当前 Filter 为 "hystrix"
public class HystrixFilter implements Filter {

    @Override
    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException {
        return new ResultHystrixCommand(invoker, invocation).execute();
    }
}

创建并配置 Filter SPI 配置文件

在相对于 ClassPath 资源 META-INF/dubbo/ 下创建 com.alibaba.dubbo.rpc.Filter，并配置如下：

hystrix=com.alibaba.boot.dubbo.demo.consumer.filter.HystrixFilter

配置 @Reference filter 属性

@RestController
public class DemoConsumerController {

    @Reference(
            version = "${demo.service.version}",
            application = "${dubbo.application.id}",
            url = "dubbo://localhost:12345",
            filter = "hystrix" // 指向 HystrixFilter 实现
    )
    private DemoService demoService;

    @RequestMapping("/sayHello")
    public String sayHello(@RequestParam String name) {
        return demoService.sayHello(name);
    }

}

Dubbo 服务端实现

服务提供者实现

@Service(
        version = "${demo.service.version}",
        application = "${dubbo.application.id}",
        protocol = "dubbo",
        registry = "${dubbo.registry.id}"
)
public class DefaultDemoService implements DemoService {

    private final Random random = new Random();

    public String sayHello(String name) {
        hold();
        return "Say : Hello, " + name + " (from Spring Boot)";
    }

    private void hold() { // 随机等待 < 200 ms，当时间超过 100 ms 时，触发客户端熔断
        long time = random.nextInt(200);
        System.out.println("To hold " + time + " ms!");
        try {
            Thread.sleep(time);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

}

测试客户端 REST 服务

依次启动服务端和客户端 Spring Boot 应用，

执行 curl 命令

mercyblitz$ curl http://localhost:8080/sayHello?name=Hello

测试结果

{"timestamp":"2018-06-23T01:33:58.682+0000","status":500,"error":"Internal Server Error","message":"ResultHystrixCommand timed-out and no fallback available.","path":"/sayHello"}

运行结果说明服务端方法执行超过 100 ms，引起客户端熔断。

（EOF）

参考资源

Dubbo 官网：https://dubbo.apache.org/
Dubbo 工程：https://github.com/apache/incubator-dubbo
Dubbo Spring Boot 工程：https://github.com/apache/incubator-dubbo-spring-boot-project
CNCF Landscape：https://landscape.cncf.io/
Spring Cloud 官网：https://projects.spring.io/spring-cloud/
Kong 社区官网：https://konghq.com/kong-community-edition/
Opentracing 官网：http://opentracing.io/
Jaeger 官网：https://www.jaegertracing.io/
Prometheus 官网：https://prometheus.io/
OpenTsdb 官网：http://opentsdb.net/
Grafana 官网：https://grafana.com/
小马哥 Github：https://github.com/mercyblitz

Spring Boot web 应用加速

Sat, 26 May 2018 00:00:00 +0000

Spring Boot Web 应用加速

默认情况下，Spring Boot Web 应用会装配一些功能组件 Bean。

在大多数 Web 应用场景下，可以选择性地关闭一下自动装配的Spring 组件 Bean，以达到提升性能的目的。

配置项优化

Spring Boot Web 应用加速完整配置项

management.add-application-context-header = false
spring.mvc.formcontent.putfilter.enabled = false

spring.autoconfigure.exclude = org.springframework.boot.autoconfigure.admin.SpringApplicationAdminJmxAutoConfiguration,\
org.springframework.boot.autoconfigure.jmx.JmxAutoConfiguration,\
org.springframework.boot.autoconfigure.gson.GsonAutoConfiguration,\
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.jdbc.XADataSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.jdbc.JndiDataSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.transaction.jta.JtaAutoConfiguration,\
org.springframework.boot.autoconfigure.websocket.WebSocketAutoConfiguration,\
org.springframework.boot.autoconfigure.websocket.WebSocketMessagingAutoConfiguration,\
org.springframework.boot.autoconfigure.freemarker.FreeMarkerAutoConfiguration,\
org.springframework.boot.autoconfigure.groovy.template.GroovyTemplateAutoConfiguration,\
org.springframework.boot.autoconfigure.mustache.MustacheAutoConfiguration,\
org.springframework.boot.autoconfigure.mail.MailSenderAutoConfiguration,\
org.springframework.boot.autoconfigure.mail.MailSenderValidatorAutoConfiguration,\
org.springframework.boot.actuate.autoconfigure.TraceRepositoryAutoConfiguration,\
org.springframework.boot.actuate.autoconfigure.TraceWebFilterAutoConfiguration,\
org.springframework.boot.actuate.autoconfigure.MetricFilterAutoConfiguration

配置项汇总

spring.autoconfigure.exclude = org.springframework.boot.actuate.autoconfigure.TraceRepositoryAutoConfiguration,\
org.springframework.boot.actuate.autoconfigure.TraceWebFilterAutoConfiguration,\
org.springframework.boot.actuate.autoconfigure.MetricFilterAutoConfiguration

关闭 Web 请求跟踪自动装配

`org.springframework.boot.actuate.autoconfigure.TraceWebFilterAutoConfiguration`

顾名思义，该自动装配用跟踪 Web 请求，通过Servlet Filter org.springframework.boot.actuate.trace.WebRequestTraceFilter 记录请求的信息（如：请求方法、请求头以及请求路径等），其计算的过程存在一定的开销，使用场景罕见，故可选择关闭。

配置项

spring.autoconfigure.exclude = org.springframework.boot.actuate.autoconfigure.TraceWebFilterAutoConfiguration

`org.springframework.boot.actuate.autoconfigure.TraceRepositoryAutoConfiguration`

当org.springframework.boot.actuate.autoconfigure.TraceWebFilterAutoConfiguration关闭后，其请求信息存储介质org.springframework.boot.actuate.trace.TraceRepository没有存在的必要，故可选择关闭。

配置项

spring.autoconfigure.exclude = org.springframework.boot.actuate.autoconfigure.TraceRepositoryAutoConfiguration

关闭 Web 请求结果指标自动装配

`org.springframework.boot.actuate.autoconfigure.MetricFilterAutoConfiguration`

该组件将自动装配org.springframework.boot.actuate.autoconfigure.MetricsFilter，该 Filter

主要记录Web 请求结果指标（如：相应状态码、请求方法执行时间等），该信息一定程度上与反向代理服务器（nginx）功能重叠，故可选择关闭。

配置项

spring.autoconfigure.exclude = org.springframework.boot.actuate.autoconfigure.MetricFilterAutoConfiguration

可关闭 Servlet Web 组件

`org.springframework.web.filter.HttpPutFormContentFilter`

引入版本

org.springframework.web.filter.HttpPutFormContentFilter 由 Spring Framework 3.1 版本引入，分发在 org.springframework:spring-web 中。

使用场景

通常 Web 场景中，浏览器通过 HTTP GET 或者 POST 请求提交 Form 数据，而非浏览器客户端（如应用程序）可能通过 HTTP PUT 请求来实现。

当 HTTP 请求头Content-Type 为 application/x-www-form-urlencoded 时，Form 数据被 encoded。而 Servlet 规范中， ServletRequest.getParameter*() 方法仅对 HTTP POST 方法支持请求参数的获取，如：

public intetfacce ServletRequest {

    ......

    public String getParameter(String name);

    public Enumeration<String> getParameterNames();

    public String[] getParameterValues(String name);

    public Map<String, String[]> getParameterMap();

    ......

}

故以上方法无法支持 HTTP PUT 或 HTTP PATCH 请求方法（请求头Content-Type 为application/x-www-form-urlencoded）。

org.springframework.web.filter.HttpPutFormContentFilter 正是这种场景的解决方案。

Spring Boot 默认场景下，将 org.springframework.web.filter.HttpPutFormContentFilter 被 org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration 自动装配，以下为 Spring Boot 1.4.1.RELEASE 以及更好版本定义（可能存在一定的差异）：

@Configuration
@ConditionalOnWebApplication
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class,
		WebMvcConfigurerAdapter.class })
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE + 10)
@AutoConfigureAfter({ DispatcherServletAutoConfiguration.class,
		ValidationAutoConfiguration.class })
public class WebMvcAutoConfiguration {

    ......

    @Bean
    @ConditionalOnMissingBean(HttpPutFormContentFilter.class)
    @ConditionalOnProperty(prefix = "spring.mvc.formcontent.putfilter", name = "enabled", matchIfMissing = true)
    public OrderedHttpPutFormContentFilter httpPutFormContentFilter() {
        return new OrderedHttpPutFormContentFilter();
    }

    ......

}

综上所述，org.springframework.web.filter.HttpPutFormContentFilter 在绝大多数 Web 使用场景下为非必须组件。

配置项

如果应用依赖 Spring Boot 版本为 1.4.1.RELEASE 以及更高的版本，可通过如下配置，进行将 org.springframework.web.filter.HttpPutFormContentFilter 关闭：

spring.mvc.formcontent.putfilter.enabled = false

`org.springframework.web.filter.HiddenHttpMethodFilter`

引入版本

org.springframework.web.filter.HiddenHttpMethodFilter 由 Spring Framework 3.0 版本引入，分发在 org.springframework:spring-web 中。

使用场景

当 Web 服务端同一资源（URL）提供了多请求方法的实现，例如 URI ：/update 提供了 HTTP POST 以及 HTTP PUT 实现），通常 Web 场景中，浏览器仅支持 HTTP GET 或者 POST 请求方法，这样的话，浏览器无法发起 HTTP PUT 请求。

为了浏览器可以消费 HTTP PUT 资源，需要在服务端将 HTTP POST 转化成 HTTP PUT 请求，为了解决这类问题，Spring 引入 org.springframework.web.filter.HiddenHttpMethodFilter Web 组件。

当浏览器发起 HTTP POST 请求时，可通过增加请求参数（默认参数名称：”_method”）的方式，进行HTTP 请求方法切换， org.springframework.web.filter.HiddenHttpMethodFilter 获取参数”_method” 值后，将参数值作为 HttpServletRequest#getMethod()的返回值，给后续 Servlet 实现使用。

出于通用性的考虑，org.springframework.web.filter.HiddenHttpMethodFilter 通过调用 #setMethodParam(String) 方法，来修改转换请求方法的参数名称。

@Configuration
@ConditionalOnWebApplication
@ConditionalOnClass({ Servlet.class, DispatcherServlet.class,
		WebMvcConfigurerAdapter.class })
@ConditionalOnMissingBean(WebMvcConfigurationSupport.class)
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE + 10)
@AutoConfigureAfter({ DispatcherServletAutoConfiguration.class,
		ValidationAutoConfiguration.class })
public class WebMvcAutoConfiguration {

    ......

    @Bean
    @ConditionalOnMissingBean(HiddenHttpMethodFilter.class)
    public OrderedHiddenHttpMethodFilter hiddenHttpMethodFilter() {
        return new OrderedHiddenHttpMethodFilter();
    }

    ......

}

综上所述，org.springframework.web.filter.HiddenHttpMethodFilter 也是特殊场景下所需，故可以关闭之。

配置项

按目前最新的 Spring Boot 1.5.2.RELEASE 版本中实现，也没有提供类似 spring.mvc.formcontent.putfilter.enabled 这样的配置项关闭，无法关闭。

Dubbo 外部化配置

Thu, 18 Jan 2018 00:00:00 +0000

Dubbo 外部化配置（Externalized Configuration）

外部化配置（External Configuration）

在Dubbo 注解驱动例子中，无论是服务提供方，还是服务消费方，均需要转配相关配置Bean：

    @Bean
    public ApplicationConfig applicationConfig() {
        ApplicationConfig applicationConfig = new ApplicationConfig();
        applicationConfig.setName("dubbo-annotation-consumer");
        return applicationConfig;
    }

下列表格记录了 Dubbo 内置配置类：

配置类	标签	用途	解释
`ProtocolConfig`	`<dubbo:protocol/>`	协议配置	用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受
`ApplicationConfig`	`<dubbo:application/>`	应用配置	用于配置当前应用信息，不管该应用是提供者还是消费者
`ModuleConfig`	`<dubbo:module/>`	模块配置	用于配置当前模块信息，可选
`RegistryConfig`	`<dubbo:registry/>`	注册中心配置	用于配置连接注册中心相关信息
`MonitorConfig`	`<dubbo:monitor/>`	监控中心配置	用于配置连接监控中心相关信息，可选
`ProviderConfig`	`<dubbo:provider/>`	提供方配置	当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选
`ConsumerConfig`	`<dubbo:consumer/>`	消费方配置	当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选
`MethodConfig`	`<dubbo:method/>`	方法配置	用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息
`ArgumentConfig`	`<dubbo:argument/>`	参数配置	用于指定方法参数配置

通过申明对应的 Spring 扩展标签，在 Spring 应用上下文中将自动生成相应的配置 Bean。

其中，引用“映射规则”的内容：

映射规则

将 XML 配置的标签名，加属性名，用点分隔，多个属性拆成多行

比如：dubbo.application.name=foo等价于<dubbo:application name="foo" />

比如：dubbo.registry.address=10.20.153.10:9090等价于<dubbo:registryaddress="10.20.153.10:9090" />

如果 XML 有多行同名标签配置，可用 id 号区分，如果没有 id 号将对所有同名标签生效

比如：dubbo.protocol.rmi.port=1234等价于<dubbo:protocol id="rmi" name="rmi" port="1099" />2

比如：dubbo.registry.china.address=10.20.153.10:9090等价于<dubbo:registry id="china"address="10.20.153.10:9090" />

下面是 dubbo.properties 的一个典型配置：
1
2
3
dubbo.application.name=foo
dubbo.application.owner=bar
dubbo.registry.address=10.20.153.10:9090

根据“映射规则”，Dubbo 即支持单配置 Bean 映射，也支持多 Bean 映射。综合以上需求，既要兼容 Dubbo 已有的一个或多个 Bean 字段映射绑定，也支持外部化配置。

特别提醒：外部化配置（External Configuration）并非 Spring Boot 特有，即使在 Spring Framework 场景下亦能支持。也就是说 Dubbo 外部化配置即可在 Spring Framework 中工作，也能在 Spring Boot 中运行。

Dubbo 外部化配置（External Configuration）支持起始版本为：2.5.8

`@EnableDubboConfig`

起始版本：`2.5.8`

使用说明

`@EnableDubboConfig` 定义

public @interface EnableDubboConfig {

    /**
     * It indicates whether binding to multiple Spring Beans.
     *
     * @return the default value is <code>false</code>
     * @revised 2.5.9
     */
    boolean multiple() default false;

}

multiple : 表示是否支持多Dubbo 配置 Bean 绑定。默认值为 false ，即单 Dubbo 配置 Bean 绑定

单 Dubbo 配置 Bean 绑定

为了更好地向下兼容，@EnableDubboConfig 提供外部化配置属性与 Dubbo 配置类之间的绑定，其中映射关系如下：

配置类	外部化配置属性前缀	用途
`ProtocolConfig`	`dubbo.protocol`	协议配置
`ApplicationConfig`	`dubbo.application`	应用配置
`ModuleConfig`	`dubbo.module`	模块配置
`RegistryConfig`	`dubbo.registry`	注册中心配置
`MonitorConfig`	`dubbo.monitor`	监控中心配置
`ProviderConfig`	`dubbo.provider`	提供方配置
`ConsumerConfig`	`dubbo.consumer`	消费方配置

当标注 @EnableDubboConfig 的类被扫描注册后，同时 Spring（Spring Boot）应用配置（PropertySources）中存在dubbo.application.* 时，ApplicationConfig Bean 将被注册到在 Spring 上下文。否则，不会被注册。如果出现dubbo.registry.*的配置，那么，RegistryConfig Bean 将会创建，以此类推。即按需装配 Dubbo 配置 Bean。

如果需要指定配置 Bean的 id，可通过**.id 属性设置，以dubbo.application 为例：

## application
dubbo.application.id = applicationBean
dubbo.application.name = dubbo-demo-application

以上配置等同于以下 Java Config Bean：

    @Bean("applicationBean")
    public ApplicationConfig applicationBean() {
        ApplicationConfig applicationConfig = new ApplicationConfig();
        applicationConfig.setName("dubbo-demo-application");
        return applicationConfig;
    }

大致上配置属性与配置类绑定模式 - dubbo.application.* 映射到 ApplicationConfig 中的字段。

注：当配置属性名称无法在配置类中找到字段时，将会忽略绑定

多 Dubbo 配置 Bean 绑定

Dubbo @Service 和 @Reference 允许 Dubbo 应用关联ApplicationConfig Bean 或者指定多个RegistryConfig Bean 等能力。换句话说，Dubbo 应用上下文中可能存在多个ApplicationConfig 等 Bean定义。

为了适应以上需要，因此从Dubbo 2.5.9 开始，@EnableDubboConfig 支持多 Dubbo 配置 Bean 绑定，同时按照业界规约标准，与单 Dubbo 配置 Bean 绑定约定不同，配置属性前缀均为英文复数形式：

详情请参考：https://github.com/alibaba/dubbo/issues/1141

dubbo.applications
dubbo.modules
dubbo.registries
dubbo.protocols
dubbo.monitors
dubbo.providers
dubbo.consumers

以dubbo.applications 为例，基本的模式如下：

dubbo.applications.${bean-name}.property-name = ${property-value}

请读者注意，在单 Dubbo 配置 Bean 绑定时，可以通过指定id 属性的方式，定义ApplicationConfig Bean 的ID，即dubbo.application.id。

而在多 Dubbo 配置 Bean 绑定时，Bean ID 则由dubbo.applications.与属性字段名称（.property-name)之间的字符来表达。

如下配置：

# multiple Bean definition
dubbo.applications.applicationBean.name = dubbo-demo-application
dubbo.applications.applicationBean2.name = dubbo-demo-application2
dubbo.applications.applicationBean3.name = dubbo-demo-application3

该配置内容中，绑定了三个ApplicationConfig Bean，分别是applicationBean、applicationBean2以及applicationBean3

示例说明

@EnableDubboConfig 的使用方法很简答，再次强调一点，当规约的外部配置存在时，相应的 Dubbo 配置类才会提升为 Spring Bean。简言之，按需装配。

单 Dubbo 配置 Bean 绑定

外部化配置文件

将以下内容的外部化配置文件物理路径为：classpath:/META-INF/config.properties:

# 单 Dubbo 配置 Bean 绑定
## application
dubbo.application.id = applicationBean
dubbo.application.name = dubbo-demo-application

## module
dubbo.module.id = moduleBean
dubbo.module.name = dubbo-demo-module

## registry
dubbo.registry.address = zookeeper://192.168.99.100:32770

## protocol
dubbo.protocol.name = dubbo
dubbo.protocol.port = 20880

## monitor
dubbo.monitor.address = zookeeper://127.0.0.1:32770

## provider
dubbo.provider.host = 127.0.0.1

## consumer
dubbo.consumer.client = netty

`@EnableDubboConfig` 配置 Bean

/**
 * Dubbo 配置 Bean
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
@EnableDubboConfig
@PropertySource("META-INF/config.properties")
@Configuration
public class DubboConfiguration {

}

实现引导类

/**
 * Dubbo 配置引导类
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
public class DubboConfigurationBootstrap {

    public static void main(String[] args) {
        // 创建配置上下文
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        // 注册当前配置 Bean
        context.register(DubboConfiguration.class);
        context.refresh();
 	    // application
        ApplicationConfig applicationConfig = context.getBean("applicationBean", ApplicationConfig.class);
        System.out.printf("applicationBean.name = %s \n", applicationConfig.getName());

        // module
        ModuleConfig moduleConfig = context.getBean("moduleBean", ModuleConfig.class);
        System.out.printf("moduleBean.name = %s \n", moduleConfig.getName());

        // registry
        RegistryConfig registryConfig = context.getBean(RegistryConfig.class);
        System.out.printf("registryConfig.name = %s \n", registryConfig.getAddress());

        // protocol
        ProtocolConfig protocolConfig = context.getBean(ProtocolConfig.class);
        System.out.printf("protocolConfig.name = %s \n", protocolConfig.getName());
        System.out.printf("protocolConfig.port = %s \n", protocolConfig.getPort());

        // monitor
        MonitorConfig monitorConfig = context.getBean(MonitorConfig.class);
        System.out.printf("monitorConfig.name = %s \n", monitorConfig.getAddress());

        // provider
        ProviderConfig providerConfig = context.getBean(ProviderConfig.class);
        System.out.printf("providerConfig.name = %s \n", providerConfig.getHost());

        // consumer
        ConsumerConfig consumerConfig = context.getBean(ConsumerConfig.class);
        System.out.printf("consumerConfig.name = %s \n", consumerConfig.getClient());
    }
}

执行结果

applicationBean.name = dubbo-demo-application 
moduleBean.name = dubbo-demo-module 
registryConfig.name = zookeeper://192.168.99.100:32770 
protocolConfig.name = dubbo 
protocolConfig.port = 20880 
monitorConfig.name = zookeeper://127.0.0.1:32770 
providerConfig.name = 127.0.0.1 
consumerConfig.name = netty 

不难发现，@EnableDubboConfig 配置 Bean 配合外部化文件 classpath:/META-INF/config.properties，与执行输出内容相同。

多 Dubbo 配置 Bean 绑定

外部化配置文件

将以下内容的外部化配置文件物理路径为：classpath:/META-INF/multiple-config.properties:

# 多 Dubbo 配置 Bean 绑定
## dubbo.applications
dubbo.applications.applicationBean.name = dubbo-demo-application
dubbo.applications.applicationBean2.name = dubbo-demo-application2
dubbo.applications.applicationBean3.name = dubbo-demo-application3

`@EnableDubboConfig` 配置 Bean（多）

@EnableDubboConfig(multiple = true)
@PropertySource("META-INF/multiple-config.properties")
private static class DubboMultipleConfiguration {

}	

实现引导类

/**
 * Dubbo 配置引导类
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
public class DubboConfigurationBootstrap {
    public static void main(String[] args) {
        // 创建配置上下文
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        // 注册当前配置 Bean
        context.register(DubboMultipleConfiguration.class);
        context.refresh();

        // 获取 ApplicationConfig Bean："applicationBean"、"applicationBean2" 和 "applicationBean3"
        ApplicationConfig applicationBean = context.getBean("applicationBean", ApplicationConfig.class);
        ApplicationConfig applicationBean2 = context.getBean("applicationBean2", ApplicationConfig.class);
        ApplicationConfig applicationBean3 = context.getBean("applicationBean3", ApplicationConfig.class);

        System.out.printf("applicationBean.name = %s \n", applicationBean.getName());
        System.out.printf("applicationBean2.name = %s \n", applicationBean2.getName());
        System.out.printf("applicationBean3.name = %s \n", applicationBean3.getName());
    }
}

执行结果

applicationBean.name = dubbo-demo-application 
applicationBean2.name = dubbo-demo-application2 
applicationBean3.name = dubbo-demo-application3 

@EnableDubboConfig(multiple = true) 执行后，运行结果说明ApplicationConfig Bean 以及 ID 的定义方式。

`@EnableDubboConfigBinding` & `@EnableDubboConfigBindings`

@EnableDubboConfig适合绝大多数外部化配置场景，然而无论是单 Bean 绑定，还是多 Bean 绑定，其外部化配置属性前缀是固化的，如dubbo.application 以及 dubbo.applications 。

当应用需要自定义外部化配置属性前缀，@EnableDubboConfigBinding能提供更大的弹性，支持单个外部化配置属性前缀（prefix) 与 Dubbo 配置 Bean 类型（AbstractConfig 子类）绑定，如果需要多次绑定时，可使用@EnableDubboConfigBindings。

尽管 Dubbo 推荐使用 Java 8 ，然而实际的情况，运行时的 JDK 的版本可能从 6到8 均有。因此，@EnableDubboConfigBinding 没有实现java.lang.annotation.Repeatable，即允许实现类不支持重复标注@EnableDubboConfigBinding。

@EnableDubboConfigBinding 在支持外部化配置属性与 Dubbo 配置类绑定时，与 Dubbo 过去的映射行为不同，被绑定的 Dubbo 配置类将会提升为 Spring Bean，无需提前装配 Dubbo 配置类。同时，支持多 Dubbo 配置Bean 装配。其 Bean 的绑定规则与@EnableDubboConfig一致。

起始版本： `2.5.8`

使用说明

`@EnableDubboConfigBinding` 定义

public @interface EnableDubboConfigBinding {

    /**
     * The name prefix of the properties that are valid to bind to {@link AbstractConfig Dubbo Config}.
     *
     * @return the name prefix of the properties to bind
     */
    String prefix();

    /**
     * @return The binding type of {@link AbstractConfig Dubbo Config}.
     * @see AbstractConfig
     * @see ApplicationConfig
     * @see ModuleConfig
     * @see RegistryConfig
     */
    Class<? extends AbstractConfig> type();

    /**
     * It indicates whether {@link #prefix()} binding to multiple Spring Beans.
     *
     * @return the default value is <code>false</code>
     */
    boolean multiple() default false;

}

prefix() : 指定待绑定 Dubbo 配置类的外部化配置属性的前缀，比如dubbo.application 为 ApplicationConfig 的外部化配置属性的前缀。prefix() 支持占位符（Placeholder）, 并且其关联前缀值是否以”.” 作为结尾字符是可选的，即prefix() = "dubbo.application" 与 prefix() = "dubbo.application." 效果相同
type() : 指定 Dubbo 配置类，所有 AbstractConfig 的实现子类即可，如ApplicationConfig 、RegistryConfig 以及 ProtocolConfig 等
multiple() : 表明是否需要将prefix() 作为多个 type() 类型的 Spring Bean 外部化配置属性。默认值为false，即默认支持单个类型的 Spring 配置 Bean

假设标注 @EnableDubboConfigBinding 的实现类被 Spring 应用上下文扫描并且注册后，其中prefix() = dubbo.app 、 type() = ApplicationConfig.class ，且外部配置内容为：

dubbo.app.id = applicationBean
dubbo.app.name = dubbo-demo-application

Spring 应用上下文启动后，一个 ID 为 “applicationBean” 的 ApplicationConfig Bean 被初始化，其 name 字段被设置为 “dubbo-demo-application”。

`EnableDubboConfigBindings` 定义

public @interface EnableDubboConfigBindings {

    /**
     * The value of {@link EnableDubboConfigBindings}
     *
     * @return non-null
     */
    EnableDubboConfigBinding[] value();

}

value : 指定多个EnableDubboConfigBinding，用于实现外部化配置属性前缀（prefix) 与 Dubbo 配置 Bean 类型（AbstractConfig 子类）绑定。

示例说明

外部化配置文件

将以下内容的外部化配置文件物理路径为：classpath:/META-INF/bindings.properties

# classpath:/META-INF/bindings.properties
## 占位符值 : ApplicationConfig 外部配置属性前缀
applications.prefix = dubbo.apps.

## 多 ApplicationConfig Bean 绑定
dubbo.apps.applicationBean.name = dubbo-demo-application
dubbo.apps.applicationBean2.name = dubbo-demo-application2
dubbo.apps.applicationBean3.name = dubbo-demo-application3

## 单 ModuleConfig Bean 绑定
dubbo.module.id = moduleBean
dubbo.module.name = dubbo-demo-module

## 单 RegistryConfig Bean 绑定
dubbo.registry.address = zookeeper://192.168.99.100:32770

`EnableDubboConfigBindings` 配置 Bean

DubboConfiguration 作为 Dubbo 配置 Bean，除通过 @EnableDubboConfigBinding 绑定之外，还需要 @PropertySource 指定外部化配置文件（classpath:/META-INF/bindings.properties）:

/**
 * Dubbo 配置 Bean
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
@EnableDubboConfigBindings({
        @EnableDubboConfigBinding(prefix = "${applications.prefix}",
                type = ApplicationConfig.class, multiple = true), // 多 ApplicationConfig Bean 绑定
        @EnableDubboConfigBinding(prefix = "dubbo.module", // 不带 "." 后缀
                type = ModuleConfig.class), // 单 ModuleConfig Bean 绑定
        @EnableDubboConfigBinding(prefix = "dubbo.registry.", // 带 "." 后缀
                type = RegistryConfig.class) // 单 RegistryConfig Bean 绑定
})
@PropertySource("META-INF/bindings.properties")
@Configuration
public class DubboConfiguration {
  
}

实现引导类

通过之前的使用说明，当 EnableDubboConfigBinding 将外部配置化文件classpath:/META-INF/dubbo.properties 绑定到 ApplicationConfig后，其中 Spring Bean “applicationBean” 的 name 字段被设置成 “dubbo-demo-application”。同时， EnableDubboConfigBinding 所标注的 DubboConfiguration 需要被 Sring 应用上下文注册：

/**
 * Dubbo 配置引导类
 *
 * @author <a href="mailto:mercyblitz@gmail.com">Mercy</a>
 */
public class DubboConfigurationBootstrap {

    public static void main(String[] args) {
        // 创建配置上下文
        AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
        // 注册当前配置 Bean
        context.register(DubboConfiguration.class);
        context.refresh();
 		// 获取 ApplicationConfig Bean："applicationBean"、"applicationBean2" 和 "applicationBean3"
        ApplicationConfig applicationBean = context.getBean("applicationBean", ApplicationConfig.class);
        ApplicationConfig applicationBean2 = context.getBean("applicationBean2", ApplicationConfig.class);
        ApplicationConfig applicationBean3 = context.getBean("applicationBean3", ApplicationConfig.class);

        System.out.printf("applicationBean.name = %s \n", applicationBean.getName());
        System.out.printf("applicationBean2.name = %s \n", applicationBean2.getName());
        System.out.printf("applicationBean3.name = %s \n", applicationBean3.getName());

        // 获取 ModuleConfig Bean："moduleBean"
        ModuleConfig moduleBean = context.getBean("moduleBean", ModuleConfig.class);

        System.out.printf("moduleBean.name = %s \n", moduleBean.getName());

        // 获取 RegistryConfig Bean
        RegistryConfig registry = context.getBean(RegistryConfig.class);

        System.out.printf("registry.address = %s \n", registry.getAddress());
    }
}

运行结果

DubboConfigurationBootstrap 运行后控制台输出：

applicationBean.name = dubbo-demo-application 
applicationBean2.name = dubbo-demo-application2 
applicationBean3.name = dubbo-demo-application3 
moduleBean.name = dubbo-demo-module 
registry.address = zookeeper://192.168.99.100:32770 

输出的内容与classpath:/META-INF/bindings.properties 绑定的内容一致，符合期望。

Mercy Ma

《深入理解 spring cloud 与实战》序

《深入理解 Spring Cloud 与实战》序

Apache dubbo 服务自省架构设计

背景

术语约定

使用场景

超大规模 Dubbo 服务治理场景

微服务架构和元原生应用

Dubbo 元数据架构的基石

传统架构

现实挑战

如何解决或缓解注册中心压力过载

注册中心内存压力

注册中心网络压力

注册中心通知压力

如何支持以应用为粒度的服务注册与发现

支持 Spring Cloud 服务注册与发现模型

支持 Kubernetes 服务注册与发现模型

兼容 Dubbo 传统服务注册与发现模型

如何精简 Dubbo URL 元数据

架构设计

服务注册与发现架构

注册实体

注册中心

Dubbo 服务与 Service 映射

中心化映射配置

配置中心潜在的压力

注册中心作为配置中心

本地化映射配置

接口映射配置

外部化映射配置

应用级别映射配置

元数据服务架构

整体架构

微观架构

宏观架构

Provider 执行流程

Consumer 执行流程

元数据服务 Metadata

元数据服务存储模式

元数据服务本地存储模式

元数据服务远程存储模式

选择存储模式

Dubbo 服务修订版本

元数据类型

Dubbo 暴露的服务 URL 列表

Dubbo 订阅的服务 URL 列表

Dubbo 服务定义

更多元数据类型支持

元数据服务升级

事件驱动架构

Dubbo 内建事件

Dubbo 服务类型事件

Dubbo Service 类型事件

Dubbo 服务实例类型事件

Dubbo 服务注册和发现类型事件

结束语

What’s the next?

2019 java 趋势报告 infoq 采访稿（小马哥部分）

趋势报告框架

第一部分：Java的技术采用生命周期

第二部分：Java趋势点评

第三部分：应用实践

参与专家：

Service mesh 时代，dubbo 架构该怎么跟进？

作为 Duboo 核心开发者，请先简单介绍下自己

Spring Cloud 和 Duboo 在微服务方面的优劣分别是什么？

请介绍下 Duboo 的现状？

Duboo在成为Apache顶级项目的过程中，背后有哪些不为人知的故事？

在未来一年，Duboo的新特性路线图可以简单介绍下吗？

Duboo 开源以来，代码贡献者中阿里本身的开发者占绝大多数，这是否意味着来自阿里的需求会起主导作用？在后续的发展过程中，计划如何引入阿里之外的开发者？

Service Mesh 时代，需要什么样的微服务框架？

对于公司内部定制Dubbo而言，你有什么建议吗？

对于初级开发者而言，学习Duboo应该如何入手？对于资深开发者而言，怎样研究Dubbo的源代码更加高效？

你作为讲师参加GIAC，对本次GIAC大会有何寄语？

作为Duboo的开发者，你最喜欢的Java（Java8以后）特性是什么？你最希望加入的Java特性是什么？

简单介绍下你自己的从业经历？

书籍推荐

Dubbo spring cloud 重塑微服务治理

初始化 `spring-cloud-dubbo-server-sample` Maven 工程

初始化 `spring-cloud-dubbo-client-sample` Maven 工程

《java编程方法论响应式之rxjava篇》序

《Java编程方法论响应式之Rxjava篇》序

Reactive programming 一种技术各自表述

理解 `Future` 的限制

限制一：`Future` 的阻塞性

限制二：`Future` 不支持链式操作