生态集成 on Apache Dubbo

使用 Apache APISIX 代理 Dubbo 服务（triple协议）

Mon, 22 Apr 2024 00:00:00 +0000

关于如何用网关代理 triple 协议服务的原理介绍，请参见 HTTP 网关接入一节文档。

本文我们使用 Apache APISIX + triple 协议 + Nacos 注册中心 的组合，演示如何使用 Apache APISIX 代理 Dubbo 服务。

示例应用说明

本示例完整源码与部署资源文件可查看 dubbo-samples-gateway-triple-apisix，示例架构图如下：

在该示例中定义并发布了一个 org.apache.dubbo.samples.gateway.apisix.DemoService 的 triple 服务，接口定义为：

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

接口实现如下：

@DubboService
public class DemoServiceImpl implements DemoService {
 @Override
 public String sayHello(String name) {
 return "Hello " + name;
 }
}

Dubbo服务相关配置：

dubbo:
 application:
 name: gateway-apisix-triple
 registry:
 address: nacos://${nacos.address:127.0.0.1}:8848
 username: nacos
 password: nacos
 protocol:
 name: tri
 port: 50052

部署应用

在本地下载并启动 Nacos
运行以下命令，启动 Dubbo 应用。

使用 Apache APISIX 代理 Dubbo 服务 (dubbo 协议)

Thu, 25 Apr 2024 00:00:00 +0000

注意

本文仅适用于 dubbo 协议通信场景。如果您是 Dubbo3 用户，建议您使用 triple 协议，可参见使用 Apache APISIX 代理 Dubbo 服务（triple协议）学习具体示例。

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

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

入门篇

安装 APISIX

本文档使用 Docker 安装 APISIX。确保本地先安装 Docker 和 Docker Compose。

首先，下载 apisix-docker 仓库。

$ git clone https://github.com/apache/apisix-docker.git
$ cd apisix-docker/example

由于本示例要接入到 Nacos 注册中心，因此 apisix-docker/example 目录下安装用的 docker-compose.yaml，添加如下内容：

 nacos:
 image: nacos/nacos-server:v2.1.1
 container_name: nacos-standalone
 environment:
 - PREFER_HOST_MODE=hostname
 - MODE=standalone
 ports:
 - "8848:8848"
 - "9848:9848"
 networks:
 apisix:

在 config.yaml 文件中增加 nacos 注册中心配置：

如何通过 Higress 网关代理 Dubbo 服务

Mon, 01 Apr 2024 00:00:00 +0000

注意

本文仅适用于 dubbo 协议通信场景。如果您是 Dubbo3 用户，建议您使用 triple 协议，具体可参见使用 Apache APISIX 代理 Dubbo 服务（triple协议）学习具体示例。

Higress提供了从HTTP协议到Dubbo协议进行转换的功能，用户通过配置协议转换，可以将一个Dubbo服务以HTTP接口暴露出来，从而用HTTP请求实现对Dubbo接口的调用。本文将通过一个示例来介绍如何用Higress配置HTTP到Dubbo的协议转换。该示例会引导您轻松地部署一个Nacos server和一个Dubbo服务，然后通过Ingress将HTTP请求转发到注册在Nacos上的Dubbo服务，并通过Higress的协议转换能力完成对Dubbo服务的HTTP调用。

以下是一个使用 Higress + dubbo协议 + Nacos注册中心 的完整示例：dubbo-samples-gateway-higress-dubbo。

前提条件

已安装Higress，并开启了对Istio CRD的支持，参考Higress安装部署文档。

部署Nacos和Dubbo服务

首先在K8s集群中apply以下资源，以部署一个Nacos注册中心，同时通过K8s service将这个Nacos server暴露出来。

# Nacos Server配置
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nacos-server
spec:
 replicas: 1
 selector:
 matchLabels:
 app: nacos-server
 template:
 metadata:
 labels:
 app: nacos-server
 spec:
 containers:
 - env:
 - name: MODE
 value: standalone
 image: nacos/nacos-server:v2.2.0
 imagePullPolicy: Always
 name: nacos-server
 ports:
 - containerPort: 8848
 name: server
 dnsPolicy: ClusterFirst
 restartPolicy: Always

# Nacos Server Service配置
---
apiVersion: v1
kind: Service
metadata:
 name: nacos-server
spec:
 ports:
 - port: 8848
 name: server
 protocol: TCP
 targetPort: 8848
 selector:
 app: nacos-server
 type: ClusterIP

在 K8s 集群中 apply 以下资源，以部署一个Dubbo服务，该 Dubbo 服务将注册到上述的 Naocs 中（你可以选择重新打包，我们接下来直接使用社区提前准备好的镜像包）。

微服务最佳实践，零改造实现 Spring Cloud & Apache Dubbo 互通

Sat, 07 Oct 2023 00:00:00 +0000

