java dubbo hessian调用怎么序列化

I、初始化过程细节： 上图中的第一步start，就是将服务装载容器中，然后准备注册服务。和Spring中启动过程类似，spring启动时，将bean装载进容器中的时候，首先要解析bean。所以dubbo也是先读配置文件解析服务。 解析服务： 1）、基于dubbo.jar内的Meta-inf/spring.handlers配置，spring在遇到dubbo名称空间时，会回调DubboNamespaceHandler类。 2）、所有的dubbo标签，都统一用DubboBeanDefinitionParser进行解析，基于一对一属性映射，将XML标签解析为Bean对象。 在ServiceConfig.export 或者ReferenceConfig.get 初始化时，将Bean对象转会为url格式，将所以Bean属性转成url的参数。 然后将URL传给Protocol扩展点，基于扩展点的Adaptive机制，根据URL的协议头，进行不同协议的服务暴露和引用。 （2）服务消费者消费一个服务的详细过程 服务消费的主过程： 首先ReferenceConfig类的init方法调用Protocol的refer方法生成Invoker实例(如上图中的红色部分)，这是服务消费的关键。 接下来把Invoker转换为客户端需要的接口(如：HelloWorld)。

总结一下服务注册与发现机制： 基于注册 中心的事件通知（订阅与发布），一切支持事件订阅与发布的框架都可以作为Dubbo注册中心的选型。 1、服务提供者在暴露服务时，会向注册中心注册自己，具体就是在${service interface}/providers目录下添加 一个节点（临时），服务提供者需要与注册中心保持长连接，一旦连接断掉（重试连接）会话信息失效后，注册中心会认为该服务提供者不可用（提供者节点会被删除）。 2、消费者在启动时，首先也会向注册中心注册自己，具体在${interface interface}/consumers目录下创建一个节点。 3、消费者订阅${service interface}/ [ providers、configurators、routers ]三个目录，这些目录下的节点删除、新增事件都胡通知消费者，根据通知，重构服务调用器(Invoker)。 以上就是Dubbo服务注册与动态发现机制的原理与实现细节。

u2003SPI全称为Service Provider Interface，是一种服务提供机制，比如在现实中我们经常会有这种场景，就是对于一个规范定义方而言（可以理解为一个或多个接口），具体的服务实现方是不可知的（可以理解为对这些接口的实现类），那么在定义这些规范的时候，就需要规范定义方能够通过一定的方式来获取到这些服务提供方具体提供的是哪些服务，而SPI就是进行这种定义的。 说明： Dubbo 的扩展点加载是基于JDK 标准的 SPI 扩展点发现机制增强而来的，Dubbo 改进了 JDK 标准的 SPI 的以下问题： dubbo对于SPI的实现主要是在ExtensionLoader这个类中，这个类主要有三个方法： 如下是getExtension()方法的源码： createExtension()方法的源码： 在createExtension()方法中，其主要做了三件事： 关于wrapper对象，这里需要说明的是，其主要作用是为目标对象实现AOP。wrapper对象有两个特点： getExtensionClasses()方法的源码 loadDirectory()方法的源码： loadClass()方法的源码 loadClass()方法主要作用是对子类进行划分，这里主要划分成了三部分： 总结而言，getExtension()方法主要是获取指定名称对应的子类。在获取过程中，首先会从缓存中获取是否已经加载过该子类，如果没加载过则通过定义文件加载，并且使用获取到的wrapper对象封装目标对象返回。 getAdaptiveExtension()方法源码

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。dubbo就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbo这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架（告别Web Service模式中的WSdl，以服务者与消费者的方式在dubbo上注册）。Dubbo的核心部分包括：1、远程通讯：提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式。2、集群容错：提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持。3、服务自动注册与发现：基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。Dubbo的作用1、透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。2、软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。3、服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。而Dubbo则是SOA服务化治理方案的一个核心框架。 Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。 Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。 作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括： Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出 服务提供方（Provider） 和 服务消费方（Consumer） 两个角色。 Dubbo包含 远程通讯、服务集群和服务发现与注册 三个核心部分。提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。 Dubbo服务组件调用关秕说明 ： Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。 图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口， 位于中轴线上的为双方都用到的接口。 下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点： 从上图可以看出， Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的） 。 根据官方提供的，对于上述各层之间关系的描述，如下所示：

Mock 机制是 RPC 框架中非常常见、也非常有用的功能，不仅可以用来实现服务降级，还可以用来在测试中模拟调用的各种异常情况。Dubbo 中的 Mock 机制是在 Consumer 这一端实现的，具体来说就是在 Cluster 这一层实现的。 在前面深入介绍了 Dubbo 提供的多种 Cluster 实现以及相关的 Cluster Invoker 实现，其中的 ZoneAwareClusterInvoker 就涉及了 MockClusterInvoker 的相关内容。本文我们就来介绍 Dubbo 中 Mock 机制的全链路流程，不仅包括与 Cluster 接口相关的 MockClusterWrapper 和 MockClusterInvoker，还会回顾之前的 Router 和 Protocol 接口，分析它们与 Mock 机制相关的实现。 Cluster 接口有两条继承线（如下图所示）：一条线是 AbstractCluster 抽象类，这条继承线涉及的全部 Cluster 实现类；另一条线是 MockClusterWrapper 这条线。 MockClusterWrapper 是 Cluster 对象的包装类，在之前介绍 Dubbo SPI 机制时已经分析过 Wrapper 的功能，MockClusterWrapper 类会对 Cluster 进行包装。下面是 MockClusterWrapper 的具体实现，其中会在 Cluster Invoker 对象的基础上使用 MockClusterInvoker 进行包装： MockClusterInvoker 是 Dubbo Mock 机制的核心，它主要是通过 invoke()、doMockInvoke() 和 selectMockInvoker() 这三个核心方法来实现 Mock 机制的。 下面就来逐个介绍这三个方法的具体实现。 首先来看 MockClusterInvoker 的 invoke() 方法，它会先判断是否需要开启 Mock 机制。如果在 mock 参数中配置的是 force 模式，则会直接调用 doMockInvoke() 方法进行 mock。如果在 mock 参数中配置的是 fail 模式，则会正常调用 Invoker 发起请求，在请求失败的时候，会调动 doMockInvoke() 方法进行 mock。下面是 MockClusterInvoker 的 invoke() 方法的具体实现： 在 doMockInvoke() 方法中，首先调用 selectMockInvoker() 方法获取 MockInvoker 对象，并调用其 invoke() 方法进行 mock 操作。doMockInvoke() 方法的具体实现如下： selectMockInvoker() 方法中并没有进行 MockInvoker 的选择或是创建，它仅仅是将 Invocation 附属信息中的 invocation.need.mock 属性设置为 true，然后交给 Directory 中的 Router 集合进行处理。selectMockInvoker() 方法的具体实现如下： MockInvokersSelector 是 Dubbo Mock 机制相关的 Router 实现，在未开启 Mock 机制的时候，会返回正常的 Invoker 对象集合；在开启 Mock 机制之后，会返回 MockInvoker 对象集合。MockInvokersSelector 的具体实现如下： 在 getMockedInvokers() 方法中，会根据 URL 的 Protocol 进行过滤，只返回 Protocol 为 mock 的 Invoker 对象，而 getNormalInvokers() 方法只会返回 Protocol 不为 mock 的 Invoker 对象。 介绍完 Mock 功能在 Cluster 层的相关实现之后，还要来看一下 Dubbo 在 RPC 层对 Mock 机制的支持，这里涉及 MockProtocol 和 MockInvoker 两个类。 首先来看 MockProtocol，它是 Protocol 接口的扩展实现，扩展名称为 mock。MockProtocol 只能通过 refer() 方法创建 MockInvoker，不能通过 export() 方法暴露服务，具体实现如下： 下面再来看 MockInvoker 是如何解析各类 mock 配置的，以及如何根据不同 mock 配置进行不同处理的。这里重点来看 MockInvoker.invoke() 方法，其中针对 mock 参数进行的分类处理具体有下面三条分支： MockInvoker.invoke() 方法的具体实现如下所示： 针对 return 和 throw 的处理逻辑比较简单，但 getInvoker() 方法略微复杂些，其中会处理 MOCK_MAP 缓存的读写、Mock 实现类的查找、生成和调用 Invoker，具体实现如下： 在 getMockObject() 方法中会检查 mockService 参数是否为 true 或 default，如果是的话，则在服务接口后添加 Mock 字符串，作为服务接口的 Mock 实现；如果不是的话，则直接将 mockService 实现作为服务接口的 Mock 实现。getMockObject() 方法的具体实现如下： 本文重点介绍了 Dubbo 中 Mock 机制涉及的全部内容：

直连加不发布服务DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。下面我例举出通过哪些配置可以实现这种方案：服务消费端:DUBBO在消费端提供了一个url的属性来指定某个服务端的地址默认的方式是从注册中心发现接口为com.alibaba.dubbo.demo.HelloWorldService的服务，但是如果需要直连，可以在dubbo.properties下面配置dubbo.reference.helloWorldService.url=dubbo://ip:port/com.alibaba.dubbo.demo.HelloWorldService可以通过配置dubbo.reference.url=dubbo://ip:port/来让某个消费者系统的服务都指向制定的服务器地址（关于配置信息可以参考《DUBBO配置规则详解》）-

