7 天前 / 猿天地
项目地址 https://github.com/yinjihuan/kitty-cloud[1] 前言 Kitty Cloud 开源后有以为朋友在 GitHub 上给我提了一个 issues，问为什么项目中要同时集成 Feign 和 Dubbo 两个框架来调用服务。今天就来聊一聊这个问题，然后讲下在 Kitty Cloud 中如何切换使用两种调用方式。 为什么要支持两种协议？关于支持两种协议，我这个是一个开源项目，主要还是为了让使用者有更多的选择。当然框架本身不是我开发的，我只是使用者而已。 一种协议更统一化，两种协议混着用也不是不可以，具体还是看实际需求。
44 天前 / ytao
Dubbo 路由机制是在服务间的调用时，通过将服务提供者按照设定的路由规则来决定调用哪一个具体的服务。 路由服务结构 Dubbo 实现路由都是通过实现 RouterFactory 接口。当前版本 dubbo-2.7.5 实现该接口类如下： 路由实现工厂类是在 router 包下 由于 RouterFactory 是 SPI 接口，同时在获取路由 RouterFactory#getRouter 方法上有 @Adaptive("protocol") 注解，所以在获取路由的时候会动态调用需要的工厂类。
63 天前 / ytao
SPI 全称为 Service Provider Interface，是一种服务发现机制。当程序运行调用接口时，会根据配置文件或默认规则信息加载对应的实现类。所以在程序中并没有直接指定使用接口的哪个实现，而是在外部进行装配。要想了解 Dubbo 的设计与实现，其中 Dubbo SPI 加载机制是必须了解的，在 Dubbo 中有大量功能的实现都是基于 Dubbo SPI 实现解耦，同时也使得 Dubbo 获得如此好的可扩展性。 Java SPI 通过完成一个 Java SPI 的操作来了解它的机制。
79 天前 / ytao
前言上篇文章《Dubbo 之服务暴露》分析 Dubbo 服务是如何暴露的，本文接着分析 Dubbo 服务的消费流程。主要从以下几个方面进行分析：注册中心的暴露；通过注册中心进行服务消费通知；直连服务进行消费。服务消费端启动时，将自身的信息注册到注册中心的目录，同时还订阅服务提供方的目录，当服务提供方的 URL 发生更改时，实时获取新的数据。 服务消费端流程下面是一个服务消费的流程图： 上图中可以看到，服务消费的流程与服务暴露的流程有点类似逆向的。
105 天前 / why技术
持续输出原创文章，点击蓝字关注我吧 这是 why 技术的第 33 篇原创文章 本周是在家办公的一周，上面的图就是我在家的工位。 工欲善其事，必先利其器。在家办公，我是认真的。 在家里开发的时候有需求是这样的：一个如果接口调用失败，需要自动进行重试。 虽然关系不大，但是我还是想到了 Dubbo 的集群容错策略：Failover Cluster，即失败自动切换。 （这个转折是不是有点生硬。......） 所以借本文对于 Dubbo 的 Cluster 集群和 FailoverCluster( 失败自动切换)策略进行一个详细分析。 本文如果没有特别说明的地方，源码均是来自最新的 2.7.5 版本。
109 天前 / 猿天地
前因那是一个月黑风高的夜晚，不管有没有圆圆的月亮，都无法解救要加班的我。这就是苦涩的人生啊！ 那天正好是春节回家的日子，定了晚上的票，然后还是上线的日子。 测试在做回归测试的时候，发现一个老功能报错了，什么鬼，都没改过那块代码怎么会出问题？案件疑点重重呀...... 为了能够早点上线，早点回家，所以这个 Bug 就显得十万火急了，因为就这一个问题，其他都没问题，解决好了就可以上线了，于是开启了破案之路。
118 天前 / why技术
我与 Dubbo 的二三事我是 2016 年毕业的，在我毕业之前，我在学校里面学到的框架都是 SSH，即 struts+spring+hibernate,是的你没有看错，在大学里面的课本里面学的是 strusts，这个还没毕业就被基本抛弃的框架。然而我大四出去实习，用的技术是 SSM,即 Spring，SpringMVC，Mybatis。实习的时候做的项目都是外包项目，非常传统的单体大项目，和学校里面做课程设计一样，所有的功能包括前后端都糅合在一个项目里面，根本不知道什么是分布式架构，不夸张的说，那个时候我对分布式这一块的知识无限趋近于零。
128 天前 / why技术
持续输出原创文章，点击蓝字关注我吧 这是 why 技术的第 28 篇原创文章 之前在《Dubbo 一致性哈希负载均衡的源码和 Bug，了解一下？》中写到了我发现了一个 Dubbo 一致性哈希负载均衡算法的 Bug。 对于解决方案我是这样写的： 特别简单，把获取 identityHashCode 的方法从 System.identityHashCode(invokers)修改为 invokers.hashCode()即可。 此方案是我提的 issue 里面的评论，这里 System.identityHashCode 和 hashCode 之间的联系和区别就不进行展开讲述了，不清楚的大家可以自行了解一下。
141 天前 / 宜信技术学院
（图片来源于网络）Dubbo是一款开源的、高性能且轻量级的Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡，以及服务自动注册和发现。Dubbo最早是阿里公司内部的RPC框架，于 2011 年开源，之后迅速成为国内该类开源项目的佼佼者，2018年2月，通过投票正式成为 Apache基金会孵化项目。目前宜信公司内部也有不少项目在使用Dubbo。本系列文章通过拆解Dubbo源码，帮助大家了解Dubbo，做到知其然，并且知其所以然。
149 天前 / 携程技术
作者简介 顾海洋，携程框架架构研发部技术专家，负责携程分布式服务化领域的工作。目前主要负责 Dubbo 在携程的二次开发和推广工作。 李伟，携程云平台技术专家，2012年加入携程，目前专注于云原生方向技术的研究和落地，先后参与负责过携程部署架构改造、接入层架构升级等项目的设计和推广。 工作中，常常会遇到连接超时的问题，一般都是先检查端口状态，然后再检查CPU、Memory、GC、Connection等机器指标是否正常。如果都在合理范围内就会怀疑到网络或者容器上，甩手丢给网络组同事去排查。
163 天前 / why技术
持续输出原创文章，点击蓝字关注我吧 这是why技术的第18篇原创文章 本文是对于Dubbo负载均衡策略之一的加权随机算法的详细分析。从2.6.4版本聊起，该版本在某些情况下存在着比较严重的性能问题。由问题入手，层层深入，了解该算法在Dubbo中的演变过程，读懂它的前世今生。 之前也写了Dubbo的负载均衡策略： 《一文讲透Dubbo负载均衡之最小活跃数算法》 《Dubbo一致性哈希负载均衡的源码和Bug，了解一下？》 本文目录第一节：什么是轮询？ 本小节主要是介绍轮询算法和其对应的优缺点。引出加权轮询算法。
169 天前 / why技术
持续输出原创文章，点击蓝字关注我吧 本文是对于Dubbo负载均衡策略之一的一致性哈希负载均衡的详细分析。对源码逐行解读、根据实际运行结果，配以丰富的图片，可能是东半球讲一致性哈希算法在Dubbo中的实现最详细的文章了。 文中所示源码，没有特别标注的地方，均为2.7.4.1版本。 在撰写本文的过程中，发现了Dubbo2.7.0版本之后的一个bug。会导致性能问题，且目前还未解决，如果你们的负载均衡配置的是一致性哈希或者考虑使用一致性哈希的话，可以了解一下。
175 天前 / wphmoon
首发于编码花写文章springboot2中使用dubbo的三重境界blue sky搞了十几年的java4 人赞同了该文章在springboot中使用dubbo，本来是件挺简单的事情，但现实的世界就是如此的复杂，今天我用一个亲身经历的跳坑和填坑的事来讲在spring boot中使用高版本dubbo（当当的魔改版）的三重境界。 1、看山是山，使用官方starter简单的使用dubbo starter集成进spring boot还是非常简单的。 在springboot2的pom.xml中引入dubbo的starter com.alibaba.spring.bootdubbo-spring-boot-starter2.0.0在启动类里面加上注解@EnableDubboConfiguration @EnableDubboConfigura...
177 天前 / why技术
持续输出原创文章，点击蓝字关注我吧 这是why技术的第16篇原创文章 全文共计7786字，50图，预计阅读15分钟。 本文是对于Dubbo负载均衡策略之一的最小活跃数算法的详细分析。文中所示源码，没有特别标注的地方均为2.6.0版本。 为什么没有用截止目前的最新的版本号2.7.4.1呢？因为2.6.0这个版本里面有两个bug。从bug讲起来，印象更加深刻。 最后会对2.6.0/2.6.5/2.7.4.1版本进行对比，通过对比学习，加深印象。 本文目录第一节：Demo准备。 本小节主要是为了演示方便，搭建了一个Demo服务。
185 天前 / 知了一笑
一、Dubbo框架简介1、框架依赖 图例说明： 1)图中小方块 Protocol, Cluster, Proxy, Service, Container, Registry, Monitor 代表层或模块，蓝色的表示与业务有交互，绿色的表示只对 Dubbo 内部交互。 2)图中背景方块 Consumer, Provider, Registry, Monitor 代表部署逻辑拓扑节点。 3)图中蓝色虚线为初始化时调用，红色虚线为运行时异步调用，红色实线为运行时同步调用。 4)图中只包含 RPC 的层，不包含 Remoting 的层，Remoting 整体都隐含在 Protocol 中。