本文以实际项目和代码为示例，一步一步演示如何以最低成本实现 Apache Dubbo 体系与 Spring Cloud 体系的互通，进而实现不同微服务体系的混合部署、迁移等，帮助您解决实际架构及业务问题。

背景与目标

如果你在微服务开发过程中正面临以下一些业务场景需要解决，那么这篇文章可以帮到您：

您已经有一套基于 Dubbo 构建的微服务应用，这时你需要将部分服务通过 REST HTTP 的形式（非接口、方法模式）发布出去，供一些标准的 HTTP 端调用（如 Spring Cloud 客户端），整个过程最好是不用改代码，直接为写好的 Dubbo 服务加一些配置、注解就能实现。
您已经有一套基于 Spring Cloud 构建的微服务体系，而后又构建了一套 Dubbo 体系的微服务，你想两套体系共存，因此现在两边都需要调用到对方发布的服务。也就是 Dubbo 应用作为消费方要调用到 Spring Cloud 发布的 HTTP 接口，Dubbo 应用作为提供方还能发布 HTTP 接口给 Spring Cloud 调用
出于一些历史原因，你正规划从一个微服务体系迁移到另外一个微服务体系，前提条件是要保证中间过程的平滑迁移。

对于以上几个场景，我们都可以借助 Dubbo3 内置的 REST 编程范式支持实现，这让 Dubbo 既可以作为消费方调用 HTTP 接口的服务，又可以作为提供方对外发布 REST 风格的 HTTP 服务，同时整个编码过程支持业界常用的 REST 编程范式（如 JAX-RS、Spring MVC 等），因此可以做到基本不改动任何代码的情况下实现 Dubbo 与 Spring Cloud 体系的互相调用。

关于这一部分更多的设计与理论阐述请参见这里的博客文章。
关于 Dubbo REST 的更多配置方式请参见 rest 使用参考手册

示例一：Dubbo 调用 Spring Cloud

在已经有一套 Spring Cloud 微服务体系的情况下，演示如何使用 Dubbo 调用 Spring Cloud 服务（包含自动的地址发现与协议传输）。在注册中心方面，本示例使用 Nacos 作为注册中心，对于 Zookeeper、Consul 等两种体系都支持的注册中心同样适用。

走向 Native 化：Spring&Dubbo AOT 技术示例与原理讲解

Wed, 28 Jun 2023 00:00:00 +0000

Java 应用在云计算时代面临“冷启动”慢、内存占用高、预热时间长等问题，无法很好的适应 Serverless 等云上部署模式，GraalVM 通过静态编译、打包等技术在很大程度上解决了这些问题，同时针对 GraalVM 的一些使用限制，Spring 和 Dubbo 等主流框架也都提供了相应的 AOT 解决方案。

本文我们将详细分析 Java 应用在云时代面临的挑战，GraalVM Native Image 是如何解决这些问题，GraalVM 的基本概念与工作原理，最后我们通过一个 Spring6 + Dubbo3 的微服务应用示例演示了如何将一个普通微服务应用进行静态化打包。

本文主要分为以下四个部分展开

首先我们会先看一下在云计算快速发展的当下，云上应用应该具备的特点，Java 应用在云上所面临的挑战有哪些。
其次，我会介绍一下 GraalVM，什么是 Native Image，如何通过 GraalVM 对 Java 应用进行静态化打出 Native Image 可执行的二进制程序。
第三部分，我们知道 GraalVM 的使用是有一定限制的，比如 Java 的反射等动态特性是不被支持的，因此我们需要提供特殊的 Metadata 配置来绕过这些限制，在这一部分我们会讲解如何加入引入 AOT Processing 来实现自动化的 Metadata 配置，包括 Spring6 框架中 AOT 处理、Dubbo3 框架的 AOT 处理等。
最后，我们将通过一个 Spring6+Dubbo3 的应用示例，来演示如何将这么一个 Java 应用进行静态化打包。

Java 应用在云时代所面临的挑战

首先，我们先看一下云计算时代的应用特点，以及 Java 在云时代所面临的挑战。从各个统计机构给出的数据来看，Java 语言仍然是当今最受开发者欢迎的编程语言之一，仅次于一些脚本开发语言。使用 Java 语言可以非常高效的开发业务应用，丰富的生态使得 Java 具有非常高的开发和运行效率，有无数的应用基于 Java 语言开发。

如何通过 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服务定义如下：

使用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）共提供两种部署模式：单节点模式和集群模式，以下为单节点模式部署步骤，集群模式部署详情参考文档。

当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

如何使用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 分布式事务解决方案

新版 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环境以及编写消费端代码。

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节点。

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 注册中心。

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"的调用里。

从跨语言调用到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 完成协议的适配

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

在 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 容器中

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 控制台了。

限流必备 - 监控管理

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

使用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 中使用 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 为若干个子节点的一棵树。