dubbo 是一款开源的 RPC 框架，主要有3个角色： 提供者（provider） 、 消费者（consumer） 、 注册中心（registry） 提供者启动时向注册中心注册服务地址，消费者启动时订阅服务，并通过获取到的提供者地址发起调用，当提供者地址变更时，通过注册中心向消费者推送变更。这就是 dubbo 主要的工作流程。 在2.7.5之前，dubbo 只支持接口级服务发现模型，>=2.7.5的版本提供了接口级与应用级两种服务发现模型，3.0之后的版本应用级服务发现更是非常重要的一个功能。 本文将从为什么需要引入应用级服务发现，dubbo 实现应用级服务发现的难点以及dubbo3 是如何解决这些问题这三个部分进行讲解。 开始前，我们先了解下 dubbo 最初提供的接口级服务发现是怎样的。 dubbo 服务的注册发现是以 接口 为最小粒度的，在 dubbo 中将其抽象为一个 URL ，大概长这样： 看着很乱？捋一捋： 无论是存储还是变更推送压力都可能遇到瓶颈，数据多表现在这两个方面： 这个问题好解决： 拆！ dubbo 在 2.7 之后的版本支持了 元数据中心 与 配置中心 ，对于URL的参数进行分类存储。持久不变的（如application、method等）参数存储到元数据中心中，可能在运行时变化（timeout、tag）的存储到配置中心中 无论是增加一台机器还是增加一个接口，其增长都是线性的，这个问题比单条数据大更严重。 当抹去注册信息中的 interface 信息，这样数据量就大大减少 只用过 dubbo 的同学可能觉得这很主流。 但从服务发现的角度来看： 无论是用的最多的服务注册发现系统 DNS ，又或者是 SpringCloud 体系、 K8S 体系，都是以应用为维度进行服务注册发现的，只有和这些体系对齐，才能更好地与之进行打通。 在我了解的范围里，目前只有 dubbo 、 SOFARPC 、 HSF 三个阿里系的 RPC 框架支持了接口级的服务发现。 provider端暴露服务： consumer端引用服务： 本地调用远程的方法时，只需要配置一个 reference ，然后直接使用 interface 来调用，我们不必去实现这个 interaface，dubbo 自动帮我们生成了一个代理进行 RPC 调用，屏蔽了通信的细节，让我们有种 像调用本地方法一样调用远程方法的感觉 ，这也是 dubbo 的优势。 从这里我们能看出为什么 dubbo 要设计成接口级服务发现，因为要为每一个 interface 生成一个代理，就必须定位到该 interface 对应服务暴露的服务地址，为了方便，dubbo 就这么设计了。 如果让我来设计应用级服务发现，注册不必多说，按应用名注册即可。 至于订阅，在目前 dubbo 机制下，必须得告诉消费者消费的每个接口是属于哪个应用，这样才能定位到接口部署在哪里。 实现 dubbo 应用级服务发现，难点在于 保留接口级服务发现，且默认采取双注册方式，可配置使用哪种服务发现模型，如下配置使用应用级服务发现 名词有点高大上，但道理很简单，让 dubbo 自己去匹配，提供者注册的时候把接口和应用名的映射关系存储起来，消费者消费时根据接口名获取到部署的应用名，再去做服务发现。 数据存储在哪里？显然元数据中心非常合适。该方案用户使用起来和之前接口级没有任何不同，但需要增加一个元数据中心，架构变得复杂。 且有一个问题是，如果接口在多个应用下部署了，dubbo 查找的策略是都去订阅，这可能在某些场景下不太合适。 本文从接口级服务发现讲到应用级服务发现，包含了为什么 dubbo 设计成接口级服务发现，接口级服务发现有什么痛点？基于 dubbo 现状如何设计应用级服务发现，应用级服务发现实现有什么难点等等问题进行解答，相信看完的小伙伴一定有所收获。

网页链接看一下子这个文章

我们都知道Dubbo可以与Spring进行融合，那是怎么进行融合的呢？ 我先介绍一下官方文档中是如何实现与Spring融合的，然后再从底层分析一下。 Service注解暴露服务 增加应用配置信息 指定Spring扫描路径 Reference注解引用服务 增加应用配置信息 指定Spring扫描路径 调用服务 上面是整体融合Spring的案例，接下来分析 Service 注解和 Reference 注解是怎么实现的。 当用户使用注解 @DubboComponentScan 时，会激活 DubboComponentScanRegister ，同时生成 ServiceAnnotationBeanPostProcessor 和 ReferenceAnnotationBeanPostProcessor , ServiceAnnotationBeanPostProcessor 处理器实现了 BeanDefinitionRegistryPostProcessor 接口，Spring容器会在所有Bean注册之后回调 postProcessBeanDefinitionRegistry 方法。 在这个方法里先提取用户配置的扫描包名称，然后委托Spring对所有符合包名的class文件做字节码分析，然后扫描Dubbo的注解@Service作为过滤条件，将扫描的服务创建 BeanDefinitionHolder ，用于生成 ServiceBean 定义，最后注册 ServiceBean 的定义并做数据绑定和解析。 这时我们注册了 ServiceBean 的定义，但是还没有实例化。 ServicecBean 的结构如下： InitializingBean 只包含 afterPropertiesSet() 方法，继承该接口的类，在初始化Bean的时候会执行该方法。在构造方法之后调用。 ApplicationContextAware Spring容器会检测容器中的所有Bean，如果发现某个Bean实现了 ApplicationContextAware 接口，Spring容器会在创建该Bean之后，自动调用该Bean的 setApplicationContextAware() 方法，调用该方法时，会将容器本身作为参数传给该方法。 ApplicationListener 当Spring容器初始化之后，会发布一个ContextRefreshedEvent事件，实现ApplicationListener接口的类，会调用 onApplicationEvent() 方法。 重要的接口主要是这几个，那么执行的先后顺序是怎样的呢？ 如果某个类实现了ApplicationContextAware接口，会在类初始化完成后调用setApplicationContext（）方法进行操作 首先会执行 ApplicationContextAware 中的 setApplicationContextAware() 方法。 这里主要是将Spring的上下文引用保存到 SpringExtensionFactory 中，里面有个set集合，保存所有的Spring上下文。这里实现了Dubbo与Spring容器的相连，在SPI机制中利用 ExtensionLoader.getExtension 生成扩展类时，会有一个依赖注入的过程，即调用 injectExtension() 方法，它会通过反射获取类的所有方法，然后遍历以set开头的方法，得到set方法的参数类型，再通过ExtensionFactory寻找参数类型相同的扩展类实例。 如果某个类实现了InitializingBean接口，会在类初始化完成后，并在setApplicationContext（）方法执行完毕后，调用afterPropertiesSet（）方法进行操作 然后会调用 InitializingBean 的 afterPropertiesSet() 方法。 主要是将Dubbo中的应用信息、注册信息、协议信息等设置到变量中。最后有个方法值得注意的是 isDelay 方法当返回true时，表示无需延迟导出；返回false时，表示需要延迟导出。 最后会调用 ApplicationListene 中的 onApplicationEvent 方法。 此时 ServiceBean 开始暴露。 具体的暴露流程之前已经介绍容量。 在Dubbo中处理 ReferenceBean 是通过 ReferenceAnnotionBeanPostProcessor 处理的，该类继承了 InstantiationAwareBeanPostProcessor ，用来解析@Reference注解并完成依赖注入。 InstatiationAwareBeanPostProcessor postProcessBeforeInstantiation 方法： 在实例化目标对象执行之前，可以自定义实例化逻辑，如返回一个代理对象。 postProcessAfterInitialization 方法：Bean实例化完成后执行的后处理操作，所有初始化逻辑、装配逻辑之前执行。 postProcessPropertyValues 方法： 完成其他定制的一些依赖注入和依赖检查等，可以增加属性和属性值修改。 新版本出现了改动，采用 AnnotationInjectedBeanPostProcessor 来处理。 AnnotationInjectedBeanPostProcessor 是 ReferenceAnnotationBeanPostProcessor 的父类，它实现InstantiationAwareBeanPostProcessorAdapter的postProcessPropertyValues方法,这个是实例化的后置处理,这个方式是在注入属性时触发,就是要在注入@Reference的接口时候,要将接口封装成动态代理的实例注入到Spring容器中. 主要分为两步： 1） 获取类中标注的@Reference注解的字段和方法。 2）反射设置字段或方法对应的引用 最重要的是第二步，通过 inject 方法进行反射绑定。 里面最主要的就是对生成的ReferenceBean设置一个代理对象。 服务引用的触发时机有两个： 一种是ReferenceBean初始化的时候；另一种是ReferenceBean对应的服务被注入到其他类中时引用。

