Dubbo

3 月，跳不动了？>>> 开篇 上一篇讲到了 Dubbo SPI 使用方法（1） - 扩展点自动包装 。 本文接着讲 Dubbo SPI - 扩展点自适应。 正文 大纲 扩展点自适应介绍 @Adaptive 注解使用方法 作用在类上 作用在方法上 1. 扩展点自适应 ExtensionLoader 注入的依赖扩展点是一个 Adaptive 实例，直到扩展点方法执行时才决定调用是哪一个扩展点实现。 Dubbo 使用 URL 对象（包含了Key-Value）传递配置信息。 扩展点方法调用会有 URL 参数（或是参数有URL成员）这样依赖的扩展点也可以从URL拿到配置信息，所有的扩展点自己定好配置的 Key 后，配置信息从 URL 上从最外层传入。URL在配置传递上即是一条总线。 上面摘自官网的一段介绍。 划重点： 扩展方法中有 URL 参数 也可以是包含 URL 成员的参数 直到扩展点方法执行时，才决定调用哪个扩展点实现 跟 扩展点自动包装 的区别 通过 URL 传递配置信息 通过 URL 中的参数，决定调用哪个扩展类实现 如果还是不好理解，就继续看下面的案例。 2. @Adaptive 注解 要想实现 扩展点自适应 ，需要借助 @Adaptive 注解，该注解可以作用在两个地方： 扩展实现类上 在类上，表示该类是一个扩展类，不需要生成代理直接用即可； 扩展接口方法上

3 月，跳不动了？>>> 线上系统为何经常出错？数据库为何屡遭黑手？业务调用为何频频失败？连环异常堆栈案，究竟是哪次调用所为？ 数百台服务器意外雪崩背后又隐藏着什么？是软件的扭曲还是硬件的沦丧？ 走进科学带你了解 Arthas，一款开源一年多 GitHub Star 2 万，99% 的阿里研发小哥都在用的 Java 终极诊断利器！ 关于 Arthas Arthas 是一款开源在线 Java 诊断工具，采用命令行交互模式，支持 web 端在线诊断，同时提供丰富的 Tab 自动补全功能，进一步方便进行问题的定位和诊断。得益于 Arthas 强大且丰富的功能，让 Arthas 能做的事情超乎想象。 它可以帮你解决这些问题： 这个类从哪个 jar 包加载的？为什么会报各种类相关的 Exception？ 我改的代码为什么没有执行到？难道是我没 commit？分支搞错了？ 遇到问题无法在线上 debug，难道只能通过加日志再重新发布吗？ 线上遇到某个用户的数据处理有问题，但线上同样无法 debug，线下无法重现！ 是否有一个全局视角来查看系统的运行状况？ 有什么办法可以监控到 JVM 的实时运行状态？ 怎么快速定位应用的热点，生成火焰图？ 有奖征文 为了让更多开发者开始用上 Arthas 这个Java 诊断神器，这一次我们联合 JetBrains 推出这次有奖征文活动，聊聊这些年你和

SPI 全称为 Service Provider Interface，是一种服务发现机制。当程序运行调用接口时，会根据配置文件或默认规则信息加载对应的实现类。所以在程序中并没有直接指定使用接口的哪个实现，而是在外部进行装配。 要想了解 Dubbo 的设计与实现，其中 Dubbo SPI 加载机制是必须了解的，在 Dubbo 中有大量功能的实现都是基于 Dubbo SPI 实现解耦，同时也使得 Dubbo 获得如此好的可扩展性。 Java SPI 通过完成一个 Java SPI 的操作来了解它的机制。 创建一个 AnimalService 接口及 category 方法 创建一个实现类 Cat 创建 META-INF/services 目录，并在该目录下创建一个文件，文件名为 AnimalService 的全限定名作为文件名 在文件中添加实现类 Cat 的全限定名 Animal 接口 public interface AnimalService { void category(); } Cat 实现类 public class Cat implements AnimalService { @Override public void category() { System.out.println("cat: Meow ~"); } } 在 META-INF/services 目录下的

