Apache Dubbo – 生态集成

Blog: 如何通过 Apache ShenYu 网关代理 Dubbo 服务

Wed, 04 May 2022 00:00:00 +0000

1. 介绍

Apache ShenYu

Apache ShenYu(Incubating) 是一个异步的，高性能的，跨语言的，响应式的 API 网关。兼容各种主流框架体系，支持热插拔，用户可以定制化开发，满足用户各种场景的现状和未来需求，经历过大规模场景的锤炼。

2021年5月，ShenYu捐献给 Apache 软件基金会，Apache 基金会全票通过，顺利进入孵化器。

Apache Dubbo

Apache Dubbo 是一款微服务开发框架，它提供了 RPC 通信与微服务治理两大关键能力。这意味着，使用 Dubbo 开发的微服务，将具备相互之间的远程发现与通信能力，同时利用 Dubbo 提供的丰富服务治理能力，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。同时 Dubbo 是高度可扩展的，用户几乎可以在任意功能点去定制自己的实现，以改变框架的默认行为来满足自己的业务需求。

2. Dubbo快速开始

本小节介绍如何将Dubbo服务接入到ShenYu网关，您可以直接在工程下找到本小节的示例代码。

2.1 启动shenyu-admin

shenyu-admin是Apache ShenYu后台管理系统，启动的方式有多种，本文通过 [本地部署](https://shenyu.apache.org/zh/docs/deployment/deployment-local) 的方式启动。启动成功后，需要在基础配置->插件管理中，把dubbo 插件设置为开启，并设置你的注册地址，请确保注册中心已经开启。

2.2 启动shenyu网关

在这里通过源码的方式启动，直接运行shenyu-bootstrap中的ShenyuBootstrapApplication。

在启动前，请确保网关已经引入相关依赖。如果客户端是apache dubbo，注册中心使用zookeeper，请参考如下配置：

 <!-- apache shenyu apache dubbo plugin start-->
 <dependency>
 <groupId>org.apache.shenyu</groupId>
 <artifactId>shenyu-spring-boot-starter-plugin-apache-dubbo</artifactId>
 <version>${project.version}</version>
 </dependency>
 <dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo</artifactId>
 <version>2.7.5</version>
 </dependency>
 <!-- Dubbo zookeeper registry dependency start -->
 <dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-client</artifactId>
 <version>4.0.1</version>
 <exclusions>
 <exclusion>
 <artifactId>log4j</artifactId>
 <groupId>log4j</groupId>
 </exclusion>
 </exclusions>
 </dependency>
 <dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-framework</artifactId>
 <version>4.0.1</version>
 </dependency>
 <dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-recipes</artifactId>
 <version>4.0.1</version>
 </dependency>
 <!-- Dubbo zookeeper registry dependency end -->
 <!-- apache dubbo plugin end-->

2.3 启动shenyu-examples-dubbo

以官网提供的例子为例 shenyu-examples-dubbo 。假如dubbo服务定义如下：

<beans /* ...... * />

 <dubbo:application name="test-dubbo-service"/>
 <dubbo:registry address="${dubbo.registry.address}"/>
 <dubbo:protocol name="dubbo" port="20888"/>

 <dubbo:service timeout="10000" interface="org.apache.shenyu.examples.dubbo.api.service.DubboTestService" ref="dubboTestService"/>

</beans>

声明应用服务名称，注册中心地址，使用dubbo协议，声明服务接口，对应接口实现类：

/**
 * DubboTestServiceImpl.
 */
@Service("dubboTestService")
public class DubboTestServiceImpl implements DubboTestService {

 @Override
 @ShenyuDubboClient(path = "/findById", desc = "Query by Id")
 public DubboTest findById(final String id) {
 return new DubboTest(id, "hello world shenyu Apache, findById");
 }

 //......
}

在接口实现类中，使用注解@ShenyuDubboClient向shenyu-admin注册服务。

在配置文件application.yml中的配置信息：

server:
 port: 8011
 address: 0.0.0.0
 servlet:
 context-path: /
spring:
 main:
 allow-bean-definition-overriding: true
dubbo:
 registry:
 address: zookeeper://localhost:2181 # dubbo使用的注册中心

shenyu:
 register:
 registerType: http #注册方式
 serverLists: http://localhost:9095 #注册地址
 props:
 username: admin
 password: 123456
 client:
 dubbo:
 props:
 contextPath: /dubbo
 appName: dubbo

在配置文件中，声明dubbo使用的注册中心地址，dubbo服务向shenyu-admin注册，使用的方式是http，注册地址是http://localhost:9095。

关于注册方式的使用，请参考 [应用客户端接入](https://shenyu.apache.org/docs/design/register-center-design/) 。

2.4 调用dubbo服务

shenyu-examples-dubbo项目成功启动之后会自动把加 @ShenyuDubboClient 注解的接口方法注册到网关。

打开 插件列表 -> Proxy -> dubbo 可以看到插件规则配置列表：

注册成功的选择器信息：

注册成功的规则信息：

选择器和规则是 Apache ShenYu 网关中最灵魂的东西。掌握好它，你可以对任何流量进行管理。对应为选择器与规则里面的匹配条件(conditions)，根据不同的流量筛选规则，我们可以处理各种复杂的场景。流量筛选可以从Header, URI, Query, Cookie 等等Http请求获取数据。

然后可以采用 Match，=，Regex，Groovy，Exclude等匹配方式，匹配出你所预想的数据。多组匹配添加可以使用And/Or的匹配策略。

具体的介绍与使用请看: [选择器与规则管理](https://shenyu.apache.org/zh/docs/user-guide/admin-usage/selector-and-rule) 。

发起GET请求，通过ShenYu网关调用dubbo服务：

GET http://localhost:9195/dubbo/findById?id=100
Accept: application/json

成功响应之后，结果如下：

{
 "name": "hello world shenyu Apache, findById",
 "id": "100"
}

至此，就成功的通过http请求访问dubbo服务了，ShenYu网关通过shenyu-plugin-dubbo模块将http协议转成了dubbo协议。

3. 深入理解Dubbo插件

在运行上述demo的过程中，是否存在一些疑问：

dubbo服务是如何注册到shenyu-admin？
shenyu-admin是如何将数据同步到ShenYu网关？
DubboPlugin是如何将http协议转换到到dubbo协议？

带着这些疑问，来深入理解dubbo插件。

3.1 应用客户端接入

应用客户端接入是指将微服务接入到Apache ShenYu网关，当前支持Http、 Dubbo、 Spring Cloud、 gRPC、 Motan、 Sofa、 Tars等协议的接入。

将应用客户端接入到Apache ShenYu网关是通过注册中心来实现的，涉及到客户端注册和服务端同步数据。注册中心支持Http、Zookeeper、Etcd、Consul和Nacos。默认是通过Http方式注册。

客户端接入的相关配置请参考 [客户端接入配置](https://shenyu.apache.org/zh/docs/user-guide/register-center-access) 。

3.1.1 客户端注册

在你的微服务配置中声明注册中心客户端类型，如Http或Zookeeper。应用程序启动时使用SPI方式加载并初始化对应注册中心客户端，通过实现Spring Bean相关的后置处理器接口，在其中获取需要进行注册的服务接口信息，将获取的信息放入Disruptor中。

注册中心客户端从Disruptor中读取数据，并将接口信息注册到shenyu-admin，Disruptor在其中起数据与操作解耦的作用，利于扩展。

3.1.2 服务端注册

在shenyu-admin配置中声明注册中心服务端类型，如Http或Zookeeper。当shenyu-admin启动时，读取配置类型，加载并初始化对应的注册中心服务端，注册中心服务端收到shenyu-client注册的接口信息后，将其放入Disruptor中，然后会触发注册处理逻辑，将服务接口信息更新并发布同步事件。

Disruptor在其中起到数据与操作解耦，利于扩展。如果注册请求过多，导致注册异常，也有数据缓冲作用。

3.2 数据同步原理

数据同步是指在 shenyu-admin 后台操作数据以后，使用何种策略将数据同步到 Apache ShenYu 网关。Apache ShenYu 网关当前支持ZooKeeper、WebSocket、Http长轮询、Nacos 、Etcd 和 Consul 进行数据同步。默认是通过WebSocket进行数据同步。

数据同步的相关配置请参考 [数据同步配置](https://shenyu.apache.org/zh/docs/user-guide/use-data-sync) 。

3.2.1 数据同步的意义

网关是流量请求的入口，在微服务架构中承担了非常重要的角色，网关高可用的重要性不言而喻。在使用网关的过程中，为了满足业务诉求，经常需要变更配置，比如流控规则、路由规则等等。因此，网关动态配置是保障网关高可用的重要因素。

当前数据同步特性如下：

所有的配置都缓存在 Apache ShenYu 网关内存中，每次请求都使用本地缓存，速度非常快。
用户可以在 shenyu-admin 后台任意修改数据，并马上同步到网关内存。
支持 Apache ShenYu 的插件、选择器、规则数据、元数据、签名数据等数据同步。
所有插件的选择器，规则都是动态配置，立即生效，不需要重启服务。
数据同步方式支持 Zookeeper、Http 长轮询、Websocket、Nacos、Etcd 和 Consul。

3.2.2 数据同步原理分析

下图展示了 Apache ShenYu 数据同步的流程，Apache ShenYu 网关在启动时，会从配置服务同步配置数据，并且支持推拉模式获取配置变更信息，然后更新本地缓存。管理员可以在管理后台（shenyu-admin），变更用户权限、规则、插件、流量配置，通过推拉模式将变更信息同步给 Apache ShenYu 网关，具体是 push 模式，还是 pull 模式取决于使用哪种同步方式。

在最初的版本中，配置服务依赖 Zookeeper 实现，管理后台将变更信息 push 给网关。而现在可以支持 WebSocket、Http长轮询、Zookeeper、Nacos、Etcd 和 Consul，通过在配置文件中设置 shenyu.sync.${strategy} 指定对应的同步策略，默认使用 webosocket 同步策略，可以做到秒级数据同步。但是，有一点需要注意的是，Apache ShenYu网关和 shenyu-admin 必须使用相同的同步策略。

如下图所示，shenyu-admin 在用户发生配置变更之后，会通过 EventPublisher 发出配置变更通知，由 EventDispatcher 处理该变更通知，然后根据配置的同步策略(http、weboscket、zookeeper、naocs、etcd、consul)，将配置发送给对应的事件处理器。

如果是 websocket 同步策略，则将变更后的数据主动推送给 shenyu-web，并且在网关层，会有对应的 WebsocketDataHandler 处理器来处理 shenyu-admin 的数据推送。
如果是 zookeeper 同步策略，将变更数据更新到 zookeeper，而 ZookeeperSyncCache 会监听到 zookeeper 的数据变更，并予以处理。
如果是 http 同步策略，由网关主动发起长轮询请求，默认有 90s 超时时间，如果 shenyu-admin 没有数据变更，则会阻塞 http 请求，如果有数据发生变更则响应变更的数据信息，如果超过 60s 仍然没有数据变更则响应空数据，网关层接到响应后，继续发起 http 请求，反复同样的请求。

3.3 流程分析

流程分析是从源码的角度，展示服务注册流程，数据同步流程和服务调用流程。

3.3.1 服务注册流程

读取dubbo服务

使用注解@ShenyuDubboClient标记需要注册到网关的dubbo服务。

注解扫描通过ApacheDubboServiceBeanListener完成，它实现了ApplicationListener<ContextRefreshedEvent>接口，在Spring容器启动过程中，发生上下文刷新事件时，开始执行事件处理方法onApplicationEvent()。在重写的方法逻辑中，读取Dubbo服务ServiceBean，构建元数据对象和URI对象，并向shenyu-admin注册。

具体的注册逻辑由注册中心实现，请参考 [客户端接入原理](https://shenyu.apache.org/zh/docs/design/register-center-design/) 。

处理注册信息

客户端通过注册中心注册的元数据和URI数据，在shenyu-admin端进行处理，负责存储到数据库和同步给shenyu网关。Dubbo插件的客户端注册处理逻辑在ShenyuClientRegisterDubboServiceImpl中。继承关系如下：

ShenyuClientRegisterService：客户端注册服务，顶层接口；
FallbackShenyuClientRegisterService：注册失败，提供重试操作；
AbstractShenyuClientRegisterServiceImpl：抽象类，实现部分公共注册逻辑；
ShenyuClientRegisterDubboServiceImpl：实现Dubbo插件的注册；

注册信息包括选择器，规则和元数据。

整体的dubbo服务注册流程如下：

3.3.2 数据同步流程

admin更新数据

假设在在后台管理系统中，新增一条选择器数据，请求会进入SelectorController类中的createSelector()方法，它负责数据的校验，添加或更新数据，返回结果信息。

在SelectorServiceImpl类中通过createOrUpdate()方法完成数据的转换，保存到数据库，发布事件，更新upstream。

在Service类完成数据的持久化操作，即保存数据到数据库。发布变更数据通过eventPublisher.publishEvent()完成，这个eventPublisher对象是一个ApplicationEventPublisher类，这个类的全限定名是org.springframework.context.ApplicationEventPublisher，发布数据的功能正是是通过Spring相关的功能来完成的。

当事件发布完成后，会自动进入到DataChangedEventDispatcher类中的onApplicationEvent()方法，根据不同数据类型和数据同步方式进行事件处理。

网关数据同步

网关在启动时，根据指定的数据同步方式加载不同的配置类，初始化数据同步相关类。

在接收到数据后，进行反序列化操作，读取数据类型和操作类型。不同的数据类型，有不同的数据处理方式，所以有不同的实现类。但是它们之间也有相同的处理逻辑，所以可以通过模板方法设计模式来实现。相同的逻辑放在抽象类AbstractDataHandler中的handle()方法中，不同逻辑就交给各自的实现类。

新增一条选择器数据，是新增操作，会进入到SelectorDataHandler.doUpdate()具体的数据处理逻辑中。

在通用插件数据订阅者CommonPluginDataSubscriber，负责处理所有插件、选择器和规则信息

将数据保存到网关的内存中，BaseDataCache是最终缓存数据的类，通过单例模式实现。选择器数据就存到了SELECTOR_MAP这个Map中。在后续使用的时候，也是从这里拿数据。

上述逻辑用流程图表示如下：

3.3.3 服务调用流程

在Dubbo插件体系中，类继承关系如下：

ShenyuPlugin：顶层接口，定义接口方法；

AbstractShenyuPlugin：抽象类，实现插件共有逻辑；

AbstractDubboPlugin：dubbo插件抽象类，实现dubbo共有逻辑（ShenYu网关支持ApacheDubbo和AlibabaDubbo）；

ApacheDubboPlugin：ApacheDubbo插件。

org.apache.shenyu.web.handler.ShenyuWebHandler.DefaultShenyuPluginChain#execute()

通过ShenYu网关代理后，请求入口是ShenyuWebHandler，它实现了org.springframework.web.server.WebHandler接口，通过责任链设计模式将所有插件连接起来。

org.apache.shenyu.plugin.base.AbstractShenyuPlugin#execute()

当请求到网关时，判断某个插件是否执行，是通过指定的匹配逻辑来完成。在execute()方法中执行选择器和规则的匹配逻辑。

org.apache.shenyu.plugin.global.GlobalPlugin#execute()

最先被执行的是GlobalPlugin ，它是一个全局插件，在execute()方法中构建上下文信息。

org.apache.shenyu.plugin.base.RpcParamTransformPlugin#execute()

接着被执行的是RpcParamTransformPlugin ，它负责从http请求中读取参数，保存到exchange中，传递给rpc服务。在execute()方法中，执行该插件的核心逻辑：从exchange中获取请求信息，根据请求传入的内容形式处理参数。

org.apache.shenyu.plugin.dubbo.common.AbstractDubboPlugin

然后被执行的是DubboPlugin 。在doExecute()方法中，主要是检查元数据和参数。在doDubboInvoker()方法中设置特殊的上下文信息，然后开始dubbo的泛化调用。

在genericInvoker()方法中：

获取ReferenceConfig对象；
获取泛化服务GenericService对象；
构造请求参数pair对象；
发起异步的泛化调用。

通过泛化调用就可以实现在网关调用dubbo服务了。

ReferenceConfig对象是支持泛化调用的关键对象，它的初始化操作是在数据同步的时候完成的。

org.apache.shenyu.plugin.response.ResponsePlugin#execute()

最后被执行的是ResponsePlugin ，它统一处理网关的响应结果信息。处理类型由MessageWriter决定，类继承关系如下：

MessageWriter：接口，定义消息处理方法；

NettyClientMessageWriter：处理Netty调用结果；

RPCMessageWriter：处理RPC调用结果；

WebClientMessageWriter：处理WebClient调用结果；

Dubbo服务调用，处理结果是RPCMessageWriter。

org.apache.shenyu.plugin.response.strategy.RPCMessageWriter#writeWith()

在writeWith()方法中处理响应结果，获取结果或处理异常。

分析至此，关于Dubbo插件的源码分析就完成了，分析流程图如下：

4. 小结

本文从实际案例出发，由浅入深分析了ShenYu网关对Dubbo服务的代理过程。涉及到的主要知识点如下：

通过责任链设计模式执行插件；
使用模板方法设计模式实现AbstractShenyuPlugin，处理通用的操作类型；
使用单例设计模式实现缓存数据类BaseDataCache；
通过springboot starter即可引入不同的注册中心和数同步方式，扩展性很好；
通过admin支持规则热更新，方便流量管控；
Disruptor队列是为了数据与操作解耦，以及数据缓冲。

Blog: 从原理到操作，让你在 Apache APISIX 中代理 Dubbo 服务更便捷

Tue, 18 Jan 2022 00:00:00 +0000

背景

Apache Dubbo 是由阿里巴巴开源并捐赠给 Apache 的微服务开发框架，它提供了 RPC 通信与微服务治理两大关键能力。不仅经过了阿里电商场景中海量流量的验证，也在国内的技术公司中被广泛落地。

在实际应用场景中，Apache Dubbo 一般会作为后端系统间 RPC 调用的实现框架，当需要提供 HTTP 接口给到前端时，会通过一个「胶水层」将 Dubbo Service 包装成 HTTP 接口，再交付到前端系统。

Apache APISIX 是 Apache 软件基金会的顶级开源项目，也是当前最活跃的开源网关项目。作为一个动态、实时、高性能的开源 API 网关，Apache APISIX 提供了负载均衡、动态上游、灰度发布、服务熔断、身份认证、可观测性等丰富的流量管理功能。

得益于 Apache Dubbo 的应用场景优势，Apache APISIX 基于开源项目 tengine/mod_dubbo 模块为 Apache Dubbo 服务配备了HTTP 网关能力。通过 dubbo-proxy 插件，可以轻松地将 Dubbo Service 发布为 HTTP 服务。

如何使用

入门篇：安装使用

这里我们建议使用 Apache APISIX 2.11 版本镜像进行安装。该版本的 APISIX-Base 中已默认编译了 Dubbo 模块，可直接使用 dubbo-proxy 插件。

在接下来的操作中，我们将使用 dubbo-samples 项目进行部分展示。该项目是一些使用 Apache Dubbo 实现的 Demo 应用，本文中我们采用其中的一个子模块作为 Dubbo Provider。

在进入正式操作前，我们先简单看下 Dubbo 接口的定义、配置以及相关实现。

接口实现一览

public interface DemoService {

 /**
 * standard samples dubbo infterace demo
 * @param context pass http infos
 * @return Map<String, Object></> pass to response http
 **/
 Map<String, Object> apisixDubbo(Map<String, Object> httpRequestContext);
}

如上所示，Dubbo 接口的定义是固定的。即方法参数中 Map 表示 APISIX 传递给 Dubbo Provider 关于 HTTP request 的一些信息（如：header、body…)。而方法返回值的 Map 表示 Dubbo Provider 传递给 APISIX 要如何返回 HTTP response 的一些信息。

接口信息配置好之后可通过 XML 配置方式发布 DemoService。

<!-- service implementation, as same as regular local bean -->
<bean id="demoService" class="org.apache.dubbo.samples.provider.DemoServiceImpl"/>

<!-- declare the service interface to be exported -->
<dubbo:service interface="org.apache.dubbo.samples.apisix.DemoService" ref="demoService"/>

通过上述配置后，Consumer 可通过 org.apache.dubbo.samples.apisix.DemoService 访问其中的apisixDubbo 方法。具体接口实现如下：

public class DemoServiceImpl implements DemoService {
 @Override
 public Map<String, Object> apisixDubbo(Map<String, Object> httpRequestContext) {
 for (Map.Entry<String, Object> entry : httpRequestContext.entrySet()) {
 System.out.println("Key = " + entry.getKey() + ", Value = " + entry.getValue());
 }

 Map<String, Object> ret = new HashMap<String, Object>();
 ret.put("body", "dubbo success\n"); // http response body
 ret.put("status", "200"); // http response status
 ret.put("test", "123"); // http response header

 return ret;
 }
}

上述代码中，DemoServiceImpl 会打印接收到的 httpRequestContext，并通过返回包含有指定 Key 的 Map 对象去描述该 Dubbo 请求的 HTTP 响应。

操作步骤

启动 dubbo-samples。
在 config.yaml 文件中进行 dubbo-proxy 插件启用。

# Add this in config.yaml
plugins:
 - ... # plugin you need
 - dubbo-proxy

创建指向 Dubbo Provider 的 Upstream。

curl http://127.0.0.1:9180/apisix/admin/upstreams/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
 "nodes": {
 "127.0.0.1:20880": 1
 },
 "type": "roundrobin"
}'

为 DemoService 暴露一个 HTTP 路由。

curl http://127.0.0.1:9180/apisix/admin/routes/1 -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
 "host": "example.org"
 "uris": [
 "/demo"
 ],
 "plugins": {
 "dubbo-proxy": {
 "service_name": "org.apache.dubbo.samples.apisix.DemoService",
 "service_version": "0.0.0",
 "method": "apisixDubbo"
 }
 },
 "upstream_id": 1
}'

使用 curl 命令请求 Apache APISIX，并查看返回结果。

curl http://127.0.0.1:9080/demo -H "Host: example.org" -X POST --data '{"name": "hello"}'

< HTTP/1.1 200 OK
< Date: Sun, 26 Dec 2021 11:33:27 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 14
< Connection: keep-alive
< test: 123
< Server: APISIX/2.11.0
<
dubbo success

:::note 说明上述代码返回中包含了 test: 123 Header，以及 dubbo success 字符串作为 Body 体。这与我们在 DemoServiceImpl 编码的预期效果一致。 :::

查看 Dubbo Provider 的日志。

Key = content-length, Value = 17
Key = host, Value = example.org
Key = content-type, Value = application/x-www-form-urlencoded
Key = body, Value = [B@70754265
Key = accept, Value = */*
Key = user-agent, Value = curl/7.80.0

:::note 说明通过 httpRequestContext 可以拿到 HTTP 请求的 Header 和 Body。其中 Header 会作为 Map 元素，而 Body 中 Key 值是固定的字符串"body"，Value 则代表 Byte 数组。 :::

进阶篇：复杂场景示例

在上述的简单用例中可以看出，我们确实通过 Apache APISIX 将 Dubbo Service 发布为一个 HTTP 服务，但是在使用过程中的限制也非常明显。比如：接口的参数和返回值都必须要是 Map<String, Object>。

那么，如果项目中出现已经定义好、但又不符合上述限制的接口，该如何通过 Apache APISIX 来暴露 HTTP 服务呢？

操作步骤

针对上述场景，我们可以通过 HTTP Request Body 描述要调用的 Service 和 Method 以及对应参数，再利用 Java 的反射机制实现目标方法的调用。最后将返回值序列化为 JSON，并写入到 HTTP Response Body 中。

这样就可以将 Apache APISIX 的「HTTP to Dubbo」能力进一步加强，并应用到所有已存在的 Dubbo Service 中。具体操作可参考下方：

为已有项目增加一个 Dubbo Service 用来统一处理 HTTP to Dubbo 的转化。

public class DubboInvocationParameter {
 private String type;
 private String value;
}

public class DubboInvocation {
 private String service;
 private String method;
 private DubboInvocationParameter[] parameters;
}

public interface HTTP2DubboService {
 Map<String, Object> invoke(Map<String, Object> context) throws Exception;
}


@Component
public class HTTP2DubboServiceImpl implements HTTP2DubboService {

 @Autowired
 private ApplicationContext appContext;

 @Override
 public Map<String, Object> invoke(Map<String, Object> context) throws Exception {
 DubboInvocation invocation = JSONObject.parseObject((byte[]) context.get("body"), DubboInvocation.class);
 Object[] args = new Object[invocation.getParameters().size()];
 for (int i = 0; i < args.length; i++) {
 DubboInvocationParameter parameter = invocation.getParameters().get(i);
 args[i] = JSONObject.parseObject(parameter.getValue(), Class.forName(parameter.getType()));
 }

 Object svc = appContext.getBean(Class.forName(invocation.getService()));
 Object result = svc.getClass().getMethod(invocation.getMethod()).invoke(args);
 Map<String, Object> httpResponse = new HashMap<>();
 httpResponse.put("status", 200);
 httpResponse.put("body", JSONObject.toJSONString(result));
 return httpResponse;
 }

}

通过如下命令请求来发起相关调用。

curl http://127.0.0.1:9080/demo -H "Host: example.org" -X POST --data '
{
 "service": "org.apache.dubbo.samples.apisix.DemoService",
 "method": "createUser",
 "parameters": [
 {
 "type": "org.apache.dubbo.samples.apisix.User",
 "value": "{'name': 'hello'}"
 }
 ]
}'

总结

本文为大家介绍了如何借助 Apache APISIX 实现 Dubbo Service 的代理，通过引入 dubbo-proxy 插件便可为 Dubbo 框架的后端系统构建更简单更高效的流量链路。

希望通过上述操作步骤和用例场景分享，能为大家在相关场景的使用提供借鉴思路。更多关于 dubbo-proxy 插件的介绍与使用可参考官方文档。

Blog: 使用 GraalVM 构建 Native Image

Thu, 14 Jan 2021 00:00:00 +0000

dubbo项目支持native-image

概述

本文档将介绍将dubbo项目接入GraalVM，进行native-image编译为二进制的方式，以及我们为了达到这个目的做了哪些工作。

GraalVM的核心就是Graal编译器，一款优秀的JIT编译器。它即可以当作JIT编译器使用，也可以用作提前编译的静态编译器。它将完成编译的主要工作。

关于GraalVm的更多信息可以阅读 https://www.graalvm.org/docs/getting-started/container-images/ 此文档。

准备工作

在编译我们的dubbo项目之前，需要确保我们正基于graalVm的环境。

安装GraalVM的工作这里不做介绍，可以进入https://www.graalvm.org/ 官网选取最新版本安装，安装完成后查看本地jdk可以看到如下：

这里我们使用的基于jdk1.8版本的GraalVM。

快速上手

为了便于用户快速上手，我们在 Dubbo 仓库中，提供了如下demo。

模块名dubbo-demo-native，该模块中提供了简易版本的dubbo的provider以及consumer:

我们在其中使用了native-image的maven插件，并定制了一些native-image的启动参数，用户只需要对应在provider以及consumer模块下执行maven的编译打包命令：

mvn -U clean package -P native -Dmaven.test.skip=true

编译成功可以看到如下输出：

在target目录中可以看到已经生成的二进制文件：

查看该二进制文件大小大约在40M左右：

MacdeMacBook-pro-3:target mac$ du -m demo-native-provider
40 demo-native-provider

(注：本例子基于zookeeper进行的服务注册和发现，所以用户需要在本地先启动一个zk，再执行二进制启动。)

直接运行启动该二进制：

MacdeMacBook-pro-3:target mac$ ./demo-native-provider
......
INFO: [DUBBO] DubboBootstrap is ready., dubbo version: 2.7.12-SNAPSHOT, current host: 10.220.186.228
Jun 15, 2021 2:29:14 PM org.apache.dubbo.common.logger.jdk.JdkLogger info
INFO: [DUBBO] DubboBootstrap has started., dubbo version: 2.7.12-SNAPSHOT, current host: 10.220.186.228
Jun 15, 2021 2:29:14 PM org.apache.dubbo.common.logger.jdk.JdkLogger info
INFO: [DUBBO] DubboBootstrap awaiting ..., dubbo version: 2.7.12-SNAPSHOT, current host: 10.220.186.228

再进入consumer的target目录，执行该二进制：

MacdeMacBook-pro-3:target mac$ ./demo-native-consumer
Hello dubbo, response from provider: 10.220.186.228:20880

以上启动以及调用均在零点几秒内完成。

我们做了哪些工作

项目中的准备

类初始化的辅助配置

由于native-image是在runtime之前构建的，它的构建依赖于对哪些代码可访问的静态分析。但是，这种分析不能总是完全预测 Java 本地接口 (JNI)、Java 反射、动态代理对象或类路径资源的所有用法。需要以native-image配置文件的形式向工具提供这些动态功能未被检测到的用法。

这里我们在jvm参数中加入：

-agentlib:native-image-agent=config-output-dir=/path/to/config-dir/

以上参数将引入agent，再将项目已常规方式运行，agent将与JVM交互，拦截所有查找类、方法、字段、资源或请求代理访问的调用。然后，agent将在指定的目录中生成文件一下文件：

jni-config.json，reflect-config.json，proxy-config.json以及resource-config.json……

将以上文件拷入项目的 resource/META-INF/native-image文件夹下，native-image编译时对于jni、反射、动态代理以及资源相关的操作将从这些json文件中找到类的信息进行加载。

（注:实际上由于该agent是在运行时检测以上几类操作，而运行时势必无法走遍所有逻辑分支，所以会有些类的json信息无法生成。然而native-image编译时会对所有类进行编译，所以会导致一些预料不到的错误发生，目前只能是在发生错误时进行判断确实的类信息，手动补充到json文件中。）

native-image插件引入

<plugin>
 <groupId>org.graalvm.nativeimage</groupId>
 <artifactId>native-image-maven-plugin</artifactId>
 <version>21.0.0.2</version>
 <executions>
 <execution>
 <goals>
 <goal>native-image</goal>
 </goals>
 <phase>package</phase>
 </execution>
 </executions>
 <configuration>
 <skip>false</skip>
 <imageName>demo-native-provider</imageName>
 <mainClass>org.apache.dubbo.demo.graalvm.provider.Application</mainClass>
 <buildArgs>
 --no-fallback
 --initialize-at-build-time=org.slf4j.MDC
 --initialize-at-build-time=org.slf4j.LoggerFactory
 --initialize-at-build-time=org.slf4j.impl.StaticLoggerBinder
 --initialize-at-build-time=org.apache.log4j.helpers.Loader
 --initialize-at-build-time=org.apache.log4j.Logger
 --initialize-at-build-time=org.apache.log4j.helpers.LogLog
 --initialize-at-build-time=org.apache.log4j.LogManager
 --initialize-at-build-time=org.apache.log4j.spi.LoggingEvent
 --initialize-at-build-time=org.slf4j.impl.Log4jLoggerFactory
 --initialize-at-build-time=org.slf4j.impl.Log4jLoggerAdapter
 --initialize-at-run-time=io.netty.channel.epoll.Epoll
 --initialize-at-run-time=io.netty.channel.epoll.Native
 --initialize-at-run-time=io.netty.channel.epoll.EpollEventLoop
 --initialize-at-run-time=io.netty.channel.epoll.EpollEventArray
 --initialize-at-run-time=io.netty.channel.DefaultFileRegion
 --initialize-at-run-time=io.netty.channel.kqueue.KQueueEventArray
 --initialize-at-run-time=io.netty.channel.kqueue.KQueueEventLoop
 --initialize-at-run-time=io.netty.channel.kqueue.Native
 --initialize-at-run-time=io.netty.channel.unix.Errors
 --initialize-at-run-time=io.netty.channel.unix.IovArray
 --initialize-at-run-time=io.netty.channel.unix.Limits
 --initialize-at-run-time=io.netty.util.internal.logging.Log4JLogger
 --initialize-at-run-time=io.netty.channel.unix.Socket
 --initialize-at-run-time=io.netty.channel.ChannelHandlerMask
 --report-unsupported-elements-at-runtime
 --allow-incomplete-classpath
 --enable-url-protocols=http
 -H:+ReportExceptionStackTraces
 </buildArgs>
 </configuration>
</plugin>

引入该插件后执行maven的打包等命令时就能自动执行native-image的命令。

引入生成的SPI代码依赖包

由于dubbo项目基于SPI的模式开放了极高的可扩展性，而该模式依赖了一些扩展适配的生成代码，在常规模式下运行的项目是没有问题的，但编译为二进制的映像无法支持动态生成编译代码，这里我们是这么解决的：

将生成的源码导出：

（注:这里我们一定程度上改动了dubbo-common中compiler的代码，后续会细说）

public Class<?> doCompile(String name, String source) throws Throwable {
 System.*out*.println("--->write code:" + name);
 Files.*write*(Paths.*get*("/tmp/sources/" + name), source.getBytes());
 ......
}

将导出的源码拷入dubbo-graalvm模块中：

在新项目中引入该模块：

pom依赖如下：

<dependency>
 <groupId>org.apache.dubbo</groupId>
 <artifactId>dubbo-graalvm</artifactId>
 <version>2.7.12-SNAPSHOT</version>
</dependency>

（注：基于本分支版本的dubbo可以直接依赖该包，后续其他版本若有新增SPI的话需要再导出一遍源码进行更新）

引入该依赖后，在doCompiler的过程中我们便能够通过类名直接找到该class，无需再动态生成：

@Override
public Class<?> doCompile(String name, String sourceCode) throws Throwable {
 try {
 Class<?> res = Class.*forName*(name);
 return res;
 } catch (Throwable ex) {
 //ignore
 }
 //......
}

到这里项目关于native-image编译所需的依赖就配置完成了，直接打包即可生成二进制文件。

对dubbo源码的改动

本分支名为：native_dubbo_0611，基于tag dubbo-2.7.12版本进行修改。这里对我们进行的主要的改动做一些说明。

规避动态生成代码

//dubbo-common/src/main/java/org/apache/dubbo/common/compiler/support/JavassistCompiler.java
@Override
public Class<?> doCompile(String name, String source) throws Throwable {
 try {
 Class<?> res = Class.*forName*(name);
 return res;
 } catch (Throwable ex) {
 //ignore
 }
 CtClassBuilder builder = new CtClassBuilder();
 builder.setClassName(name)
 //......
}
//dubbo-common/src/main/java/org/apache/dubbo/common/compiler/support/JdkCompiler.java
@Override
public Class<?> doCompile(String name, String sourceCode) throws Throwable {
 try {
 Class<?> res = Class.*forName*(name);
 return res;
 } catch (Throwable ex) {
 //ignore
 }
 int i = name.lastIndexOf('.');
 String packageName = i < 0 ? "" : name.substring(0, i);
 //......
}

这里针对dubbo中的两类代码编译方式都做了修改，需要编译源码时先根据全类名反射查找本地是否已经加载了该类，实际上也就是我们引入的dubbo-graalvm中包含的生成代码，引入该包后这里将直接返回加载好的Class，无需动态进行编译。

替换ExtensionLoader中的代码生成

//dubbo-common/src/main/java/org/apache/dubbo/common/extension/ExtensionLoader.java
private Class<?> createAdaptiveExtensionClass() {
 try {
 Class c = Class.*forName*(generatePackageInfo() + "." + type.getSimpleName() + "$Adaptive");
 return c;
 } catch (Throwable e) {
 //ignore
 }
 String code = new AdaptiveClassCodeGenerator(type,cachedDefaultName).generate();
 //......
}
private static final String *CODE_PACKAGE* = "%s";
private String generatePackageInfo() {
 return String.*format*(*CODE_PACKAGE*, type.getPackage().getName());
}

ExtensionLoader是整个扩展机制的主要逻辑类，在这个类里面实现了配置的加载、扩展类缓存、自适应对象生成等所有工作。

在getAdaptiveExtension()方法中，会为扩展点接口自动生成实现类字符串。而这里同第一个变更一样，由于我们直接引入了生成好的SPI代码包，这里边不再需要进行代码生成，直接根据类名获取本地的Class即可，这里注意生成的扩展类名都以 $Adaptive 为后缀，查找类时需要拼接。找到实现类直接返回。

Reference/ServiceConfig中替换Wrapper的用法

//dubbo-config/dubbo-config-api/src/main/java/org/apache/dubbo/config/ReferenceConfig.java
// String[] methods = Wrapper.getWrapper(interfaceClass).getMethodNames();
 String[] methods = Arrays.*stream*(interfaceClass.getMethods()).map(it->it.getName()).toArray(String[]::new);
 if (methods.length == 0) {
 l*ogger*.warn("No method found in service interface " + interfaceClass.getName());
 map.put(*METHODS_KEY*, *ANY_VALUE*);
 //......
}
//dubbo-config/dubbo-config-api/src/main/java/org/apache/dubbo/config/ServiceConfig.java
// String[] methods = Wrapper.getWrapper(interfaceClass).getMethodNames();
 String[] methods = Arrays.*stream*(interfaceClass.getMethods()).map(it->it.getName()).toArray(String[]::new);
 if (methods.length == 0) {
 l*ogger*.warn("No method found in service interface " + interfaceClass.getName());
 map.put(*METHODS_KEY*, *ANY_VALUE*);
 //......
}

这里由于Wrapper的getWrapper需要进行动态的代码生成，所以直接换成反射的getMethods。

加入dubbo-graalvm模块

该模块用处上面已经说明。
替换fastjson为gson

//dubbo-registry/dubbo-registry-api/src/main/java/org/apache/dubbo/registry/client/metadata/store/InMemoryWritableMetadataService.java
@Override
public void publishServiceDefinition(URL providerUrl) {
 try {
 if (!ProtocolUtils.*isGeneric*(providerUrl.getParameter(*GENERIC_KEY*))) {
 String interfaceName = providerUrl.getParameter(*INTERFACE_KEY*);
 if (StringUtils.*isNotEmpty*(interfaceName)) {
 Class interfaceClass = Class.*forName*(interfaceName);
 ServiceDefinition serviceDefinition = ServiceDefinitionBuilder.*build*(interfaceClass);
 String data = new Gson().toJson(serviceDefinition);
 serviceDefinitions.put(providerUrl.getServiceKey(), data);
 return;
 }
 //......
}

由于fastjson中使用要了cglib进行动态代理，而native-image编译目前还不支持cglib，所以这里换成gson。

多接口proxy调用替换set为list

//dubbo-rpc/dubbo-rpc-api/src/main/java/org/apache/dubbo/rpc/proxy/AbstractProxyFactory.java
@Override
public <T> T getProxy(Invoker<T> invoker, boolean generic) throws RpcException {
 List<Class<?>> interfaces = new ArrayList<>();
 String config = invoker.getUrl().getParameter(*INTERFACES*);
 if (config != null && config.length() > 0) {
 String[] types = *COMMA_SPLIT_PATTERN*.split(config);
 for (String type : types) {
 // *TODO can we load successfully for a different classloader?.*
 interfaces.add(ReflectUtils.*forName*(type));
 }
 }
 //......
}

这里由于该service拥有多个接口获取proxy时需要是有序的，原先使用的set不满足需求，这里用ArrayList替代。

以上就是为了支持graalvm对dubbo源码的主要改动点。

Blog: 使用Apache Skywalking (Incubator) 做分布式跟踪

Sun, 11 Aug 2019 00:00:00 +0000

Apache Skywalking(Incubator)简介

Apache Skywalking(Incubator) 专门为微服务架构和云原生架构系统而设计并且支持分布式链路追踪的APM系统。Apache Skywalking(Incubator)通过加载探针的方式收集应用调用链路信息，并对采集的调用链路信息进行分析，生成应用间关系和服务间关系以及服务指标。Apache Skywalking (Incubating)目前支持多种语言，其中包括Java，.Net Core，Node.js和Go语言。

目前Skywalking已经支持从6个可视化维度剖析分布式系统的运行情况。总览视图是应用和组件的全局视图，其中包括组件和应用数量，应用的告警波动，慢服务列表以及应用吞吐量；拓扑图从应用依赖关系出发，展现整个应用的拓扑关系；应用视图则是从单个应用的角度，展现应用的上下游关系，TopN的服务和服务器，JVM的相关信息以及对应的主机信息。服务视图关注单个服务入口的运行情况以及此服务的上下游依赖关系，依赖度，帮助用户针对单个服务的优化和监控；调用链展现了调用的单次请求经过的所有埋点以及每个埋点的执行时长；告警视图根据配置阈值针对应用、服务器、服务进行实时告警。

Dubbo与Apache Skywalking(Incubator)

编写Dubbo示例程序

Dubbo实例程序已上传到Github仓库中。方便大家下载使用。

API工程

服务接口：

package org.apache.skywalking.demo.interfaces;

public interface HelloService {
 String sayHello(String name);
}

Dubbo服务提供工程

package org.apache.skywalking.demo.provider;

@Service(version = "${demo.service.version}",
 application = "${dubbo.application.id}",
 protocol = "${dubbo.protocol.id}",
 registry = "${dubbo.registry.id}", timeout = 60000)
public class HelloServiceImpl implements HelloService {

 public String sayHello(String name) {
 LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(1));
 return "Hello, " + name;
 }

}

Consumer工程

package org.apache.skywalking.demo.consumer;

@RestController
public class ConsumerController {

 private static int COUNT = 0;

 @Reference(version = "${demo.service.version}",
 application = "${dubbo.application.id}",
 url = "dubbo://localhost:20880", timeout = 60000)
 private HelloService helloService;

 @GetMapping("/sayHello/{name}")
 public String sayHello(@PathVariable(name = "name") String name) {
 if ((COUNT++) % 3 == 0){
 throw new RuntimeException();
 }
 LockSupport.parkNanos(TimeUnit.SECONDS.toNanos(2));
 return helloService.sayHello(name);
 }
}

部署Apache Skywalking(Incubator)

Apache Skywalking(Incubator）共提供两种部署模式：单节点模式和集群模式，以下为单节点模式部署步骤，集群模式部署详情参考文档。

依赖第三方组件

JDK8+
Elasticsearch 5.x

部署步骤

下载 Apache Skywalking Collector
部署ElasticSearch
- 修改elasticsearch.yml文件，并设置cluster.name设置成CollectorDBCluster。此名称需要和collector配置文件一致。
- 修改ES配置network.host值，将network.host的值修改成0.0.0.0。
- 启动Elasticsearch
解压并启动Skywalking Collector。运行bin/startup.sh命令即可启动Skywalking Collector

启动示例程序

在启动示例程序之前，执行编译打包的命令:

./mvnw clean package

启动服务提供端

java -jar -javaagent:$AGENT_PATH/skywalking-agent.jar -Dskywalking.agent.application_code=dubbo-provider -Dskywalking.collector.servers=localhost:10800 dubbo-provider/target/dubbo-provider.jar

启动服务消费端

java -jar -javaagent:$AGENT_PATH/skywalking-agent.jar -Dskywalking.agent.application_code=dubbo-consumer -Dskywalking.collector.servers=localhost:10800 dubbo-consumer/target/dubbo-consumer.jar

访问消费端提供的服务

curl http://localhost:8080/sayHello/test

Skywalking监控截图：

首页

拓扑图

应用视图

JVM信息

服务视图

服务消费端：

服务提供端：

Trace视图

Span信息：

告警视图

Blog: 当Dubbo遇上Arthas：排查问题的实践

Sat, 02 Feb 2019 00:00:00 +0000

Apache Dubbo是Alibaba开源的高性能RPC框架，在国内有非常多的用户。

Github: https://github.com/apache/dubbo
文档：http://dubbo.apache.org/zh-cn/

Arthas是Alibaba开源的应用诊断利器，9月份开源以来，Github Star数三个月超过6000。

Github: https://github.com/alibaba/arthas
文档：https://arthas.aliyun.com/doc/
Arthas开源交流QQ群: 916328269
Arthas开源交流钉钉群: 21965291

当Dubbo遇上Arthas，会碰撞出什么样的火花呢？下面来分享Arthas排查Dubbo问题的一些经验。

dubbo-arthas-demo

下面的排查分享基于这个dubbo-arthas-demo，非常简单的一个应用，浏览器请求从Spring MVC到Dubbo Client，再发送到Dubbo Server。

Demo里有两个spring boot应用，可以先启动server-demo，再启动client-demo。

https://github.com/hengyunabc/dubbo-arthas-demo

 /user/{id} -> UserService -> UserServiceImpl
 Browser Dubbo Client Dubbo Server

Client端：

@RestController
public class UserController {

 @Reference(version = "1.0.0")
 private UserService userService;

 @GetMapping("/user/{id}")
 public User findUserById(@PathVariable Integer id) {
 return userService.findUser(id);
 }

Server端：

@Service(version = "1.0.0")
public class UserServiceImpl implements UserService {
 @Override
 public User findUser(int id) {
 if (id < 1) {
 throw new IllegalArgumentException("user id < 1, id: " + id);
 }
 for (User user : users) {
 if (user.getId() == id) {
 return user;
 }
 }
 throw new RuntimeException("Can not find user, id: " + id);
 }

Arthas快速开始

https://arthas.aliyun.com/doc/install-detail.html

$ wget https://arthas.aliyun.com/arthas-boot.jar
$ java -jar arthas-boot.jar

启动后，会列出所有的java进程，选择1，然后回车，就会连接上ServerDemoApplication

$ java -jar arthas-boot.jar
* [1]: 43523 ServerDemoApplication
 [2]: 22342
 [3]: 44108 ClientDemoApplication
1
[INFO] arthas home: /Users/hengyunabc/.arthas/lib/3.0.5/arthas
[INFO] Try to attach process 43523
[INFO] Attach process 43523 success.
[INFO] arthas-client connect 127.0.0.1 3658
 ,---. ,------. ,--------.,--. ,--. ,---. ,---.
 / O \ | .--. ''--. .--'| '--' | / O \ ' .-'
| .-. || '--'.' | | | .--. || .-. |`. `-.
| | | || |\  \  | | | | | || | | |.-' |
`--' `--'`--' '--' `--' `--' `--'`--' `--'`-----'

wiki: https://arthas.aliyun.com/doc
version: 3.0.5
pid: 43523
time: 2018-12-05 16:23:52

$

Dubbo线上服务抛出异常，怎么获取调用参数？

https://arthas.aliyun.com/doc/watch.html

当线上服务抛出异常时，最着急的是什么参数导致了抛异常？

在demo里，访问 http://localhost:8080/user/0 ，UserServiceImpl就会抛出一个异常，因为user id不合法。

在Arthas里执行 watch com.example.UserService * -e -x 2 '{params,throwExp}' ，然后再次访问，就可以看到watch命令把参数和异常都打印出来了。

$ watch com.example.UserService * -e -x 2 '{params,throwExp}'
Press Ctrl+C to abort.
Affect(class-cnt:1 , method-cnt:4) cost in 230 ms.
ts=2018-12-05 16:26:44; [cost=3.905523ms] result=@ArrayList[
 @Object[][
 @Integer[0],
 ],
 java.lang.IllegalArgumentException: user id < 1, id: 0
 at com.example.UserServiceImpl.findUser(UserServiceImpl.java:24)
 at com.alibaba.dubbo.common.bytecode.Wrapper1.invokeMethod(Wrapper1.java)
 at com.alibaba.dubbo.rpc.proxy.javassist.JavassistProxyFactory$1.doInvoke(JavassistProxyFactory.java:45)
 at com.alibaba.dubbo.rpc.proxy.AbstractProxyInvoker.invoke(AbstractProxyInvoker.java:71)
 at com.alibaba.dubbo.config.invoker.DelegateProviderMetaDataInvoker.invoke(DelegateProviderMetaDataInvoker.java:48)
 at com.alibaba.dubbo.rpc.protocol.InvokerWrapper.invoke(InvokerWrapper.java:52)
 at com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:61)

怎样线上调试Dubbo服务代码?

https://arthas.aliyun.com/doc/redefine.html

在本地开发时，可能会用到热部署工具，直接改代码，不需要重启应用。但是在线上环境，有没有办法直接动态调试代码？比如增加日志。

在Arthas里，可以通过redefine命令来达到线上不重启，动态更新代码的效果。

比如我们修改下UserServiceImpl，用System.out打印出具体的User对象来：

 public User findUser(int id) {
 if (id < 1) {
 throw new IllegalArgumentException("user id < 1, id: " + id);
 }
 for (User user : users) {
 if (user.getId() == id) {
 System.out.println(user);
 return user;
 }
 }
 throw new RuntimeException("Can not find user, id: " + id);
 }

本地编绎后，把server-demo/target/classes/com/example/UserServiceImpl.class传到线上服务器，然后用redefine命令来更新代码：

$ redefine -p /tmp/UserServiceImpl.class
redefine success, size: 1

这样子更新成功之后，访问 http://localhost:8080/user/1 ，在ServerDemoApplication的控制台里就可以看到打印出了user信息。

怎样动态修改Dubbo的logger级别?

在排查问题时，需要查看到更多的信息，如果可以把logger级别修改为DEBUG，就非常有帮助。

ognl是apache开源的一个轻量级表达式引擎。下面通过Arthas里的ognl命令来动态修改logger级别。

首先获取Dubbo里TraceFilter的一个logger对象，看下它的实现类，可以发现是log4j。

$ ognl '@com.alibaba.dubbo.rpc.protocol.dubbo.filter.TraceFilter@logger.logger'
@Log4jLogger[
 FQCN=@String[com.alibaba.dubbo.common.logger.support.FailsafeLogger],
 logger=@Logger[org.apache.log4j.Logger@2f19bdcf],
]

再用sc命令来查看具体从哪个jar包里加载的：

$ sc -d org.apache.log4j.Logger
 class-info org.apache.log4j.Logger
 code-source /Users/hengyunabc/.m2/repository/org/slf4j/log4j-over-slf4j/1.7.25/log4j-over-slf4j-1.7.25.jar
 name org.apache.log4j.Logger
 isInterface false
 isAnnotation false
 isEnum false
 isAnonymousClass false
 isArray false
 isLocalClass false
 isMemberClass false
 isPrimitive false
 isSynthetic false
 simple-name Logger
 modifier public
 annotation
 interfaces
 super-class +-org.apache.log4j.Category
 +-java.lang.Object
 class-loader +-sun.misc.Launcher$AppClassLoader@5c647e05
 +-sun.misc.Launcher$ExtClassLoader@59878d35
 classLoaderHash 5c647e05

Affect(row-cnt:1) cost in 126 ms.

可以看到log4j是通过slf4j代理的。

那么通过org.slf4j.LoggerFactory获取root logger，再修改它的level：

$ ognl '@org.slf4j.LoggerFactory@getLogger("root").setLevel(@ch.qos.logback.classic.Level@DEBUG)'
null
$ ognl '@org.slf4j.LoggerFactory@getLogger("root").getLevel().toString()'
@String[DEBUG]

可以看到修改之后，root logger的level变为DEBUG。

怎样减少测试小姐姐重复发请求的麻烦?

https://arthas.aliyun.com/doc/tt.html

在平时开发时，可能需要测试小姐姐发请求过来联调，但是我们在debug时，可能不小心直接跳过去了。这样子就尴尬了，需要测试小姐姐再发请求过来。

Arthas里提供了tt命令，可以减少这种麻烦，可以直接重放请求。

$ tt -t com.example.UserServiceImpl findUser
Press Ctrl+C to abort.
Affect(class-cnt:1 , method-cnt:1) cost in 145 ms.
 INDEX TIMESTAMP COST(ms) IS-RET IS-EXP OBJECT CLASS METHOD
----------------------------------------------------------------------------------------------------------------
 1000 2018-12-05 17:47:52 1.56523 true false 0x3233483 UserServiceImpl findUser
 1001 2018-12-05 17:48:03 0.286176 false true 0x3233483 UserServiceImpl findUser
 1002 2018-12-05 17:48:11 90.324335 true false 0x3233483 UserServiceImpl findUser

上面的tt -t命令捕获到了3个请求。然后通过tt --play可以重放请求：

$ tt --play -i 1000
 RE-INDEX 1000
 GMT-REPLAY 2018-12-05 17:55:50
 OBJECT 0x3233483
 CLASS com.example.UserServiceImpl
 METHOD findUser
 PARAMETERS[0] @Integer[1]
 IS-RETURN true
 IS-EXCEPTION false
 RETURN-OBJ @User[
 id=@Integer[1],
 name=@String[Deanna Borer],
 ]
Time fragment[1000] successfully replayed.
Affect(row-cnt:1) cost in 4 ms.

Dubbo运行时有哪些Filter? 耗时是多少?

https://arthas.aliyun.com/doc/trace.html

Dubbo运行时会加载很多的Filter，那么一个请求会经过哪些Filter处理，Filter里的耗时又是多少呢？

通过Arthas的trace命令，可以很方便地知道Filter的信息，可以看到详细的调用栈和耗时。

$ trace com.alibaba.dubbo.rpc.Filter *
Press Ctrl+C to abort.
Affect(class-cnt:19 , method-cnt:59) cost in 1441 ms.
`---ts=2018-12-05 19:07:26;thread_name=DubboServerHandler-30.5.125.152:20880-thread-10;id=3e;is_daemon=true;priority=5;TCCL=sun.misc.Launcher$AppClassLoader@5c647e05
 `---[8.435844ms] com.alibaba.dubbo.rpc.filter.EchoFilter:invoke()
 +---[0.124572ms] com.alibaba.dubbo.rpc.Invocation:getMethodName()
 +---[0.065123ms] java.lang.String:equals()
 `---[7.762928ms] com.alibaba.dubbo.rpc.Invoker:invoke()
 `---[7.494124ms] com.alibaba.dubbo.rpc.filter.ClassLoaderFilter:invoke()
 +---[min=0.00355ms,max=0.049922ms,total=0.057637ms,count=3] java.lang.Thread:currentThread()
 +---[0.0126ms] java.lang.Thread:getContextClassLoader()
 +---[0.02188ms] com.alibaba.dubbo.rpc.Invoker:getInterface()
 +---[0.004115ms] java.lang.Class:getClassLoader()
 +---[min=0.003906ms,max=0.014058ms,total=0.017964ms,count=2] java.lang.Thread:setContextClassLoader()
 `---[7.033486ms] com.alibaba.dubbo.rpc.Invoker:invoke()
 `---[6.869488ms] com.alibaba.dubbo.rpc.filter.GenericFilter:invoke()
 +---[0.01481ms] com.alibaba.dubbo.rpc.Invocation:getMethodName()

Dubbo动态代理是怎样实现的?

https://arthas.aliyun.com/doc/jad.html
com.alibaba.dubbo.common.bytecode.Wrapper

通过Arthas的jad命令，可以看到Dubbo通过javaassist动态生成的Wrappr类的代码：

$ jad com.alibaba.dubbo.common.bytecode.Wrapper1

ClassLoader:
+-sun.misc.Launcher$AppClassLoader@5c647e05
 +-sun.misc.Launcher$ExtClassLoader@59878d35

Location:
/Users/hengyunabc/.m2/repository/com/alibaba/dubbo/2.5.10/dubbo-2.5.10.jar

package com.alibaba.dubbo.common.bytecode;

public class Wrapper1
extends Wrapper
implements ClassGenerator.DC {

 public Object invokeMethod(Object object, String string, Class[] arrclass, Object[] arrobject) throws InvocationTargetException {
 UserServiceImpl userServiceImpl;
 try {
 userServiceImpl = (UserServiceImpl)object;
 }
 catch (Throwable throwable) {
 throw new IllegalArgumentException(throwable);
 }
 try {
 if ("findUser".equals(string) && arrclass.length == 1) {
 return userServiceImpl.findUser(((Number)arrobject[0]).intValue());
 }
 if ("listUsers".equals(string) && arrclass.length == 0) {
 return userServiceImpl.listUsers();
 }
 if ("findUserByName".equals(string) && arrclass.length == 1) {
 return userServiceImpl.findUserByName((String)arrobject[0]);
 }
 }

获取Spring context

除了上面介绍的一些排查技巧，下面分享一个获取Spring Context，然后“为所欲为”的例子。

在Dubbo里有一个扩展com.alibaba.dubbo.config.spring.extension.SpringExtensionFactory，把Spring Context保存到了里面。因此，我们可以通过ognl命令获取到。

$ ognl '#context=@com.alibaba.dubbo.config.spring.extension.SpringExtensionFactory@contexts.iterator.next, #context.getBean("userServiceImpl").findUser(1)'
@User[
 id=@Integer[1],
 name=@String[Deanna Borer],
]

SpringExtensionFactory@contexts.iterator.next 获取到SpringExtensionFactory里保存的spring context对象
#context.getBean("userServiceImpl").findUser(1) 获取到userServiceImpl再执行一次调用

只要充分发挥想像力，组合Arthas里的各种命令，可以发挥出神奇的效果。

总结

本篇文章来自杭州Dubbo Meetup的分享《当DUBBO遇上Arthas - 排查问题的实践》，希望对大家线上排查Dubbo问题有帮助。

分享的PDF可以在 https://github.com/alibaba/arthas/issues/327 里下载。

Blog: 如何使用Seata保证Dubbo微服务间的一致性

Thu, 17 Jan 2019 00:00:00 +0000

案例

用户采购商品业务，整个业务包含3个微服务:

库存服务: 扣减给定商品的库存数量。
订单服务: 根据采购请求生成订单。
账户服务: 用户账户金额扣减。

业务结构图

StorageService

public interface StorageService {

 /**
 * 扣除存储数量
 */
 void deduct(String commodityCode, int count);
}

OrderService

public interface OrderService {

 /**
 * 创建订单
 */
 Order create(String userId, String commodityCode, int orderCount);
}

AccountService

public interface AccountService {

 /**
 * 从用户账户中借出
 */
 void debit(String userId, int money);
}

主要的业务逻辑：

public class BusinessServiceImpl implements BusinessService {

 private StorageService storageService;

 private OrderService orderService;

 /**
 * 采购
 */
 public void purchase(String userId, String commodityCode, int orderCount) {

 storageService.deduct(commodityCode, orderCount);

 orderService.create(userId, commodityCode, orderCount);
 }
}

public class StorageServiceImpl implements StorageService {

 private StorageDAO storageDAO;

 @Override
 public void deduct(String commodityCode, int count) {
 Storage storage = new Storage();
 storage.setCount(count);
 storage.setCommodityCode(commodityCode);
 storageDAO.update(storage);
 }
}

public class OrderServiceImpl implements OrderService {

 private OrderDAO orderDAO;

 private AccountService accountService;

 public Order create(String userId, String commodityCode, int orderCount) {

 int orderMoney = calculate(commodityCode, orderCount);

 accountService.debit(userId, orderMoney);

 Order order = new Order();
 order.userId = userId;
 order.commodityCode = commodityCode;
 order.count = orderCount;
 order.money = orderMoney;

 return orderDAO.insert(order);
 }
}

Seata 分布式事务解决方案

此处仅仅需要一行注解 @GlobalTransactional 写在业务发起方的方法上:


 @GlobalTransactional
 public void purchase(String userId, String commodityCode, int orderCount) {
 ......
 }

Dubbo 与 Seata 结合的例子

Step 1: 安装数据库

要求: MySQL (InnoDB 存储引擎)。

提示: 事实上例子中3个微服务需要3个独立的数据库，但为了方便我们使用同一物理库并配置3个逻辑连接串。

更改以下xml文件中的数据库url、username和password

dubbo-account-service.xml dubbo-order-service.xml dubbo-storage-service.xml

 <property name="url" value="jdbc:mysql://x.x.x.x:3306/xxx" />
 <property name="username" value="xxx" />
 <property name="password" value="xxx" />

Step 2: 为 Seata 创建 undo_log 表

UNDO_LOG 此表用于 Seata 的AT模式。

-- 注意当 Seata 版本升级至 0.3.0+ 将由之前的普通索引变更为唯一索引。
CREATE TABLE `undo_log` (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `branch_id` bigint(20) NOT NULL,
 `xid` varchar(100) NOT NULL,
 `context` varchar(128) NOT NULL,
 `rollback_info` longblob NOT NULL,
 `log_status` int(11) NOT NULL,
 `log_created` datetime NOT NULL,
 `log_modified` datetime NOT NULL,
 `ext` varchar(100) DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `ux_undo_log` (`xid`,`branch_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

Step 3: 创建相关业务表


DROP TABLE IF EXISTS `storage_tbl`;
CREATE TABLE `storage_tbl` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `commodity_code` varchar(255) DEFAULT NULL,
 `count` int(11) DEFAULT 0,
 PRIMARY KEY (`id`),
 UNIQUE KEY (`commodity_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


DROP TABLE IF EXISTS `order_tbl`;
CREATE TABLE `order_tbl` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `user_id` varchar(255) DEFAULT NULL,
 `commodity_code` varchar(255) DEFAULT NULL,
 `count` int(11) DEFAULT 0,
 `money` int(11) DEFAULT 0,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;


DROP TABLE IF EXISTS `account_tbl`;
CREATE TABLE `account_tbl` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `user_id` varchar(255) DEFAULT NULL,
 `money` int(11) DEFAULT 0,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Step 4: 启动 Seata-Server 服务

下载服务器软件包，将其解压缩。

Usage: sh seata-server.sh(for linux and mac) or cmd seata-server.bat(for windows) [options]
 Options:
 --host, -h
 The host to bind.
 Default: 0.0.0.0
 --port, -p
 The port to listen.
 Default: 8091
 --storeMode, -m
 log store mode : file、db
 Default: file
 --help

e.g.

sh seata-server.sh -p 8091 -h 127.0.0.1 -m file

Step 5: 运行例子

启动账户服务 (DubboAccountServiceStarter).
启动库存服务 (DubboStorageServiceStarter).
启动订单服务 (DubboOrderServiceStarter).
运行BusinessService入口 (DubboBusinessTester).

Blog: 新版 Dubbo Admin 介绍

Mon, 07 Jan 2019 00:00:00 +0000

github: https://github.com/apache/dubbo-ops

Dubbo Admin之前的版本过于老旧，也长期疏于维护，因此在去年年中的时候，对该项目进行了一次重构，项目结构上的变化如下：

将后端框架从webx替换成spring boot
前端采用Vue和Vuetify.js作为开发框架
移除velocity模板
集成swagger，提供api管理功能

当前版本的Dubbo Admin包含了之前版本中的绝大部分功能，包括服务治理，服务查询等，同时支持了Dubbo2.7中服务治理的新特性。

配置规范

由于在Dubbo2.7中，配置中心和注册中心做了分离，并且增加了元数据中心，因此Dubbo Admin的配置方式也做了更新，application.properties中的配置如下:

admin.registry.address=zookeeper://127.0.0.1:2181
admin.config-center=zookeeper://127.0.0.1:2181
admin.metadata-report.address=zookeeper://127.0.0.1:2181

也可以和Dubbo2.7一样，在配置中心指定元数据和注册中心的地址，以zookeeper为例，配置的路径和内容如下:

# /dubbo/config/dubbo/dubbo.properties
dubbo.registry.address=zookeeper://127.0.0.1:2181
dubbo.metadata-report.address=zookeeper://127.0.0.1:2181

配置中心里的地址会覆盖掉本地application.properties的配置

功能介绍

功能上，主要延续了之前版本的功能，包括服务查询和服务治理，2.7版本在服务治理的功能上有了很大的改进，这些改进也大部分都会以Dubbo Admin作为入口来体现。

标签路由

标签路由是Dubbo2.7引入的新功能，配置以应用作为维度，给不同的服务器打上不同名字的标签，配置如下图所示：

调用的时候，客户端可以通过setAttachment的方式，来设置不同的标签名称，比如本例中，setAttachment(tag1)，客户端的选址范围就在如图所示的三台机器中，可以通过这种方式来实现流量隔离，灰度发布等功能。

应用级别的服务治理

在Dubbo2.6及更早版本中，所有的服务治理规则都只针对服务粒度，如果要把某条规则作用到应用粒度上，需要为应用下的所有服务配合相同的规则，变更，删除的时候也需要对应的操作，这样的操作很不友好，因此Dubbo2.7版本中增加了应用粒度的服务治理操作，对于条件路由(包括黑白名单)，动态配置(包括权重，负载均衡)都可以做应用级别的配置：

上图是条件路由的配置，可以按照应用名，服务名两个维度来填写，也可以按照这两个维度来查询。

条件路由，标签路由和动态配置都采用了yaml格式的文本编写，其他的规则配置还是采用了表单的形式。

关于兼容性

Dubbo2.6到Dubbo2.7，服务治理发生了比较大的变化，Dubbo Admin兼容两个版本的用法：

对于服务级别的配置，会按照Dubbo2.6(URL)和Dubbo2.7(配置文件)两种格式进行写入，保证Dubbo2.6的客户端能够正确读取，解析规则
对于应用级别的配置，包括标签路由，只会按照Dubbo2.7的格式进行写入，因为Dubbo2.6无此功能，不需要做向前兼容。
Dubbo Admin只会按照Dubbo2.7的格式进行配置读取，因此，所有在Dubbo Admin上做的配置都可以被读到，但是之前遗留的，Dubbo2.6格式的URL无法被读取。
对于同一个应用或者服务，每种规则只能够配置一条，否则新的会覆盖旧的。

配置管理

配置管理也是配合Dubbo2.7新增的功能，在Dubbo2.7中，增加了全局和应用维度的配置，

全局配置：

全局配置里可以指定注册中心，元数据中心的地址，服务端和客户端的超时时间等，这些配置在全局内生效。除了配置写入，也可以用来查看。如果使用zookeeper作为注册中心和元数据中心，还可以看到配置文件所在位置的目录结构。

应用，服务配置

应用级别的配置可以为应用或者应用内的服务指定配置，在服务维度上，需要区分提供者和消费者。dubbo.reference.{serviceName}表示作为该服务消费者的配置，dubbo.provider.{servcieName}表示作为该服务提供者的配置。优先级服务 > 应用 > 全局。其中注册中心和元数据中心的地址，只能在全局配置中指定，这也是Dubbo2.7中推荐的使用方式。

元数据和服务测试

元数据是Dubbo2.7中新引入的元素，主要的使用场景就在Dubbo Admin中，主要体现在两个地方：

服务详情展示：

跟之前版本相比，Dubbo2.7中增加了对服务方法完整签名的记录，因此服务详情中也增加了方法信息的详情，可以看到方法名，方法参数列表以及返回值信息。

服务测试：

更重要的，元数据为服务测试提供了数据基础，可以在页面上调用真实的服务提供者，方便测试，也不需要为了调用服务去搭建一套Dubbo环境以及编写消费端代码。

Blog: Dubbo 在瓜子二手车的实践

Sat, 05 Jan 2019 00:00:00 +0000

前言

随着瓜子业务的不断发展，系统规模在逐渐扩大，目前在瓜子的私有云上已经运行着数百个dubbo应用，上千个dubbo实例。瓜子各部门业务迅速发展，版本没有来得及统一，各个部门都有自己的用法。随着第二机房的建设，dubbo版本统一的需求变得越发迫切。几个月前，公司发生了一次与dubbo相关的生产事故，成为了公司dubbo版本升级的诱因。

接下来，我会从这次事故开始，讲讲我们这段时间所做的dubbo版本升级的历程以及dubbo后续多机房的方案。

一、Ephermal节点未及时删除导致provider不能恢复注册的问题修复

事故背景

在生产环境，瓜子内部各业务线共用一套zookeeper集群作为dubbo的注册中心。2019年9月份，机房的一台交换机发生故障，导致zookeeper集群出现了几分钟的网络波动。在zookeeper集群恢复后，正常情况下dubbo的provider应该会很快重新注册到zookeeper上，但有一小部分的provider很长一段时间没有重新注册到zookeeper上，直到手动重启应用后才恢复注册。

排查过程

首先，我们统计了出现这种现象的dubbo服务的版本分布情况，发现在大多数的dubbo版本中都存在这种问题，且发生问题的服务比例相对较低，在github中我们也未找到相关问题的issues。因此，推断这是一个尚未修复的且在网络波动情况的场景下偶现的问题。

接着，我们便将出现问题的应用日志、zookeeper日志与dubbo代码逻辑进行相互印证。在应用日志中，应用重连zookeeper成功后provider立刻进行了重新注册，之后便没有任何日志打印。而在zookeeper日志中，注册节点被删除后，并没有重新创建注册节点。对应到dubbo的代码中，只有在FailbackRegistry.register(url)的doRegister(url)执行成功或线程被挂起的情况下，才能与日志中的情况相吻合。

 public void register(URL url) {
 super.register(url);
 failedRegistered.remove(url);
 failedUnregistered.remove(url);
 try {
 // Sending a registration request to the server side
 doRegister(url);
 } catch (Exception e) {
 Throwable t = e;

 // If the startup detection is opened, the Exception is thrown directly.
 boolean check = getUrl().getParameter(Constants.CHECK_KEY, true)
 && url.getParameter(Constants.CHECK_KEY, true)
 && !Constants.CONSUMER_PROTOCOL.equals(url.getProtocol());
 boolean skipFailback = t instanceof SkipFailbackWrapperException;
 if (check || skipFailback) {
 if (skipFailback) {
 t = t.getCause();
 }
 throw new IllegalStateException("Failed to register " + url + " to registry " + getUrl().getAddress() + ", cause: " + t.getMessage(), t);
 } else {
 logger.error("Failed to register " + url + ", waiting for retry, cause: " + t.getMessage(), t);
 }

 // Record a failed registration request to a failed list, retry regularly
 failedRegistered.add(url);
 }
 }

在继续排查问题前，我们先普及下这些概念：dubbo默认使用curator作为zookeeper的客户端，curator与zookeeper是通过session维持连接的。当curator重连zookeeper时，若session未过期，则继续使用原session进行连接；若session已过期，则创建新session重新连接。而ephemeral节点与session是绑定的关系，在session过期后，会删除此session下的ephemeral节点。

继续对doRegister(url)的代码进行进一步排查，我们发现在CuratorZookeeperClient.createEphemeral(path)方法中有这么一段逻辑：在createEphemeral(path)捕获了NodeExistsException，创建ephemeral节点时，若此节点已存在，则认为ephemeral节点创建成功。这段逻辑初看起来并没有什么问题，且在以下两种常见的场景下表现正常：

Session未过期，创建Ephemeral节点时原节点仍存在,不需要重新创建
Session已过期，创建Ephemeral节点时原节点已被zookeeper删除，创建成功

 public void createEphemeral(String path) {
 try {
 client.create().withMode(CreateMode.EPHEMERAL).forPath(path);
 } catch (NodeExistsException e) {
 } catch (Exception e) {
 throw new IllegalStateException(e.getMessage(), e);
 }
 }

但是实际上还有一种极端场景，zookeeper的Session过期与删除Ephemeral节点不是原子性的，也就是说客户端在得到Session过期的消息时，Session对应的Ephemeral节点可能还未被zookeeper删除。此时dubbo去创建Ephemeral节点,发现原节点仍存在，故不重新创建。待Ephemeral节点被zookeeper删除后，便会出现dubbo认为重新注册成功，但实际未成功的情况，也就是我们在生产环境遇到的问题。

此时，问题的根源已被定位。定位问题之后，我们与dubbo社区交流，发现考拉的同学也遇到过同样的问题，更确定了这个原因。

问题的复现与修复

定位到问题之后，我们便开始尝试本地复现。由于zookeeper的Session过期但Ephemeral节点未被删除的场景直接模拟比较困难，我们通过修改zookeeper源码，在Session过期与删除Ephemeral节点的逻辑中增加了一段休眠时间，间接模拟出这种极端场景，并在本地复现了此问题。

在排查问题的过程中，我们发现kafka的旧版本在使用zookeeper时也遇到过类似的问题，并参考kafka关于此问题的修复方案，确定了dubbo的修复方案。在创建Ephemeral节点捕获到NodeExistsException时进行判断，若Ephemeral节点的SessionId与当前客户端的SessionId不同，则删除并重建Ephemeral节点。在内部修复并验证通过后，我们向社区提交了issues及pr。

kafka类似问题issues：https://issues.apache.org/jira/browse/KAFKA-1387

dubbo注册恢复问题issues：https://github.com/apache/dubbo/issues/5125

二、瓜子的dubbo升级历程

上文中的问题修复方案已经确定，但我们显然不可能在每一个dubbo版本上都进行修复。在咨询了社区dubbo的推荐版本后，我们决定在dubbo2.7.3版本的基础上，开发内部版本修复来这个问题。并借这个机会，开始推动公司dubbo版本的统一升级工作。

为什么要统一dubbo版本

统一dubbo版本后，我们可以在此版本上内部紧急修复一些dubbo问题（如上文的dubbo注册故障恢复失效问题）。
瓜子目前正在进行第二机房的建设，部分dubbo服务也在逐渐往第二机房迁移。统一dubbo版本，也是为dubbo的多机房做铺垫。
有利于我们后续对dubbo服务的统一管控。
dubbo社区目前的发展方向与我们公司现阶段对dubbo的一些诉求相吻合，如支持gRPC、云原生等。

为什么选择dubbo2.7.3

在我们之前，携程与dubbo社区合作进行了携程dubbo内部版本的升级，并在社区2.7.3版本上修复了很多兼容性问题。感谢携程的同学帮我们踩坑～
dubbo2.7.3版本在当时虽然是最新的版本，但已经发布了2个月的时间，从社区issues反馈来看，dubbo2.7.3相对dubbo2.7之前的几个版本，在兼容性方面要好很多。
我们也咨询了dubbo社区的同学，推荐升级版本为2.7.3。

内部版本定位

基于社区dubbo2.7.3版本开发的dubbo内部版本属于过渡性质的版本，目的是为了修复线上provider不能恢复注册的问题，以及一些社区dubbo2.7.3的兼容性问题。瓜子的dubbo最终还是要跟随社区的版本，而不是开发自已的内部功能。因此我们在dubbo内部版本中修复的所有问题均与社区保持了同步，以保证后续可以兼容升级到社区dubbo的更高版本。

兼容性验证与升级过程

我们在向dubbo社区的同学咨询了版本升级方面的相关经验后，于9月下旬开始了dubbo版本的升级工作。

初步兼容性验证 首先,我们梳理了一些需要验证的兼容性case，针对公司内部使用较多的dubbo版本，与dubbo2.7.3一一进行了兼容性验证。经验证，除dubboX外，dubbo2.7.3与其他dubbo版本均兼容。dubboX由于对dubbo协议进行了更改，与dubbo2.7.3不兼容。
生产环境兼容性验证 在初步验证兼容性通过后，我们与业务线合作，挑选了一些重要程度较低的项目，在生产环境对dubbo2.7.3与其他版本的兼容性进行了进一步验证。并在内部版本修复了一些兼容性问题。
推动公司dubbo版本升级 在10月初，完成了dubbo兼容性验证后，我们开始在各个业务线推动dubbo的升级工作。截止到12月初,已经有30%的dubbo服务的完成了版本升级。按照排期，预计于2020年3月底前完成公司dubbo版本的统一升级。

兼容性问题汇总

在推动升级dubbo2.7.3版本的过程整体上比较顺利,当然也遇到了一些兼容性问题：

创建zookeeper节点时提示没有权限 dubbo配置文件中已经配置了zookeeper的用户名密码，但在创建zookeeper节点时却抛出KeeperErrorCode = NoAuth的异常，这种情况分别对应两个兼容性问题：
- issues:https://github.com/apache/dubbo/issues/5076 dubbo在未配置配置中心时，默认使用注册中心作为配置中心。通过注册中心的配置信息初始化配置中心配置时，由于遗漏了用户名密码，导致此问题。
- issues:https://github.com/apache/dubbo/issues/4991 dubbo在建立与zookeeper的连接时会根据zookeeper的address复用之前已建立的连接。当多个注册中心使用同一个address，但权限不同时，就会出现NoAuth的问题。参考社区的pr，我们在内部版本进行了修复。
curator版本兼容性问题
- dubbo2.7.3与低版本的curator不兼容，因此我们默认将curator版本升级至4.2.0
```
<dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-framework</artifactId>
 <version>4.2.0</version>
</dependency>
<dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-recipes</artifactId>
 <version>4.2.0</version>
</dependency>
```
- 分布式调度框架elastic-job-lite强依赖低版本的curator,与dubbo2.7.3使用的curator版本不兼容,这给dubbo版本升级工作带来了一定阻塞。考虑到elastic-job-lite已经很久没有人进行维护，目前一些业务线计划将elastic-job-lite替换为其他的调度框架。
openFeign与dubbo兼容性问题 issues: https://github.com/apache/dubbo/issues/3990 dubbo的ServiceBean监听spring的ContextRefreshedEvent,进行服务暴露。openFeign提前触发了ContextRefreshedEvent，此时ServiceBean还未完成初始化，于是就导致了应用启动异常。参考社区的pr，我们在内部版本修复了此问题。
RpcException兼容性问题 dubbo低版本consumer不能识别dubbo2.7版本provider抛出的org.apache.dubbo.rpc.RpcException。因此，在consumer全部升级到2.7之前，不建议将provider的com.alibaba.dubbo.rpc.RpcException改为org.apache.dubbo.rpc.RpcException
qos端口占用 dubbo2.7.3默认开启qos功能，导致一些混部在物理机的dubbo服务升级时出现qos端口占用问题。关闭qos功能后恢复。
自定义扩展兼容性问题 业务线对于dubbo的自定义扩展比较少，因此在自定义扩展的兼容性方面暂时还没有遇到比较难处理的问题，基本上都是变更package导致的问题，由业务线自行修复。
skywalking agent兼容性问题 我们项目中一般使用skywalking进行链路追踪，由于skywalking agent6.0的plugin不支持dubbo2.7，因此统一升级skywalking agent到6.1。

三、dubbo多机房方案

瓜子目前正在进行第二机房的建设工作，dubbo多机房是第二机房建设中比较重要的一个话题。在dubbo版本统一的前提下，我们就能够更顺利的开展dubbo多机房相关的调研与开发工作。

初步方案

我们咨询了dubbo社区的建议，并结合瓜子云平台的现状，初步确定了dubbo多机房的方案。

在每个机房内，部署一套独立的zookeeper集群。集群间信息不同步。这样就没有了zookeeper集群跨机房延迟与数据不同步的问题。
dubbo服务注册时，仅注册到本机房的zookeeper集群；订阅时，同时订阅两个机房的zookeeper集群。
实现同机房优先调用的路由逻辑。以减少跨机房调用导致的不必要网络延迟。

同机房优先调用

dubbo同机房优先调用的实现比较简单，相关逻辑如下：

瓜子云平台默认将机房的标志信息注入容器的环境变量中。
provider暴露服务时，读取环境变量中的机房标志信息，追加到待暴露服务的url中。
consumer调用provider时，读取环境变量中的机房标志信息，根据路由策略优先调用具有相同标志信息的provider。

针对以上逻辑，我们简单实现了dubbo通过环境变量进行路由的功能，并向社区提交了pr。 dubbo通过环境变量路由pr: https://github.com/apache/dubbo/pull/5348

Blog: Dubbo 融合 Nacos 成为注册中心

Wed, 07 Nov 2018 00:00:00 +0000

Nacos 作为 Dubbo 生态系统中重要的注册中心实现，其中 dubbo-registry-nacos 则是 Dubbo 融合 Nacos 注册中心的实现。

预备工作

当您将 dubbo-registry-nacos 整合到您的 Dubbo 工程之前，请确保后台已经启动 Nacos 服务。如果您尚且不熟悉 Nacos 的基本使用的话，可先行参考 Nacos 快速入门：https://nacos.io/en-us/docs/quick-start.html。建议使用 Nacos 0.6.1 以上的版本。

快速上手

Dubbo 融合 Nacos 成为注册中心的操作步骤非常简单，大致步骤可分为“增加 Maven 依赖”以及“配置注册中心“。

增加 Maven 依赖

首先，您需要 dubbo-registry-nacos 的 Maven 依赖添加到您的项目中 pom.xml 文件中，并且强烈地推荐您使用 Dubbo 2.6.5：

<dependencies>

 ...

 <!-- Dubbo Nacos registry dependency -->
 <dependency>
 <groupId>com.alibaba</groupId>
 <artifactId>dubbo-registry-nacos</artifactId>
 <version>0.0.2</version>
 </dependency>

 <!-- Keep latest Nacos client version -->
 <dependency>
 <groupId>com.alibaba.nacos</groupId>
 <artifactId>nacos-client</artifactId>
 <version>[0.6.1,)</version>
 </dependency>

 <!-- Dubbo dependency -->
 <dependency>
 <groupId>com.alibaba</groupId>
 <artifactId>dubbo</artifactId>
 <version>2.6.5</version>
 </dependency>

 <!-- Alibaba Spring Context extension -->
 <dependency>
 <groupId>com.alibaba.spring</groupId>
 <artifactId>spring-context-support</artifactId>
 <version>1.0.2</version>
 </dependency>

 ...

</dependencies>

当项目中添加 dubbo-registry-nacos 后，您无需显示地编程实现服务发现和注册逻辑，实际实现由该三方包提供，接下来配置 Naocs 注册中心。

配置注册中心

假设您 Dubbo 应用使用 Spring Framework 装配，将有两种配置方法可选，分别为：Dubbo Spring 外部化配置以及 Spring XML 配置文件以及，笔者强烈推荐前者。

Dubbo Spring 外部化配置

Dubbo Spring 外部化配置是由 Dubbo 2.5.8 引入的新特性，可通过 Spring Environment 属性自动地生成并绑定 Dubbo 配置 Bean，实现配置简化，并且降低微服务开发门槛。

假设您 Dubbo 应用的使用 Zookeeper 作为注册中心，并且其服务器 IP 地址为：10.20.153.10，同时，该注册地址作为 Dubbo 外部化配置属性存储在 dubbo-config.properties 文件，如下所示：

## application
dubbo.application.name = your-dubbo-application

## Zookeeper registry address
dubbo.registry.address = zookeeper://10.20.153.10:2181
...

假设您的 Nacos Server 同样运行在服务器 10.20.153.10 上，并使用默认 Nacos 服务端口 8848，您只需将 dubbo.registry.address 属性调整如下：

## 其他属性保持不变

## Nacos registry address
dubbo.registry.address = nacos://10.20.153.10:8848
...

随后，重启您的 Dubbo 应用，Dubbo 的服务提供和消费信息在 Nacos 控制台中可以显示：

如图所示，服务名前缀为 providers: 的信息为服务提供者的元信息，consumers: 则代表服务消费者的元信息。点击“详情”可查看服务状态详情：

如果您正在使用 Spring XML 配置文件装配 Dubbo 注册中心的话，请参考下一节。

Spring XML 配置文件

同样，假设您 Dubbo 应用的使用 Zookeeper 作为注册中心，并且其服务器 IP 地址为：10.20.153.10，并且装配 Spring Bean 在 XML 文件中，如下所示：

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

 <!-- 提供方应用信息，用于计算依赖关系 -->
 <dubbo:application name="dubbo-provider-xml-demo" />

 <!-- 使用 Zookeeper 注册中心 -->
 <dubbo:registry address="zookeeper://10.20.153.10:2181" />
 ...
</beans>

与 Dubbo Spring 外部化配置配置类似，只需要调整 address 属性配置即可：

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

 <!-- 提供方应用信息，用于计算依赖关系 -->
 <dubbo:application name="dubbo-provider-xml-demo" />

 <!-- 使用 Nacos 注册中心 -->
 <dubbo:registry address="nacos://10.20.153.10:8848" />
 ...
</beans>

重启 Dubbo 应用后，您同样也能发现服务提供方和消费方的注册元信息呈现在 Nacos 控制台中：

您是否绝对配置或切换 Nacos 注册中心超级 Easy 呢？如果您仍旧意犹未尽或者不甚明白的话，可参考以下完整的示例。

完整示例

以上图片中的元数据源于 Dubbo Spring 注解驱动示例以及 Dubbo Spring XML 配置驱动示例，下面将分别介绍两者，您可以选择自己偏好的编程模型。在正式讨论之前，先来介绍两者的预备工作，因为它们皆依赖 Java 服务接口和实现。同时，请确保本地（127.0.0.1）环境已启动 Nacos 服务。

示例接口与实现

首先定义示例接口，如下所示：

package com.alibaba.dubbo.demo.service;

/**
 * DemoService
 *
 * @since 2.6.5
 */
public interface DemoService {

 String sayName(String name);

}

提供以上接口的实现类：

package com.alibaba.dubbo.demo.service;

import com.alibaba.dubbo.config.annotation.Service;
import com.alibaba.dubbo.rpc.RpcContext;

import org.springframework.beans.factory.annotation.Value;

/**
 * Default {@link DemoService}
 *
 * @since 2.6.5
 */
@Service(version = "${demo.service.version}")
public class DefaultService implements DemoService {

 @Value("${demo.service.name}")
 private String serviceName;

 public String sayName(String name) {
 RpcContext rpcContext = RpcContext.getContext();
 return String.format("Service [name :%s , port : %d] %s(\"%s\") : Hello,%s",
 serviceName,
 rpcContext.getLocalPort(),
 rpcContext.getMethodName(),
 name,
 name);
 }
}

接口与实现准备妥当后，下面将采用注解驱动和 XML 配置驱动各自实现。

Spring 注解驱动示例

Dubbo 2.5.7 重构了 Spring 注解驱动的编程模型。

服务提供方注解驱动实现

定义 Dubbo 提供方外部化配置属性源 - provider-config.properties

## application
dubbo.application.name = dubbo-provider-demo

## Nacos registry address
dubbo.registry.address = nacos://127.0.0.1:8848

## Dubbo Protocol
dubbo.protocol.name = dubbo
dubbo.protocol.port = -1

# Provider @Service version
demo.service.version=1.0.0
demo.service.name = demoService

实现服务提供方引导类 - DemoServiceProviderBootstrap

package com.alibaba.dubbo.demo.provider;

import com.alibaba.dubbo.config.spring.context.annotation.EnableDubbo;
import com.alibaba.dubbo.demo.service.DemoService;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.PropertySource;

import java.io.IOException;

/**
 * {@link DemoService} provider demo
 */
@EnableDubbo(scanBasePackages = "com.alibaba.dubbo.demo.service")
@PropertySource(value = "classpath:/provider-config.properties")
public class DemoServiceProviderBootstrap {

 public static void main(String[] args) throws IOException {
 AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
 context.register(DemoServiceProviderBootstrap.class);
 context.refresh();
 System.out.println("DemoService provider is starting...");
 System.in.read();
 }
}

其中注解 @EnableDubbo 激活 Dubbo 注解驱动以及外部化配置，其 scanBasePackages 属性扫描指定 Java 包，将所有标注 @Service 的服务接口实现类暴露为 Spring Bean，随即被导出 Dubbo 服务。

@PropertySource 是 Spring Framework 3.1 引入的标准导入属性配置资源注解，它将为 Dubbo 提供外部化配置。

服务消费方注解驱动实现

定义 Dubbo 消费方外部化配置属性源 - consumer-config.properties

## Dubbo Application info
dubbo.application.name = dubbo-consumer-demo

## Nacos registry address
dubbo.registry.address = nacos://127.0.0.1:8848

# @Reference version
demo.service.version= 1.0.0

同样地，dubbo.registry.address 属性指向 Nacos 注册中心，其他 Dubbo 服务相关的元信息通过 Nacos 注册中心获取。

实现服务消费方引导类 - DemoServiceConsumerBootstrap

package com.alibaba.dubbo.demo.consumer;

import com.alibaba.dubbo.config.annotation.Reference;
import com.alibaba.dubbo.config.spring.context.annotation.EnableDubbo;
import com.alibaba.dubbo.demo.service.DemoService;

import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.PropertySource;

import javax.annotation.PostConstruct;
import java.io.IOException;

/**
 * {@link DemoService} consumer demo
 */
@EnableDubbo
@PropertySource(value = "classpath:/consumer-config.properties")
public class DemoServiceConsumerBootstrap {

 @Reference(version = "${demo.service.version}")
 private DemoService demoService;

 @PostConstruct
 public void init() {
 for (int i = 0; i < 10; i++) {
 System.out.println(demoService.sayName("小马哥（mercyblitz）"));
 }
 }

 public static void main(String[] args) throws IOException {
 AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext();
 context.register(DemoServiceConsumerBootstrap.class);
 context.refresh();
 context.close();
 }
}

同样地，@EnableDubbo 注解激活 Dubbo 注解驱动和外部化配置，不过当前属于服务消费者，无需指定 Java 包名扫描标注 @Service 的服务实现。

@Reference 是 Dubbo 远程服务的依赖注入注解，需要服务提供方和消费端约定接口（interface）、版本（version）以及分组（group）信息。在当前服务消费示例中，DemoService 的服务版本来源于属性配置文件 consumer-config.properties。

@PostConstruct 部分代码则说明当 DemoServiceConsumerBootstrap Bean 初始化时，执行十次 Dubbo 远程方法调用。

运行注解驱动示例

在本地启动两次 DemoServiceProviderBootstrap，注册中心将出现两个健康服务：

再运行 DemoServiceConsumerBootstrap，运行结果如下：

Service [name :demoService , port : 20880] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20881] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20880] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20880] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20881] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20881] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20880] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20880] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20881] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :demoService , port : 20881] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）

