Dubbo

从编程开发的角度来说，Apache Dubbo （以下简称 Dubbo ）首先是一款 RPC 服务框架，它最大的优势在于提供了面向接口代理的服务编程模型，对开发者屏蔽了底层的远程通信细节。同时 Dubbo 也是一款服务治理框架，它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案。 在这篇文章中，我们将以以上基础能力为背景，尝试突破 Dubbo 体系自身，探索如何利用 Dubbo 对多协议、多服务发现模型的支持，来实现异构微服务体系间的互联互通。在实际业务场景中，这可以用来解决异构技术体系共存场景下的通信问题，帮助公司实现在异构技术体系间作平滑迁移，解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。 面向接口代理的透明服务开发框架 我们还是从 Dubbo 是一个微服务开发框架 这个大家熟知的概念开始。就像 Spring 是开发 Java 应用的基础框架一样，我们经常会选用 Dubbo 作为开发微服务业的基础框架。 Dubbo 框架的最大优势我认为就在其面向接口的编程模型，使得开发远程服务调用就像开发本地服务一样（以 Java 语言为例）： 服务定义 public interface GreetingsService { String sayHi(String name); } 消费方调用服务 // 和调用本地服务一样，完全透明。 @Reference

分布式环境下，对于线上出现问题往往比单体应用要复杂的多，原因是前端的一个请求可能对应后端多个系统的多个请求，错综复杂。 对于快速问题定位，我们一般希望是这样的： 从下到下关键节点的日志,入参，出差，异常等。 关键节点的响应时间 关键节点依赖关系 而这些需求原来在单体应用中可以比较容易实现，但到了分布式环境，可能会出现： 每个系统的技术栈不同 有的系统有日志有的连日志都没有 日志实现手段不相同 以上系统都是自治的，要想看整体的调用链非常困难。 分布式系统日志统一的手段有很多，比如常见的ELK，但这些日志都是文本，不太容易做分析。 更希望看到类似如下浏览器对于网络请求的分析：将分散的请求串联在一起 zipkin 这是推特的一个产品，通过API收集各系统的调用链信息然后做数据分析，展示调用链数据。 核心功能： 搜索调用链信息 此处不多说，无非就是从存储中按一定条件搜索请求信息。 zipkin默认是内存存储，也可以是其它的比如：mysq,elasticsearch 查看某条请求的详细调用链 比如查询产品明细，除了产品的基本信息还需要展示对产品的所有评论。下图可以清晰的展示调用关系，product-dubbo-consumer调用product-dubbo-provider，product-dubbo-provider内部再调用comment-dubbo-provider

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 从编程开发的角度来说，Apache Dubbo （以下简称 Dubbo）首先是一款 RPC 服务框架，它最大的优势在于提供了面向接口代理的服务编程模型，对开发者屏蔽了底层的远程通信细节。同时 Dubbo 也是一款服务治理框架，它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案。 在这篇文章中，我们将以以上基础能力为背景，尝试突破 Dubbo 体系自身，探索如何利用 Dubbo 对多协议、多服务发现模型的支持，来实现异构微服务体系间的互联互通。在实际业务场景中，这可以用来解决异构技术体系共存场景下的通信问题，帮助公司实现在异构技术体系间作平滑迁移，解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。 面向接口代理的透明服务开发框架 我们还是从 Dubbo 是一个微服务开发框架 这个大家熟知的概念开始。就像 Spring 是开发 Java 应用的基础框架一样，我们经常会选用 Dubbo 作为开发微服务业的基础框架。Dubbo 框架的最大优势我认为就在其面向接口的编程模型，使得开发远程服务调用就像开发本地服务一样（以 Java 语言为例）： 1、服务定义 public interface GreetingsService { String sayHi(String name); } 2

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 从编程开发的角度来说，Apache Dubbo （以下简称 Dubbo ）首先是一款 RPC 服务框架，它最大的优势在于提供了面向接口代理的服务编程模型，对开发者屏蔽了底层的远程通信细节。同时 Dubbo 也是一款服务治理框架，它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案。 在这篇文章中，我们将以以上基础能力为背景，尝试突破 Dubbo 体系自身，探索如何利用 Dubbo 对多协议、多服务发现模型的支持，来实现异构微服务体系间的互联互通。在实际业务场景中，这可以用来解决异构技术体系共存场景下的通信问题，帮助公司实现在异构技术体系间作平滑迁移，解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。 面向接口代理的透明服务开发框架 我们还是从 Dubbo 是一个微服务开发框架 这个大家熟知的概念开始。就像 Spring 是开发 Java 应用的基础框架一样，我们经常会选用 Dubbo 作为开发微服务业的基础框架。 Dubbo 框架的最大优势我认为就在其面向接口的编程模型，使得开发远程服务调用就像开发本地服务一样（以 Java 语言为例）： 服务定义 public interface GreetingsService { String sayHi(String name); }

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 通过前面文章详解，我们知道Dubbo服务消费者标签dubbo:reference最终会在Spring容器中创建一个对应的ReferenceBean实例，而ReferenceBean实现了Spring生命周期接口：InitializingBean，接下来应该看一下其afterPropertiesSet方法的实现。 1、源码分析ReferenceBean#afterPropertiesSet ReferenceBean#afterPropertiesSet if (getConsumer() == null) { Map<string, consumerconfig> consumerConfigMap = applicationContext == null ? null : BeanFactoryUtils.beansOfTypeIncludingAncestors(applicationContext, ConsumerConfig.class, false, false); if (consumerConfigMap != null && consumerConfigMap.size() > 0) { ConsumerConfig consumerConfig = null; for

