Dubbo

序 本文主要研究一下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

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

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

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

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

安装   主机上的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

这几年来，微服务这个概念越来越火了，火到什么程度呢？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

转自：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(

分布式服务框架： –高性能和透明化的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，即回传