运行无误，并且服务消费方使用了负载均衡策略，将十次 RPC 调用平均分摊到两个 Dubbo 服务提供方实例中。

Spring XML 配置驱动示例

Spring XML 配置驱动是传统 Spring 装配组件的编程模型。

服务提供方 XML 配置驱动

定义服务提供方 XML 上下文配置文件 - /META-INF/spring/dubbo-provider-context.xml

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

 <!-- 提供方应用信息，用于计算依赖关系 -->
 <dubbo:application name="dubbo-provider-xml-demo"/>

 <!-- 使用 Nacos 注册中心 -->
 <dubbo:registry address="nacos://127.0.0.1:8848"/>

 <!-- 用dubbo协议在随机端口暴露服务 -->
 <dubbo:protocol name="dubbo" port="-1"/>

 <!-- 声明需要暴露的服务接口 -->
 <dubbo:service interface="com.alibaba.dubbo.demo.service.DemoService" ref="demoService" version="2.0.0"/>

 <!-- 和本地bean一样实现服务 -->
 <bean id="demoService" class="com.alibaba.dubbo.demo.service.DefaultService"/>
</beans>

实现服务提供方引导类 - DemoServiceProviderXmlBootstrap

package com.alibaba.dubbo.demo.provider;

import com.alibaba.dubbo.demo.service.DemoService;