部署开发，需要三部分：服务提供者、服务容器、服务消费者 本人用 eclipse 开发 1、服务提供者jar生成 A、项目截图 B、源码： ? 1 2 3 4 5 package com.alibaba.dubbo.demo; public interface DemoService { String sayHello(String name); } ? 1 2 3 4 5 6 7 8 9 package com.alibaba.dubbo.demo.provider; import com.alibaba.dubbo.demo.DemoService; public class DemoServiceImpl implements DemoService{ public String sayHello(String name) { return "Hello " + name; } } provider.xml ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 <? xml version = "1.0" encoding = "UTF-8" ?> < beans xmlns = "http://www.springframework.org/schema/beans" xmlns:xsi =

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。 此时，用于简化增删改查工作量的 数据访问框架 (ORM) 是关键。 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。 此时，用于加速前端页面开发的 Web 框架 (MVC) 是关键。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。 此时，用于提高业务复用及整合的 分布式服务框架 (RPC) 是关键。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。 此时，用于提高机器利用率的 资源调度和治理中心 (SOA) 是关键。 Dubbo 就是 资源调度和治理中心 的管理工具。 1.1.1. Dubbo 的架构 节点角色说明： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor:

dubbo超时重试和异常处理 参考： https://www.cnblogs.com/ASPNET2008/p/7292472.html https://www.tuicool.com/articles/YfA3Ub https://www.cnblogs.com/binyue/p/5380322.html https://blog.csdn.net/mj158518/article/details/51228649 dubbo源码分析：超时原理以及应用场景 本篇主要记录dubbo中关于超时的常见问题，实现原理，解决的问题以及如何在服务降级中体现作用等。 超时问题 为了检查对dubbo超时的理解，尝试回答如下几个问题，如果回答不上来或者不确定那么说明此处需要再多研究研究。 我只是针对个人的理解提问题，并不代表我理解的就是全面深入的，但我的问题如果也回答不了，那至少说明理解的确是不够细的。 超时是针对消费端还是服务端？ 超时在哪设置？ 超时设置的优先级是什么？ 超时的实现原理是什么？ 超时解决的是什么问题？ 问题解答 RPC场景 本文所有问题均以下图做为业务场景，一个web api做为前端请求，product service是产品服务，其中调用comment service(评论服务)获取产品相关评论，comment service从持久层中加载数据。 超时是针对消费端还是服务端？

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Mr. Tech经常听到有人吐槽 每天上下班挤地铁 每个月给房东打工 每日Bug改到头秃 但是 忙十年却赶不上同事三年 房价物价年年涨 而你的升职加薪却遥遥无期 为什么你光努力没成绩？ 为什么你在职场没有竞争力？ 为什么你总被同龄人甩在身后？ 其实，这不是因为同事比你聪明，而是因为你没有掌握职场升级打怪的正确窍门。为此，Mr. Tech特地请来个推传说中的优秀“同事”——个推Java主管逍遥，为大家传授一下职场超车、告别打杂的秘诀。 逍遥大学毕业仅仅一年，便协助主管承担了团队管理任务；工作两年，便开始独立负责个推核心技术团队基础推送线；工作三年便正式任命为B2D研发部基础推送线Java主管，现负责管理数十人的核心技术团队。逍遥将职场感悟归结为四点：技术知识体系构建、做好职业规划、思维模式转变、情绪调整及控制。 （以下为逍遥的个人分享） 技术知识体系构建 我经常在面试的过程中会问大家如何构建自己的Java学习体系，来帮助自己更快更好地掌握相关的知识并应用到工作中来。然而，就面试者来看，大多数人对此并没有进行过深入思考，回答起来吞吞吐吐，知识体系不全。为此，我建议大家不妨可以从初学、进阶两方面着手，来全方位提高Java学习能力。 初学 初学者建议从学习的语言基础看起。拿Java举例，设计模式自不必提，Java虚拟机

一 需求分析阶段 二 设计分析阶段 三 开发联调自测阶段 四 提测阶段 五 测试执行 六 上线阶段 七 运营阶段 一 需求分析阶段 1.业务修改 现有业务修改是否清晰 核心逻辑是否遗漏 有无业务冲突 2.用户体验和影响 交互是否合理 会不会拉长交易流程 干扰用户选择 下单和支付响应时长 3.周边业务线的影响 是否清晰描述上下游系统的影响 4.安全 黑白名单 反作弊 开关 规则和阈值 5.旧数据兼容 二 设计分析阶段 系统结构： 针对项目需求，结合业务现状来评估RD设计的系统修改点是否合理 模块、系统间使用了什么接口、中间件进行通讯（http、dubbo、mq、缓存、数据库、定时任务等），是否合理，例如dubbo循环依赖等 - 画出当前的系统结构图 - 标注出系统结构的改动点 数据流： 能不能拿到自己想要的数据，做出的修改是否会对现有系统造成负面影响，例如数据结构不兼容，缓存结构不兼容等 - 接口和接口字段的CUD（增、改、删） - 数据存储的变化（表、字段） 三 开发联调自测阶段 1.根据需求和设计文档进行case设计和评审（后续自动化case同步进行？） 2.测试环境准备 分支 sql ng 权限配置等 3.跨团队项目的上下游沟通 测试计划沟通 和上下游模块沟通各自负责的测试计划安排、测试范围、测试重要场景、跨团队 测试数据的构造、配合的方式，把团队间的影响降到最低。 环境对接