能力说明:
了解变量作用域、Java类的结构,能够创建带main方法可执行的java应用,从命令行运行java程序;能够使用Java基本数据类型、运算符和控制结构、数组、循环结构书写和运行简单的Java程序。
暂无个人介绍
造个轮子玩玩
微服务治理中限流、熔断、降级是一块非常重要的内容。目前市面上开源的组件也不是很多,简单场景可以使用Guava,复杂场景可以选用Hystrix、Sentinel。今天要说的就是Sentinel,Sentinel是一款阿里开源的产品,
在开发测试中我们通常会遇到多项目并行开发测试,假设应用ABCDE均为dubbo应用,需求1修改了应用A、C代码,需求2修改了应用A、B、E代码,此时如果并行测试,需求1可能会调用到需求2修改的代码上,造成测试混乱。
今天的主角是标签路由和dubbo的多注册中心。标签路由在之前的文章《以为是青铜,没想到是王者的dubbo标签路由》中已经详细介绍过,多注册中心是dubbo可以使用多个注册中心来提供或者消费服务,利用多注册中心的特性可以搭建多机房。然而很不幸,当多注册中心遇上标签路由,却产生了一个bug。
nacos在它的官网上是这样介绍自己的 一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台
在微服务架构中,不同的微服务有不同的网络地址,而客户端则是通过统一的地址进行调用,在客户端与服务端之间需要有一个通信的桥梁,这就产生了微服务网关。微服务网关可以连接客户端与微服务,提供统一的认证方式,管理接口的生命周期,做更好的负载均衡、熔断限流,提供方便的监控,提供统一的风控入口。
最近写的关于dubbo内存泄露稍微复杂了一点,很多人表示看不明白,想到之前遇到的比较简单的内存泄露问题,更容易入门,于是拿出来分享一下。
基准测试是指通过设计科学的测试方法、测试工具和测试系统,实现对一类测试对象的某项性能指标进行定量的和可对比的测试。而JMH是一个用来构建,运行,分析Java或其他运行在JVM之上的语言的 纳秒/微秒/毫秒/宏观 级别基准测试的工具。
前段时间调研nacos,用来代替zookeeper当作dubbo的注册中心,使用的是nacos的1.1.4版本。还用了nacosSync,一款nacos提供的迁移工具,可将常见的注册中心上的服务同步到nacos上。这玩意很不好用,至少不是生产级别的工具。
但凡对Java有一点深入就会知道 CAS,即 compareAndSwap。在Java中使用 Unsafe 类提供的native方法可以直接操作内存,其中就有对compareAndSwap的实现。
在分布式场景中,很多地方需要生成全局唯一的id,如数据库分库分表后需要用唯一id代替单机版本的自增id。发号器的基本要求是 全局唯一,无论如何都不能重复 某些场景下还要求单调递增,如排序需求等。
LongAdder是jdk8引入的适用于统计场景的线程安全的计数器。
公司的RPC框架是dubbo,配合使用的服务发现组件一直是zookeeper,长久以来也没什么大问题。至于为什么要考虑换掉zookeeper,并不是因为它的性能瓶颈,而是考虑往云原生方向演进
async-profiler是一款采集分析java性能的工具,翻译一下github上的项目介绍
举个日志采集的例子,日志在不同的线程上生产,在日志生产速度远超消费者速度时,可以丢弃部分数据,要求打日志的性能损耗最小,这种情况下可采用本文提供的极致性能的缓冲队列。
尽管很早我们就做了会员、商品、交易的服务化,但流量入口还是php主站,php实际上仍是一个单体应用,单体应用无需网关。当全站java化之后,单体应用将被拆分为微服务,自然需要一个网关来负责统一流量入口、鉴权、安全防护、业务统一处理等。
最近工作重心转向了注册中心,于是想来写一篇关于注册中心的文章
了解dubbo的朋友知道,dubbo的provider启动时向注册中心注册,consumer从注册中心消费。 目前dubbo往注册中心上注册的数据是接口级,而应用级服务发现是往注册中心上注册实例(ip+port),两者的区别只是注册的粒度不同。
OpenResty通过汇聚各种设计精良的 Nginx模块(主要由 OpenResty 团队自主开发),从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样,Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块,快速构造出足以胜任 10K 乃至 1000K 以上单机并发连接的高性能 Web 应用系统。
Cobar 是阿里开源的一款数据库中间件产品。
业务上的配置,功能开关,服务治理上对弱依赖的降级,甚至数据库的密码等,都可能用到动态配置中心。 在没有专门的配置中心组件时,我们使用硬编码、或配置文件、或数据库、缓存等方式来解决问题。 硬编码修改配置时需要重新编译打包,配置文件需要重启应用,数据库受限于性能,缓存丧失了及时性
dubbo 是一款开源的 RPC 框架,主要有3个角色:提供者(provider)、消费者(consumer) 、注册中心(registry)
最近翻看以前写的 PPT, 发现了在2019年做的一次技术分享,关于 Java 问题排查,由于没什么公司机密可言,整理下分享给大家~
事儿还得从一次重构优化说起。 最近在重构一个路由功能,由于路由比较复杂,需求变化也多,于是想通过责任链模式来重构,刚好这段时间也在 Sentinel-Go 中看到相关源码。
要说现在工程师最重要的能力,我觉得工程能力要排第一。 就算现在大厂面试经常要手撕算法,也是更偏向考查代码工程实现的能力,之前在群里看到这样的图片,就觉得很离谱(大概率是假的~)。
hello大家好,我是小楼。 不知道大家还记不记得我上次找到了一个Go的Benchmark执行会超时的Bug?就是这篇文章《我好像发现了一个Go的Bug?》。 之后我就向Go提交了一个PR进行修复,本想等着代码被Merge进去,以后也可以吹牛说自己是个Go的Contributor,但事情并不顺利,今天就来分享一下这次失败的代码提交。
hello大家好,我是小楼。 最近踩了个DNS解析的小坑,虽然问题解决了,但排查过程比较曲折,最后还是有一点没有想通,整个过程分享给大家。
hello~大家好,我是小楼,今天分享的话题是Go是否能实现AOP? 在开始之前,请允许我推荐《Go语言底层原理剖析》的作者,最近在读这本书,发现作者竟然是我同事,本文是从这本书的第一章得到的灵感,作者也在公众号上写文章,可以关注下哦 ~ 当然买书支持也是可以的。
今天给大家分享一个关于HBase数据倾斜的排查案例,不懂调用链?不懂HBase?没关系,看完包懂~
今天又带来一次性能优化的分享,这是我刚进公司时接手的祖传(坏笑)项目,这个项目在我的文章中屡次被提及,我在它上面做了很多的性能优化,比如《记一次提升18倍的性能优化》这篇文章,比较偏向某个细节的优化,本文更偏向宏观上的性能优化,可以说是个老演员了。
OpenResty通过汇聚各种设计精良的 Nginx模块(主要由 OpenResty 团队自主开发),从而将 Nginx 有效地变成一个强大的通用 Web 应用平台。这样,Web 开发人员和系统工程师可以使用 Lua 脚本语言调动 Nginx 支持的各种 C 以及 Lua 模块,快速构造出足以胜任 10K 乃至 1000K 以上单机并发连接的高性能 Web 应用系统。
最近负责的一个自研的 Dubbo 注册中心经常收到 CPU 使用率的告警,于是进行了一波优化,效果还不错,于是打算分享下思考、优化过程,希望对大家有一些帮助。 自研 Dubbo 注册中心是个什么东西,我画个简图大家稍微感受一下就好,看不懂也没关系,不影响后续的理解。
Java的单元测试需要使用第三方库,一般是Junit,配置起来比较复杂。在使用了golang之后发现golang自带的单元测试真的非常简单。 如果我们有一个cal.go文件,那么其对应的单元测试文件为cal_test.go,其中的方法命名必须为TestXxx,这种按照命名进行单元测试的方式简单有效,也正是通常所说的“约定大于配置”。
Tengine是阿里巴巴基于Nginx开发并开源的Web服务器,它继承了Nginx所有的功能和特性,并在其基础上做了大量的扩展和增强,其中像动态模块加载,四层负载均衡,reuseport支持等能力,都逐渐被Nginx官方吸收引用。Tengine在开源以后大受欢迎,成为了Nginx最好的替代品之一,官方网站(http://tengine.taobao.org/)。 Dubbo是阿里巴巴开源的一款高性能、轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
为了解释什么是Agent技术,我在网上搜了一圈,但没有找到想要的结果。反倒是搜到了不少Java Agent技术,要注意Java Agent技术指的是一种Java字节码修改技术,和本文要说的完全是两码事。 既然搜不到,我就说下自己的理解吧。Agent技术是在「客户端」机器上部署一个Agent进程,「客户端」与「服务端」的交互通过这个Agent进行代理,其中Agent与Client通常在同一主机,即可通过「localhost」进行访问。
RPC,全称Remote Procedure Call,即远程过程调用,一句话描述就是调用远程对象就像调用本地方法一样方便简单。常见的RPC框架有dubbo、grpc、thrift等。
迁移注册中心的方案大致有两种: 方案一:使用Dubbo提供的多注册中心能力,Provider先进行双注册,Consumer逐步迁移消费新注册中心,最后下线老注册中心。该方案的缺点是修改时有上下游依赖关系。 方案二:使用一个同步工具把老注册中心的数据同步到新注册中心,Consumer逐步迁移到新注册中心,最后下线老注册中心。同步工具有开源的Nacos-sync,我之前的文章《zookeeper到nacos的迁移实践》就提到了这个方案。这个方案的缺点是架构变得复杂,需要解决同步数据的顺序性、一致性、同步组件的高可用等问题。
在《聊聊dubbo协议》中介绍了attachments在consumer和provider间的传递情况,有个疑问没有给出答案。 为什么2.7.x版本的dubbo不支持provider端向consumer端回传隐式参数呢?今天的续集将揭晓答案。
协议通俗易懂地解释就是通信双方需要遵循的约定。 我们了解的常见的网络传输协议有tcp、udp、http等。再到我们常用的基础组件,一般来说client端与server端也有相应的协议,如redis、mysql、zookeeper等都是各自约定的私有协议,同样今天标题中的dubbo协议也是一种私有协议,他们都是应用层协议,基于tcp或udp设计。
总之一句话总结起来就是Provider节点没有摘除流量前,就无法处理请求了。可以分为三类: 系统异常:如断电、断网、其他硬件故障、或操作系统异常退出 进程异常退出:进程异常退出,端口挂掉,如有注销机制但没来得及注销,如执行了kill -9 进程无法处理请求:端口还在,但服务无法正常响应,如Full GC期间
诞生于阿里巴巴,2011年开源的Dubbo已经走过了10个年头。在2019年,它被用Go重写并开源,如今两年过去,已经从当初的V1.0.0版本发展到了V3.0.0,截止目前star数3.8K。 有一次同事问我,为什么Dubbo这么"老"的项目还要用Go重写,有什么现实意义吗? 今天就来谈谈我的一些看法。
可从三个方面入手 知识:有些问题,思考一下就有答案,就像传说中多隆那样,回忆下就知道第83行代码有问题~ 工具:当然不是每个人都能做到过目不忘,也有可能这代码完全不是你写的,这时就需要靠工具来定位问题 数据:程序运行时产生的数据,也能提供很多线索
在配置dubbo注册中心时,一般会这样写 dubbo.registry.protocol=zookeeper dubbo.registry.address=127.0.0.1:2181 也会简单地写成 dubbo.registry.address=zookeeper://127.0.0.1:2181
Sentinel-Go 初始化时主要做了以下2件事情: 通过各种方式(文件、环境变量等)载入全局配置 启动异步的定时任务或服务,如机器 cpu、内存信息收集、metric log 写入等等
很久之前我给业务方写了一个 dubbo loadbalance 的扩展(为了叙述方便,这个 loadbalance 扩展就叫它 XLB 吧),这两天业务方反馈说 XLB 不生效了 我心想,不可能啊,都用了大半年了~
上周遇到个关于升级dubbo 2.6 到2.7的兼容性问题,差点造成线上故障,这里记录下,也给大家提个醒。
这个话题展开具体说说,我们在Java中获取时间戳的方法是System.currentTimeMillis(),返回的是毫秒级的时间戳,查看源码,注释写的比较清楚,虽然该方法返回的是毫秒级的时间戳,但精度取决于操作系统,很多操作系统返回的精度是10毫秒
看到这个标题你可能会说,TCP 连接的建立与断开,这个我熟,不就是三次握手与四次挥手嘛。且慢,脑海中可以先尝试回答这几个问题: 四次挥手是谁发起的? 如果断电/断网了连接会断开吗? 什么情况下没有四次挥手连接也会断开?
表面上看报错是因为使用了已经关闭的数据源 数据源什么时候会关闭呢?只有进程被杀死的时候 莫非是应用关闭时不够平滑?发布时会先摘除流量的呀,应该不至于呀 天色已经很晚,漫无目的地拖动日志,疲惫地寻找新线索,突然报错日志中一个单词引入眼帘:rocketmq 精神抖擞,大概知道原因了,这应用中还有个兢兢业业的rocketmq consumer一直在消费消息,在应用关闭时,外部流量被摘除了,但没人通知rocketmq consumer,于是它抛异常了。
有了ShutdownHook我们可以 在进程结束时做一些善后工作,例如释放占用的资源,保存程序状态等 为优雅(平滑)发布提供手段,在程序关闭前摘除流量