Dubbo

Dubbo Dubbo是一个分布式服务治理框架，提供高性能和透明化的RPC远程服务调用方案及 SOA 架构治理方案。 远程通信 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及 “ 请求-响应”模式的信息交换方式。 集群容错 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败 容错，地址路由，动态配置等集群支持。 自动发现 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使 服务提供方可以平滑增加或减少机器。 springboot整合dubbo 引入依赖 在服务提供者、消费者工程中的pom.xml文件中添加依赖。 配置Dubbo相关参数 启动类添加 @EnableDubbo 注解 服务提供方和服务消费方 实现服务提供者和消费者 服务治理和配置管理 服务治理 服务治理主要作用是改变运行时服务的行为和选址逻辑，达到限流，权重配置等目的，主要有以下几个功能： 应用级别的服务治理 在Dubbo2.6及更早版本中，所有的服务治理规则都只针对服务粒度，如果要把某条规则作用到应用粒度上，需要为应用下的所有服务配合相同的规则，变更，删除的时候也需要对应的操作，这样的操作很不友好，因此Dubbo2.7版本中增加了应用粒度的服务治理操作，对于条件路由(包括黑白名单)，动态配置(包括权重，负载均衡)都可以做应用级别的配置：

欲速则不达，欲达则欲速！ 一、前言 微服务架构被提出很短的时间内，就被越来越多的开发人员推崇，简单来说其主要的目的是有效的拆分应用，实现敏捷开发和部署。本博客尝试介绍微服务架构的一些实施细节和要求，探询微服务架构的由来，并最终提供我们团队内部的有一些实践总结，希望对大家有帮助。 二、什么是微服务 传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（比较难传神的翻译）。所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。 用《The art of scalability》一书里提到的scale cube比较容易理解如何拆分。 我们叫分库分表，为人总结成了scale cube，这就是抽象的能力，把复杂的东西用最简单的概念解释和总结。X轴代表运行多个负载均衡器之后运行的实例，Y轴代表应用进一步分解为微服务（分库），数据量大时，还可以用Z轴将服务按数据分区分表。 Monolithic比较适合小项目，优点是： 开发简单直接，集中式管理 基本不会重复开发 功能都在本地，没有分布式的管理开销和调用开销 它的缺点也非常明显

一、什么是Spring Boot ？ 现阶段的 Spring Boot 可谓是太火了，为什么呢？因为使用方便、配置简洁、上手快速，那么它是什么？从官网上我们可以看到，它是 Spring 开源组织下的一个子项目，主要简化了 Spring 繁重的配置，而且 Spring Boot 内嵌了各种 Servlet 容器，如：Tomcat、Jetty 等 官方网站： http://projects.spring.io/spring-boot/ GitHub源码： https://github.com/spring-projects/spring-boot 二、Spring Boot 的优势 ？ 1、独立运行：不需要在用 tomcat 等容器运行。 2、简化配置：不需要在像 Spring mvc 那样配置很多的xml了； 3、自动配置：根据包路径自动配置 bean 4、应用监控：Spring Boot 提供监控服务 三、项目创建 1、创建提供者 后面点击 finish，创建完毕，然后删掉多余包，使得项目结构如下图： 右击项目，新建一个提供者对外提供服务的模块 qbs-facade 然后再按照该模式创建一个 qbs-web 模块（这里就不介绍了）最终的项目结构如下图所示： 修改 主 pom 文件 <?xml version="1.0" encoding="UTF-8"?> <project