国外也有很多的， Dubbo是阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及作为SOA服务治理的方案。它的核心功能包括：uf06c remoting: 远程通讯基础，提供对多种NIO框架抽象封装，包括“同步转异步”和“请求-响应”模式的信息交换方式。uf06c Cluster: 服务框架核心，提供基于接口方法的远程过程调用，包括多协议支持，并提供软负载均衡和容错机制的集群支持。uf06c registry: 服务注册中心，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

这次讲 dubbo-spring-boot-starter 启动方式，所以入口就是Spring的SPI机制； 首先在META-INF/spring.factories配置下，配置了org.apache.dubbo.spring.boot.autoconfigure.DubboAutoConfiguration类，在启动时，则会把DubboAutoConfiguration类注册到spring容器中； 我们来看下DubboAutoConfiguration 先看启动流程 我们先看下生产者端的启动流程，首先是在Spring中注册ServiceAnnotationBeanPostProcessor类该类实现了BeanDefinitionRegistryPostProcessor接口，则在Spring容器初始化时，会调用postProcessBeanDefinitionRegistry方法 我们会看到，这个时候会去注册DubboBootstrapApplicationListener类，这个类我们等流程到了在分析，我们先按启动流程看过去；resolvePackagesToScan方法先获取到需要扫描的包 ，然后再调用registerServiceBeans去注册相关实例，我们重点来看下registerServiceBeans方法 接下来，我们主要去看下registerServiceBean方法 接下来，我们来看下buildServiceBeanDefinition方法 到这，ServiceBean注册成功，ServiceBean类很重要，每个Dubbo service实例都对应一个ServiceBean，相关配置都在ServiceBean中；我们再回到开始注册的DubboBootstrapApplicationListener类 DubboBootstrapApplicationListener类继承了OneTimeExecutionApplicationContextEventListener，OneTimeExecutionApplicationContextEventListener实现了ApplicationListener，主要监听了Spring容器生命周期，我们看下onApplicationContextEvent方法 我们可以看到，当Spring容器启动成功时，会调用dubboBootstrap.start()； 接下来，主要逻辑在ServiceBean中，这个export方法在其父类ServiceConfig中，我们下一篇主要讲ServiceConfig逻辑；

dubbo没有熔断机制，不过可以自己实现，或者使用Spring Cloud。二者区别如下对比：顺便分享下资料：37套精品Java架构师高并发高性能高可用分布式集群电商缓存

总所周知，Dubbo、SpringCloud和Kubernetes是当前三个主流的开源框架和平台。 服务化框架和平台的选择是搭建微服务的一个基础，非常重要。其中Dubbo是阿里巴巴开源的，SpringCloud是netflix开源的，Kubernetes是谷歌开源的。它们都是分布式微服务框架平台的一套解决办法。值得一提的是，这3种产品其功能上是有重叠的，部分功能还可能是排他的，所以说不要相互之间进行混搭使用，架构保持一致性，维护起来也方便。 微服务的最终目的是要实现业务逻辑，实现业务价值。为了让开发人员更专注于业务逻辑的开发，通常微服务需要底层的基础设施的支撑，这些基础设施的支撑称为微服务公共关注点(Common Concerns)。如下图所示： 服务发现与负载均衡中，dubbo主要是基于Zookeeper实现的，阿里还开源了一个产品Nacos，其功能像Java版的Consul，Nacos后续可能会替换zk成为dubbo首选的服务发现机制。 在API网关中，阿里没有开源网关，而K8s中则是定义了名叫Ingress规范，具体可以采用不同的实现，比如说Nginx，Envoy或者Traefik。 在配置管理中，Nacos也具备配置的功能。SpringCloud采用的是Config，其后端是基于Git进行配置管理的。 在服务框架中，K8s是与框架无关的，只认容器，不同的语言栈都可以住在K8s中，这是最大的亮点。 在自动伸缩和自愈方面，K8s具有自动故障和自愈的能力，自动伸缩需要引入额外的组件，完全实现是需要一定的门槛，感兴趣可以关注一下。 在进程隔离方面，K8s是通过容器进行进程隔离的，同时还引入Pod进一步对服务进行隔离。 在环境管理方面，K8s是内置Namespace进行逻辑隔离的，可以实现多环境，各个环境可以单独配置认证授权机制。 在流量治理方面，这里的流量治理指的是高级的流量调度、A、B和蓝绿部署的能力。Dubbo通过zk+client是支持一定的流量调度能力的。 Dubbo、SpringCloud是框架组件，K8s是平台。 所以我们在理解服务的关注点，根据企业上下文考量后选择，尽量不要混搭，保持体系的一致性。 看了大牛的分析，自己学到了很多。

推荐的关于redis、dubbo、nocas的书：1.Redis设计与实现：Redis技术专家撰写，深入了解Redis技术内幕的之作。从源码角度解析Redis的架构设计、实现原理和工作机制，为高效使用 Redis 提供原理性指导；2.深入理解Apache Dubbo与实战：主要侧重于详细解读Dubbo框架工作原理和底层机制，并结合少量核心源码进行讲解。在原理的基础上，展示一些动手扩展Dubbo特性的实战场；3.Nacos架构&原理：Nacos 开源之前在阿里内部已经发展了十年，沉淀了很多优秀的能力，如其易用性、稳定性、实时性以及大规模的特性；也有很多历史负担，在开源的时候我们取其精华进行开源，为了提升代码的健壮性和扩展性，进行了充分的分层和模块化设计。

从架构的角度来看，API网关暴露http接口服务,其本身不涉及业务逻辑,只负责包括请求路由、负载均衡、权限验证、流量控制、缓存等等功能。其定位类似于Nginx请求转发、但功能要多于Nginx,背后连接了成百上千个后台服务，这些服务协议可能是rest的，也可能是rpc协议等等。 网关的定位决定了它生来就需要高性能、高效率的。网关对接着成百上千的服务接口,承受者高并发的业务需求，因此我们对其性能要求严苛，其基本功能如下: Flurry是云集自研的一款轻量级、异步流式化、针对Dubbo的高性能API网关。与业界大多数网关不同的是，flurry自己实现了 http与dubbo协议互转的流式化的dubbo-json协议，可高性能、低内存要求的对http和dubbo协议进行转换。除此之外，其基于 netty作为服务容器，提供服务元数据模型等等都是非常具有特点的。下面我们将详细介绍 flurry的特性: Flurry 网关请求响应基于Netty线程模型,后者是实现了Reactive,反应式模式规范的,其设计就是来榨干CPU的，可以大幅提升单机请求响应的处理能力。 最终,Flurry通过使用Netty线程模型和NIO通讯协议实现了HTTP请求和响应的异步化。 每一次http请求最终都会由Netty的一个Client Handler来处理,其最终以异步模式请求后台服务，并返回一个CompletableFuture,当有结果返回时才会将结果返回给前端。 见下面一段例子: 有了服务元数据,我们就可以不必需要服务的API包,并能够清晰的知道整个服务API的定义。 这在Dubbo服务Mock调用、服务测试、文档站点、流式调用等等场景下都可以发挥抢到的作用。 小孩子才分对错，成年人只看利弊。额外引入一个元数据生成机制，必然带来运维成本、理解成本、迁移成本等问题，那么它具备怎样的价值，来说服大家选择它呢？上面我们介绍元数据中心时已经提到了服务测试、服务 MOCK 等场景，这一节我们重点探讨一下元数据中心的价值和使用场景。 那么，Dubbo服务元数据能够利用到哪些场景呢？下面我们来详细描述。 Http请求，数据通过JSON传输,其格式严格按照接口POJO属性。返回结果再序列化为Json返回前端。现在大多数开源的网关,在dubbo协议适配上都是采用的泛化模式来做到协议转换的,这其中就包括 Soul 等。 JsonString -> JSONObject(Map) -> Binary 将JSON 字符串转换为 JSON 对象模型（JSONObject),此处通过第三方JSON映射框架（如Google的Gson, 阿里的FastJSON等)来做,然后将Map通过Hessian2 协议序列化为Binaray。 自定义的Dubbo-Json协议参考了 dapeng-soa 的流式解析协议的思想,详情请参考: dapeng-json 针对上述泛化模式转换Dubbo协议的缺点,我们在flurry-core 中的 Dubbo-Json 序列化协议做到了这点，下面我们来讲解它是如何高效率的完成JsonString到 dubbo hessian2 序列化buffer的转换的。 虽然大部分情况下的JSON请求、返回都是数据量较小的场景, 但作为平台框架, 也需要应对更大的JSON请求和返回, 比如1M、甚至10M. 在这些场景下, 如果需要占用大量的内存, 那么势必导致巨大的内存需求, 同时引发频繁的GC操作, 也会联动影响到整个网关的性能. Dubbo-Json参考了XML SAX API的设计思想, 创造性的引入了JSON Stream API, 采用流式的处理模式, 实现JSON 对 hessian2 的双向转换, 无论数据包有多大, 都可以在一定固定的内存规模内完成. 流式协议，顾名思义就是边读取边解析,数据像水流一样在管道中流动,边流动边解析，最后，数据解析完成时，转换成的hessian协议也已全部写入到了buffer中。 这里处理的核心思想就是实现自己的Json to hessian2 buffer 的语法和此法解析器,并配合前文提及的元数据功能,对每一个读取到的json片段通过元数据获取到其类型，并使用 hessian2协议以具体的方式写入到buffer中。 首先我们来看看JSON的结构. 一个典型的JSON结构体如下 其对应Java POJO 自然就是上述三个属性,这里我们略过。下面是POJO生成的元数据信息 相比XML而言，JSON数据类型比较简单, 由 Object/Array/Value/String/Boolean/Number 等元素组成, 每种元素都由特定的字符开和结束. 例如Object以"{"以及"}"这两个字符标志开始以及结束, 而Array是"["以及"]". 简单的结构使得JSON比较容易组装以及解析。 如图,我们可以清晰的了解JSON的结构,那么对上述JSON进行解析时,当每一次解析到一个基本类型时,先解析到key，然后根据key到元数据信息中获取到其value类型，然后直接根据对应类型的hessian2序列化器将其序列化到byte buffer中。 当解析到引用类型,即 Struct类型时,我们将其压入栈顶,就和java方法调用压栈操作类似。 通过上面的步骤一步一步，每解析一步Json，就将其写入到byte buffer中，最终完成整个流式的解析过程。 拿上面json为例: 总结: 上述整个请求和响应,网关处理如下: 请求和响应中没有像泛化模式中的中间对象转换，直接一步到位，没有多余的临时对象占用内存,没有多余的数据转换,整个过程像在管道中流式的进行。 如上图所示，flurry dubbo网关不必依赖任何dubbo接口API包,而是直接通过获取服务元数据、并通过dubbo-json流式协议来调用后端服务。其本身不会耦合业务逻辑。 硬件部署与参数调整 对基于Y-Hessian的 异步化、流式转换的Yunji Dubbo API网关进行性能压测，了解它的处理能力极限是多少，这样有便于我们推断其上线后的处理能力,以及对照现有的Tomcat接入层模式的优势,能够节约多少资源，做到心里有数。 性能测试场景 上述场景均使用wrk在压测节点上进行5～10min钟的压测，压测参数基本为12线程256连接或者512连接，以发挥最大的压测性能。 flurry集Dubbo网关、异步、流式、高性能于一身,其目标就是替代一些以tomcat作为dubbo消费者的接入层，以更少的节点获得更多的性能提升，节约硬件资源和软件资源。 后续在flurry的基础上，将实现鉴权管理、流量控制、限流熔断、监控收集等等功能 Flurry : 基于Dubbo服务的高性能、异步、流式网关 dubbo-json : 自定义的Dubbo协议，支持流式序列化模式，为flurry网关序列化/反序列化组件。 Yunji-doc-site : 与元数据集成相关的项目,以及文档站点 dapeng-soa : Dapeng-soa 是一个轻量级、高性能的微服务框架，构建在Netty以及定制的精简版Thrift之上。 同时，从Thrift IDL文件自动生成的服务元数据信息是本框架的一个重要特性，很多其它重要特性都依赖于服务元数据信息。 最后，作为一站式的微服务解决方案，Dapeng-soa还提供了一系列的脚手架工具以支持用户快速的搭建微服务系统 dapeng-json :dapeng-json协议介绍

