Dubbo

聊聊skywalking的dubbo-2.7.x-plugin

荒凉一梦 提交于 2020-03-12 00:13:13
序 本文主要研究一下skywalking的dubbo-2.7.x-plugin skywalking-plugin.def skywalking-6.6.0/apm-sniffer/apm-sdk-plugin/dubbo-2.7.x-plugin/src/main/resources/skywalking-plugin.def dubbo=org.apache.skywalking.apm.plugin.asf.dubbo.DubboInstrumentation skywalking的dubbo-plugin提供了DubboInstrumentation增强 DubboInstrumentation skywalking-6.6.0/apm-sniffer/apm-sdk-plugin/dubbo-2.7.x-plugin/src/main/java/org/apache/skywalking/apm/plugin/asf/dubbo/DubboInstrumentation.java public class DubboInstrumentation extends ClassInstanceMethodsEnhancePluginDefine { private static final String ENHANCE_CLASS = "org.apache.dubbo

分布式服务框架dubbo原理解析

老子叫甜甜 提交于 2020-03-11 21:48:22
alibaba有好几个分布式框架,主要有:进行远程调用(类似于RMI的这种远程调用)的(dubbo、hsf),jms消息服务(napoli、notify),KV数据库(tair)等。这个框架/工具/产品在实现的时候,都考虑到了容灾,扩展,负载均衡,于是出现一个配置中心(ConfigServer)的东西来解决这些问题。 基本原理如图: 在我们的系统中,经常会有一些跨系统的调用,如在A系统中要调用B系统的一个服务,我们可能会使用RMI直接来进行,B系统发布一个RMI接口服务,然后A系统就来通过RMI调用这个接口,为了解决容灾,扩展,负载均衡的问题,我们可能会想很多办法,alibaba的这个办法感觉不错。 本文只说dubbo,原理如下: ConfigServer 配置中心,和每个Server/Client之间会作一个实时的心跳检测(因为它们都是建立的Socket长连接),比如几秒钟检测一次。收集每个Server提供的服务的信息,每个Client的信息,整理出一个服务列表,如: serviceName serverAddressList clientAddressList UserService 192.168.0.1,192.168.0.2,192.168.0.3,192.168.0.4 172.16.0.1,172.16.0.2 ProductService 192.168.0.3

RPC

会有一股神秘感。 提交于 2020-03-11 21:35:06
rpc(Remote Procedure Call) 概念:rpc(远程过程调用)是一个通信协议,该协议允许运行于一台计算机的程序调用另一台计算机的程序。 角色: 消费方: 客户端(client) 负责发起服务的调用。 客户端存根(client stub) 负责与提供方通信: 1>存放着提供方的地址等信息。 2>将客户端的请求参数打包成网络消息,然后(通过socket)发送给提供方。 3>(通过socket)接收提供方返回的消息,并将消息解包然后将执行的结果返回给客户端。 提供方: 服务器(server) 服务提供者、执行者,将执行的结果返回给服务端存根。 服务端存根(server stub) (通过socket)接收消费方发送过来的消息,将消息解包,并调用服务器上的服务,最后将执行结果打包成消息(通过socket)发送给消费方。 RPC请求调用的流程: 请求:消费方 =======> 提供方 客户端 --> 客户端存根 --> 服务端存根 --> 服务器:执行请求。 响应:提供方 =======> 消费方 服务器 --> 服务端存根 --> 客户端存根 --> 客户端:得到请求的结果。 和http请求的对比: 性能: http协议传输的报文比较臃肿,rpc传输的报文相对较小,故rpc的传输效率更高一些。 rpc框架一般都支持多种高效的序列化机制

Dubbo基本原理

不羁的心 提交于 2020-03-11 19:42:16
简介: Dubbo是阿里巴巴开源的高性能RPC框架,该框架可以采用Spring配置方式,透明化接入应用,只需要Spring加载Dubbo配置即可。 调用流程 调用说明: 服务容器负责启动,加载,运行服务提供者。 服务提供者在启动时,向注册中心注册自己提供的服务。 服务消费者在启动时,向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。 系统架构 Dubbo底层架构主要分为十层: Service层:业务接口层,主要为提供方和消费方接口的设计与实现。 Config层:系统配置层,以ReferenceConfig与ServiceConfig为核心,可以初始化配置,也可以通过Spring解析生成配置类。 Proxy层:服务代理层,主要负责给provider与consumer生成代理对象,使其可以进行网络通信。 Register层:服务注册层,封装服务注册与发现的相关实现功能。 CLuster层:集群层,封装provider的路由与负载均衡相关功能。 Monitor层:监控层,统计RPC调用信息,包括访问时间有访问次数记录。

微服务治理实践 | 金丝雀发布

拟墨画扇 提交于 2020-03-11 17:54:38
前言 阿里巴巴集团内部有不少故障是因为发布直接或间接引起。因此提升发布的质量,减少错误的发生,是有效减少线上故障的一个关键环节。 为什么大部分的故障和发布相关?因为发布是整个功能更新到线上的最后一个环节,一些研发过程中累计的问题,在最后发布环节才会触发。同时发布本身也是一个复杂的过程,在发布过程中,往往容易出现一些错误操作或者遗漏关键操作。 日常发布中,我们常常会有如下一些错误的想法: 这次改动的内容比较小,而且上线要求比较急,就不需要测试直接发布上线好了 发布不需要走灰度流程,快速发布上线即可 灰度发布没有什么用,就是一个流程而已,发布完就直接发布线上,不用等待观察 虽然灰度发布很重要,但是灰度环境很难搭建,耗时耗力优先级并不高 这些想法都可能让我们进行一次错误的发布。 阿里巴巴内部有安全生产三板斧概念: 可灰度、可观测、可回滚。所有研发同学必须要掌握发布系统的灰度、观测和回滚功能如何使用。 今天我们来聊聊灰度发布。 灰度发布策略 灰度发布是发布整个过程中一个非常重要的环境。目前灰度发布策略有这几种: 蓝绿发布(Blue-Green Deployment) 通过部署两套环境来解决新老版本的发布问题。如果新版本(New Version)发生问题要进行回滚的时候,直接通过切流将流量全部切到老版本(Old Version)上。 优点:升级切换和回退比发布回滚迅速 缺点:成本较高

0基础教你搭建一套可自动化构建的微服务框架(SpringBoot+Dubbo+Docker+Jenkins)

倖福魔咒の 提交于 2020-03-11 11:08:05
本文你将学到什么? 本文将以原理+实战的方式,首先对“微服务”相关的概念进行知识点扫盲,然后开始手把手教你搭建这一整套的微服务系统。 项目完整源码下载 https://github.com/bz51/SpringBoot-Dubbo-Docker-Jenkins 这套微服务框架能干啥? 这套系统搭建完之后,那可就厉害了: 微服务架构 你的整个应用程序将会被拆分成一个个功能独立的子系统,独立运行,系统与系统之间通过RPC接口通信。这样这些系统之间的耦合度大大降低,你的系统将非常容易扩展,团队协作效率提升了N个档次。这种架构通过眼下流行的SpringBoot和阿里巴巴吊炸天的Dubbo框架来实现。 容器化部署 你的各个微服务将采用目前处于浪潮之巅的Docker来实现容器化部署,避免一切因环境引起的各种问题,让你们团队的全部精力集中在业务开发上。 自动化构建 项目被微服务化后,各个服务之间的关系错中复杂,打包构建的工作量相当可怕。不过没关系,本文将借助Jenkins,帮助你一键自动化部署,从此你便告别了加班。 知识点扫盲篇 咳咳,敲黑板啦!笔记赶紧记起来,课后我要检查的!检查不合格的同学放学后留下来! 知识点1:微服务 微服务一次近几年相当火,成为程序猿饭前便后装逼热门词汇,你不对它有所了解如何在程序猿装逼圈子里混?下面我用最为通俗易懂的语言介绍它。 要讲清楚微服务

dubbo-admin for docker

↘锁芯ラ 提交于 2020-03-11 11:01:43
安装   主机上的dubbo-admin服务是基于docker安装的,具体安装脚本如下: docker run --detach \ --restart always \ --name dubbo-admin \ --publish 8081:8080 \ -e admin.registry.address=zookeeper://192.168.3.72:2181 \ -e admin.config-center=zookeeper://192.168.3.72:2181 \ -e admin.metadata-report.address=zookeeper://192.168.3.72:2181 \ apache/dubbo-admin:0.1.0 重启 docker restart dubbo-admin 关闭 docker stop dubbo-admin 卸载 docker rm dubbo-admin 来源: oschina 链接: https://my.oschina.net/qwfys200/blog/3191545

一个成功的程序员,自然要懂微服务,汇总微服务架构的15钟框架!

左心房为你撑大大i 提交于 2020-03-11 07:02:24
这几年来,微服务这个概念越来越火了,火到什么程度呢?2019年有一个统计说,两千家企业里,45%在使用微服务,16%在实验开发和测试微服务架构,24%在学习微服务准备转型,只有剩下的15%的企业没有使用微服务。 微服务到底有什么好呢?微服务在2013年才被提出,短短几年就有这么快速的发展。微服务架构能够实现由小型自主服务组成一个整体应用,各个组成部分之间是松耦合的,复杂性低,各个部分可以独立部署,修复bug或者引入新特性更容易,能够独立扩展,不同技术栈之间可以使用不同框架、不同版本库甚至不同的操作系统平台。 对于中大型架构系统来说,微服务更加便捷,微服务成为很多企业架构重构的方向,同时也对架构师提出更高的挑战。目前有很多常用于微服务构建的框架,对于构建微服务架构能够带来一些帮助。 Java语言相关微服务框架 1.Spring Boot Spring Boot的设计目的是简化新Spring应用初始搭建以及开发过程,2017年有64.4%的受访者决定使用Spring Boot,可以说是最受欢迎的微服务开发框架。利用Spring Boot开发的便捷度简化分布式系统基础设施的开发,比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。 2.Spring Cloud Spring Cloud是一个系列框架的合计,基于HTTP(s)的RETS服务构建服务体系,Spring

Dubbo基本原理机制

|▌冷眼眸甩不掉的悲伤 提交于 2020-03-11 06:49:10
转自:http://blog.csdn.net/paul_wei2008/article/details/19355681 分布式服务框架: –高性能和透明化的RPC远程服务调用方案 –SOA服务治理方案 -Apache MINA 框架基于Reactor模型通信框架,基于TCP长连接 Dubbo缺省协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况。 分析源代码,基本原理如下: client一个线程调用远程接口,生成一个唯一的ID(比如一段随机字符串,UUID等),Dubbo是使用AtomicLong从0开始累计数字的 将打包的方法调用信息(如调用的接口名称,方法名称,参数值列表等),和处理结果的回调对象callback,全部封装在一起,组成一个对象object 向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object) 将ID和打包的方法调用信息封装成一对象connRequest,使用IoSession.write(connRequest)异步发送出去 当前线程再使用callback的get()方法试图获取远程返回的结果,在get()内部,则使用synchronized获取回调对象callback的锁, 再先检测是否已经获取到结果,如果没有,然后调用callback的wait(

Dubbo基本原理机制

被刻印的时光 ゝ 提交于 2020-03-11 05:26:57
分布式服务框架: –高性能和透明化的RPC远程服务调用方案 –SOA服务治理方案 -Apache MINA 框架基于Reactor模型通信框架,基于tcp长连接 Dubbo缺省协议采用单一长连接和NIO异步通讯, 适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况 分析源代码,基本原理如下: client一个线程调用远程接口,生成一个唯一的ID(比如一段随机字符串,UUID等),Dubbo是使用AtomicLong从0开始累计数字的 将打包的方法调用信息(如调用的接口名称,方法名称,参数值列表等),和处理结果的回调对象callback,全部封装在一起,组成一个对象object 向专门存放调用信息的全局ConcurrentHashMap里面put(ID, object) 将ID和打包的方法调用信息封装成一对象connRequest,使用IoSession.write(connRequest)异步发送出去 当前线程再使用callback的get()方法试图获取远程返回的结果,在get()内部,则使用synchronized获取回调对象callback的锁, 再先检测是否已经获取到结果,如果没有,然后调用callback的wait()方法,释放callback上的锁,让当前线程处于等待状态。 服务端接收到请求并处理后,将结果(此结果中包含了前面的ID,即回传