Dubbo

本文是基于 maven的，预先使用，先装 maven。 d ubbo是一个分布式服务框架，提供一个 SOA的解决方案。简单的说， dubbo就像在生产者和消费者中间架起了一座桥梁，使之能透明交互。 本文旨在搭建一个可供使用和 测试 的 dubbo环境，使用了 spring 框架；使用了 zookeeper和 dubbo服务。 准备： zookeeper：直接去官方网站下载即可，下载后解压，不需要改任何配置即可使用。 dubbo：直接去阿里巴巴下载即可，下载后解压并放到 tomcat的 webapps目录下，修改 WEB-INF/dubbo.properties中属性如下： #zookeeper的地址和端口 dubbo.registry.address=zookeeper://127.0.0.1:2181 #登录 dubbo管理页面时的 root用户和 guest用户的密码 dubbo.admin.root.password=root dubbo.admin.guest.password=guest 代码： 如果你清楚生产者 -消费者模型，那么将会很容易理解 dubbo的使用步骤。 一个生产者 -消费者模型的代码实现需要 3部分：生产者代码，消费者代码，中间接口。 中间接口 ：创建一个 mavan项目，然后添加一个接口如下： publicinterface ITest {

3 月，跳不动了？>>> 1. 简介 在上一篇文章中，我详细的分析了服务导出的原理。本篇文章我们趁热打铁，继续分析服务引用的原理。在 Dubbo 中，我们可以通过两种方式引用远程服务。第一种是使用服务直联的方式引用服务，第二种方式是基于注册中心进行引用。服务直联的方式仅适合在调试或测试服务的场景下使用，不适合在线上环境使用。因此，本文我将重点分析通过注册中心引用服务的过程。从注册中心中获取服务配置只是服务引用过程中的一环，除此之外，服务消费者还需要经历 Invoker 创建、代理类创建等步骤。这些步骤，我将在后续章节中一一进行分析。在此我向大家推荐一个架构学习交流裙。交流学习裙号：821169538 2.服务引用原理 Dubbo 服务引用的时机有两个，第一个是在 Spring 容器调用 ReferenceBean 的 afterPropertiesSet 方法时引用服务，第二个是在 ReferenceBean 对应的服务被注入到其他类中时引用。这两个引用服务的时机区别在于，第一个是饿汉式的，第二个是懒汉式的。默认情况下，Dubbo 使用懒汉式引用服务。如果需要使用饿汉式，可通过配置 <dubbo:reference> 的 init 属性开启。下面我们按照 Dubbo 默认配置进行分析，整个分析过程从 ReferenceBean 的 getObject 方法开始