首先是不建议采用XA两阶段提交方式去处理分布式事务，要知道要能够支持XA分布式事务，必须是要实现XA规范才可以，而Service本身是无状态的，如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。 可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析: 事务补偿机制 事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态，也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理，建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。 在这种情况下以上面例子来说，首先调用取款服务，完全调用成功并返回，数据已经持久化。然后调用异地的存款服务，如果也调用成功，则本身无任何问题。如果调用失败，则需要调用本地...首先是不建议采用XA两阶段提交方式去处理分布式事务，要知道要能够支持XA分布式事务，必须是要实现XA规范才可以，而Service本身是无状态的，如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析:事务补偿机制事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态，也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理，建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。在这种情况下以上面例子来说，首先调用取款服务，完全调用成功并返回，数据已经持久化。然后调用异地的存款服务，如果也调用成功，则本身无任何问题。如果调用失败，则需要调用本地注册的逆向服务（本地存款服务），如果本地存款服务调用失败，则必须考虑重试，如果约定重试次数仍然不成功，则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件，由消息中间件接管后续操作。在上面方式中可以看到需要手工编写大量的代码来处理以保证事务的完整性，我们可以考虑实现一个通用的事务管理器，实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操作均在事务管理和协同器上注册，由事务管理器接管所有的事务补偿和回滚操作。基于消息的最终一致性在这里首先要回答的是我们需要时实时一致性还是最终一致性的问题，如果需要的是最终一致性，那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。还是以上面的例子来看。对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。如果第二步在本地，则保证事务的完整性基本无任何问题，即本身就是本地事务的管理机制。只要两个操作都成功即可以返回客户成功。由于解耦，我们看到客户得到成功返回的时候，如果是上面一种情况则异地卡马上就能查询账户存款增加。而第二种情况则不一定，因为本身是一种异步处理机制。消息中间件得到消息后会去对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试。异地银行存款操作不应该长久地出现异常而无法使用，因此一旦发现异常我们可以迅速的解决，消息中间件中异常服务自然会进行重试以保证事务的最终一致性。这种方式假设问题一定可以解决，在不到万不得已的情况下本地的取款服务一般不进行可逆操作。在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个账户，而只是在一个事务的中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。关于等幂操作的问题重复调用多次产生的业务结果与调用一次产生的业务结果相同，简单点讲所有提供的业务服务，不管是正向还是逆向的业务服务，都必须要支持重试。因为服务调用失败这种异常必须考虑到，不能因为服务的多次调用而导致业务数据的累计增加或减少。关于是否可以补偿的问题在这里我们谈的是多个跨系统的业务服务组合成一个分布式事务，因此在对事务进行补偿的时候必须要考虑客户需要的是否一定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。在上面的例子来看，如果采用事务补偿机制，基本可以是做到准实时的补偿，不会有太大的影响。而如果采用基于消息的最终一致性方式，则可能整个周期比较长，需要较长的时间才能给得到最终的一致性。比如周六转款，客户可能下周一才得到通知转账不成功而进行了回退，那么就必须要考虑客户是否能给忍受。其次对于前面讨论，如果真正需要的是实时的一致性，那么即使采用事务补偿机制，也无法达到实时的一致性。即很可能在两个业务服务调用中间，客户前台业务操作对持久化的数据进行了其它额外的操作。在这种模式下，我们不得不考虑需要在数据库表增加业务状态锁的问题，即整个事务没有完整提交并成功前，第一个业务服务调用虽然持久化在数据库，但是仍然是一个中间状态，需要通过业务锁来标记，控制相关的业务操作和行为。但是在这种模式下无疑增加了整个分布式业务系统的复杂度。

