weiythi的Blog

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题，也常常为这个问题而纠结。生成ID的方法有很多，适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。数据库自增长序列或字段最常见的方式。利用数据库，全数据库唯一。优点：1）简单，代码方便，性能可以接受。2）数字ID天然排序，对分页或者需要排序的结果很有帮助。缺点：1）不同数据库语法

Dubbo是Alibaba开源的分布式服务框架，它最大的特点是按照分层的方式来架构，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。关于注册中心、协议支持、服务监控等内容，详见后面描述。

上文书整理了dubbo是如何生成服务代理的，并且留了个尾巴，这一文主要介绍dubbo是如何实现服务发现的，继续前文的脚步，看一下dubbo如何完成传说中的服务自动发现 打开com.alibaba.dubbo.config.ReferenceConfig 类，只关注@SuppressWarnings({ "unchecked", "rawtypes", "deprecation" }) pr

dubbo的consumer的初始过程一个常见的consumer配置是这样的<dubbo:reference id="dubboDemo" interface="com.company.dsp.adcenter.protocol.dubbo.DubboDemo" protocol="dubbo"/>这样spring会创建一个beanName为dubboDemo的be

之前已经分析的dubbo的服务的发现和注册，这里先看一下dubbo协议是如何实现的，之前已经知道了，调用DubboProtocol类的export来暴露服务的,协议实现比较复杂，这里只关系主体实现即排除一些特性功能的处理代码本章主要处理服务端对应的暴露流程,继续回到···com.alibaba.dubbo.config.ServiceConfig···的doExportUrlsFor1Protoco

接上《 Dubbo/Dubbox的服务暴露（二）-扩展点机制》上文书依旧疑留的疑问，这两句到底在干啥Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.toFullString()))

接上《 Dubbo/Dubbox的服务暴露（一）》上文书留的疑问，这两句到底在干啥 Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(Constants.EXPORT_KEY, url.t

前言源码入手平时我要了解一个框架，基本会去从他的Listener入手，如果web.xml中没有配置listener可能还会有 filter，这是spring给我们的启示，可是当要去了解dubbo的时候，发现dubbo并没有自己的listener监听器。已知dubbo是一款和spring结合较好的rpc框架，那么其不使用web容器相关的方式，必然遵循spring的方式。依据平时开发经验，我们知道要想在

一个常见的dubbo配置，参照我们项目中的配置，我们项目中使用的是dubbox，是当当基于dubbo的修改版，添加了对rest风格的支持，这里不多叙述。 dubbo:application name="XXXXX" organization="YYYY" owner="ZZZZ" logger="log4j"/> dubbo:registry address="${dub