目录 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 如何解决ResourceManager单点问题，实现高可用？ 6.2.3 Kafka 术语介绍 问题 Kafka与Zookeeper Broker注册管理 Topic注册管理 生产者负载均衡 消费者负载均衡 消费分区与消费者关系 消息消费进度Offset记录 消费者注册 负载均衡 1）Range策略 2）RoundRobin策略 资料 6.3 Zookeeper在阿里巴巴的实践与应用 6.3.2 案例二 RPC服务框架：Dubbo 服务提供者 服务消费者 监控中心 6.3.3 案例三 基于MySQL Binlog的增量订阅和消费组件：Canal Canal基本工作原理 Canal Server主备切换设计 Canal Client的HA设计 6.3.4 案例四 分布式数据库同步系统：Otter 分布式SEDA模型 数据模型 任务处理流程(多阶段任务协调处理) 6.2 Zookeeper在大型分布式系统中的应用 6.2.1 Hadoop YARN介绍 YARN是Hadoop为了提高计算节点的扩展性，同时为了支持多计算模型和提供资源的细粒度调度而引入的全新一代分布式协调框架。 核心为ResourceManager，资源管理中心，负责集群中所有资源的统一管理和分配。 （可理解为YARN的大脑

3 月，跳不动了？>>> SOFA:Channel/ ，有趣实用的分布式架构频道。 回顾视频以及 PPT 查看地址见文末。欢迎加入直播互动钉钉群 : 21992058，不错过每场直播。 本文根据 SOFAChannel#13 直播分享整理，主题：云原生网络代理 MOSN 多协议机制解析。 大家好，我是今天的讲师无钩，目前主要从事蚂蚁金服网络代理相关的研发工作，也是 MOSN 的 Committer。今天要和大家分享的是《云原生网络代理 MOSN 多协议机制解析》，并介绍对应的私有协议快速接入实践案例以及对 MOSN 实现多协议低成本接入的设计进行解读。 我们将按以下顺序进行介绍： 多协议机制产生的背景与实践痛点； 常见的协议扩展思路初探； SOFABolt 协议接入实践；（重点） MOSN 多协议机制设计解读；（重点） 后续规划及展望； 其中第三点「接入实践」是今天分享的重点，希望能给大家就「如何在 MOSN 中快速扩展私有协议接入」有一个具体的感受。另外「MOSN 如何实现多协议框架」也是很多人关心和问题，我们将摘选几个技术功能，对其背后的设计思考进行解读。 MOSN 简介 云原生网络代理 MOSN 定位是一个全栈的网络代理，支持包括网络接入层(Ingress)、API Gateway、Service Mesh 等场景，目前在蚂蚁金服内部的核心业务集群已经实现全面落地，并经受了

3 月，跳不动了？>>> 前言：今天给大家给大家讲解的是Dubbp的调用原理，以及一个demo测试向大家展示Dubbo的运行过程。在前面一文中，给大家讲到了--- Dubbo之Zookeeper安装测试和Zookeeper集群的搭建 ,在其中已经给大家讲到了Zookeeper集群的搭建，今天我们也要用到该集群，如果没有安装的，请先行安装，再看下文！！ 1.Dubbo原理 1.1 高性能Java RPC框架 Apache Dubbo 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。 1.2 Dubbo特性 面向接口代理的高性能RPC调用 服务自动注册与发现 运行期流量调度 智能负载均衡 高度可扩展能力 可视化的服务治理与运维 以上几点接来源于dubbo的官网: http://dubbo.apache.org/zh-cn/ 1.3 Dubbo工作原理 1.3.1 Dubbo高可用测试 测试1:将后台提供者宕机一台,检查是否影响消费者调用。 不影响 注册中心实现心跳检测机制. 即使没有注册中心,又要有提供者就可以正常访问 测试2: 将zookeeper宕机一台,检查是否影响用户使用。 不影响 因为zk搭建了集群.可以实现高可用 测试3: 将zookeeper集群全部宕机,检查是否影响用户使用。