XML 序列化的好处在于可读性好，方便阅读和调试。但是序列化以后的字节码文件比较大，而且效率不高，适用于对性能不高，而且 QPS 较低的企业级内部系统之间的数据交换的场景，同时 XML 又具有语言无关性，所以还可以用于异构系统之间的数据交换和协议。比如我们熟知的 webservice，就是采用 XML 格式对数据进行序列化的。XML 序列化/反序列化的实现方式有很多，熟知的方式有 XStream 和 Java 自带的 XML 序列化和反序列化两种 JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，相对于 XML 来说，JSON的字节流更小，而且可读性也非常好。现在 JSON 数据格式在企业运用是最普遍的JSON 序列化常用的开源工具有很多 这几种 json 序列化工具中，Jackson 与 fastjson 要比 GSON 的性能要好，但是 Jackson、GSON 的稳定性要比 Fastjson 好。而 fastjson 的优势在于提供的 api 非常容易使用 Hessian 是一个支持跨语言传输的二进制序列化协议，相对于 Java 默认的序列化机制来说，Hessian 具有更好的性能和易用性，而且支持多种不同的语言 实际上 Dubbo 采用的就是 Hessian 序列化来实现，只不过 Dubbo 对 Hessian 进行了重构，性能更高 Avro 是一个数据序列化系统，设计用于支持大批量数据交换的应用。它的主要特点有：支持二进制序列化方式，可以便捷，快速地处理大量数据；动态语言友好，Avro 提供的机制使动态语言可以方便地处理 Avro 数据 Kryo 是一种非常成熟的序列化实现，已经在 Hive、Storm）中使用得比较广泛，不过它不能跨语言. 目前 dubbo 已经在 2.6 版本支持 kyro 的序列化机制。它的性能要优于之前的hessian2 Protobuf 是 Google 的一种数据交换格式，它独立于语言、独立于平台。Google 提供了多种语言来实现，比如 Java、C、Go、Python，每一种实现都包含了相应语言的编译器和库文件，Protobuf 是一个纯粹的表示层协议，可以和各种传输层协议一起使用。 Protobuf 使用比较广泛，主要是空间开销小和性能比较好，非常适合用于公司内部对性能要求高的 RPC 调用。 另外由于解析性能比较高，序列化以后数据量相对较少，所以也可以应用在对象的持久化场景中但是要使用 Protobuf 会相对来说麻烦些，因为他有自己的语法，有自己的编译器，如果需要用到的话必须要去投入成本在这个技术的学习中 protobuf 有个缺点就是要传输的每一个类的结构都要生成对应的 proto 文件，如果某个类发生修改，还得重新生成该类对应的 proto 文件 各个序列化技术的性能比较 这个地址有针对不同序列化技术进行性能比较： https://github.com/eishay/jvm-serializers/wiki 使用 protobuf 开发的一般步骤是 编写 proto 文件 数据类型 string / bytes / bool / int32（4 个字节） /int64/float/double enum 枚举类 message 自定义类 修饰符 required 表示必填字段 optional 表示可选字段 repeated 可重复，表示集合 1，2，3，4 需要在当前范围内是唯一的，表示顺序 生成实体类 实现序列化 输出结果：10 3 77 105 99 16 -84 2 可以看到，序列化出来的数字基本看不懂，但是序列化以后的数据确实很小，那我们来了解一下底层的原理 正常来说，要达到最小的序列化结果，一定会用到压缩的技术，而 protobuf 里面用到了两种 压缩算法，一种是 varint，另一种是 zigzag -varint 先来看 age=300 这个数字是如何被压缩的 这两个字节字节分别的结果是：-84 、2 -84 怎么计算来的呢？ 我们知道在二进制中表示负数的方法，高位设置为 1， 并且是对应数字的二进制取反以后再计算补码表示（补码是反码+1） 所以如果要反过来计算 字符如何转化为编码 “Mic”这个字符，需要根据 ASCII 对照表转化为数字。 M =77、i=105、c=99 所以结果为 77 105 99 这里的结果为什么直接就是 ASCII 编码的值呢？怎么没有做压缩呢？ 原因是，varint 是对字节码做压缩，但是如果这个数字的二进制只需要一个字节表示的时候，其实最终编码出来的结果是不会变化的 还有两个数字，3 和 16 代表什么呢？那就要了解 protobuf 的存储格式了 存储格式 protobuf 采用 T-L-V 作为存储方式 tag 的计算方式是 field_number(当前字段的编号) << 3 | wire_type 比如 Mic 的字段编号是 1 ，类型 wire_type 的值为 2 所以 ： 1 <<3 | 2 =10 age=300 的字段编号是 2，类型 wire_type 的值是 0， 所以 : 2<<3|0 =16 第一个数字 10，代表的是 key，剩下的都是 value 负数的存储 在计算机中，负数会被表示为很大的整数，因为计算机定义负数符号位为数字的最高位，所以如果采用 varint 编码表示一个负数，那么一定需要 5 个比特位。所以在 protobuf 中通过sint32/sint64 类型来表示负数，负数的处理形式是先采用 zigzag 编码（把符号数转化为无符号数），再采用 varint 编码。 sint32：(n << 1) ^ (n >> 31) sint64：(n << 1) ^ (n >> 63) 比如存储一个（-300）的值 -300 原码：0001 0010 1100 取反：1110 1101 0011 加 1 ：1110 1101 0100 n<<1: 整体左移一位，右边补 0 -> 1101 1010 1000 n>>31: 整体右移 31 位，左边补 1 -> 1111 1111 1111 n<<1 ^ n >>31 1101 1010 1000 ^ 1111 1111 1111 = 0010 0101 0111 十进制： 0010 0101 0111 = 599 varint 算法： 从右往做，选取 7 位，高位补 1/0（取决于字节数） 得到两个字节 1101 0111 和 0000 0100 -41 和 4 Protocol Buffer 的性能好，主要体现在 序列化后的数据体积小 & 序列化速度快，最终使得传输效率高，其原因如下：

　　具体的缺点不太清楚，毕竟不是专业的人员，只能给你简单介绍下：　　Dubbo是一种服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。　　主要的核心部件：　　Remoting: 网络通信框架，实现了 sync-over-async 和　　request-response 消息机制.　　RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能　　Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

大部分人跳槽都选择年前筹备，年后跳槽，所以过年后的三四月，是找工作的黄金时期，企业人才缺口大，需要岗位多，所以称为金三银四！所以上春季班的学生春季入学，春季毕业，就业更有优势！

有可能是超时重试了 也有可能就是有两个dubbo的jar包

看看有没有报错，可能是触发到dubbo的重试机制，在service里面配置一下超时时间以及重试次数就可以了：@Service(timeout = 5000,retries = -1)

直连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面

这个做好了很牛了，但要有大量的知识做支撑:1 linux操作系统的知识，这里指的是linux内核的运作机制，如进程管理/内存管理等，总之需要懂得linux是怎么运作的。2 linux外围，如shell脚本/各种工具集这些3 分布式理论基础，可以看看hadoop这些开源分布式系统的实现原理4 大量的经验，系统集成是个大工程，经验永远是很重要的。5 一定的语言基础C++/JAVA

Dubbo有很长一段时间的发展史，2018年的时候不知道为什么阿里暂更了一年，之后又重新开始更新。之前一直是阿里在维护，后面阿里把它捐给了Apache基金会，由Apache来维护，2.6.x之前，maven中的包名都是alibaba，2.7.0之后包名改成了apache，其中整合入系统中有一些差异；发展史: Dubbo的原理什么的以及它的组成这里就不扯了，直接说说dubbo的项目结构吧。 基本的Dubbo项目组成分为三个部分： 接口层这里自定义了接口，实现部分由服务提供层来实现。建议将model也放在接口层中，接口层中对dubbo没有相关依赖，在这里pom就不提供了。

Remoting: 网络通信框架，实现了 sync-over-async 和 request-response 消息机制.RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能Registry: 服务目录框架用于服务的注册和服务事件发布和订阅

1、Dubbo与Spring的整合 Dubbo在使用上可以做到非常简单，不管是Provider还是Consumer都可以通过Spring的配置文件进行配置，配置完之后，就可以像使用 spring bean一样进行服务暴露和调用了，完全看不到dubbo api的存在。这是因为dubbo使用了spring提供的可扩展Schema自定义配置支持。在spring配置文件中，可以像、这样进行配置。 META-INF下的spring.handlers文件中指定了dubbo的xml解析类：DubboNamespaceHandler。像前面的被解 析成ServiceConfig，被解析成ReferenceConfig等等。 2、jdk spi扩展 由于Dubbo是开源框架，必须要提供很多的可扩展点。Dubbo是通过扩展jdk spi机制来实现可扩展的。具体来说，就是在META-INF目录下，放置文件名为接口全称，文件中为key、value键值对，value为具体实现类 的全类名，key为标志值。由于dubbo使用了url总线的设计，即很多参数通过URL对象来传递，在实际中，具体要用到哪个值，可以通过url中的参 数值来指定。 Dubbo对spi的扩展是通过ExtensionLoader来实现的，查看ExtensionLoader的源码，可以看到Dubbo对jdk spi做了三个方面的扩展：（1）jdk spi仅仅通过接口类名获取所有实现，而ExtensionLoader则通过接口类名和key值获取一个实现；（2）Adaptive实现，就是生成一个代理类，这样就可以根据实际调用时的一些参数动态决定要调用的类了。（3）自动包装实现，这种实现的类一般是自动激活的，常用于包装类，比如Protocol的两个实现类：ProtocolFilterWrapper、ProtocolListenerWrapper。 3、url总线设计 Dubbo为了使得各层解耦，采用了url总线的设计。我们通常的设计会把层与层之间的交互参数做成Model，这样层与层之间沟通成本比较大，扩展起来也比较麻烦。因此，Dubbo把各层之间的通信都采用url的形式。比如，注册中心启动时，参数的url为： registry://0.0.0.0:9090?codec=registry&transporter=netty 这就表示当前是注册中心，绑定到所有ip，端口是9090，解析器类型是registry，使用的底层网络通信框架是netty。 二、Dubbo启动过程Dubbo分为注册中心、服务提供者(provider)、服务消费者(consumer)三个部分。 1、注册中心启动过程 注册中心的启动过程，主要看两个类：RegistrySynchronizer、RegistryReceiver，两个类的初始化方法都是start。 RegistrySynchronizer的start方法：（1）把所有配置信息load到内存；（2）把当前注册中心信息保存到数据库；（3）启动5个定时器。 5个定时器的功能是： （1）AutoRedirectTask，自动重定向定时器。默认1小时运行1次。如果当前注册中心的连接数高于平均值的1.2倍，则将多出来的连接数重定向到其他注册中心上，以达到注册中心集群的连接数均衡。 （2）DirtyCheckTask，脏数据检查定时器。作用是：分别检查缓存provider、数据库provider、缓存consumer、数据库 consumer的数据，清除脏数据；清理不存活的provider和consumer数据；对于缓存中的存在的provider或consumer而数 据库不存在，重新注册和订阅。 （3）ChangedClearTask，changes变更表的定时清理任务。作用是读取changes表，清除过期数据。 （4）AlivedCheckTask，注册中心存活状态定时检查，会定时更新registries表的expire字段，用以判断注册中心的存活状态。如果有新的注册中心，发送同步消息，将当前所有注册中心的地址通知到所有客户端。 （5）ChangedCheckTask，变更检查定时器。检查changes表的变更，检查类型包括：参数覆盖变更、路由变更、服务消费者变更、权重变更、负载均衡变更。

