Dubbo

1.描述下数据库中的事务--ACID各个的特点 原子性（Atomicity）：事务中的操作要么全部成功要么全部失败。 一致性（Consistency）：事务前后数据的完整性必须保持一致。 隔离性（Isolation）：多个并发的事务之间是相互隔离的，互不干扰的。 持久性（Durability）：事务提交后，数据是永久改变的。 2.什么是springboot？你们公司是用的哪个版本？ SpringBoot是Spring推出用于解决传统框架配置文件冗余,装配组件操作繁杂并基于Maven的解决方案,主要目的是能够快速搭建单个微服务。 Spring boot 的优点 轻松创建独立的Spring应用程序 内联Tomcat、jetty等web容器，不需要部署WAR文件。 提供一系列的“starter”来简化的Maven配置 开箱即用，尽可能自动配置Spring 版本号：2.1.6 3.什么是redis？ Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。 Redis优势 性能极高-Redis能读的速度是110000次/s，写的速度是81000次/s 。 丰富的数据类型-Redis支持二进制案列的String，Lists,Hashes,Sets及Ordered Sets 数据类型操作。 原子—Redis的所有操作都是原子性（不可再分）的

一.项目搭建 1.步骤 建立一个空项目，添加两个springboot模块：provide-server和consumer-server 一个提供服务另一个消费服务（略） 两个模块的pom.xml中都导入依赖 编写provide-server代码 编写consumer-server代码 启动dubbo和zookeeper（略） 启动provide-server和consumer-server（略） 查看dubbo后台 2.两个模块的pom.xml中都导入依赖 <!-- Dubbo Spring Boot Starter --> <dependency> <groupId>org.apache.dubbo</groupId> <artifactId>dubbo-spring-boot-starter</artifactId> <version>2.7.3</version> </dependency> <!--zkclient--> <dependency> <groupId>com.github.sgroschupf</groupId> <artifactId>zkclient</artifactId> <version>0.1</version> </dependency> <!-- 引入zookeeper --> <dependency> <groupId>org.apache

研读dubbo源码已经有一段时间了，dubbo中有非常多优秀的设计模式和示例代码值得学习，但是dubbo的调用层级和方法链都较为繁杂，如果不对源码思路进行梳理则很容易忘却，因此总结一篇研读心得，从 阅读源码的思路 、 应用调配的参数 以及 面试准备上 对此进行一个全面总结。 一、dubbo的架构思路 1.1 dubbo框架设计 dubbo官网的 架构设计 提供了一张整体的框架图，10个层级看起来挺吓人的。但是其核心总结起来就是： Microkernel + Plugin（微内核+插件） 。 官网介绍的架构设计思想是两点： 采用 URL 作为配置信息的统一格式，所有扩展点都通过传递 URL 携带配置信息； 采用 Microkernel + Plugin 模式，Microkernel 只负责组装 Plugin，Dubbo 自身的功能也是通过扩展点实现的，也就是 Dubbo 的所有功能点都可被用户自定义扩展所替换。 对于第一点比较容易理解，因为是分布式环境，各系统之间的参数传递基于URL来携带配置信息，所有的参数都封装成 Dubbo 自定义的 URL 对象进行传递。URL 对象主要包括以下属性： String protocol String host int port String path Map < String , String > parameters 第二点

多版本 当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用，用法如下： <dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" version="1.0.0" /> 利用dubbo该特性，我们能够实现一些功能的灰度发布，实现步骤如下： 接口旧的实现定义version="1.0.0"，接口新的实现version="2.0.0" Consumer端定义version="*" 这样定义Provider和Consumer后，新旧接口实现各承担 50% 的流量； 利用dubbo该特性，还能完成不兼容版本迁移： 在低压力时间段，先升级一半Provider为新版本； 再将所有消费者升级为新版本； 然后将剩下的一半提供者升级为新版本。 来源： https://www.cnblogs.com/jingqi123/p/12446676.html

摘自： https://www.cnblogs.com/yangyuanhu/p/12439106.html Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 2 | 0 什么是RPC RPC全称(Remote Procedure Call)远程过程调用 过程指的是某个代码片段的执行,远程调用则意味着我们可以在其他进程,甚至其他机器上去调用这段代码,当然也能获取到其执行后的返回值,按照这个定义,我们请求某个http地址得到相应数据其实也算一次RPC,但是这样的方式太过麻烦,(数据要先打包成http请求格式,在调用相关的请求库,拿到的结果也是文本格式的需要在进行转换),执行效率,和开发效率相比RPC则低一些; 我们需要一种更简单的方式来完成分布式开发中的RPC环节,这也是Dubbo的核心所在,有多简单呢? 调用远程服务器上的某个服务时就像是调用本地的某个方法一样简单,就像下面这样 2 | 1 为什么需要rpc RPC是用来实现分布式构架的基石,分布式构架将同一个系统中的不同模块拆分到不同的子系统中,而子系统又分布在不同的服务器上,这时就需要RPC在来完成子系统之间的相互访问; 可以这么说分布式少不了RPC,RPC也要在分布式系统中才能发挥其核心价值; 2 | 2 rpc的实现原理