import org.springframework.context.support.ClassPathXmlApplicationContext;

import java.io.IOException;

/**
 * {@link DemoService} provider demo XML bootstrap
 */
public class DemoServiceProviderXmlBootstrap {

 public static void main(String[] args) throws IOException {
 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext();
 context.setConfigLocation("/META-INF/spring/dubbo-provider-context.xml");
 context.refresh();
 System.out.println("DemoService provider (XML) is starting...");
 System.in.read();
 }
}

服务消费方 XML 配置驱动

定义服务消费方 XML 上下文配置文件 - /META-INF/spring/dubbo-consumer-context.xml

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

 <!-- 提供方应用信息，用于计算依赖关系 -->
 <dubbo:application name="dubbo-consumer-xml-demo"/>

 <!-- 使用 Nacos 注册中心 -->
 <dubbo:registry address="nacos://127.0.0.1:8848"/>

 <!-- 引用服务接口 -->
 <dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.service.DemoService" version="2.0.0"/>

</beans>

实现服务消费方引导类 - DemoServiceConsumerXmlBootstrap

package com.alibaba.dubbo.demo.consumer;

import com.alibaba.dubbo.demo.service.DemoService;

import org.springframework.context.support.ClassPathXmlApplicationContext;

import java.io.IOException;

/**
 * {@link DemoService} consumer demo XML bootstrap
 */