首先是不建议采用XA两阶段提交方式去处理分布式事务，要知道要能够支持XA分布式事务，必须是要实现XA规范才可以，而Service本身是无状态的，如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。 可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析: 事务补偿机制 事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态，也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理，建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。 在这种情况下以上面例子来说，首先调用取款服务，完全调用成功并返回，数据已经持久化。然后调用异地的存款服务，如果也调用成功，则本身无任何问题。如果调用失败，则需要调用本地...首先是不建议采用XA两阶段提交方式去处理分布式事务，要知道要能够支持XA分布式事务，必须是要实现XA规范才可以，而Service本身是无状态的，如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。可以设想一个最简单的分布式事务场景，对于跨银行的转账操作，该操作涉及到调用两个异地的Service服务，一个是本地提供的取款服务，一个是目标银行提供的存款服务，该两个服务本身无状态且独立，构成一个完整的事务。对于事务的处理初步分析:事务补偿机制事务补偿即在事务链中的任何一个正向事务操作，都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链，则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态，也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理，建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。在这种情况下以上面例子来说，首先调用取款服务，完全调用成功并返回，数据已经持久化。然后调用异地的存款服务，如果也调用成功，则本身无任何问题。如果调用失败，则需要调用本地注册的逆向服务（本地存款服务），如果本地存款服务调用失败，则必须考虑重试，如果约定重试次数仍然不成功，则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件，由消息中间件接管后续操作。在上面方式中可以看到需要手工编写大量的代码来处理以保证事务的完整性，我们可以考虑实现一个通用的事务管理器，实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操作均在事务管理和协同器上注册，由事务管理器接管所有的事务补偿和回滚操作。基于消息的最终一致性在这里首先要回答的是我们需要时实时一致性还是最终一致性的问题，如果需要的是最终一致性，那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦，解耦的关键就是异步消息和消息持久化机制。还是以上面的例子来看。对于转账操作，原有的两个服务调用变化为第一步调用本地的取款服务，第二步发送异地取款的异步消息到消息中间件。如果第二步在本地，则保证事务的完整性基本无任何问题，即本身就是本地事务的管理机制。只要两个操作都成功即可以返回客户成功。由于解耦，我们看到客户得到成功返回的时候，如果是上面一种情况则异地卡马上就能查询账户存款增加。而第二种情况则不一定，因为本身是一种异步处理机制。消息中间件得到消息后会去对消息解析，然后调用异地银行提供的存款服务进行存款，如果服务调用失败则进行重试。异地银行存款操作不应该长久地出现异常而无法使用，因此一旦发现异常我们可以迅速的解决，消息中间件中异常服务自然会进行重试以保证事务的最终一致性。这种方式假设问题一定可以解决，在不到万不得已的情况下本地的取款服务一般不进行可逆操作。在本地取款到异地存款两个服务调用之间，会存在一个真空期，这段时间相关现金不在任何一个账户，而只是在一个事务的中间状态，但是客户并不关心这个，只要在约定的时间保证事务最终的一致性即可。关于等幂操作的问题重复调用多次产生的业务结果与调用一次产生的业务结果相同，简单点讲所有提供的业务服务，不管是正向还是逆向的业务服务，都必须要支持重试。因为服务调用失败这种异常必须考虑到，不能因为服务的多次调用而导致业务数据的累计增加或减少。关于是否可以补偿的问题在这里我们谈的是多个跨系统的业务服务组合成一个分布式事务，因此在对事务进行补偿的时候必须要考虑客户需要的是否一定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。在上面的例子来看，如果采用事务补偿机制，基本可以是做到准实时的补偿，不会有太大的影响。而如果采用基于消息的最终一致性方式，则可能整个周期比较长，需要较长的时间才能给得到最终的一致性。比如周六转款，客户可能下周一才得到通知转账不成功而进行了回退，那么就必须要考虑客户是否能给忍受。其次对于前面讨论，如果真正需要的是实时的一致性，那么即使采用事务补偿机制，也无法达到实时的一致性。即很可能在两个业务服务调用中间，客户前台业务操作对持久化的数据进行了其它额外的操作。在这种模式下，我们不得不考虑需要在数据库表增加业务状态锁的问题，即整个事务没有完整提交并成功前，第一个业务服务调用虽然持久化在数据库，但是仍然是一个中间状态，需要通过业务锁来标记，控制相关的业务操作和行为。但是在这种模式下无疑增加了整个分布式业务系统的复杂度。

一、Dubbo整体架构1、Dubbo与Spring的整合Dubbo在使用上可以做到非常简单，不管是Provider还是Consumer都可以通过Spring的配置文件进行配置，配置完之后，就可以像使用spring bean一样进行服务暴露和调用了，完全看不到dubbo api的存在。这是因为dubbo使用了spring提供的可扩展Schema自定义配置支持。在spring配置文件中，可以像、这样进行配置。META-INF下的spring.handlers文件中指定了dubbo的xml解析类：DubboNamespaceHandler。像前面的被解析成ServiceConfig，被解析成ReferenceConfig等等。 2、jdk spi扩展由于Dubbo是开源框架，必须要提供很多的可扩展点。Dubbo是通过扩展jdk spi机制来实现可扩展的。具体来说，就是在META-INF目录下，放置文件名为接口全称，文件中为key、value键值对，value为具体实现类的全类名，key为标志值。由于dubbo使用了url总线的设计，即很多参数通过URL对象来传递，在实际中，具体要用到哪个值，可以通过url中的参数值来指定。 Dubbo对spi的扩展是通过ExtensionLoader来实现的，查看ExtensionLoader的源码，可以看到Dubbo对jdk spi做了三个方面的扩展： （1）jdk spi仅仅通过接口类名获取所有实现，而ExtensionLoader则通过接口类名和key值获取一个实现；（2）Adaptive实现，就是生成一个代理类，这样就可以根据实际调用时的一些参数动态决定要调用的类了。 （3）自动包装实现，这种实现的类一般是自动激活的，常用于包装类，比如Protocol的两个实现类：ProtocolFilterWrapper、ProtocolListenerWrapper。 3、url总线设计Dubbo为了使得各层解耦，采用了url总线的设计。我们通常的设计会把层与层之间的交互参数做成Model，这样层与层之间沟通成本比较大，扩展起来也比较麻烦。因此，Dubbo把各层之间的通信都采用url的形式。比如，注册中心启动时，参数的url为： registry://0.0.0.0:9090?codec=registry&transporter=netty 这就表示当前是注册中心，绑定到所有ip，端口是9090，解析器类型是registry，使用的底层网络通信框架是netty。 二、Dubbo启动过程Dubbo分为注册中心、服务提供者(provider)、服务消费者(consumer)三个部分。 1、注册中心启动过程注册中心的启动过程，主要看两个类：RegistrySynchronizer、RegistryReceiver，两个类的初始化方法都是start。 RegistrySynchronizer的start方法： （1）把所有配置信息load到内存；（2）把当前注册中心信息保存到数据库； （3）启动5个定时器。 5个定时器的功能是： （1）AutoRedirectTask，自动重定向定时器。默认1小时运行1次。如果当前注册中心的连接数高于平均值的1.2倍，则将多出来的连接数重定向到其他注册中心上，以达到注册中心集群的连接数均衡。 （2）DirtyCheckTask，脏数据检查定时器。作用是：分别检查缓存provider、数据库provider、缓存consumer、数据库consumer的数据，清除脏数据；清理不存活的provider和consumer数据；对于缓存中的存在的provider或consumer而数据库不存在，重新注册和订阅。 （3）ChangedClearTask，changes变更表的定时清理任务。作用是读取changes表，清除过期数据。 （4）AlivedCheckTask，注册中心存活状态定时检查，会定时更新registries表的expire字段，用以判断注册中心的存活状态。如果有新的注册中心，发送同步消息，将当前所有注册中心的地址通知到所有客户端。 （5）ChangedCheckTask，变更检查定时器。检查changes表的变更，检查类型包括：参数覆盖变更、路由变更、服务消费者变更、权重变更、负载均衡变更。 RegistryReceiver的start方法：启动注册中心服务。默认使用netty框架，绑定本机的9090端口。最后启动服务的过程是在NettyServer来完成的。接收消息时，抛开dubbo协议的解码器，调用类的顺序是 NettyHandler-》NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》DecodeHandler-》HeaderExchangeHandler-》RegistryReceiver-》RegistryValidator-》RegistryFailover-》RegistryExecutor。2、provider启动过程provider的启动过程是从ServiceConfig的export方法开始进行的，具体步骤是： （1）进行本地jvm的暴露，不开放任何端口，以提供injvm这种形式的调用，这种调用只是本地调用，不涉及进程间通信。 （2）调用RegistryProtocol的export。 （3）调用DubboProtocol的export，默认开启20880端口，用以提供接收consumer的远程调用服务。 （4）通过新建RemoteRegistry来建立与注册中心的连接。 （5）将服务地址注册到注册中心。 （6）去注册中心订阅自己的服务。 3、consumer启动过程consumer的启动过程是通过ReferenceConfig的get方法进行的，具体步骤是： （1）通过新建RemoteRegistry来建立与注册中心的连接。 （2）新建RegistryDirectory并向注册中心订阅服务，RegistryDirectory用以维护注册中心获取的服务相关信息。 （3）创建代理类，发起consumer远程调用时，实际调用的是InvokerInvocationHandler。 三、实际调用过程consumer端发起调用时，实际调用经过的类是： 1、consumer: InvokerInvocationHandler-》MockClusterInvoker(如果配置了Mock，则直接调用本地Mock类)-》FailoverClusterInvoker(负载均衡，容错机制，默认在发生错误的情况下，进行两次重试)-》RegistryDirectory$InvokerDelegete-》ConsumerContextFilter-》FutureFilter->DubboInvoker NettyServer-》MultiMessageHandler-》HeartbeatHandler-》AllDispatcher-》DecodeHandler-》HeaderExchangeHandler-》DubboProtocol.requestHandler-》EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》TimeoutFilter-》MonitorFilter-》TraceFilter-》实际service。四、Dubbo使用的设计模式1、工厂模式ServiceConfig中有个字段，代码是这样的： private static final Protocol protocol = ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();Dubbo里有很多这种代码。这也是一种工厂模式，只是实现类的获取采用了jdk spi的机制。这么实现的优点是可扩展性强，想要扩展实现，只需要在classpath下增加个文件就可以了，代码零侵入。另外，像上面的Adaptive实现，可以做到调用时动态决定调用哪个实现，但是由于这种实现采用了动态代理，会造成代码调试比较麻烦，需要分析出实际调用的实现类。 2、装饰器模式Dubbo在启动和调用阶段都大量使用了装饰器模式。以Provider提供的调用链为例，具体的调用链代码是在ProtocolFilterWrapper的buildInvokerChain完成的，具体是将注解中含有group=provider的Filter实现，按照order排序，最后的调用顺序是 EchoFilter-》ClassLoaderFilter-》GenericFilter-》ContextFilter-》ExceptionFilter-》TimeoutFilter-》MonitorFilter-》TraceFilter。更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter的作用是判断是否是回声测试请求，是的话直接返回内容，这是一种责任链的体现。而像ClassLoaderFilter则只是在主功能上添加了功能，更改当前线程的ClassLoader，这是典型的装饰器模式。 3、观察者模式Dubbo的provider启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，采用了观察者模式，开启一个listener。注册中心会每5秒定时检查是否有服务更新，如果有更新，向该服务的提供者发送一个notify消息，provider接受到notify消息后，即运行NotifyListener的notify方法，执行监听器方法。 4、动态代理模式Dubbo扩展jdk spi的类ExtensionLoader的Adaptive实现是典型的动态代理实现。Dubbo需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪个实现类，所以采用先生成代理类的方法，能够做到灵活的调用。生成代理类的代码是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理类的主要逻辑是，获取URL参数中指定参数的值作为获取实现类的key。