转： Dubbo 服务治理-mock实例 老生住长亭 2017.02.28 10:56* 字数 514 阅读 2552 评论 10 喜欢 2 Dubbo的mock自己折腾的实例，配置信息有点简陋，有点粗鄙，如果是处女座的程序员，就建议看看就行哈。 其实Dubbo的mock的实例原理简单而言就是调用真实的接口实现类不通，就会调用你的mock类（mock类和真实实现类都Implements 同一个接口，自己mock的名字要是：接口类名+mock）。 我这个人直接来例子，不太喜欢讲太多文绉绉的字。处女座的程序员就是这样的哈，比较直接。 接口定义和mock定义（可单独在一个maven module） 接口类： package cn.nest.facde; public interface HelloService { String sayHello(String content); } mock类（mock类和接口类要在同一个项目中，其他项目方便maven依赖）： package cn.nest.facde; @SuppressWarnings("unused") public class HelloServiceMock implements HelloService { public HelloServiceMock() { } @Override public String

1.Dubbo介绍 Dubbo,一个是一款高性能Java RPC框架.私以为有 中文官方文档 ，就不再重复介绍了 2.RPC扩展-本地存根stub RPC扩展功能：提前效验参数，缓存调用结果，日志记录等等，可以使用AOP织入这些扩展功能，但Dubbo提供了更灵活简单的实现-本地存根stub。 3.本地Mock-本地伪装mock RPC在服务异常时，请求返回mock的(假)数据，而不是简单的抛出异常，达到服务降级和本地mock的效果.只有在服务抛出异常时才会调用。 4.调用流程 服务消费者发起调用 如果服务消费者端存在本地存根 Stub 的话，会先执行本地存根 本地存根 Stub 持有远程服务的 Proxy 对象，Stub 在执行的时候，会先执行自己的逻辑 (before)，然后通过 Proxy 发起远程调用，最后在返回过程之前也会执行自己的逻辑 (after-returning) 如果远程服务的 Proxy 对象在执行过程中抛出了 exception，会执行服务消费端的本地伪装 Mock 的逻辑 (after-throwing)，返回容错数据，从而达到服务降级的目的 5.本地存根实例 定义一个demo接口 public interface DemoService { String sayHello(String name); } 根据约定大于配置原则，实现一个demo的stub实例

文章目录 1 zookeeper简介 1.1 数据发布与订阅（配置中心） 1.2 负载均衡 1.3 命名服务(Naming Service) 1.4 分布式通知/协调 1.5 集群管理与 Master 选举 1.6 分布式锁 1.7 分布式队列 1 zookeeper简介 ZooKeeper 是一个高可用的分布式数据管理不系统协调框架。基于对 Paxos 算法的实现，使该框架保证了分布式环境中数据的强一致性，也正是基于这样的特性，使得 ZooKeeper 解决很多分布式问题。 网上对 ZK 的应用场景也有不少介绍，本文将系统地对 ZK 的应用场景迚行一个分门归类的介绍。 值得注意的是， ZK 并非天生就是为这些应用场景设计的，都是后来众多开发者根据其框架的特性，利用其提供的一系列 API 接口，摸索出来的典型使用方法。 1.1 数据发布与订阅（配置中心） 发布不订阅模型，即所谓的 配置中心 ，顾名思义就是发布者将数据发布到 ZK 节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。 应用中用到的一些配置信息放到 ZK 上迚行集中管理。这类场景通常是这样：应用在启劢的时候会主动来获取一次配置，同时，在节点上注册一个 Watcher ，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端

什么是Dubbo Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 什么是RPC RPC全称(Remote Procedure Call)远程过程调用 过程指的是某个代码片段的执行,远程调用则意味着我们可以在其他进程,甚至其他机器上去调用这段代码,当然也能获取到其执行后的返回值,按照这个定义,我们请求某个http地址得到相应数据其实也算一次RPC,但是这样的方式太过麻烦,(数据要先打包成http请求格式,在调用相关的请求库,拿到的结果也是文本格式的需要在进行转换),执行效率,和开发效率相比RPC则低一些; 我们需要一种更简单的方式来完成分布式开发中的RPC环节,这也是Dubbo的核心所在,有多简单呢? 调用远程服务器上的某个服务时就像是调用本地的某个方法一样简单,就像下面这样 为什么需要rpc RPC是用来实现分布式构架的基石,分布式构架将同一个系统中的不同模块拆分到不同的子系统中,而子系统又分布在不同的服务器上,这时就需要RPC在来完成子系统之间的相互访问; 可以这么说分布式少不了RPC,RPC也要在分布式系统中才能发挥其核心价值; rpc的实现原理 毫无以为底层肯定是要通过socket来进行网络通讯的,但是如何能够直接调用另一个机器上的方法呢? 服务消费方（client

出处： 浅析dubbo原理和实现 一、Duboo基本概念解释 Dubbo是一种分布式服务框架。 Webservice也是一种服务框架，但是webservice并不是分布式的服务框架，他需要结合F5实现负载均衡。因此，dubbo除了可以提供服务之外，还可以实现软负载均衡。它还提供了两个功能Monitor 监控中心和调用中心。这两个是可选的，需要单独配置。 Dubbo的计数架构图如下： 我们解释以下这个架构图： 　　Consumer服务消费者，Provider服务提供者。Container服务容器。消费当然是invoke提供者了，invoke这条实线按照图上的说明当然同步的意思了，多说一句，在实际调用过程中，Provider的位置对于Consumer来说是透明的，上一次调用服务的位置（IP地址）和下一次调用服务的位置，是不确定的。这个地方就是实现了软负载。 　　Monitor这是一个监控，图中虚线表明Consumer 和Provider通过异步的方式发送消息至Monitor，Consumer和Provider会将信息存放在本地磁盘，平均1min会发送一次信息。Monitor在整个架构中是可选的（图中的虚线并不是可选的意思），Monitor功能需要单独配置，不配置或者配置以后，Monitor挂掉并不会影响服务的调用 二 分析源代码，基本原理如下： 　　1：client一个线程调用远程接口