public class DemoServiceConsumerXmlBootstrap {

 public static void main(String[] args) throws IOException {
 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext();
 context.setConfigLocation("/META-INF/spring/dubbo-consumer-context.xml");
 context.refresh();
 System.out.println("DemoService consumer (XML) is starting...");
 DemoService demoService = context.getBean("demoService", DemoService.class);
 for (int i = 0; i < 10; i++) {
 System.out.println(demoService.sayName("小马哥（mercyblitz）"));
 }
 context.close();
 }
}

运行 XML 配置驱动示例

同样地，先启动两个 DemoServiceProviderXmlBootstrap 引导类，观察 Nacos 注册中心服务提供者变化：

XML 配置驱动的服务版本为 2.0.0，因此注册服务无误。

再运行服务消费者引导类 DemoServiceConsumerXmlBootstrap，观察控制台输出内容：

Service [name :null , port : 20882] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20882] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20883] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20882] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20882] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20883] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20882] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20883] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20883] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）
Service [name :null , port : 20883] sayName("小马哥（mercyblitz）") : Hello,小马哥（mercyblitz）

结果同样运行和负载均衡正常，不过由于当前示例尚未添加属性 demo.service.name 的缘故，因此，“name”部分信息输出为 null。更多内容请参考：https://github.com/apache/dubbo/tree/master/dubbo-registry/dubbo-registry-nacos。