这个做好了很牛了，但要有大量的知识做支撑: 1 linux操作系统的知识，这里指的是linux内核的运作机制，如进程管理/内存管理等，总之需要懂得linux是怎么运作的。 2 linux外围，如shell脚本/各种工具集这些 3 分布式理论基础，可以看看hadoop这些开源分布式系统的实现原理 4 大量的经验，系统集成是个大工程，经验永远是很重要的。 5 一定的语言基础C++/JAVA

dubbo调用模块核心功能是发起一个远程方法的调用并顺利拿到返回结果，其体系组成如下：1. 透明代理：通过动态代理技术，屏蔽远程调用细节以提高编程友好性。2. 负载均衡：当有多个提供者是，如何选择哪个进行调用的负载算法。3. 容错机制：当服务调用失败时采取的策略4. 调用方式：支持同步调用、异步调用5. 结果获取：指同步等待结果返回，还是异步通过回调通知获取结果。

微服务架构，主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用，其代表框架有 Spring cloud、Dubbo 等。微服务 Microservices 之父，马丁.福勒，对微服务大概的概述如下：就目前而言，对于微服务业界并没有一个统一的、标准的定义（While there is no precise definition of this architectural style ) 。但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。六种常见的微服务架构模式：1、聚合器微服务设计模式聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。代理微服务设计模式这是聚合模式的一个变种，在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。3、链式微服务设计模式这种模式在接收到请求后会产生一个经过合并的响应，在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。因此，服务调用链不宜过长，以免客户端长时间等待。4、分支微服务设计模式这种模式是聚合器模式的扩展，允许同时调用两个微服务链。5、数据共享微服务设计模式自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会导致数据重复和不一致。因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。6、异步消息传递微服务设计模式虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应。谐云微服务治理平台，就是基于Istio的Mesh方案完全透明支持Dubbo和SpringCloud等平台框架，无侵入、无开发语言限制的完整服务治理，整理功能上覆盖微服务总览、注册中心、配置中心、API网关和ServiceMesh的同时，还从多维度立体覆盖了微服务的运维监控。并能从服务拆分方法、技术选型与问题解决等方面指导客户开发微服务应用。

刚开始测试时候将所有容器都放在同一台主机中，测试过程很顺利，但是当进行Docker主机扩展，将容器部署在不同的主机时候，就发现一个奇怪的现象：应用之间调试不通了。这里对具体问题解释一下：Dubbo提供了一个方便的服务发现机制，每个服务（这里称为提供者）只要向Dubbo注册中心注册过，注册中心就会将服务的地址发送给同样在注册中心注册的服务调用方（这里称为消费者），之后即使Dubbo注册中心挂了也不影响服务的调用。

直连加不发布服务DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。下面我例举出通过哪些配置可以实现这种方案：服务消费端:DUBBO在消费端提供了一个url的属性来指定某个服务端的地址默认的方式是从注册中心发现接口为com.alibaba.dubbo.demo.HelloWorldService的服务，但是如果需要直连，可以在dubbo.properties下面配置dubbo.reference.helloWorldService.url=dubbo://ip:port/com.alibaba.dubbo.demo.HelloWorldService可以通过配置dubbo.reference.url=dubbo://ip:port/来让某个消费者系统的服务都指向制定的服务器地址（关于配置信息可以参考《DUBBO配置规则详解》）

dubbo的Filter在调用的什么阶段执行的呢Dubbo的Filter是一个调用另一个的，最后再执行业务代码。在这一行调下一个Filter，那么写在这行代码前面的代码就是在业务代码前拦截了，写在之后的代码就是执行完业务代码后拦截了。直连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。

周末看到社区的协议迁移开始被提交了pr，还没merge,打算拜读一下 看到 HttpRemoteInvocation 被更改了，这里是要把 json-rpc 协议转换为 http 协议 HTTP 请求本身也可以看做是 RPC 的一种具体形式。HTTP 请求也一样是可以从本地发一个信号到服务器，服务器上执行某个函数，然后返回一些信息给客户端。 经常用的一些数据通过HTTP协议来传输，thrift，grpc，xml-rpc，json-rpc都是通过HTTP传输的。也就说json-rpc是依赖http协议传输的，所以新建一个公共的代理协议，凡是用http协议传输的数据格式都设置这个协议，是比较好的方案。 根据dubbo的类机构继承图，是沿用SPI机制实现的 AbstractProxyProtocol 这里比较重要的是 protocolBindingRefer 方法。,构建一个DubboInvoker对象,根据dubbo的动态代理不断找到调用方的目标对象，添加到invoke当中，但这里没有指定要传输的格式，所以在dubbo序列化的时候还是会走默认的hessian协议，需要对协议中传入的格式进行校验 基本思路：将参数中的service(传输格式传入)设置到dubbo的代理，拿到代理之后添加到invoke的责任链当中，返回一个dubbo的代理对象给调用方

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案主要核心部件Remoting: 网络通信框架，实现了sync-over-async 和 request-response 消息机制.RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能Registry: 服务目录框架用于服务的注册和服务事件发布和订阅。Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

自定义的spring配置 基于sping 扩展schma 利用 DubboNamespaceHandler 实现对自定义schema的解析。见配置文件：spring.handlers spring.schemas 二，Consumer对于服务接口的透明调用 基于Javassist的动态代理模式，自动生成代理类。 通过InvokerInvocationHandler的invoker调用： return invoker.invoke(new RpcInvocation(method, args)).recreate(); invoker RPC通信，基于mina、netty等。 三，dubbo的扩展机制 实现方式类似sun的spi模式，实现自身的可扩展性。简单实现了接口的注入。 1，Extension 注解 value=组件的名字 具体实现见ExtensionLoader 2，主要方法： loadExtensionClasses 加载所有实现了META-INF/services目录下文件中的类，文件名为接口名。根据Extension注解的名字为key，CLASS为VALUE放到缓存的MAP中。 getAdaptiveExtension 利用代码生成创建一下接口的适配器类： Protocol Cluster ProxyFactory 等等 这个适配器类以Adaptive注解声明的值或者接口名为KEY，从URL中的参数或者URL getProtocol() 作为key的值， 然后ExtensionLoader.getExtensionLoader(Protocol.class).getExtension(key ) 获得