3 月，跳不动了？>>> 开篇 前面有说到 Java SPI 的介绍与使用方法 , 而本篇要说的 Dubbo SPI 是基于 Java SPI 的一个升级与改造（改善了部分缺点，增加了几个新玩法）。具体内容可以去看官网 Dubbo-SPI 部分 。 本文主要来讲下 Dubbo SPI 的部分使用方法。 另外，后续文章会补齐 Dubbo SPI 的其他用法以及 Dubbo SPI 部分的源码解析。 当然 官网 也有 Dubbo SPI 的使用说明与源码导读，可以自行选择。 正文 Dubbo SPI 的使用方法具体分为以下部分： 基本使用 扩展点自动包装 扩展点自适应 扩展点自动装配 扩展点自动激活 本文先来介绍前两种使用方法，建议先看下 Java SPI 的介绍与使用方法 ，了解下 SPI 的机制及用途。 1. 基本使用 从这点来看，Dubbo SPI 从使用上与 JAVA SPI 并无很大差异。 主要区别在于： JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。 而 Dubbo SPI 可以选择性实例化某个实现。 下面来看下写法上的差别，具体代码如下： 1.1 定义一个接口 // 差别一：Dubbo 需要 SPI 注解 @SPI public interface HelloService { void

3 月，跳不动了？>>> Install mvn install:install-file -DgroupId=org.apache.kafka -DartifactId=kafka_2.10 -Dversion=0.10.0-kafka-2.1.1 -Dfile=D:\lib\kafka_2.10-0.10.0-kafka-2.1.1.jar -Dpackaging=jar -DgeneratePom=true -DpomFile=kafka_2.10-0.10.0-kafka-2.1.1.pom Deploy mvn deploy:deploy-file -DgroupId = com .alibaba -DartifactId = dubbo -Dversion = 2 .8.4 -Dpackaging = jar -Dfile = E :\dubbo\dubbo-2.8.4.jar -Durl = http ://192.168.1.11:8181/repository/maven-releases/thirdparty/ -DrepositoryId = deploymentRepo pom.xml 加载项目内的依赖 < dependency > < groupId > org.apache.kafka </ groupId > < artifactId > kafka

SPI 全称为 Service Provider Interface，是一种服务发现机制。SPI 的本质是将接口实现类的全限定名配置在文件中，并由服务加载器读取配置文件，加载实现类。这样可以在运行时，动态为接口替换实现类。正因此特性，我们可以很容易的通过 SPI 机制为我们的程序提供拓展功能。SPI 机制在第三方框架中也有所应用，比如 Dubbo 就是通过 SPI 机制加载所有的组件。不过，Dubbo 并未使用 Java 原生的 SPI 机制，而是对其进行了增强，使其能够更好的满足需求。在 Dubbo 中，SPI 是一个非常重要的模块。 Dubbo SPI的改进 Dubbo 的扩展点加载从 JDK 标准的 SPI (Service Provider Interface) 扩展点发现机制加强而来。 Dubbo 改进了 JDK 标准的 SPI 的以下问题： DK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。 如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby

zookeeper 注册中心 Zookeeper 是 Apacahe Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 [1]。 流程说明： 服务提供者启动时: 向 /dubbo/com.foo.BarService/providers 目录下写入自己的 URL 地址 服务消费者启动时: 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者 URL 地址。并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的 URL 地址 监控中心启动时: 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者 URL 地址。 支持以下功能： 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息 当注册中心重启时，能自动恢复注册数据，以及订阅请求 当会话过期时，能自动恢复注册数据，以及订阅请求 当设置 <dubbo:registry check="false" /> 时，记录失败注册和订阅请求，后台定时重试 可通过 <dubbo:registry username="admin" password="1234" /> 设置 zookeeper 登录信息 可通过 <dubbo:registry