如果您关注或喜爱 Dubbo 以及 Nacos 等开源工程，不妨为它们点 “star”，加油打气链接：

Apache Dubbo：https://github.com/apache/dubbo
Dubbo Nacos Registry：https://github.com/apache/dubbo/tree/master/dubbo-registry/dubbo-registry-nacos
Alibaba Nacos：https://github.com/alibaba/nacos

Blog: Spring应用快速集成Dubbo + Hystrix

Wed, 22 Aug 2018 00:00:00 +0000

背景

Hystrix 旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能。

Dubbo是Alibaba开源的，目前国内最流行的java rpc框架。

本文介绍在spring应用里，怎么把Dubbo和Hystrix结合起来使用。

Spring Boot应用

Demo地址： https://github.com/dubbo/dubbo-samples/tree/master/4-governance/dubbo-samples-spring-boot-hystrix

生成dubbo集成spring boot的应用

对于不熟悉dubbo 集成spring boot应用的同学，可以在这里直接生成dubbo + spring boot的工程： http://start.dubbo.io/

配置spring-cloud-starter-netflix-hystrix

spring boot官方提供了对hystrix的集成，直接在pom.xml里加入依赖：

 <dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
 <version>1.4.4.RELEASE</version>
 </dependency>

然后在Application类上增加@EnableHystrix来启用hystrix starter：

@SpringBootApplication
@EnableHystrix
public class ProviderApplication {

配置Provider端

在Dubbo的Provider上增加@HystrixCommand配置，这样子调用就会经过Hystrix代理。

@Service(version = "1.0.0")
public class HelloServiceImpl implements HelloService {
 @HystrixCommand(commandProperties = {
 @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),
 @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000") })
 @Override
 public String sayHello(String name) {
 // System.out.println("async provider received: " + name);
 // return "annotation: hello, " + name;
 throw new RuntimeException("Exception to show hystrix enabled.");
 }
}

配置Consumer端

对于Consumer端，则可以增加一层method调用，并在method上配置@HystrixCommand。当调用出错时，会走到fallbackMethod = "reliable"的调用里。

 @Reference(version = "1.0.0")
 private HelloService demoService;

 @HystrixCommand(fallbackMethod = "reliable")
 public String doSayHello(String name) {
 return demoService.sayHello(name);
 }
 public String reliable(String name) {
 return "hystrix fallback value";
 }

通过上面的配置，很简单地就完成了Spring Boot里Dubbo + Hystrix的集成。

传统Spring Annotation应用

Demo地址： https://github.com/dubbo/dubbo-samples/tree/master/4-governance/dubbo-samples-spring-hystrix

传统spring annotation应用的配置其实也很简单，和spring boot应用不同的是：

显式配置Spring AOP支持：@EnableAspectJAutoProxy
显式通过@Configuration配置HystrixCommandAspect Bean。

 @Configuration
 @EnableDubbo(scanBasePackages = "com.alibaba.dubbo.samples.annotation.action")
 @PropertySource("classpath:/spring/dubbo-consumer.properties")
 @ComponentScan(value = {"com.alibaba.dubbo.samples.annotation.action"})
 @EnableAspectJAutoProxy
 static public class ConsumerConfiguration {

 @Bean
 public HystrixCommandAspect hystrixCommandAspect() {
 return new HystrixCommandAspect();
 }
 }

Hystrix集成Spring AOP原理

在上面的例子里可以看到，Hystrix对Spring的集成是通过Spring AOP来实现的。下面简单分析下实现。

@Aspect
public class HystrixCommandAspect {
 @Pointcut("@annotation(com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand)")
 public void hystrixCommandAnnotationPointcut() {
 }
 @Pointcut("@annotation(com.netflix.hystrix.contrib.javanica.annotation.HystrixCollapser)")
 public void hystrixCollapserAnnotationPointcut() {
 }

 @Around("hystrixCommandAnnotationPointcut() || hystrixCollapserAnnotationPointcut()")
 public Object methodsAnnotatedWithHystrixCommand(final ProceedingJoinPoint joinPoint) throws Throwable {
 Method method = getMethodFromTarget(joinPoint);
 Validate.notNull(method, "failed to get method from joinPoint: %s", joinPoint);
 if (method.isAnnotationPresent(HystrixCommand.class) && method.isAnnotationPresent(HystrixCollapser.class)) {
 throw new IllegalStateException("method cannot be annotated with HystrixCommand and HystrixCollapser " +
 "annotations at the same time");
 }
 MetaHolderFactory metaHolderFactory = META_HOLDER_FACTORY_MAP.get(HystrixPointcutType.of(method));
 MetaHolder metaHolder = metaHolderFactory.create(joinPoint);
 HystrixInvokable invokable = HystrixCommandFactory.getInstance().create(metaHolder);
 ExecutionType executionType = metaHolder.isCollapserAnnotationPresent() ?
 metaHolder.getCollapserExecutionType() : metaHolder.getExecutionType();

 Object result;
 try {
 if (!metaHolder.isObservable()) {
 result = CommandExecutor.execute(invokable, executionType, metaHolder);
 } else {
 result = executeObservable(invokable, executionType, metaHolder);
 }
 } catch (HystrixBadRequestException e) {
 throw e.getCause() != null ? e.getCause() : e;
 } catch (HystrixRuntimeException e) {
 throw hystrixRuntimeExceptionToThrowable(metaHolder, e);
 }
 return result;
 }

HystrixCommandAspect里定义了两个注解的AspectJ Pointcut：@HystrixCommand, @HystrixCollapser。所有带这两个注解的spring bean都会经过AOP处理
在@Around AOP处理函数里，可以看到Hystrix会创建出HystrixInvokable，再通过CommandExecutor来执行

spring-cloud-starter-netflix-hystrix的代码分析

@EnableHystrix 引入了@EnableCircuitBreaker，@EnableCircuitBreaker引入了EnableCircuitBreakerImportSelector

@EnableCircuitBreaker
public @interface EnableHystrix {
}

@Import(EnableCircuitBreakerImportSelector.class)
public @interface EnableCircuitBreaker {
}

EnableCircuitBreakerImportSelector继承了SpringFactoryImportSelector<EnableCircuitBreaker>，使spring加载META-INF/spring.factories里的EnableCircuitBreaker声明的配置

在META-INF/spring.factories里可以找到下面的配置，也就是引入了HystrixCircuitBreakerConfiguration。
```
org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker=\
org.springframework.cloud.netflix.hystrix.HystrixCircuitBreakerConfiguration
```

在HystrixCircuitBreakerConfiguration里可以发现创建了HystrixCommandAspect

@Configuration
public class HystrixCircuitBreakerConfiguration {

 @Bean
 public HystrixCommandAspect hystrixCommandAspect() {
 return new HystrixCommandAspect();
 }

可见spring-cloud-starter-netflix-hystrix实际上也是创建了HystrixCommandAspect来集成Hystrix。

另外spring-cloud-starter-netflix-hystrix里还有metrics, health, dashboard等集成。

总结

对于dubbo provider的@Service是一个spring bean，直接在上面配置@HystrixCommand即可
对于dubbo consumer的@Reference，可以通过加一层简单的spring method包装，配置@HystrixCommand即可
Hystrix本身提供HystrixCommandAspect来集成Spring AOP，配置了@HystrixCommand和@HystrixCollapser的spring method都会被Hystrix处理

链接

Blog: 从跨语言调用到dubbo2.js

Tue, 14 Aug 2018 00:00:00 +0000

dubbo2.js 是千米网贡献给 dubbo 社区的一款 nodejs dubbo 客户端，它提供了 nodejs 对原生 dubbo 协议的支持，使得 nodejs 和 java 这两种异构语言的 rpc 调用变得便捷，高效。

微服务跨语言调用

微服务架构已成为目前互联网架构的趋势，关于微服务的讨论，几乎占据了各种技术大会的绝大多数版面。国内使用最多的服务治理框架非阿里开源的 dubbo 莫属，千米网也选择了 dubbo 作为微服务治理框架。另一方面，和大多数互联网公司一样，千米的开发语言是多样的，大多数后端业务由 java 支撑，而每个业务线有各自开发语言的选择权，便出现了 nodejs，python，go 多语言调用的问题。跨语言调用是一个很大的话题，也是一个很有挑战的技术活，目前业界经常被提及的解决方案有如下几种，不妨拿出来老生常谈一番：

spring cloud。spring cloud 提供了一整套微服务开发组件，它主要面向 java 开发，但由于其使用的协议是基于 restful 风格的 http 协议，这使得其天然具备跨语言能力，异构语言只需要提供 http 客户端，便可以实现跨语言调用。
service mesh。号称下一代微服务框架的 service mesh，其解决跨语言问题的核心在于 SideCar ，SideCar 在 service mesh 的发展过程中概念不断的迁移，但本质都是完成了一件事：处理服务间通信，负责实现请求的可靠传递。
motan。motan 是新浪微博开源的一款跨语言服务治理框架，在其早期版本中仅支持 motan-java，随着版本演进，在目前最新版本(1.1.0)中，提供了 motan-go，motan-php，motan-openresty 等跨语言特性。类似于 service mesh 中的 SideCar，motan 借助于 motan-go 作为 agent 完成协议的转发，并且依赖于定制协议：motan2，实现跨语言调用。

当我们再聊跨语言调用时我们在聊什么？纵观上述几个较为通用，成熟的解决方案，可以得出结论：解决跨语言调用的思路无非是两种：

寻找一个通用的协议
使用 agent 完成协议的适配

如果一个新型的团队面临技术选型，我认为上述的方案都可以纳入参考，可考虑到遗留系统的兼容性问题

旧系统的迁移成本

这也关键的选型因素。我们做出的第一个尝试，便是在 RPC 协议上下功夫。

通用协议的跨语言支持

springmvc的美好时代

在没有实现真正的跨语言调用之前，想要实现“跨语言”大多数方案是使用 http 协议做一层转换，最常见的手段莫过于借助 springmvc 提供的 controller/restController，间接调用 dubbo provider。这种方案的优势和劣势显而易见

优势是简单，是最通俗的解决方案。
劣势是使得调用链路变长，tcp 通信之上又多了一层 http 通信；开发体验差，为了将 rpc 接口暴露出去，需要额外编写一份 controller 层的代码。

通用协议的支持

事实上，大多数服务治理框架都支持多种协议，dubbo 框架除默认的 dubbo 协议之外，还有当当网扩展的 rest 协议和千米网扩展的 json-rpc 协议可供选择。这两者都是通用的跨语言协议。

rest 协议为满足 JAX-RS 2.0 标准规范，在开发过程中引入了 @Path，@POST，@GET 等注解，习惯于编写传统 rpc 接口的人可能不太习惯 rest 风格的 rpc 接口。一方面这样会影响开发体验，另一方面，独树一帜的接口风格使得它与其他协议不太兼容，旧接口的共生和迁移都无法实现。如果没有遗留系统，rest 协议无疑是跨语言方案最简易的实现，绝大多数语言支持 rest 协议。

和 rest 协议类似，json-rpc 的实现也是文本序列化&http 协议。dubbox 在 restful 接口上已经做出了尝试，但是 rest 架构和 dubbo 原有的 rpc 架构是有区别的，rest 架构需要对资源(Resources)进行定义，需要用到 http 协议的基本操作 GET、POST、PUT、DELETE。在我们看来，restful 更合适互联网系统之间的调用，而 rpc 更适合一个系统内的调用。使用 json-rpc 协议使得旧接口得以兼顾，开发习惯仍旧保留，同时获得了跨语言的能力。

千米网在早期实践中采用了 json-rpc 作为 dubbo 的跨语言协议实现，并开源了基于 json-rpc 协议下的 python 客户端 dubbo-client-py 和 node 客户端 dubbo-node-client，使用 python 和 nodejs 的小伙伴可以借助于它们直接调用 dubbo-provider-java 提供的 rpc 服务。系统中大多数 java 服务之间的互相调用还是以 dubbo 协议为主，考虑到新旧协议的适配，在不影响原有服务的基础上，我们配置了双协议。

<dubbo:protocol name="dubbo" port="20880" />
<dubbo:protocol name="jsonrpc" port="8080" />

dubbo 协议主要支持 java 间的相互调用，适配老接口；json-rpc 协议主要支持异构语言的调用。

定制协议的跨语言支持

微服务框架所谓的协议(protocol)可以简单理解为：报文格式和序列化方案。服务治理框架一般都提供了众多的协议配置项供使用者选择，除去上述两种通用协议，还存在一些定制化的协议，如 dubbo 框架的默认协议：dubbo 协议以及 motan 框架提供的跨语言协议：motan2。

motan2协议的跨语言支持

motan2 协议被设计用来满足跨语言的需求主要体现在两个细节中—MetaData 和 motan-go。在最初的 motan 协议中，协议报文仅由 Header+Body 组成，这样导致 path，param，group 等存储在 Body 中的数据需要反序列得到，这对异构语言来说是很不友好的，所以在 motan2 中修改了协议的组成；weibo 开源了 motan-go ，motan-php，motan-openresty ,并借助于 motan-go 充当了 agent 这一翻译官的角色，使用 simple 序列化方案来序列化协议报文的 Body 部分（simple 序列化是一种较弱的序列化方案）。

仔细揣摩下可以发现这么做和双协议的配置区别并不是大，只不过这里的 agent 是隐式存在的，与主服务共生。明显的区别在于 agent 方案中异构语言并不直接交互。

dubbo协议的跨语言支持

dubbo 协议设计之初只考虑到了常规的 rpc 调用场景，它并不是为跨语言而设计，但跨语言支持从来不是只有支持、不支持两种选择，而是要按难易

程度来划分。是的，dubbo 协议的跨语言调用可能并不好做，但并非无法实现。千米网便实现了这一点，nodejs 构建的前端业务是异构语言的主战场，最终实现了 dubbo2.js，打通了 nodejs 和原生 dubbo 协议。作为本文第二部分的核心内容，重点介绍下我们使用 dubbo2.js 干了什么事。

Dubbo协议报文格式

dubbo协议报文消息头详解：

magic：类似java字节码文件里的魔数，用来判断是不是 dubbo 协议的数据包。魔数是常量 0xdabb
flag：标志位, 一共8个地址位。低四位用来表示消息体数据用的序列化工具的类型（默认 hessian），高四位中，第一位为 1 表示是 request 请求，第二位为 1 表示双向传输（即有返回 response），第三位为 1 表示是心跳 ping 事件。
status：状态位, 设置请求响应状态，dubbo 定义了一些响应的类型。具体类型见com.alibaba.dubbo.remoting.exchange.Response
invoke id：消息 id, long 类型。每一个请求的唯一识别 id（由于采用异步通讯的方式，用来把请求 request 和返回的 response 对应上）
body length：消息体 body 长度, int 类型，即记录 Body Content 有多少个字节
body content：请求参数，响应参数的抽象序列化之后存储于此。

协议报文最终都会变成字节，使用 tcp 传输，任何语言只要支持网络模块，有类似 Socket 之类的封装，那么通信就不成问题。那，跨语言难在哪儿？以其他语言调用 java 来说，主要有两个难点：

异构语言如何表示 java 中的数据类型，特别是动态语言，可能不存在严格的数据类型
序列化方案如何做到跨语言

dubbo2.js解决方案

上面我们分析出了两个难点，dubbo2.js 解决这两个问题的关键依赖于两个类库：js-to-java，hessian.js 。js-to-java 使得 nodejs 具备 java 对象的表达能力，而 hessian.js 提供了序列化能力。借助于 nodejs 的 socket ，复制一套 dubbo 协议的报文格式，最终便实现了 nodejs 对 java-dubbo-provider 的调用。

dubbo2.js快速入门

为了让对 dubbo2.js 感兴趣的读者有一个直观的体验，本节呈现一个快速入门示例，让你体会到使用 dubbo2.js 调用 dubbo 服务是一件多么轻松的事。

1. 创建 dubbo-java-provider

后端 dubbo 服务使用 java 来提供，这服务大多数的业务场景。首先定义服务接口：

public interface DemoProvider {
 String sayHello(String name);
 String echo() ;
 void test();
 UserResponse getUserInfo(UserRequest request);
}

其次，实现服务：

public class DemoProviderImpl implements DemoProvider {
 public String sayHello(String name) {
 System.out.println("[" + new SimpleDateFormat("HH:mm:ss").format(new Date()) + "] Hello " + name + ", request from consumer: " + RpcContext.getContext().getRemoteAddress());
 return "Hello " + name + ", response form provider: " + RpcContext.getContext().getLocalAddress();
 }
 @Override
 public String echo() {
 System.out.println("receive....");
 return "pang";
 }
 @Override
 public void test() {
 System.out.println("test");
 }
 @Override
 public UserResponse getUserInfo(UserRequest request) {
 System.out.println(request);
 UserResponse response = new UserResponse();
 response.setStatus("ok");
 Map<String, String> map = new HashMap<String, String>();
 map.put("id", "1");
 map.put("name", "test");
 response.setInfo(map);
 return response;
 }
}

暴露服务：

<?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="demo-provider"/>

