Dubbo

目录 一、分布式基本知识 1.1) 架构演变 1.2)、分布式基本概念 二、RPC简介 2.1) RPC概念 2.2) RPC核心模块 三、Dubbo原理简介 3.1) Dubbo简介 3.2) 核心功能 3.3) 原理简介 四、Dubbo安装部署 4.1) Zookeeper安装 4.2) Dubbo监控平台部署 一、分布式基本知识 1.1) 架构演变 先给出dubbo官方的图，图片表示了架构的演变。然后我说一下自己的理解。 应用最开始是单体应用，即一个应用包括了所有应用模块。 随后就是垂直应用架构，也就是将系统拆分为多个应用模块。 随后就是RPC架构，之前的垂直应用架构其实可以说是在一个进程内的通讯，而RPC就是一种进步，RPC是进程之间的通讯，远程过程调用就是这么来的。 有了RPC之后，虽然可以实现进程之间的通讯，但是服务器集群后的服务器资源利用有些时候容易造成浪费，比如有个系统，一般情况都是不能很好地预估需要分配多少机器的，很容易造成一种情况就是业务访问很频繁的模块分配了不足的机器，而访问不是很频繁的模块分配了太多的机器，这种情况就不能实现资源的很好利用，所以针对这种情况就有了SOA(Service Oriented Architecture)的出现，SOA其实就是一个服务注册中心，可以实现资源调度，合理地分配资源，提高资源调度，是一个治理中心。 1.2)、分布式基本概念