3 月，跳不动了？>>> 在上篇文章中，我们了解了dubbo服务引用的启动阶段所做的事情，还有远程调用阶段没有看。Dubbo 服务调用过程比较复杂，包含众多步骤，比如发送请求、编解码、服务降级、过滤器链处理、序列化、线程派发以及响应请求等步骤。限于篇幅原因，本篇文章无法对所有的步骤一一进行分析。本篇文章将会重点分析请求的发送与接收、编解码、线程派发以及响应的发送与接收等过程，至于服务降级、过滤器链和序列化大家自行进行分析。 一、代理对象 Dubbo 支持同步 和 异步 两种调用方式，其中异步调用还可细分为“有返回值”的异步调用和“无返回值”的异步调用。所谓“无返回值”异步调用是指服务消费方只管调用，但不关心调用结果，此时 Dubbo 会直接返回一个空的 RpcResult。若要使用异步特性，需要服务消费方手动进行配置。默认情况下，Dubbo 使用同步调用方式。 上篇文章我们分析了，dubbo实际上是通过代理类去调用远程方法，所以我们先通过反编译看下代理类里的具体内容： public class proxy0 implements ClassGenerator.DC, EchoService, DemoService { // 方法数组 public static Method[] methods; private InvocationHandler handler; public

3 月，跳不动了？>>> 开篇 本文会通过 Java 实现一个简单的 rpc 框架，rpc 的概念在此不多赘述。相信看完整个实现过程，会对 rpc 的实现原理有更清晰的，更直观的认识。 目标 实现一个类似 Dubbo 官方 Demo 的效果 ，先来看几段代码： 定义一个服务接口类 public interface HelloService { public void sayHello(String name); } 服务提供者的接口实现类 public class HelloServiceImpl implements HelloService { @Override public String sayHello(String name) { return "hello " + name; } } 服务提供者 public class Provider { public static void main(String[] args) throws Exception { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(new String[] {"http://10.20.160.1l"}); context.start(); System.in.read(); //

3 月，跳不动了？>>> 一、前言 这期我想写很久了，但是因为时间的原因一直拖到了现在，我以为一两天就写完了，结果从构思到整理资料，再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的，所以我肯定不会一本正经的写，我想了好几个切入点，最后决定用一个完整的电商系统作为切入点，带着大家看看，我们需要学些啥，我甚至还收集配套视频和资料，暖男石锤啊，这期是呕心沥血之作，不要白嫖了。 二、正文 在写这个文章之前，我花了点时间，自己臆想了一个电商系统，基本上算是麻雀虽小五脏俱全，我今天就用它开刀，一步步剖析，我会讲一下我们可能会接触的技术栈可能不全，但是够用，最后给个学习路线。 Tip：请多欣赏一会，每个点看一下，看看什么地方是你接触过的，什么技术栈是你不太熟悉的，我觉得还算是比较全的，有什么建议也可以留言给我。 不知道大家都看了一下没，现在我们就要庖丁解牛了，我从上到下依次分析。 三、前端 你可能会会好奇，你不是讲后端学习路线嘛，为啥还有前端的部分，我只能告诉你，傻瓜，肤浅。 我们可不能闭门造车，谁告诉你后端就不学点前端了？ 前端现在很多也了解后端的技术栈的，你想我们去一个网站，最先接触的，最先看到的是啥？ 没错就是前端，在大学你要是找不到专门的前端同学，去做系统肯定也要自己顶一下前端的，那我觉得最基本的技术栈得熟悉和了解吧

3 月，跳不动了？>>> 之前在 Apache/dubbo-go（以下简称 dubbo-go ）社区中，有同志希望配置文件可以放置于配置管理中心，不仅放置于本地。放置于本地及配置管理中心究竟有什么不一样呢？ 放置于本地，每次更新需要重启，配置文件管理困难，无法做到实时更新即刻生效。本地文件还依赖人工版本控制，在微服务的场景下，大大的增加了运维的成本与难度。 而配置管理中心提供统一的配置文件管理，提供文件更新实时同步，统一版本控制，权限管理等功能。 目标 基于以上几个背景，可以总结出以下 目标 与 dubbo 现有的配置中心内的配置文件兼容，降低新增语言栈的学习成本； 支持多种配置文件格式； 支持主流配置中心，适应不一样的使用场景，实现高扩展的配置下发； 配置中心 配置中心在 dubbo-go 中主要承担以下场景的职责： 作为外部化配置中心，即存储 dubbo.properties 配置文件，此时，key 值通常为文件名如 dubbo.properties , value 则为配置文件内容。 存储单个配置项，如各种开关项、常量值等。 存储服务治理规则，此时 key 通常按照 “服务名 + 规则类型” 的格式来组织，而 value 则为具体的治理规则。 就目前而言，dubbo-go 首要支持 dubbo 中所有支持的各种开源配置中心，包括： Apollo

3 月，跳不动了？>>> 前言 今天在测试环境发布 SpringBoot 服务，发现死活找不到错误的地方，错误日志也生成，然后就一顿 tail ，一顿 cat ，发现日志就截止到我发服务之前， dubbo 服务结束的地方，如图所示。 <img src="http://qiniu-cdn.janker.top/oneblog/20200318202129609.jpg" style="zoom:50%;" /> WTF，why,我是丈二和尚摸不着头脑，后来我发现他这个服务不是像我之前那种 nohup java -jar xxx.jar 启动的，他这个是使用 systemctl restart service@xx 启动的。 <img src="http://qiniu-cdn.janker.top/oneblog/20200318202527014.png" style="zoom:50%;" /> 正文 第六感告诉我，系统启动日志中肯定有猫腻，说完就干，一顿搜索。journalctl这个是我想要的查看linux各种服务启动指令。 journalctl -f | grep "xxxx" 比较粗略展示log journalctl -xe| grep "xxxx" 比较详细展示log 结果如我所料，如图我没权限创建文件，emmmm，我好像找到我的锅了（之前为了本地调试改了日志的文件夹）

dubbo需要额外的注册中心,其实也可以配置直连,但是那也没有意义了,支持几种注册中心但是推荐还是zookeeper 这里就不说怎么搭建zookeeper了,去官网下载一个 然后在conf目录下新建zoo.cfg文件 至于内容可以复制zoo_sample.cfg 只需要修改一下里面数据存储的目录即可 启动zookeeper,进入bin目录下如果是Windows执行zkServer.cmd,liunx就是zkServer.sh 这是启动zookeeper服务,至于客户端可以用zkCli.sh或cmd dubbo就是把所有的接口(服务)采用统一声明管理,建一个工程,里面创建别的模块所需要的service接口和相关的实体类 命名为dubbo-api 然后在别的模块中引入这个工程 maven依赖如下 1 <dependency> 2 <groupId>com.tqq</groupId> 3 <artifactId>dubbo-api</artifactId> 4 <version>1.0-SNAPSHOT</version> 5 </dependency> 6 <!-- Dubbo Spring Boot Starter --> 7 <dependency> 8 <groupId>org.apache.dubbo</groupId> 9 <artifactId>dubbo-spring

SPI 全称为 Service Provider Interface ，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。 Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。基于 SPI，我们可以很容易的对 Dubbo 进行拓展。如果大家想要学习 Dubbo 的源码，SPI 机制务必弄懂。接下来，我们先来了解一下 Java SPI 与 Dubbo SPI 的用法，然后再来分析 Dubbo SPI 的源码。 1.0 Java SPI 示例 //定义接口 public interface SpiInterface { void sayHello(); } //实现类 public class SpiImpl01 implements SpiInterface { @Override public void sayHello() { System.out.println("Hello, I am SpiImpl01."); }} public class SpiImpl02 implements SpiInterface{ @Override public void sayHello() {

最近，开源社区发生了一件大事，那个全国 Java 开发者使用最广的开源服务框架 Dubbo 低调重启维护，并且 3 个月连续发布了 4 个维护版本。 我上次在写 放弃Dubbo，选择最流行的Spring Cloud微服务架构实践与经验总结 这篇文章的时候，就有很多的网友给我留言说，Dubbo 又开始更新了。我当然是清楚的，我也一直在关注着 Dubbo 的走向，在几个月前技术圈里面就有一个消息说是 Dubbo 又开始更新了，大家议论纷纷不知真伪。我还专门跑到 GitHub 上面进行了留言询问，最后在 Dubbo 的 gitter 聊天室里面找到了确信的答案，说是正在组建团队。虽然稍稍有所期待，但也不知道阿里这次拿出了多少的诚意来做这件事，于是我昨天又到 GitHub 逛了一下，发现从 9 月开始，阿里三个月连着发布了四个版本，还是非常有诚意的，值得关注。 Dubbo简介 Dubbo 是阿里巴巴公司一个开源的高性能服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案，使得应用可通过高性能 RPC 实现服务的输出、输入功能和 Spring 框架无缝集成。Dubbo 包含远程通讯、集群容错和自动发现三个核心部分。 它提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何 API 侵入。同时它具备软负载均衡及容错机制