 <dubbo:registry protocol="zookeeper" address="localhost:2181"/>

 <!-- 用dubbo协议在20880端口暴露服务 -->
 <dubbo:protocol name="dubbo" port="20880"/>

 <!-- 和本地bean一样实现服务 -->
 <bean id="demoProvider" class="com.alibaba.dubbo.demo.provider.DemoProviderImpl"/>

 <!-- 声明需要暴露的服务接口 -->
 <dubbo:service interface="com.alibaba.dubbo.demo.DemoProvider" ref="demoProvider" version="1.0.0"/>

</beans>

我们完成了服务端的所有配置，启动启动类即可在本地注册一个 dubbo 服务。

public class Provider {
 public static void main(String[] args) throws Exception {
 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[]{"META-INF/spring/dubbo-demo-provider.xml"});
 context.start();
 System.in.read();
 }
}

2. 实现 nodejs 的 dubbo 客户端

安装 dubbo2.js：

npm install dubbo2.js --save

配置 dubboConfig.ts：

import { Dubbo, java, TDubboCallResult } from 'dubbo2.js'

const dubbo = new Dubbo({
 application: {name: 'demo-provider'},
 register: 'localhost:2181',
 dubboVersion: '2.0.0',
 interfaces: [
 'com.alibaba.dubbo.demo.DemoProvider',
 ],
});

interface IDemoService {
 sayHello(name: string): TDubboCallResult<string>;
}

export const demoService = dubbo.proxyService<IDemoService>({
 dubboInterface: 'com.alibaba.dubbo.demo.DemoProvider',
 version: '1.0.0',
 methods: {
 sayHello(name: string) {
 return [java.String(name)];
 },

 echo() {},

 test() {},

 getUserInfo() {
 return [
 java.combine('com.alibaba.dubbo.demo.UserRequest', {
 id: 1,
 name: 'nodejs',
 email: 'node@qianmi.com',
 }),
 ];
 },
 },
});

使用 typescript 可以带来更好的开发体验。

编写调用类 main.ts：

import {demoService} from './dubboConfig'

demoService.sayHello('kirito').then(({res,err})=>{
 console.log(res)
});

3. 执行调用

Debug 模式启动 nodejs 客户端：

DEBUG=dubbo* ts-node main.ts

查看运行结果：

Hello kirito, response form provider: 172.19.6.151:20880

Congratulation！

dubbo2.js特性

支持 zookeeper 注册中心
支持原生 dubbo 协议
支持服务直连
全链路跟踪
dubbo 接口自动生成

Blog: 在 Dubbo 应用中使用 Zookeeper

Tue, 07 Aug 2018 00:00:00 +0000

Zookeeper 介绍

基本概念

在现代的分布式应用中，往往会出现节点和节点之间的协调问题，其中就包括了：选主、集群管理、分布式锁、分布式配置管理、统一命名服务、状态同步等诉求。Apache Zookeeper，正如它的名字所暗示的那样，动物园管理员，就是为了解决这些诉求的一个分布式协调服务框架。

为了保证高可用，ZooKeeper 本身也可以部署成集群模式，称之为 ZooKeeper ensemble。ZooKeeper 集群中始终确保其中的一台为 leader 的角色，并通过 ZAB (Zookeeper Atomic Broadcast Protocol) ¹ 协议确保所有节点上的信息的一致。客户端可以访问集群中的任何一台进行读写操作，而不用担心数据出现不一致的现象。

Image Credit : ebook -Zookeeper-Distributed Process Coordination from O’Reilly

Zookeeper 中的数据存储方式与传统的 UNIX 文件系统相似，节点按照树状结构来组织，其中，节点被称之为 znodes (ZooKeeper data nodes)

Image Credit : ebook -Zookeeper-Distributed Process Coordination from O’Reilly

基本用法

可以通过直接下载的方式 ²安装并运行 Zookeeper ，在 Mac 上也可以通过 Homebrew ³ brew install zookeeper 来安装，考虑到通用性，本文采用 docker 的方式来运行 Zookeeper。如果没有安装 docker，请先准备好 docker 环境 ⁴。

1. 启动 Zookeeper

执行命令将 Zookeeper 运行在 docker 容器中

docker run --rm --name zookeeper -p 2181:2181 zookeeper

2. 进入 Zookeeper 容器

docker exec -it zookeeper bash

在 bin 目录下有启动 Zookeeper 的命令 zkServer 以及管理控制台 zkCli

bash-4.4# ls -l bin
total 36
-rwxr-xr-x 1 zookeepe zookeepe 232 Mar 27 04:32 README.txt
-rwxr-xr-x 1 zookeepe zookeepe 1937 Mar 27 04:32 zkCleanup.sh
-rwxr-xr-x 1 zookeepe zookeepe 1056 Mar 27 04:32 zkCli.cmd
-rwxr-xr-x 1 zookeepe zookeepe 1534 Mar 27 04:32 zkCli.sh
-rwxr-xr-x 1 zookeepe zookeepe 1759 Mar 27 04:32 zkEnv.cmd
-rwxr-xr-x 1 zookeepe zookeepe 2696 Mar 27 04:32 zkEnv.sh
-rwxr-xr-x 1 zookeepe zookeepe 1089 Mar 27 04:32 zkServer.cmd
-rwxr-xr-x 1 zookeepe zookeepe 6773 Mar 27 04:32 zkServer.sh

3. 通过 zkCli 进入 Zookeeper 管理界面

由于是通过 Docker 启动，Zookeeper 进程已经启动，并通过 2181 端口对外提供服务。

bash-4.4# ps
PID USER TIME COMMAND
 1 zookeepe 0:02 /usr/lib/jvm/java-1.8-openjdk/jre/bin/java -Dzookeeper.log.dir=. -Dzookeeper.root
 32 root 0:00 bash
 42 root 0:00 ps

因此可以直接通过 zkCli 来访问 Zookeeper 的控制台来进行管理。

bash-4.4# bin/zkCli.sh -server 127.0.0.1:2181
Connecting to 127.0.0.1:2181
...
WATCHER::

WatchedEvent state:SyncConnected type:None path:null

[zk: 127.0.0.1:2181(CONNECTED) 0] help
ZooKeeper -server host:port cmd args
 stat path [watch]
 set path data [version]
 ls path [watch]
 delquota [-n|-b] path
 ls2 path [watch]
 setAcl path acl
 setquota -n|-b val path
 history
 redo cmdno
 printwatches on|off
 delete path [version]
 sync path
 listquota path
 rmr path
 get path [watch]
 create [-s] [-e] path data acl
 addauth scheme auth
 quit
 getAcl path
 close
 connect host:port

4. zkCli 上的一些基本操作

创建 /hello-zone 节点：

[zk: 127.0.0.1:2181(CONNECTED) 19] create /hello-zone 'world'
Created /hello-zone

列出 / 下的子节点，确认 hello-zone 被创建：

[zk: 127.0.0.1:2181(CONNECTED) 20] ls /
[zookeeper, hello-zone]

列出 /hello-zone 的子节点，确认为空：

[zk: 127.0.0.1:2181(CONNECTED) 21] ls /hello-zone
[]

获取存储在 /hello-zone 节点上的数据：

[zk: 127.0.0.1:2181(CONNECTED) 22] get /hello-zone
world

在 Dubbo 中使用 Zookeeper

Dubbo 使用 Zookeeper 用于服务的注册发现和配置管理，在 Zookeeper 中数据的组织由下图所示：

首先，所有 Dubbo 相关的数据都组织在 /dubbo 的根节点下。

二级目录是服务名，如 com.foo.BarService。

三级目录有两个子节点，分别是 providers 和 consumers，表示该服务的提供者和消费者。

四级目录记录了与该服务相关的每一个应用实例的 URL 信息，在 providers 下的表示该服务的所有提供者，而在 consumers 下的表示该服务的所有消费者。举例说明，com.foo.BarService 的服务提供者在启动时将自己的 URL 信息注册到 /dubbo/com.foo.BarService/providers 下；同样的，服务消费者将自己的信息注册到相应的 consumers 下，同时，服务消费者会订阅其所对应的 providers 节点，以便能够感知到服务提供方地址列表的变化。

准备示例代码

本文的代码可以在 https://github.com/apache/dubbo-samples/tree/master/3-extensions/registry/dubbo-samples-zookeeper 中找到。

1. 接口定义

定义一个简单的 GreetingService 接口，里面只有一个简单的方法 sayHello 向调用者问好。

public interface GreetingService {
 String sayHello(String name);
}

2. 服务端：服务实现

实现 GreetingService 接口，并通过 @Service 来标注其为 Dubbo 的一个服务。

@Service
public class AnnotatedGreetingService implements GreetingService {
 public String sayHello(String name) {
 return "hello, " + name;
 }
}

3. 服务端：组装

定义 ProviderConfiguration 来组装 Dubbo 服务。

@Configuration
@EnableDubbo(scanBasePackages = "com.alibaba.dubbo.samples.impl")
@PropertySource("classpath:/spring/dubbo-provider.properties")
static class ProviderConfiguration {}

dubbo-provider.properties 是在 Spring 应用中外置配置的方式，内容如下：

dubbo.application.name=demo-provider
dubbo.registry.address=zookeeper://$DOCKER_HOST:2181
dubbo.protocol.name=dubbo
dubbo.protocol.port=20880

由于 Zookeeper 运行在 Docker 容器中，需要注意的是：

本文假定 Dubbo 应用运行在宿主机上，也就是 Docker 容器外，需要将 Zookeeper 的地址替换成环境变量 ${DOCKER_HOST} 所指定的 IP 地址，相关信息请查阅 Docker 官方文档
如果 Dubbo 应用也是 Docker 化的应用，只需要用 Zookeeper 的容器名，在本文中容器名是 zookeeper
当然，如果不用容器方式启动 Zookeeper，只需要简单的将这里的 $DOCKER_HOST 换成 localhost 即可

4. 服务端：启动服务

在 main 方法中通过启动一个 Spring Context 来对外提供 Dubbo 服务。

public class ProviderBootstrap {
 public static void main(String[] args) throws Exception {
 AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ProviderConfiguration.class);
 context.start();
 System.in.read();
 }
}

启动服务端的 main 方法，将会看到下面的输出，代表服务端启动成功，并在注册中心（ZookeeperRegistry）上注册了 GreetingService 这个服务：

[03/08/18 10:50:33:033 CST] main INFO zookeeper.ZookeeperRegistry: [DUBBO] Register: dubbo://192.168.99.1:20880/com.alibaba.dubbo.samples.api.GreetingService?anyhost=true&application=demo-provider&dubbo=2.6.2&generic=false&interface=com.alibaba.dubbo.samples.api.GreetingService&methods=sayHello&pid=12938&side=provider&timestamp=1533264631849, dubbo version: 2.6.2, current host: 192.168.99.1

通过 Zookeeper 管理终端观察服务提供方的注册信息：

$ docker exec -it zookeeper bash
bash-4.4# bin/zkCli.sh -server localhost:218
Connecting to localhost:2181
...
Welcome to ZooKeeper!
JLine support is enabled
...
[zk: localhost:2181(CONNECTED) 0] ls /dubbo/com.alibaba.dubbo.samples.api.GreetingService/providers
[dubbo%3A%2F%2F192.168.99.1%3A20880%2Fcom.alibaba.dubbo.samples.api.GreetingService%3Fanyhost%3Dtrue%26application%3Ddemo-provider%26dubbo%3D2.6.2%26generic%3Dfalse%26interface%3Dcom.alibaba.dubbo.samples.api.GreetingService%26methods%3DsayHello%26pid%3D12938%26side%3Dprovider%26timestamp%3D1533264631849]

可以看到刚刚启动的 Dubbo 的服务在 providers 节点下注册了自己的 URL 地址：dubbo://192.168.99.1:20880/com.alibaba.dubbo.samples.api.GreetingService?anyhost=true&application=demo-provider&dubbo=2.6.2&generic=false&interface=com.alibaba.dubbo.samples.api.GreetingService&methods=sayHello&pid=12938&side=provider&timestamp=1533264631849

5. 客户端：引用服务

通过 @Reference 来在客户端声明服务的引用，运行时将会通过该引用发起全程调用，而服务的目标地址将会从 Zookeeper 的 provider 节点下查询。

@Component("annotatedConsumer")
public class GreetingServiceConsumer {
 @Reference
 private GreetingService greetingService;