package top.hh.consumer.service; import com.alibaba.dubbo.config.annotation.Reference; import org.springframework.stereotype.Service; import top.hh.service.UserServiceApi; import java.util.List; @Service public class LoginServiceImpl { //failfast快速失效，只发起一次调用，失败立即报错 @Reference(cluster = "failfast", retries = 0, interfaceClass = UserServiceApi.class, lazy = true, check = false, timeout = 50000) UserServiceApi userServiceApi; /** * 测试rpc直接传参数耗时 1秒 */ public String testprc1() { String s1 = rpc1("1"); String s2 = rpc2("2"); long start = System.currentTimeMillis(); String str = userServiceApi

一、基于zookeeper+dubbo组合的分布式系统 分布式系统中，常用zookeeper+dubbo组合 zookeeper：一个分布式的、开放源码的分布式应用程序协调服务。提供的功能：配置维护、域名服务、分布式同步、组服务 dubbo：分布式服务框架，按照分层的方式来架构，使各层解耦。模型简单，分为服务提供方和服务消费方 例子：有两个模块A、B，dubbo负责解决A模块和B模块的远程过程调用（RPC问题），A需要通过注册中心（zookeeper）得到B的地址再进行调用。 dubbo框架工作图如下图： dubbo的服务容器Container，启动时启动和加载Provider（服务提供者） 服务提供者（Provider）启动时，将自己能提供的服务信息注册到注册中心（Registry）】 服务消费者（Consumer）启动时会从注册中心订阅所需要的服务 注册中心会把所需服务的地址列表返回给服务消费者（如果服务有变更，注册中心会基于长连接的方式将信息变更给消费者） 消费者需要调用时，会从提供者的地址列表中找到某个提供者的位置，调用他的服务，服务失败，会从地址列表中找寻另一个服务器供着并调用服务，直到调用成功 监控中心（Monitor）有监控机制，会获得调用次数、调用时间等信息，进行监控 二、配置分布式框架 1、docker安装zookeeper sudo docker pull

1.container负责启动和加载容器；--init 2.provider启动时负责向regisrty暴漏提供的服务；--init 3.consumer启动时负责向registry请求所需要的服务；--init 4.registry向consumer返回provider的地址列表；--async 5.consume调用provider的服务；--sync 6.provider与consumer统计调用或者服务请求的次数与时长，定期报告给monitor； 来源： oschina 链接： https://my.oschina.net/u/4434424/blog/3165274

最近我们 dubbo-go 社区里面，呼声很大的一个 feature 就是对 gRPC 的支持。在某位大佬的不懈努力之下，终于弄出来了。 今天我就给大家分析一下大佬是怎么连接 dubbo-go 和 gRPC 。 gRPC 先来简单介绍一下 gRPC 。它是 Google 推出来的一个 RPC 框架。gRPC是通过 IDL ( Interface Definition Language )——接口定义语言——编译成不同语言的客户端来实现的。可以说是RPC理论的一个非常非常标准的实现。 因而 gRPC 天然就支持多语言。这几年，它几乎成为了跨语言 RPC 框架的标准实现方式了，很多优秀的rpc框架，如 Spring Cloud 和 dubbo ，都支持 gRPC 。 server 端 在 Go 里面，server 端的用法是： 它的关键部分是： s := grpc.NewServer() 和 pb.RegisterGreeterServer(s, &server{}) 两个步骤。第一个步骤很容易，唯独第二个步骤 RegisterGreeterServer 有点麻烦。为什么呢？ 因为 pb.RegisterGreeterServer(s, &server{}) 这个方法是通过用户定义的 protobuf 编译出来的。 好在，这个编译出来的方法，本质上是： 也就是说，如果我们在 dubbo

0x00. 前言 依赖冲突是日常开发中经常碰到的过程，如果运气好，并不会有什么问题。偏偏小黑哥有点背，碰到好几次生产问题，排查一整晚，最后发现却是依赖冲突的引起的问题。 没碰到过这个问题同学可能没什么感觉，小黑哥举两个最近碰到例子，让大家感受一些。 例子 1： 我们公司有个古老的业务基础包 A。B，C 业务依赖这个包。某个团队拷贝 A 的部分代码进行重构， 类名与路径完全一样 ，然后重新打包成 D 发布。 一次业务改动，B 业务也引入了 D 包，测试环境运行的时候，一切 OK，但是在生产运行时，却抛出 NoSuchMethodError 。 问题原因在于 B 业务依赖 A，D。而 A,D 存在两个同包同名类，运行的时候，具体加载谁，不同环境还真不一样。 例子 2： A 业务使用 Dubbo 进行 RPC 调用， Dubbo 需要依赖 javassist 。当前依赖关系为： A------->Dubbo------->javassist-3.18.1.GA 某次改动中引入另外一个第三方开源包，其依赖 javassist-3.15.0-GA 。生产发布的时候，将 javassist-3.15.0-GA 打包到应用中，由于生产环节为 JDK1.8，从而导致运行直接失败。 除了上述问题，依赖冲突还可能导致应用抛出 ClassNotFoundException ，

节点角色说明 节点 角色说明 Provider 暴露服务的服务提供方 Consumer 调用远程服务的服务消费方 Registry 服务注册与发现的注册中心 Monitor 统计服务的调用次数和调用时间的监控中心 Container 服务运行容器 调用关系说明 服务容器负责启动，加载，运行服务提供者。 服务提供者在启动时，向注册中心注册自己提供的服务。 服务消费者在启动时，向注册中心订阅自己所需的服务。 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 Dubbo 架构具有以下几个特点，分别是连通性、健壮性、伸缩性、以及向未来架构的升级性。 连通性 注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小 监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示 服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销 服务消费者向注册中心获取服务提供者地址列表，并根据负载算法直接调用提供者

1.正确答案【A】 答案解析 Dubbo提供了随机、轮询、最少调用优先等多种负载均衡策略，提供对zk等多种注册中心等支持，能够自动完成服务的注册与发现。dubbo提供可视化的管理后台，方便对服务状态进行监控和管理。dubbo的数据通信默认使用netty来实现，拥有非常不错的性能。Dubbo默认的容错方案是Failover Cluster，即：失败自动切换，当出现失败，重试其它服务器。 除此之外，还提供以下其他容错方式： Failfast Cluster 快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。 Failsafe Cluster 失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。 Failback Cluster 失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。 Forking Cluster 并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks=”2″ 来设置最大并行数。 Broadcast Cluster 广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息。 2.正确答案【B、D】 答案解析 Kafka只保证一个分区内的消息有序，不能保证一个topic的不同分区之间的消息有序。 为了保证较高的处理效率