Dubbo

观看本篇博客，需要先看上篇： https://jym12138.blog.csdn.net/article/details/104445084 服务引用流程 先看 DubboNamespaceHandler类的 init方法，在定义属性的时候有这样一行代码: this . registerBeanDefinitionParser ( "reference" , new DubboBeanDefinitionParser ( ReferenceBean . class , false ) ) ; ReferenceBean 继承ReferenceConfig 实现了 FactoryBean接口 FactoryBean接口： 通过 Object getObject() 注册进ioc容器 调用了get方法。 在get方法进行判断，如果ref为空，初始化 init方法。 在init方法中调用了： this . ref = this . createProxy ( map ) ; 创建代理对象 createProxy方法调用了this.invoker = refprotocol.refer(this.interfaceClass, url); RegistryProtocol refer 方法 —> doRefer 在doRefer 方法里调用了 directory . subscribe

高可用：通过设计，减少系统不能提供服务的时间。 ZooKeeper宕机 现象：ZooKeeper注册中心宕机，还可以消费Dubbo暴露的服务。 原因： 注册中心全部宕机后，服务提供者和服务消费者仍能通过本地缓存通信 ； 监控中心宕机不影响使用，只是丢失部分采样数据； 数据库宕机后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务； 注册中心对等集群，任意一台宕机后，将自动切换到另一台； 服务提供者无状态，任意一台宕机后，不影响使用； 服务提供者全部宕机后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。 Dubbo直连 当没有注册中心时，可以绕过注册中心通过Dubbo直连的方式进行服务调用。只需在代码中加入一点： //通过url直接告诉调用者服务所在的地址 @Reference(url="127.0.0.1:20880") UserService userService; 负载均衡 集群模式下Dubbo负载均衡配置 服务降级 服务降级：当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运作或高效运作。 可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。 向注册中心写入动态配置覆盖规则： 其中： mock=force:return+null

RPC原理 一次完整的RPC调用流程如下（同步调用，异步另说）： 服务消费方（client）调用以本地调用方式调用服务 ； client stub（客户端代理）接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体； client stub找到服务地址，并将消息发送到服务端； server stub收到消息后进行解码（序列化与反序列化）； server stub根据解码结果调用本地的服务； 本地服务执行并将结果返回给server stub； server stub将返回结果打包成消息并发送至消费方； client stub接收到消息，并进行解码； 服务消费方得到最终结果 。 RPC框架的目标就是要将2~8这些步骤都封装起来，这些细节对用户来说是透明的，不可见的。 Netty通信原理 Netty是一个异步事件驱动的网络应用程序框架，用于快速开发可维护的高性能协议服务器和客户端。它极大地简化了TCP和UDP套接字服务器等网络编程。 Netty基于Java的NIO（Non-Blocking IO）进行通信。 Netty通信原理： 初始化Channel； 注册Channel到Selector； 轮询accept事件； 处理accept建立Channel； 注册Channel 到Selector； 轮询读写事件； 处理读写事件。 来源： CSDN 作者： xingze0516 链接：

1:新建 gmall-interface，boot-user-serivce-provider，boot-order-service-consumer三个maven工程 2：boot-user-serivce-provider，boot-order-service-consumer pom中添加如下： 3： gmall-interface 用于存放公共接口以及实体类，而且不需要任何依赖 public interface IOrderService { List initOrder(String id); } public interface IUserAddressService { List getUserAddress(String id); } public class UserVO implements Serializable{ private static final long serialVersionUID = 1L; private String id; private String userName; private String address; private Integer phoneNumber; } （为什么不能显示缩进呢？预览代码好丑!） 4:boot-user-serivce-provider工程结构： package com.zhou

转至 java那些事 2017-02-09 有些朋友工作一年了觉得该深入一下子了，所以想深入学习一下以提升自己的专业技能，想问一下如何入门Java分布式应用，学习过程大致是怎么样的，涉及到那些知识，框架呢？有那些资料可以推荐？ 所以在网络上找了一些资源给大家分享一下！ 首先推荐4本书（京东就有） 大型分布式网站架构设计与实践 大型网站技术架构：核心原理与案例分析》 ，大型网站系统与Java中间件实践 《分布式Java应用：基础与实践》 貌似都是4位阿里人写的，一本一本的看吧，绝对会增强你的内功。 小小的总结 分布式架构的演进 系统架构演化历程-初始阶段架构 初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP 特征： 应用程序、数据库、文件等所有的资源都在一台服务器上。 描述： 通常服务器操作系统使用linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用Mysql，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。 系统架构演化历程-应用服务和数据服务分离 好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver 特征： 应用程序、数据库、文件分别部署在独立的资源上。 描述： 数据量增加，单台服务器性能及存储空间不足