 public String doSayHello(String name) {
 return greetingService.sayHello(name);
 }
}

6. 客户端：组装

定义 ConsumerConfiguration 来组装 Dubbo 服务。

@Configuration
@EnableDubbo(scanBasePackages = "com.alibaba.dubbo.samples.action")
@PropertySource("classpath:/spring/dubbo-consumer.properties")
@ComponentScan(value = {"com.alibaba.dubbo.samples.action"})
static class ConsumerConfiguration {}

dubbo-consumer.properties 是在 Spring 应用中外置配置的方式，内容如下：

dubbo.application.name=demo-consumer
dubbo.registry.address=zookeeper://$DOCKER_HOST:2181
dubbo.consumer.timeout=3000

与 3. 服务端：组装 相同，需要根据自己的运行环境来修改 dubbo.registry.address 中定义的 $DOCKER_HOST。请参阅步骤 3 的说明部分。

7. 客户端：发起远程调用

运行 main 向已经启动的服务提供方发起一次远程调用。Dubbo 会先向 Zookeeper 订阅服务地址，然后从返回的地址列表中选取一个，向对端发起调用：

public class ConsumerBootstrap {
 public static void main(String[] args) {
public class ConsumerBootstrap {

 public static void main(String[] args) throws IOException {
 AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ConsumerConfiguration.class);
 context.start();
 GreetingServiceConsumer greetingServiceConsumer = context.getBean(GreetingServiceConsumer.class);
 String hello = greetingServiceConsumer.doSayHello("zookeeper");
 System.out.println("result: " + hello);
 System.in.read();
 }
}

运行结果如下：

[03/08/18 01:42:31:031 CST] main INFO zookeeper.ZookeeperRegistry: [DUBBO] Register: consumer://192.168.99.1/com.alibaba.dubbo.samples.api.GreetingService?application=demo-consumer&category=consumers&check=false&default.timeout=3000&dubbo=2.6.2&interface=com.alibaba.dubbo.samples.api.GreetingService&methods=sayHello&pid=82406&side=consumer&timestamp=1533274951195, dubbo version: 2.6.2, current host: 192.168.99.1 #1
[03/08/18 01:42:31:031 CST] main INFO zookeeper.ZookeeperRegistry: [DUBBO] Subscribe: consumer://192.168.99.1/com.alibaba.dubbo.samples.api.GreetingService?application=demo-consumer&category=providers,configurators,routers&default.timeout=3000&dubbo=2.6.2&interface=com.alibaba.dubbo.samples.api.GreetingService&methods=sayHello&pid=82406&side=consumer&timestamp=1533274951195, dubbo version: 2.6.2, current host: 192.168.99.1 #2
...
result: hello, zookeeper

说明：

Register: consumer://192.168.99.1/…&category=consumers&：消费者向 Zookeeper 注册自己的信息，并放在 consumers 节点下
Subscribe: consumer://192.168.99.1/…&category=providers,configurators,routers&：消费者同时向 Zookeeper 订阅了 providers、configurators、routers 节点，其中 configurations 与 Dubbo 配置相关，routers 与路由规则相关，值得注意的是 providers 节点的订阅，当有新的服务提供方加入后，由于订阅的关系，新的地址列表会推送给订阅方，服务的消费者也因此动态感知到了地址列表的变化。

通过 Zookeeper 管理终端观察服务提供方的注册信息：

$ docker exec -it zookeeper bash
bash-4.4# bin/zkCli.sh -server localhost:218
Connecting to localhost:2181
...
Welcome to ZooKeeper!
JLine support is enabled
...
[zk: localhost:2181(CONNECTED) 4] ls /dubbo/com.alibaba.dubbo.samples.api.GreetingService/consumers
[consumer%3A%2F%2F192.168.99.1%2Fcom.alibaba.dubbo.samples.api.GreetingService%3Fapplication%3Ddemo-consumer%26category%3Dconsumers%26check%3Dfalse%26default.timeout%3D3000%26dubbo%3D2.6.2%26interface%3Dcom.alibaba.dubbo.samples.api.GreetingService%26methods%3DsayHello%26pid%3D82406%26side%3Dconsumer%26timestamp%3D1533274951195]

可以看到 Dubbo 的服务消费者在 consumers 节点下注册了自己的 URL 地址：consumer://192.168.99.1/com.alibaba.dubbo.samples.api.GreetingService?application=demo-consumer&category=providers,configurators,routers&default.timeout=3000&dubbo=2.6.2&interface=com.alibaba.dubbo.samples.api.GreetingService&methods=sayHello&pid=82406&side=consumer&timestamp=1533274951195

总结

本文侧重介绍了如何在 Dubbo 应用中使用 Zookeeper 做为注册中心，当然，本文也提到了 Zookeeper 在 Dubbo 的应用场景下还承担了配置中心和服务治理的职责。本文中的 Zookeeper 是单节点、Standalone 的模式，在生产环境中为了高可用的诉求，往往会组件 Zookeeper 集群，也就是 Zookeeper ensemble 模式。

通过本文的学习，读者可以掌握到：

Zookeeper 的基本概念和基本用法
Zookeeper 在 Dubbo 应用中的作用
通过实战了解 Zookeeper 与 Dubbo 的交互
Dubbo 在 Zookeeper 中服务注册、消费信息的存储方式

https://www.ixiacom.com/company/blog/apache-zab—zookeeper-atomic-broadcast-protocol ↩︎
https://www.apache.org/dyn/closer.cgi/zookeeper/ ↩︎
https://brew.sh ↩︎
https://www.docker.com/community-edition ↩︎

Blog: Sentinel 为 Dubbo 服务保驾护航

Fri, 27 Jul 2018 00:00:00 +0000

在复杂的生产环境下可能部署着成千上万的 Dubbo 服务实例，流量持续不断地进入，服务之间进行相互调用。但是分布式系统中可能会因流量激增、系统负载过高、网络延迟等一系列问题，导致某些服务不可用，如果不进行相应的控制可能导致级联故障，影响服务的可用性，因此如何对流量进行合理的控制，成为保障服务稳定性的关键。

Sentinel 是阿里中间件团队开源的，面向分布式服务架构的轻量级流量控制产品，主要以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度来帮助用户保护服务的稳定性。本文将基于 Dubbo，看看 Sentinel 是如何进行流量控制的，并且提供 Dubbo 整合 Sentinel 的最佳实践。

快速接入 Sentinel

Sentinel 意为哨兵，这个命名形象的诠释了 Sentinel 在分布式系统中的工作角色和重要性。以 Sentinel 在 Dubbo 生态系统中的作用为例，Dubbo 的核心模块包括注册中心、服务提供方、服务消费方（服务调用方）和监控四个模块。Sentinel 通过对服务提供方和服务消费方的限流来进一步提升服务的可用性。接下来我们看看 Sentinel 对服务提供方和服务消费方限流的技术实现方式。

Sentinel 提供了与 Dubbo 适配的模块 – Sentinel Dubbo Adapter，包括针对服务提供方的过滤器和服务消费方的过滤器（Filter）。使用时我们只需引入以下模块（以 Maven 为例）：

<dependency>
 <groupId>com.alibaba.csp</groupId>
 <artifactId>sentinel-dubbo-adapter</artifactId>
 <version>x.y.z</version>
</dependency>

引入此依赖后，Dubbo 的服务接口和方法（包括调用端和服务端）就会成为 Sentinel 中的资源，在配置了规则后就可以自动享受到 Sentinel 的防护能力。同时提供了灵活的配置选项，例如若不希望开启 Sentinel Dubbo Adapter 中的某个 Filter，可以手动关闭对应的 Filter。

接入 Sentinel Dubbo Adapter 后，即使未配置规则，Sentinel 也会对相应的 Dubbo 服务的调用信息进行统计。那么我们怎么知道 Sentinel 接入成功了呢？这时候就要请出一大利器 —— Sentinel 控制台了。

限流必备 - 监控管理

流量具有很强的实时性，之所以需要限流，是因为我们无法对流量的到来作出精确的预判，不然的话我们完全可以通过弹性的计算资源来处理，所以这时候为了保证限流的准确性，限流框架的监控功能就非常重要了。

Sentinel 的控制台（Dashboard）是流量控制、熔断降级规则统一配置和管理的入口，同时它为用户提供了多个维度的监控功能。在 Sentinel 控制台上，我们可以配置规则并实时查看流量控制效果。

接入 Sentinel 控制台的步骤如下（缺一不可）：

按照 Sentinel 控制台文档启动控制台
应用引入 sentinel-transport-simple-http 依赖，以便控制台可以拉取对应应用的相关信息
给应用添加相关的启动参数，启动应用。需要配置的参数有：
- -Dcsp.sentinel.api.port：客户端的 port，用于上报相关信息（默认为 8719）
- -Dcsp.sentinel.dashboard.server：控制台的地址
- -Dproject.name：应用名称，会在控制台中显示

注意某些环境下本地运行 Dubbo 服务还需要加上 -Djava.net.preferIPv4Stack=true 参数。比如中 Service Provider 的启动参数可以配成：

-Djava.net.preferIPv4Stack=true -Dcsp.sentinel.api.port=8720 -Dcsp.sentinel.dashboard.server=localhost:8080 -Dproject.name=dubbo-provider-demo

这样在启动应用后就能在控制台找到对应的应用了。以下是常用功能：

单台设备监控：当在机器列表中看到您的机器，就代表着已经成功接入控制台，可以查看单台设备的设备名称、IP地址、端口号、健康状态和心跳时间等信息。

链路监控：簇点链路实时的去拉取指定客户端资源的运行情况，它提供了两种展示模式，一种用书状结构展示资源的调用链路；另外一种则不区分调用链路展示资源的运行情况。通过链路监控，可以查看到每个资源的流控和降级的历史状态。

树状链路	平铺链路

聚合监控：同一个服务下的所有机器的簇点信息会被汇总，实现实时监控，精确度达秒级。

规则配置：可以查看已有的限流、降级和系统保护规则，并实时地进行配置。

Sentinel 基于 Dubbo 的最佳实践

具体 Demo 代码请见 sentinel-demo-dubbo。

Service Provider

对服务提供方的流量控制可分为服务提供方的自我保护能力和服务提供方对服务消费方的请求分配能力两个维度。

Service Provider 用于向外界提供服务，处理各个消费者的调用请求。为了保护 Provider 不被激增的流量拖垮影响稳定性，可以给 Provider 配置 QPS 模式的限流，这样当每秒的请求量超过设定的阈值时会自动拒绝多的请求。限流粒度可以是 服务接口 和 服务方法 两种粒度。若希望整个服务接口的 QPS 不超过一定数值，则可以为对应服务接口资源（resourceName 为接口全限定名）配置 QPS 阈值；若希望服务的某个方法的 QPS 不超过一定数值，则可以为对应服务方法资源（resourceName 为接口全限定名:方法签名）配置 QPS 阈值。有关配置详情请参考流量控制 | Sentinel。

我们看一下这种模式的限流产生的效果。假设我们已经定义了某个服务接口 com.alibaba.csp.sentinel.demo.dubbo.FooService，其中有一个方法 sayHello(java.lang.String)，Provider 端该方法设定 QPS 阈值为 10。在 Consumer 端在 1s 之内连续发起 15 次调用，可以通过日志文件看到 Provider 端被限流。拦截日志统一记录在 ~/logs/csp/sentinel-block.log 中：

2018-07-24 17:13:43|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,|5,0

在 Provider 对应的 metrics 日志中也有记录：

1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService|15|0|15|0|3
1532423623000|2018-07-24 17:13:43|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String)|10|5|10|0|0

根据调用方的需求来分配服务提供方的处理能力也是常见的限流方式。比如有两个服务 A 和 B 都向 Service Provider 发起调用请求，我们希望只对来自服务 B 的请求进行限流，则可以设置限流规则的 limitApp 为服务 B 的名称。Sentinel Dubbo Adapter 会自动解析 Dubbo 消费者（调用方）的 application name 作为调用方名称（origin），在进行资源保护的时候都会带上调用方名称。若限流规则未配置调用方（default），则该限流规则对所有调用方生效。若限流规则配置了调用方则限流规则将仅对指定调用方生效。

注：Dubbo 默认通信不携带对端 application name 信息，因此需要开发者在调用端手动将 application name 置入 attachment 中，provider 端进行相应的解析。Sentinel Dubbo Adapter 实现了一个 Filter 用于自动从 consumer 端向 provider 端透传 application name。若调用端未引入 Sentinel Dubbo Adapter，又希望根据调用端限流，可以在调用端手动将 application name 置入 attachment 中，key 为 dubboApplication。

在限流日志中会也会记录调用方的名称，如下面的日志中的 demo-consumer 即为调用方名称：

2018-07-25 16:26:48|1|com.alibaba.csp.sentinel.demo.dubbo.FooService:sayHello(java.lang.String),FlowException,default,demo-consumer|5,0

Service Consumer

对服务提供方的流量控制可分为控制并发线程数和服务降级两个维度。

并发线程数限流

Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务，若某个服务 A 依赖的下游服务 B 出现了不稳定的情况，服务 A 请求服务 B 的响应时间变长，从而服务 A 调用服务 B 的线程就会产生堆积，最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问，来保证下游服务不可靠的时候，不会拖垮服务自身。基于这种场景，推荐给 Consumer 配置线程数模式的限流，来保证自身不被不稳定服务所影响。采用基于线程数的限流模式后，我们不需要再显式地去进行线程池隔离，Sentinel 会控制资源的线程数，超出的请求直接拒绝，直到堆积的线程处理完成，可以达到信号量隔离的效果。

我们看一下这种模式的效果。假设当前服务 A 依赖两个远程服务方法 sayHello(java.lang.String) 和 doAnother()。前者远程调用的响应时间为 1s-1.5s 之间，后者 RT 非常小（30 ms 左右）。服务 A 端设两个远程方法 thread count 为 5。然后每隔 50 ms 左右向线程池投入两个任务，作为消费者分别远程调用对应方法，持续 10 次。可以看到 sayHello 方法被限流 5 次，因为后面调用的时候前面的远程调用还未返回（RT 高）；而 doAnother() 调用则不受影响。线程数目超出时快速失败能够有效地防止自己被慢调用所影响。

服务降级

当服务依赖于多个下游服务，而某个下游服务调用非常慢时，会严重影响当前服务的调用。这里我们可以利用 Sentinel 熔断降级的功能，为调用端配置基于平均 RT 的降级规则。这样当调用链路中某个服务调用的平均 RT 升高，在一定的次数内超过配置的 RT 阈值，Sentinel 就会对此调用资源进行降级操作，接下来的调用都会立刻拒绝，直到过了一段设定的时间后才恢复，从而保护服务不被调用端短板所影响。同时可以配合 fallback 功能使用，在被降级的时候提供相应的处理逻辑。

Fallback

从 0.1.1 版本开始，Sentinel Dubbo Adapter 还支持配置全局的 fallback 函数，可以在 Dubbo 服务被限流/降级/负载保护的时候进行相应的 fallback 处理。用户只需要实现自定义的 DubboFallback 接口，并通过 DubboFallbackRegistry 注册即可。默认情况会直接将 BlockException 包装后抛出。同时，我们还可以配合 Dubbo 的 fallback 机制来为降级的服务提供替代的实现。

Sentinel 与 Hystrix 的比较

目前业界常用的熔断降级/隔离的库是 Netflix 的 Hystrix，那么 Sentinel 与 Hystrix 有什么异同呢？Hystrix 的关注点在于以隔离和熔断为主的容错机制，而 Sentinel 的侧重点在于多样化的流量控制、熔断降级、系统负载保护、实时监控和控制台，可以看到解决的问题还是有比较大的不同的。

Hystrix 采用命令模式封装资源调用逻辑，并且资源的定义与隔离规则是强依赖的，即在创建 HystrixCommand 的时候就要指定隔离规则（因其执行模型依赖于隔离模式）。Sentinel 的设计更为简单，不关注资源是如何执行的，资源的定义与规则的配置相分离。用户可以先定义好资源，然后在需要的时候配置规则即可。Sentinel 的原则非常简单：根据对应资源配置的规则来为资源执行相应的限流/降级/负载保护策略，若规则未配置则仅进行统计。从 0.1.1 版本开始，Sentinel 还引入了注解支持，可以更方便地定义资源。

隔离是 Hystrix 的核心功能。Hystrix 通过线程池或信号量的方式来对依赖（即 Sentinel 中对应的资源）进行隔离，其中最常用的是资源隔离。Hystrix 线程池隔离的好处是比较彻底，但是不足之处在于要开很多线程池，在应用本身线程数目比较多的时候上下文切换的 overhead 会非常大；Hystrix 的信号量隔离模式可以限制调用的并发数而不显式创建线程，这样的方式比较轻量级，但缺点是无法对慢调用自动进行降级，只能等待客户端自己超时，因此仍然可能会出现级联阻塞的情况。Sentinel 可以通过并发线程数模式的流量控制来提供信号量隔离的功能。并且结合基于响应时间的熔断降级模式，可以在不稳定资源的平均响应时间比较高的时候自动降级，防止过多的慢调用占满并发数，影响整个系统。

Hystrix 熔断降级功能采用熔断器模式，在某个服务失败比率高时自动进行熔断。Sentinel 的熔断降级功能更为通用，支持平均响应时间与失败比率两个指标。Sentinel 还提供各种调用链路关系和流量控制效果支持，同时还可以根据系统负载去实时地调整流量来保护系统，应用场景更为丰富。同时，Sentinel 还提供了实时的监控 API 和控制台，可以方便用户快速了解目前系统的状态，对服务的稳定性了如指掌。

更详细的对比请参见 Sentinel 与 Hystrix 的对比。

总结

以上介绍的只是 Sentinel 的一个最简单的场景 —— 限流。Sentinel 还可以处理更复杂的各种情况，比如超时熔断、冷启动、请求匀速等。可以参考 Sentinel 文档，更多的场景等待你去挖掘！

Blog: 使用Pinpoint做分布式跟踪

Thu, 12 Jul 2018 00:00:00 +0000

在使用Dubbo进行服务化或者整合应用后，假设某个服务后台日志显示有异常，这个服务又被多个应用调用的情况下，我们通常很难判断是哪个应用调用的，问题的起因是什么，因此我们需要一套分布式跟踪系统来快速定位问题，Pinpoint可以帮助我们快速定位问题（当然，解决方案也不止这一种）。

什么是Pinpoint

摘自Pinpoint学习笔记

Pinpoint是一个开源的 APM (Application Performance Management/应用性能管理)工具，用于基于java的大规模分布式系统。仿照Google Dapper，Pinpoint通过跟踪分布式应用之间的调用来提供解决方案，以帮助分析系统的总体结构和内部模块之间如何相互联系。

注：对于各个模块之间的通讯英文原文中用的是transaction一词，但是我觉得如果翻译为"事务"容易引起误解，所以替换为"交互"或者"调用"这种比较直白的字眼。

在使用上力图简单高效：

安装agent，不需要修改哪怕一行代码
最小化性能损失

服务器地图(ServerMap)

通过可视化分布式系统的模块和他们之间的相互联系来理解系统拓扑。点击某个节点会展示这个模块的详情，比如它当前的状态和请求数量。

实时活动线程图表(Realtime Active Thread Chart)

实时监控应用内部的活动线程。

请求/应答分布图表(Request/Response Scatter Chart)

长期可视化请求数量和应答模式来定位潜在问题。通过在图表上拉拽可以选择请求查看更多的详细信息。

调用栈(CallStack)

在分布式环境中为每个调用生成代码级别的可视图，在单个视图中定位瓶颈和失败点。

巡查(Inspector)

查看应用上的其他详细信息，比如CPU使用率，内存/垃圾回收，TPS，和JVM参数。

支持模块

JDK 6+
Tomcat 6/7/8, Jetty 8/9, JBoss EAP 6, Resin 4, Websphere 6/7/8, Vertx 3.3/3.4/3.5
Spring, Spring Boot (Embedded Tomcat, Jetty)
Apache HTTP Client 3.x/4.x, JDK HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient
Thrift Client, Thrift Service, DUBBO PROVIDER, DUBBO CONSUMER
ActiveMQ, RabbitMQ
MySQL, Oracle, MSSQL, CUBRID,POSTGRESQL, MARIA
Arcus, Memcached, Redis, CASSANDRA
iBATIS, MyBatis
DBCP, DBCP2, HIKARICP
gson, Jackson, Json Lib
log4j, Logback
自定义模块

Pinpoint与Dubbo的结合

启动Pinpoint

参考Pinpoint的Quick start搭建环境（不需要启动TestApp）

准备Dubbo示例程序

创建API包

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <groupId>com.example</groupId>
 <artifactId>demo-api</artifactId>
 <version>0.0.1-SNAPSHOT</version>
</project>

新建API接口：

package com.example.demoapi;

public interface HelloService {
 String sayHello(String name);
}

实现 Dubbo 服务提供方

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <groupId>com.example</groupId>
 <artifactId>demo-provider</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <packaging>jar</packaging>

 <name>demo-provider</name>

 <parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>2.0.3.RELEASE</version>
 <relativePath/> <!-- lookup parent from repository -->
 </parent>

 <properties>
 <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
 <java.version>1.8</java.version>
 </properties>

 <repositories>
 <repository>
 <id>sonatype-nexus-snapshots</id>
 <url>https://oss.sonatype.org/content/repositories/snapshots</url>
 <releases>
 <enabled>false</enabled>
 </releases>
 <snapshots>
 <enabled>true</enabled>
 </snapshots>
 </repository>
 </repositories>