连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。

直连加不发布服务DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。下面我例举出通过哪些配置可以实现这种方案：服务消费端:DUBBO在消费端提供了一个url的属性来指定某个服务端的地址<!--lang:xml--><dubbo:reference interface="com.alibaba.dubbo.demo.HelloWorldService" check="false" id="helloWorldService"/>默认的方式是从注册中心发现接口为com.alibaba.dubbo.demo.HelloWorldService的服务，但是如果需要直连，可以在dubbo.properties下面配置dubbo.reference.helloWorldService.url=dubbo://ip:port/com.alibaba.dubbo.demo.HelloWorldService可以通过配置dubbo.reference.url=dubbo://ip:port/来让某个消费者系统的服务都指向制定的服务器地址（关于配置信息可以参考《DUBBO配置规则详解》）

看你怎么架构了，一般国内喜欢用dubbo这个soa框架，国外用spring cloud比较多，微服务架构

dubbo 的设计思路是微内核+插件， Filter 等插件被 dubbo 创建，而不是被 spring 创建。 Filter 和 spring 两不相认，如果想在 Filter 中使用被 spring 管理的对象，注入 spring 的bean，怎么办？ 在 Filter 中新建一个 setter 方法。此方法名称形如 setAbc ，有且仅有一个参数。 在 spring 上下文中定义一个名为“abc”的bean，类型要对。 如此即可实现，在 Fliter 被实例化后，此 setter 被调用，传入名为“abc”的bean（一定要类型正确，名字对上更好，详细算法见3.2节结尾处）。 （4.章介绍另一种机制， spring 利用 instrumentation ， load-time-weaver 令非 spring 管理的对象也能使用 spring 基础设施，开阔思路，不建议用） 这部分尽可能从现象到原因探索。 Filter 中的 setter 可被 dubbo 调起，在 spring 的 ApplicationContext 中按名字查找并塞进一个bean。 Filter 等插件被按 SPI 机制管理， com.alibaba.dubbo.common.extension.ExtensionLoader<T> 的 public T getExtension(String name) 函数被用于加载特定的插件，其中有一层缓存，真正的创建过程在 private T createExtension(String name) 函数中。 createExtension(...) 函数源码如下 可见其中的主要步骤： 再看 injectExtension(...) 函数源码： 可见其中的主要步骤： 属性 private final ExtensionFactory objectFactory 在私有构造函数中被初始化： 接口 ExtensionFactory 中只有一个方法，见源码： 按照 dubbo 的 SPI 机制的惯例，见 META-INF/dubbo/internal/com.alibaba.dubbo.common.extension.ExtensionFactory 内容： 关注“spring”名称对应的 SpringExtensionFactory ，其源码片段： 可见其中查找逻辑： 查找 SpringExtensionFactory 在哪里被调用，仅 ReferenceBean 和 ServiceBean ，这两个类是使用 dubbo-spring 一定绕不开的。 涉及 SpringExtensionFactory 的逻辑相似， ReferenceBean 和 ServiceBean 均实现了 ApplicationContextAware ，回调方法中有 （ ServiceBean 的此方法中多了增加监听器的功能） 可见其中调用了 SpringExtensionFactory 的静态方法 public static void addApplicationContext(ApplicationContext context) 核心思路是利用 instrumentation 和 load-time-weaver 。 启动时加入 -javaagent 参数，在自定义 Filter 上加 @Configurable 注解。 不建议的理由主要是需要修改启动脚本。

直连加不发布服务DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。

直连加不发布服务DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。

dubbo的Filter在调用的什么阶段执行的呢Dubbo的Filter是一个调用另一个的，最后再执行业务代码。在这一行调下一个Filter，那么写在这行代码前面的代码就是在业务代码前拦截了，写在之后的代码就是执行完业务代码后拦截了。直连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。

可以的DUBBO配置规则详解研究DUBBO也已经大半年了，对它的大部分源码进行了分析，以及对它的内部机制有了比较深入的了解，以及各个模块的实现。DUBBO包含很多内容，如果想了解DUBBO第一步就是启动它，从而可以很好的使用它，那么如何更好的使用呢？就需要知道DUBBO的各个配置项，以及它可以通过哪些途径进行配置。个人对配置的理解，就好比时对动物的驯服，如何很好的驯服一头猛兽，那就需要知道它各种因子，从而调整，已达到自己期望的结果。这篇不对DUBBO有哪些配置项可以配置，但是通过这篇文章，你应该能够知道DUBBO可以进行哪些配置。本文会通过分析DUBBO加载配置源码的分析，来使得大家对DUBBO的配置一块有更加深入的了解。从而达到“驯服”DUBBO，以使得它成为你们自己的DUBBO。DUBBO在配置这一块做的确实很完美，提供很很多参数，以及提供了多种渠道。下面进入正题，看看DUBBO怎么加载配置的。在讲这些之前，先给大家介绍一下在DUBBO源码层面定义了哪些类来存储各个模块的配置项，从而了解DUBBO可以对哪些模块进行配置。哪些东西可以配置由于大部分项目都会使用Spring，而且DUBBO也提供了通过Spring来进行配置，那么先从这里进行着手。DUBBO加载Spring的集成时在dubbo-config下面的dubbo-config-spring模块下面，其中有一个类DubboNamespaceHandler，它实现了Spring提供的接口NamespaceHandlerSupport。那么Spring怎么发现整个实现类的呢？在该模块的META-INF文件夹下有两个文件： spring.handlers和spring.schemas，这两个文件里面制定了dubbo的namespace的XSD文件的位置以及dubbo的namespace由DubboNamespaceHandler来处理解析。说了这么多废话，只是想说明Spring是怎么解析<dubbo:.../>配置的。知道了DUBBO和Spring关于配置一块时怎么整合的之后，那么你应该就不会诧异Spring怎么那么聪明，能够解析dubbo的namespace。接下来看看DubboNamespaceHandler类里面有什么东西。

直连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。

直连加不发布服务 DUBBO的配置属性里面对消费端提供了不从注册中心发现服务的机制，直接配置远程接口的地址，这样可以保证消费端连接到制定的环境接口。这样消费端是解决了问题，但是服务提供端呢？如上图的B1它即是消费端也是服务提供端，它提供A1所依赖的接口，那么如果B1将它的服务发布到注册中心里面(这里需要提醒，STABLE环境机制里面所有子环境公用一个注册中心)，那么势必会导致stable环境里面的A会发现B1提供的服务？势必会导致stable环境的不稳定（stable环境的机制是stable环境只能进不能出，就是不能调用外部其他子环境的服务）？所以B1不能发布服务到注册中心，dubbo也提供了相关的配置属性来支持这一点。

Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案主要核心部件Remoting: 网络通信框架，实现了sync-over-async 和 request-response 消息机制.RPC: 一个远程过程调用的抽象，支持负载均衡、容灾和集群功能Registry: 服务目录框架用于服务的注册和服务事件发布和订阅。Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

在分布式系统架构中多个系统之间通常是通过远程RPC调用进行通信，也就是 A 系统调用 B 系统服务，B 系统调用 C 系统的服务。当尾部应用 C 发生故障而系统 B 没有服务降级时候可能会导致 B，甚至系统 A 瘫痪，这种现象被称为雪崩现象。所以在系统设计时候要使用一定的降级策略，来保证当服务提供方服务不可用时候，服务调用方可以切换到降级后的策略进行执行。 我们可以把熔断器想象为一个保险丝，在电路系统中，一般在所有的家电系统连接外部供电的线路中间都会加一个保险丝，当外部电压过高，达到保险丝的熔点时候，保险丝就会被熔断，从而可以切断家电系统与外部电路的联通，进而保障家电系统不会因为电压过高而损坏。 Hystrix提供的熔断器就有类似功能，当在一定时间段内服务调用方调用服务提供方的服务的次数达到设定的阈值，并且出错的次数也达到设置的出错阈值，就会进行服务降级，让服务调用方之间执行本地设置的降级策略，而不再发起远程调用。但是Hystrix提供的熔断器具有自我反馈，自我恢复的功能，Hystrix会根据调用接口的情况，让熔断器在closed,open,half-open三种状态之间自动切换。 open状态说明打开熔断，也就是服务调用方执行本地降级策略，不进行远程调用。 closed状态说明关闭了熔断，这时候服务调用方直接发起远程调用。 half-open状态，则是一个中间状态，当熔断器处于这种状态时候，直接发起远程调用。 三种状态的转换： 那么有一个问题，用来判断熔断器从closed->open转换的数据是哪里来的那？其实这个是HystrixCommandMetrics对象来做的，该对象用来存在HystrixCommand的一些指标数据，比如接口调用次数，调用接口失败的次数等等，后面我们会讲解。 系统设计时候要使用一定的降级策略，来保证当服务提供方服务不可用时候，服务调用方可以切换到降级后的策略进行执行，Hystrix作为熔断器组件使用范围还是很广泛的. 更多关于分布式系统中服务降级策略的知识可以单击 单击我 想系统学dubbo的 单击我 想学并发的童鞋可以 单击我