Dubbo的服务暴露是一个重要的特性，了解其机制很重要。之前有很多人写了有关的源代码分析，在本文中不再重新分析。官方文档中的一篇写的就很好，本文主要是有关内容进行补充与总结。 传送门： 服务导出 为什么要服务暴露 服务暴露分为远程暴露和本地暴露。在远程服务暴露中会将服务信息上传到注册中心。这时客户端要调用某个服务时会从注册中心找到该服务的远程地址等信息。然后客户端根据这个地址进行远程调用。服务端接收到远程调用请求后会最终调用 getInvoker() 方法进行查找对用的 invoker 。在 getInvoker() 方法中会从一个HashMap中进行查找，如果在这个Map中查找不到就会抛出异常。在远程服务暴露中，会按照规则将实例Invoker存储在HashMap中，其中Key名包含端口、接口名、接口版本和接口分组。所以进行服务暴露很重要。 本地服务暴露是暴露在JVM中，不需要远程通信。Dubbo会默认把远程服务用injvm协议再暴露一份。 为什么会有本地服务暴露 在Dubbo中，一个服务可以即是provider,又是Consumer,因此就存在它自己调用自己服务的时候，如果再通过网络去访问，那么就是舍近求远，因此有了本地暴露服务这个设计。消费者可以直接消费同一个JVM内部的服务，避免了跨网络进行远程通信。 服务暴露起点 我们会通过XML或注解的方式来指定要暴露的服务。l例子如下：

1、什么是Dubbo 概述: Dubbo是阿里巴巴内部使用的分布式业务框架，2012年由阿里巴巴开源，由于Dubbo在阿里内部经过广泛的业务验证，在很短时间内，Dubbo就被许多互联网公司所采用，并产生了许多衍生版本，如网易，京东，新浪，当当等等。由于阿里策略变化，2014年10月Dubbo停止维护。随后部分互联网公司公开了自行维护的Dubbo版本，比较著名的如当当DubboX，新浪Motan等。经过三年的沉寂，在2017年9月，阿里宣布重启Dubbo项目，并决策在未来对开源进行长期持续的投入。随后Dubbo开始了密集的更新，并将停摆三年以来大量分支上的特性及缺陷修正快速整合。 基于rpc： rpc远程过程调用协议；是JDK底层提出的协议,Dubbo只是对这个协议的实现的一个框架技术； rpc协议就是跨服务器,跨tomcat； 可以从一个项目调用另一个项目中的方法 2、作用 跨项目调用方法， 从一个项目中的Controller可以调用另一个项目中的service方法 3、同类型的技术有哪些 Dubbo： DubboX 优点：传输效率快 缺点：Controller和Service两个项目必须都是Java语言实现 springCloud webService技术 4、如何使用 ①.服务层注解 service实现类上写@service注解 写此注解的时候,注意先包

1、创建生产者maven项目 ①目录结构 ②添加pom文件依赖 <properties> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> <maven.compiler.source>1.8</maven.compiler.source> <maven.compiler.target>1.8</maven.compiler.target> <spring.version>5.1.7.RELEASE</spring.version> </properties> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.11</version> <scope>test</scope> </dependency> <!-- Spring --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId

一、分布式应用 在分布式系统中，国内常用zookeeper+dubbo组合，而Spring Boot推荐使用全栈的Spring，Spring Boot+Spring Cloud。 分布式系统： 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。 流动计算架构 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。 二、Zookeeper和Dubbo ZooKeeper ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。 Dubbo

为什么用springcloud，和传统rpc相比有什么好处？和dubbo相比呢？ 一 . 答：在传统rpc（如httpclient）远程调用中，服务与服务依赖关系，管理比较复杂，所以需要使用 服务治理，管理服务与服务之间依赖关系 ，可以实现 1.服务调用、负载均衡、容错等；(注意是本地负载均衡，即:调用者拿到服务方调用信息之后，就像本地调用一样的使用调用方法。和传统nginx负载均衡是有区别的) 2.实现服务注册与发现 。（ 服务提供者会把当前自己服务器的信息 比如服务地址通讯地址等以别名方式注册到注册中心上 ； 调用者以别名的方式去注册中心上获取到实际的服务器的信息 ，然后在实现本地rpc调用远程 还有一个很好的优点，动态注册与发现，即服务注册中心不用重启，提供者可以开启一个新的服务，注册中心会检测到它。 ） 二 . 答： Dubbo仅仅是一个实现了远程调用的RPC框架,服务化的中间件则需要自己开发;而 SpringCloud 则是实施微服务的一系列套件,包括: 远程调用负载均衡、服务注册与发现、断路器服务保护、服务状态监控、分布式配置中心、智能路由网关 、一次性令牌、全局锁、分布式会话管理、集群状态管理等 springcloud和dubbo 组件运行流程对比 下图中的每个组件都是需要部署在单独的服务器上，gateway用来接受前端请求、聚合服务，并批量调用后台原子服务