 <dependencies>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter</artifactId>
 </dependency>
 <dependency>
 <groupId>com.alibaba.boot</groupId>
 <artifactId>dubbo-spring-boot-starter</artifactId>
 <version>0.2.0</version>
 </dependency>
 <dependency>
 <groupId>com.example</groupId>
 <artifactId>demo-api</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 </dependency>

 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-test</artifactId>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-maven-plugin</artifactId>
 </plugin>
 </plugins>
 </build>

</project>

实现 HelloService 接口：

package com.example.demoprovider.provider;

import com.alibaba.dubbo.config.annotation.Service;
import com.example.demoapi.HelloService;

@Service(version = "${demo.service.version}",
 application = "${dubbo.application.id}",
 protocol = "${dubbo.protocol.id}",
 registry = "${dubbo.registry.id}")
public class HelloServiceImpl implements HelloService {
 static int i = 0;
 @Override
 public String sayHello(String name) {
 i++;
 if (i % 3 == 0) {
 throw new RuntimeException("ex");
 }
 return "Hello " + name + "!";
 }
}

编写 Spring Boot 引导程序：

package com.example.demoprovider;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoProviderApplication {

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

配置 application.properties：

# Spring boot application
spring.application.name = dubbo-provider-demo
server.port = 9090
management.port = 9091

# Service version
demo.service.version = 1.0.0

# Base packages to scan Dubbo Components (e.g @Service , @Reference)
dubbo.scan.basePackages = com.example.demoprovider

# Dubbo Config properties
## ApplicationConfig Bean
dubbo.application.id = dubbo-provider-demo
dubbo.application.name = dubbo-provider-demo

## ProtocolConfig Bean
dubbo.protocol.id = dubbo
dubbo.protocol.name = dubbo
dubbo.protocol.port = 12345

## RegistryConfig Bean
dubbo.registry.id = my-registry
dubbo.registry.address = N/A

实现 Dubbo 服务消费方

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <groupId>com.example</groupId>
 <artifactId>demo-consumer</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 <packaging>jar</packaging>

 <name>demo-consumer</name>

 <parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>2.0.3.RELEASE</version>
 <relativePath/> <!-- lookup parent from repository -->
 </parent>

 <properties>
 <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
 <java.version>1.8</java.version>
 </properties>

 <repositories>
 <repository>
 <id>sonatype-nexus-snapshots</id>
 <url>https://oss.sonatype.org/content/repositories/snapshots</url>
 <releases>
 <enabled>false</enabled>
 </releases>
 <snapshots>
 <enabled>true</enabled>
 </snapshots>
 </repository>
 </repositories>

 <dependencies>
 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-web</artifactId>
 </dependency>
 <dependency>
 <groupId>com.alibaba.boot</groupId>
 <artifactId>dubbo-spring-boot-starter</artifactId>
 <version>0.2.0</version>
 </dependency>
 <dependency>
 <groupId>com.example</groupId>
 <artifactId>demo-api</artifactId>
 <version>0.0.1-SNAPSHOT</version>
 </dependency>

 <dependency>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-test</artifactId>
 <scope>test</scope>
 </dependency>
 </dependencies>

 <build>
 <plugins>
 <plugin>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-maven-plugin</artifactId>
 <configuration>
 <classifier>exec</classifier>
 </configuration>
 </plugin>
 </plugins>
 </build>

</project>

通过 @Reference 注入 HelloService

package com.example.democonsumer.controller;

import com.alibaba.dubbo.config.annotation.Reference;
import com.example.demoapi.HelloService;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class DemoConsumerController {
 @Reference(version = "${demo.service.version}",
 application = "${dubbo.application.id}",
 url = "dubbo://<注意，这里填写具体IP>:12345")
 private HelloService helloService;

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

直连提供者调用需要填写具体IP地址，如果写localhost也可以，但是会被Pinpoint额外识别为一个未知服务

编写 Spring Boot 引导程序（Web 应用）：

package com.example.democonsumer;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class DemoConsumerApplication {

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

配置 application.properties：

# Spring boot application
spring.application.name=dubbo-consumer-demo
server.port=8080
management.port=8081

# Service Version
demo.service.version=1.0.0

# Dubbo Config properties
## ApplicationConfig Bean
dubbo.application.id=dubbo-consumer-demo
dubbo.application.name=dubbo-consumer-demo

## ProtocolConfig Bean
dubbo.protocol.id=dubbo
dubbo.protocol.name=dubbo
dubbo.protocol.port=12345

使用Pinpoint-agent启动服务提供方和服务消费方

启动服务提供方

编译打包

mvn clean package

附加参数启动服务提供方

java -jar -javaagent:$AGENT_PATH/pinpoint-bootstrap-$VERSION.jar -Dpinpoint.agentId=demo-provider -Dpinpoint.applicationName=DP target/demo-provider-0.0.1-SNAPSHOT.jar

附加参数启动服务消费方

java -jar -javaagent:$AGENT_PATH/pinpoint-bootstrap-$VERSION.jar -Dpinpoint.agentId=demo-consumer -Dpinpoint.applicationName=DC target/demo-comsumer-0.0.1-SNAPSHOT-exec.jar

访问消费方地址模拟用户请求

http://localhost:8080/sayHello?name=ABC

使用Pinpoint快速定位问题

首页

这里的用户请求是请求DubboProvider数量的双倍，原因是记录了favicon.ico图标请求导致的

调用树

深入跟踪

其他

示例简单的模拟了Dubbo的提供和调用，并没有进行数据库等其他中间件的应用，详细使用请参照Pinpoint文档。

Blog: 在 Dubbo 中使用 Zipkin

Sun, 17 Jun 2018 00:00:00 +0000

随着业务的发展，应用的规模不断的扩大，传统的应用架构无法满足诉求，服务化架构改造势在必行，以 Dubbo 为代表的分布式服务框架成为了服务化改造架构中的基石。随着微服务理念逐渐被大众接受，应用进一步向更细粒度拆分，并且，不同的应用由不同的开发团队独立负责，整个分布式系统变得十分复杂。没有人能够清晰及时的知道当前系统整体的依赖关系。当出现问题时，也无法及时知道具体是链路上的哪个环节出了问题。

在这个背景下，Google 发表了 Dapper 的论文，描述了如何通过一个分布式追踪系统解决上述问题。基于该论文，各大互联网公司实现并部署了自己的分布式追踪系统，其中比较出名的有阿里巴巴的 EagleEye。本文中提到的 Zipkin 是 Twitter 公司开源的分布式追踪系统。下面会详细介绍如何在 Dubbo 中使用 Zipkin 来实现分布式追踪。

Zipkin 简介

Zipkin 是基于 Dapper 论文实现，由 Twitter 开源的分布式追踪系统，通过收集分布式服务执行时间的信息来达到追踪服务调用链路、以及分析服务执行延迟等目的。

Zipkin 架构

Collector 收集器、Storage 存储、API、UI 用户界面等几部分构成了 Zipkin Server 部分，对应于 GitHub 上 openzipkin/zipkin 这个项目。而收集应用中调用的耗时信息并将其上报的组件与应用共生，并拥有各个语言的实现版本，其中 Java 的实现是 GitHub 上 openzipkin/brave。除了 Java 客户端实现之外，openzipkin 还提供了许多其他语言的实现，其中包括了 go、php、JavaScript、.net、ruby 等，具体列表可以参阅 Zipkin 的 Exiting instrumentations。

Zipkin 的工作过程

当用户发起一次调用时，Zipkin 的客户端会在入口处为整条调用链路生成一个全局唯一的 trace id，并为这条链路中的每一次分布式调用生成一个 span id。span 与 span 之间可以有父子嵌套关系，代表分布式调用中的上下游关系。span 和 span 之间可以是兄弟关系，代表当前调用下的两次子调用。一个 trace 由一组 span 组成，可以看成是由 trace 为根节点，span 为若干个子节点的一棵树。

Span 由调用边界来分隔，在 Zipkin 中，调用边界由以下四个 annotation 来表示：

cs - Clent Sent 客户端发送了请求
sr - Server Receive 服务端接受到请求
ss - Server Send 服务端处理完毕，向客户端发送回应
cr - Client Receive 客户端收到结果

显然，通过这四个 annotation 上的时间戳，可以轻易的知道一次完整的调用在不同阶段的耗时，比如：

sr - cs 代表了请求在网络上的耗时
ss - sr 代表了服务端处理请求的耗时
cr - ss 代表了回应在网络上的耗时
cr - cs 代表了一次调用的整体耗时

Zipkin 会将 trace 相关的信息在调用链路上传递，并在每个调用边界结束时异步的把当前调用的耗时信息上报给 Zipkin Server。Zipkin Server 在收到 trace 信息后，将其存储起来，Zipkin 支持的存储类型有 inMemory、MySql、Cassandra、以及 ElasticsSearch 几种方式。随后 Zipkin 的 Web UI 会通过 API 访问的方式从存储中将 trace 信息提取出来分析并展示，如下图所示：

在 Dubbo 中使用

由于 Brave 对 Dubbo 已经主动做了支持，在 Dubbo 中集成基于 Zipkin 的链路追踪变的十分简单。下面会按照 Brave 中关于 Dubbo RPC 支持的指引来说明如何在 Dubbo 中使用 Zipkin。

安装 Zipkin Server

按照 Zipkin 官方文档中的快速开始来安装 Zipkin，如下所示：

$ curl -sSL https://zipkin.io/quickstart.sh | bash -s
$ java -jar zipkin.jar

按照这种方式安装的 Zipkin Server 使用的存储类型是 inMemory 的。当服务器停机之后，所有收集到的 trace 信息会丢失，不适用于生产系统。如果在生产系统中使用，需要配置另外的存储类型。Zipkin 支持 MySql、Cassandra、和 ElasticSearch。推荐使用 Cassandra 和 ElasticSearch，相关的配置请自行查阅官方文档。

本文为了演示方便，使用的存储是 inMemory 类型。成功启动之后，可以在终端看到如下的提示：

$ java -jar zipkin.jar
Picked up JAVA_TOOL_OPTIONS: -Djava.awt.headless=true
 ********
 ** **
 * *
 ** **
 ** **
 ** **
 ** **
 ********
 ****
 ****
 **** ****
 ****** **** ***
 ****************************************************************************
 ******* **** ***
 **** ****
 **
 **


 ***** ** ***** ** ** ** ** **
 ** ** ** * *** ** **** **
 ** ** ***** **** ** ** ***
 ****** ** ** ** ** ** ** **

:: Powered by Spring Boot :: (v2.0.5.RELEASE)

...

o.s.b.w.e.u.UndertowServletWebServer : Undertow started on port(s) 9411 (http) with context path ''
2018-10-10 18:40:31.605 INFO 21072 --- [ main] z.s.ZipkinServer : Started ZipkinServer in 6.835 seconds (JVM running for 8.35)

然后在浏览器中访问 http://localhost:9411 验证 WEB 界面。

配置 Maven 依赖

引入 Brave 依赖

新建一个新的 Java 工程，并在 pom.xml 中引入 Brave 相关的依赖如下：

 <properties>
 <brave.version>5.4.2</brave.version>
 <zipkin-reporter.version>2.7.9</zipkin-reporter.version>
 </properties>

 <dependencyManagement>
 <dependencies>
 <!-- 引入 zipkin brave 的 BOM 文件 -->
 <dependency>
 <groupId>io.zipkin.brave</groupId>
 <artifactId>brave-bom</artifactId>
 <version>${brave.version}</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>

 <!-- 引入 zipkin repoter 的 BOM 文件 -->
 <dependency>
 <groupId>io.zipkin.reporter2</groupId>
 <artifactId>zipkin-reporter-bom</artifactId>
 <version>${zipkin-reporter.version}</version>
 <type>pom</type>
 <scope>import</scope>
 </dependency>
 </dependencies>
 </dependencyManagement>

 <dependencies>
 <!-- 1. brave 对 dubbo 的集成 -->
 <dependency>
 <groupId>io.zipkin.brave</groupId>
 <artifactId>brave-instrumentation-dubbo-rpc</artifactId>
 </dependency>

 <!-- 2. brave 的 spring bean 支持 -->
 <dependency>
 <groupId>io.zipkin.brave</groupId>
 <artifactId>brave-spring-beans</artifactId>
 </dependency>

 <!-- 3. 在 SLF4J 的 MDC (Mapped Diagnostic Context) 中支持 traceId 和 spanId -->
 <dependency>
 <groupId>io.zipkin.brave</groupId>
 <artifactId>brave-context-slf4j</artifactId>
 </dependency>

 <!-- 4. 使用 okhttp3 作为 reporter -->
 <dependency>
 <groupId>io.zipkin.reporter2</groupId>
 <artifactId>zipkin-sender-okhttp3</artifactId>
 </dependency>
 </dependencies>

其中：

引入 brave-instrumentation-dubbo-rpc，brave 对 dubbo 的支持：https://github.com/openzipkin/brave/blob/master/instrumentation/dubbo-rpc/README.md
引入 brave-spring-beans，brave 对 spring bean 的支持：https://github.com/openzipkin/brave/blob/master/spring-beans/README.md
引入 brave-context-slf4j，brave 对 SLF4J 的支持，可以在 MDC 中使用 traceId 和 spanId：https://github.com/openzipkin/brave/blob/master/context/slf4j/README.md
引入 zipkin-sender-okhttp3，使用 okhttp3 上报数据：https://github.com/openzipkin/zipkin-reporter-java

引入 Dubbo 相关依赖

Dubbo 相关的依赖是 Dubbo 本身以及 Zookeeper 客户端，在下面的例子中，我们将会使用独立的 Zookeeper Server 作为服务发现。

 <dependencies>
 <!-- 1. Zookeeper 客户端依赖 -->
 <dependency>
 <groupId>org.apache.curator</groupId>
 <artifactId>curator-framework</artifactId>
 <version>2.12.0</version>
 <exclusions>
 <exclusion>
 <groupId>io.netty</groupId>
 <artifactId>netty</artifactId>
 </exclusion>
 </exclusions>
 </dependency>
 <!-- 2. Dubbo 依赖 -->
 <dependency>
 <groupId>com.alibaba</groupId>
 <artifactId>dubbo</artifactId>
 <version>2.6.2</version>
 </dependency>
 </dependencies>

其中：

Dubbo 这里依赖独立的 Zookeeper Server 做服务发现，这里使用的客户端是 Curator
引入 Dubbo 框架的依赖，原则上 2.6 的任何版本都是工作的，这里使用的是 2.6.2 版本

实现

我们这里构造的场景是一个有两个节点的服务依赖链，也就是，当一个 Dubbo 客户端调用服务 A 时，服务 A 将会继续调用服务 B。在这个例子中，服务 A 是 greeting service，它所依赖的下游服务服务 B 是 hello service。

定义服务接口

为此需要事先定义两个服务接口 GreetingService 以及 HelloService

com.alibaba.dubbo.samples.api.GreetingService

package com.alibaba.dubbo.samples.api;

public interface GreetingService {
 String greeting(String message);
}

com.alibaba.dubbo.samples.api.HelloService

package com.alibaba.dubbo.samples.api;

public interface HelloService {
 String hello(String message);
}

实现服务接口

为了区分对待，所有和 HelloService 相关的实现代码都放在 hello 子包下，同理 GreetingService 相关的放在 greeting 子包下。

实现 com.alibaba.dubbo.samples.api.HelloService

package com.alibaba.dubbo.samples.service.hello;

import com.alibaba.dubbo.samples.api.HelloService;

import java.util.Random;

public class HelloServiceImpl implements HelloService {
 @Override
 public String hello(String message) {
 try {
 // 通过 sleep 模拟业务逻辑处理时间
 Thread.sleep(new Random(System.currentTimeMillis()).nextInt(1000));
 } catch (InterruptedException e) {
 // no op
 }
 return "hello, " + message;
 }
}

实现 com.alibaba.dubbo.samples.api.GreetingService
```
package com.alibaba.dubbo.samples.service.greeting;

import com.alibaba.dubbo.samples.api.GreetingService;
import com.alibaba.dubbo.samples.api.HelloService;

import java.util.Random;

public class GreetingServiceImpl implements GreetingService {
 // 下游依赖服务，运行时靠 spring 容器注入 HelloService 的服务代理
 private HelloService helloService;

 public void setHelloService(HelloService helloService) {
 this.helloService = helloService;
 }

 @Override
 public String greeting(String message) {
 try {
 // 通过 sleep 模拟业务逻辑处理时间
 Thread.sleep(new Random(System.currentTimeMillis()).nextInt(1000));
 } catch (InterruptedException e) {
 // no op
 }
 return "greeting, " + helloService.hello(message);
 }
}
```
这里需要注意的是，GreetingServiceImpl 的实现中声明了一个类型是 HelloService 的成员变量，并在 greeting 方法中，执行完自己逻辑之后又调用了 HelloService 上的 hello 方法。这里的 helloService 的实现将会在运行态由外部注入，注入的不是 HelloServiceImpl 的实现，而是 HelloService 的远程调用代理。通过这样的方式，完成了在一个 Dubbo 服务中继续调用另一个远程 Dubbo 服务的目的。从链路追踪的角度来说，客户端调用 GreetingService 是一个 span，GreetingService 调用 HelloService 是另一个 span，并且两者有父子关系，同属于一个 trace，也就是属于同一条调用链路。

另外，在 GreetingServiceImpl 和 HelloServiceImpl 的实现中，通过 Thread.sleep 来模拟了处理业务逻辑的耗时，以便在 Zipkin UI 上更好的展示。

配置

为了专注在展示如何使用 Zipkin 这一点上，本文在配置和编程模型上没有采用更多的高级技术，而是使用了最传统的 Spring XML 的配置方式，帮助读者理解。更高级的通过 annotation 甚至 spring boot 的方式，读者可以自行查阅 Dubbo 和 Zipkin 相关的文档。

暴露 HelloService 服务

在 resouces/spring/hello-service.xml 中增加以下的配置来将 HelloServiceImpl 暴露成一个 Dubbo 服务：

使用了本地启动的 Zookeeper Server 作为注册中心，地址为默认值 zookeeper://127.0.0.1:2181
用 Dubbo 原生服务在端口 20880 上暴露服务
将 HelloServiceImpl 注册成 id 是 helloService 的 Spring Bean，这样就可以在后续的 <dubbo:service> 中引用到这个实现类
通过 <dubbo:service> 将 HelloServiceImpl 暴露成 Dubbo 服务

 <!-- 定义 HelloService 的应用名 -->
 <dubbo:application name="hello-service-provider"/>

 <!-- 指定注册中心地址 -->
 <dubbo:registry address="zookeeper://127.0.0.1:2181"/>

 <!-- 使用 Dubbo 原生协议在 20880 端口上暴露服务 -->
 <dubbo:protocol name="dubbo" port="20880"/>

 <!-- 将 HelloServiceImpl 的实现声明成一个 spring bean -->
 <bean id="helloService" class="com.alibaba.dubbo.samples.service.hello.HelloServiceImpl"/>

 <!-- 将 HelloServiceImpl 声明成一个 Dubbo 服务 -->
 <dubbo:service interface="com.alibaba.dubbo.samples.api.HelloService" ref="helloService"/>

增加 Zipkin 相关的配置

在 resources/spring/hello-service.xml 中增加 Zipkin 相关的配置：

修改 dubbo 服务暴露的配置，添加 Zipkin 的 tracing filter 到 Dubbo 的 filter chain 中
按照 https://github.com/openzipkin/brave/blob/master/spring-beans/README.md 来配置 Zipkin 的 sender 和 tracing 的 spring bean

 <!-- 1. 修改 dubbo 服务暴露配置，在 filter chain 中增加 zipkin 的 tracing 过滤器 -->
 <dubbo:service interface="com.alibaba.dubbo.samples.api.HelloService" ref="helloService" filter="tracing"/>

 <!-- 2. zipkin 相关的配置 -->
 <!-- 使用 OKHttp 来发送 trace 信息到 Zipkin Server。这里的 Zipkin Server 启动在本地 -->
 <bean id="sender" class="zipkin2.reporter.beans.OkHttpSenderFactoryBean">
 <property name="endpoint" value="http://localhost:9411/api/v2/spans"/>
 </bean>

 <bean id="tracing" class="brave.spring.beans.TracingFactoryBean">
 <property name="localServiceName" value="hello-service"/>
 <property name="spanReporter">
 <bean class="zipkin2.reporter.beans.AsyncReporterFactoryBean">
 <property name="sender" ref="sender"/>
 <!-- wait up to half a second for any in-flight spans on close -->
 <property name="closeTimeout" value="500"/>
 </bean>
 </property>
 <property name="currentTraceContext">
 <bean class="brave.spring.beans.CurrentTraceContextFactoryBean">
 <property name="scopeDecorators">
 <bean class="brave.context.slf4j.MDCScopeDecorator" factory-method="create"/>
 </property>
 </bean>
 </property>
 </bean>

增加 HelloService 的启动类

在 com.alibaba.dubbo.samples.service.hello.Application 中通过 ClassPathXmlApplicationContext 读取刚才配置的 spring/hello-service.xml 来初始化一个 spring context 并启动

package com.alibaba.dubbo.samples.service.hello;

import org.springframework.context.support.ClassPathXmlApplicationContext;

import java.io.IOException;

public class Application {
 public static void main(String[] args) throws IOException {
 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring/hello-service.xml");
 context.start();

 System.out.println("Hello service started");
 // press any key to exit
 System.in.read();
 }
}

暴露 GreetingService 服务，并使用 Zipkin

在 resources/spring/greeting-service.xml 中配置 GreetingService。相关步骤与 HelloService 类似，不再赘述，重点关注如何在 GreetingService 中配置下游服务的依赖。完整的 XML 配置如下：

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:dubbo="http://dubbo.apache.org/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.xsd
 http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

 <!-- 1. 定义 GreetingService 的应用名 -->
 <dubbo:application name="greeting-service-provider"/>

 <!-- 2. 指定注册中心地址 -->
 <dubbo:registry address="zookeeper://127.0.0.1:2181"/>

 <!-- 3. 使用 Dubbo 原生协议在 20881 端口上暴露服务 -->
 <dubbo:protocol name="dubbo" port="20881"/>

 <!-- 4. 声明 HelloService 的远程代理，并在 Dubbo 的 filter chain 中增加 tracing filter -->
 <dubbo:reference id="helloService" check="false" interface="com.alibaba.dubbo.samples.api.HelloService" filter="tracing"/>

 <!-- 5. 将 GreetingServiceImpl 的实现声明成一个 spring bean，并将 HelloService 的远程代理装配进去 -->
 <bean id="greetingService" class="com.alibaba.dubbo.samples.service.greeting.GreetingServiceImpl">
 <property name="helloService" ref="helloService"/>
 </bean>

 <!-- 6. 将 GreetingServiceImpl 声明成一个 Dubbo 服务，并在 Dubbo 的 filter chain 中增加 tracing filter -->
 <dubbo:service interface="com.alibaba.dubbo.samples.api.GreetingService" ref="greetingService" filter="tracing"/>

 <!-- 7. zipkin 相关的配置 -->
 <bean id="sender" class="zipkin2.reporter.beans.OkHttpSenderFactoryBean">
 <property name="endpoint" value="http://localhost:9411/api/v2/spans"/>
 </bean>

 <bean id="tracing" class="brave.spring.beans.TracingFactoryBean">
 <property name="localServiceName" value="greeting-service"/>
 <property name="spanReporter">
 <bean class="zipkin2.reporter.beans.AsyncReporterFactoryBean">
 <property name="sender" ref="sender"/>
 <!-- wait up to half a second for any in-flight spans on close -->
 <property name="closeTimeout" value="500"/>
 </bean>
 </property>
 <property name="currentTraceContext">
 <bean class="brave.spring.beans.CurrentTraceContextFactoryBean">
 <property name="scopeDecorators">
 <bean class="brave.context.slf4j.MDCScopeDecorator" factory-method="create"/>
 </property>
 </bean>
 </property>
 </bean>
</beans>

这里的配置与上面的 HelloService 类似，需要重点关注的有两点：

第 3 步中注意服务需要暴露在不同的端口上，否则会和 HelloService 冲突，本例中选择的是 20881 这个端口
通过第 4 步先声明 HelloService 的远程代理，然后在第 5 步中将其组装给 GreetingService 来完成服务上下游依赖的声明

增加 GreeeingService 的启动类，与 HelloService 类似，通过 spring/greeting-service.xml 的配置来初始化一个新的 spring context 来完成。

package com.alibaba.dubbo.samples.service.greeting;

import org.springframework.context.support.ClassPathXmlApplicationContext;

import java.io.IOException;

public class Application {
 public static void main(String[] args) throws IOException {
 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring/greeting-service.xml");
 context.start();

 System.out.println("Greeting service started");
 // press any key to exit
 System.in.read();
 }
}

实现客户端

通过 resources/spring/client.xml 初始化一个 spring context，从其中获取 GreetingService 的远程代理，发起远程调用。

package com.alibaba.dubbo.samples.client;

import com.alibaba.dubbo.samples.api.GreetingService;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Application {

 public static void main(String[] args) {
 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring/client.xml");
 context.start();
 // 获取远程代理并发起调用
 GreetingService greetingService = (GreetingService) context.getBean("greetingService");
 System.out.println(greetingService.greeting("world"));
 }
}

resource/spring/client.xml 中的配置与 Dubbo 服务的配置类似，主要是配置远程代理，以及配置 Zipkin

<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:dubbo="http://dubbo.apache.org/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.xsd
 http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">

 <!-- 1. 定义 dubbo 客户端的应用名 -->
 <dubbo:application name="dubbo-client"/>

 <!-- 2. 指定注册中心地址 -->
 <dubbo:registry address="zookeeper://127.0.0.1:2181"/>

 <!-- 3. 声明 GreetingService 的远程代理，并在 Dubbo 的 filter chain 中增加 tracing filter -->
 <dubbo:reference id="greetingService" check="false" interface="com.alibaba.dubbo.samples.api.GreetingService" filter="tracing"/>

 <!-- 4. zipkin 相关的配置 -->
 <bean id="sender" class="zipkin2.reporter.beans.OkHttpSenderFactoryBean">
 <property name="endpoint" value="http://localhost:9411/api/v2/spans"/>
 </bean>

 <bean id="tracing" class="brave.spring.beans.TracingFactoryBean">
 <property name="localServiceName" value="client"/>
 <property name="spanReporter">
 <bean class="zipkin2.reporter.beans.AsyncReporterFactoryBean">
 <property name="sender" ref="sender"/>
 <!-- wait up to half a second for any in-flight spans on close -->
 <property name="closeTimeout" value="500"/>
 </bean>
 </property>
 <property name="currentTraceContext">
 <bean class="brave.spring.beans.CurrentTraceContextFactoryBean">
 <property name="scopeDecorators">
 <bean class="brave.context.slf4j.MDCScopeDecorator" factory-method="create"/>
 </property>
 </bean>
 </property>
 </bean>
</beans>

完成之后的工程的目录结构如下：

运行

现在让我们把整个链路运行起来，看看 Zipkin 链路追踪的效果。

启动 Zookeeper Server

执行以下命令在本地启动一个 Zookeeper Server，如果没有安装，请自行从 ZooKeeper 官网下载：

$ zkServer start

启动 Zipkin Server

执行以下命令在本地启动一个 Zipkin Server：

$ curl -sSL https://zipkin.io/quickstart.sh | bash -s
$ java -jar zipkin.jar

启动 HelloService

使用下面的命令启动 HelloService，当然也可以直接在 IDE 中启动：

$ mvn exec:java -Dexec.mainClass=com.alibaba.dubbo.samples.service.hello.Application

启动成功后应该可以在终端上看到 “Hello service started” 的字样。

启动 GreetingService

使用下面的命令启动 GreetingService，当然也可以直接在 IDE 中启动：

$ mvn exec:java -Dexec.mainClass=com.alibaba.dubbo.samples.service.greeting.Application

启动成功后应该可以在终端上看到 “Greeting service started” 的字样。

运行 Dubbo 客户端

使用下面的命令运行 Dubbo 客户端向 GreetingService 发起远程调用，当然也可以直接在 IDE 中运行：

$ mvn exec:java -Dexec.mainClass=com.alibaba.dubbo.samples.client.Application

执行成功后，客户端会在终端上输出 “greeting, hello, world”。

链路追踪

打开浏览器访问 “http://localhost:9411” 并通过 “Find Traces” 按钮来搜索，可以找到刚刚调用的链路追踪，效果如下图所示：

还可以进一步的选择每一个 span 来查看本次调用边界内的详情，比如，hello-service 这个 span 的详情如下：

总结

本文介绍了链路追踪的基本概念以及 Zipkin 的基本用法，然后用 Dubbo 构建了一条最简单的调用链路，并引入了 Zipkin 做全链路追踪。由于 Zipkin 对 Dubbo 做了很好的支持，整个集成的过程还是十分简单明了的。

Zipkin 对 Dubbo 的支持是构建在 Dubbo 的 filter 扩展机制上的，有兴趣的读者可以通过 https://github.com/openzipkin/brave/blob/master/instrumentation/dubbo-rpc/src/main/java/brave/dubbo/rpc/TracingFilter.java 了解其实现细节。

本文中涉及的例子可以从 https://github.com/dubbo/dubbo-samples 中的 “dubbo-samples-zipkin” 子模块中获取。另外，spring-cloud-sleth 2.0 中开始正式支持 Dubbo，相关的文章和例子后续计划提供。