一、Dubbo 创造者对于Dubbo的价值与意义作出过精辟的见解 1、单一应用架构 网站流量很小，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本 此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。 2、垂直应用架构 访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率， 此时，用于加速前端页面开发的 Web框架(MVC) 是关键。 3、分布式服务架构 垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求， 此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。 4、流动计算架构 服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率， 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。 关键在于第3向第4的转变 ，原因在大规模服务化之前，应用可能只是通过RMI或Hessian等工具，简单的暴露和引用远程服务，通过配置服务的URL地址进行调用，通过F5等硬件进行负载均衡。 (1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。 此时需要一个服务注册中心，动态的注册和发现服务，使服务的位置透明。

1 dubbo的 作用 以下内容摘自dubbo官网： 　　dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现; 2 查看官网大坑 　　(二)dubbo管理控制台的搭建 git clone https://github.com/apache/incubator-dubbo-ops cd incubator-dubbo-ops && mvn package 用法，分为三个 admin, register/ monitor dubbo admin Dubbo admin is a spring boot application, you can start it with fat jar or in IDE directly. 进入 dubbo-admin,执行 mvn install ----------------------------- maven 下载打包时需要配置 仓库MAVEN_HOME,Path=xxxxxj,这样的话就会用配置的阿里云镜像，下载会很快 碰到了不能编译，需要配置java环境变量 编译后启动报错了，因为没改zookeeper的配置ip,重新安装打包，运行target下的 java -jar dubbo-xxxxxx.jar，账号参考配置里的 root/root

关于分布式系统的连环炮 为什么要进行系统拆分？拆分后不用dubbo可以吗？ 系统越来越复杂，维护起来非常麻烦，各种冲突，各种合并，非常耗费时间，之间依赖复杂，异常处理起来非常麻烦，各种痛苦 拆分后每个服务都是一个单独的模块，一个人维护一个服务，每个机器部署一个服务， 避免了很多冲突，代码清爽 可以，但是我们如果调用其他服务的接口时会有很多问题需要考虑，负载均衡，超时重试等等一系列问题，dubbo是一个rpc框架，就是本地接口 进行调用，底层会帮我们处理负载均衡，服务上下线自动感知，超时重试等，不需要我们自己去考虑，直接使用就可以了 说一下dubbo的工作原理？注册中心挂了可以继续通信吗？说说一次rpc请求流程？ dubbo一共分为10层，provider层，如果一个服务A部署在三台机器上，每台机器有各自的ip，服务会将自己的信息在注册中心进行注册，这样注册中心就有了这个服务的注册信息。 这时一个用户请求发送过来，然后消费者会连接注册中心拉取自己需要调用的服务，消费者就会获取到注册中心里需要调用的服务的信息，这时消费者和服务提供者都会有dubbo 生成的代理，消费者的代理通过负载均衡找到服务A其中的个代理获取需要的数据，服务A返回数据给自己的代理，服务A的代理在返回给消费者的代理，然后返回给消费者，最后返回 给用户，这样就是一个dubbo的执行流程。 如果注册中心挂了还是可以继续通信

Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。 Motan 是新浪微博开源的一个Java 框架。它诞生的比较晚，起于2013年，2016年5月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。 rpcx 是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。 gRPC 是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。 thrift 是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。 以下是它们的功能比较： 对于RPC的考察， 性能是很重要的一点，因为RPC框架经常用在服务的大并发调用的环境中，性能的好坏决定服务的质量以及公司在硬件部署上的花费。 本文通过一个统一的服务，测试这四种框架实现的完整的服务器端和客户端的性能。 这个服务传递的消息体有一个protobuf文件定义： syntax =

Dubbox简介 Dubbox 是一个分布式服务框架，其前身是阿里巴巴开源项目Dubbo ，被国内电商及互联网项目中使用，后期阿里巴巴停止了该项目的维护，当当网便在Dubbo基础上进行优化，并继续维护，为了与原有的Dubbo区分，故将其命名为Dubbox。 Dubbox 致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。简单的说，dubbox就是个服务框架，如果没有分布式的需求，其实是不需要用的，只有在分布式的时候，才有dubbox这样的分布式服务框架的需求，并且本质上是个服务调用的东东，说白了就是个远程服务调用的分布式框架。 节点角色说明： Provider: 暴露服务的服务提供方。 Consumer: 调用远程服务的服务消费方。 Registry: 服务注册与发现的注册中心。 Monitor: 统计服务的调用次调和调用时间的监控中心。 Container: 服务运行容器。 调用关系说明： 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推 送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用， 如果调用失败，再选另一台调用。 服务消费者和提供者

个人博客地址 studyidea.cn ,点击查看更多原创文章 0x00. 翻车现场 那是个月黑风高的夜晚，小黑哥成功将新版本发布到了生产，小心翼翼检查了应用日志，后续测试小姐姐验收成功。 恩，小黑哥我还是一如既往的稳~ 接着小黑哥就跑到楼下食堂吃个夜宵，谁知正吃到一半，线上运维同学发来几条告警信息，服务器连接数过多警告，连接数已经飙升到上万。 天啦撸，赶紧放下正在啃的鸡腿，火速跑到工位上查看问题。 0x01. 历尽艰辛，深入排查 打开电脑，首先确认生产交易一切还正常。查看这段时间日志，发现并没有什么异常情况，日志都是正常输出。没办法只好再次走查此次改动的代码，发现全是业务代码，并没有任何与网络连接有关的代码改动。 问题真的请奇怪，一时半会想不到解决方案，只好先实施重启大法。重启过后，连接数下降了，到达了正常阈值。但是不一会连接数持续升高，不一会还是升到上万。 这下重启解决不了办法，只好从应用出发，找找到底什么问题。 这个应用是一个路由服务，会根据上游系统指定路由编码，将交易分发到下游子系统。架构图如下: 之前在这篇文章 路由系统演化史 讲过，路由系统使用 Dubbo API ，代码如下： 由于我们还有另外一套系统，也部署这个应用，但是该系统生产机器连接数却很少。交叉比对了两套系统应用的系统配置值，只有 connections 设置不一样，当前有问题的系统设置为 1000

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的所有操作都是原子性（不可再分）的，意思就是要么成功执行要么失败不执行

文章目录 springBoot 分布式zookeeper+Dubbo 一、基础知识 单一应用架构 垂直应用架构 分布式架构 流动计算架构 什么是RPC？ 二、Dubbo 什么是Dubbo 为什么使用Dubbo 调用关系说明 Dubbo环境搭建 window下安装dubbo-admin SpringBoot + Dubbo + zookeeper 服务提供者(provider) 服务消费者（consumer） springBoot 分布式zookeeper+Dubbo 一、基础知识 什么是分布式系统 1 、分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统 2 、分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。 3 、分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理更多的数据。 为什么提倡分布式架构 随着互联网规模和需求越来越大，传统的单体应用已经不能支撑 单一应用架构 将网站所有东西打包在一个应用中，将其部署，减少部署成本，此时ORM成为重点 优点：适合小网站，访问量不大的情况下 缺点： 性能扩展比较难 协同开发问题 不利于升级维护 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时

can not register RM,err:can not connect to services-server. Caused by: java.lang.IllegalStateException: Failed to check the status of the service cn.iocoder.mall.order.api.CartService. No provider available for the service cn.iocoder.mall.order.api.CartService:1.0.0 from the url zookeeper://127.0.0.1:2181/org.apache.dubbo.registry.RegistryService?application=search-service&default.lazy=false&default.sticky=false&dubbo=2.0.2&interface=cn.iocoder.mall.order.api.CartService&lazy=false&methods=add,deleteList,calcOrderPrice,updateQuantity,updateSelected,count,deleteAll,list,calcSkuPrice&pid=20352