前言

本文是我介绍 Arthas 系列文章的第一篇。

一般线上问题比开发环境的问题更难解决，一个主要的原因便在于开发态可以任意 debug 断点调试，而线上环境一般不允许远程调试，所以在实践中，我一般习惯用 Arthas 来定位线上的问题。

Arthas 是阿里巴巴开源的 Java 应用诊断利器

Arthas 可以完成很多骚操作，今天给大家介绍的 Arthas 诊断技巧便是 – 热更新线上代码。在生产环境热更新代码，并不是很好的行为，可能会引发一些问题

• 黑屏化的操作可能会导致误操作
• 不符合安全生产的规范，不满足可监控、可回滚、可降级

但有时候也有一些场景可以考虑使用 Arthas 来热更，例如开发环境无法复现的问题、找到修复思路后临时验证等。

本文以 Arthas 3.1.7 版本为例，主要使用到 jad/mc/redefine 三个指令。

前言

2020 是多事的一年，新冠状性病毒的肆虐，其次是自己也生了一场病，希望随着天气暖和起来，一起都能变得更好。

前一段时间真的很忙，一直没有抽出时间，也没有什么思路给大家分享优质的文章，今天这篇文章很久之前就想写了，抓住这次假期的尾巴，总结一下我最近这一年的工作。

问题描述

上周四晚刚回到家，就接到了软负载同学的电话，说是客户线上出了故障，我一听”故障“两个字，立马追问是什么情况，经过整理，还原出线上问题的原貌：

客户使用了 Dubbo，注册中心使用的是 Nacos，在下午开始不断有调用报错，查看日志，发现了 Nacos 心跳请求返回 502

1
2

2019-11-15 03:02:41.973 [com.alibaba.nacos.client.naming454] -ERROR [com.alibaba.nacos.naming.beat.sender] request xx.xx.xx.xx failed.
com.alibaba.nacos.api.exception.NacosException: failed to req  API: xx.xx.xx.xx:8848/nacos/v1/ns/instance/beat. code:502 msg: 

此时还没有大范围的报错。随后，用户对部分机器进行了重启，开始出现大规模的 Nacos 连接不上的报错，并且调用开始出现大量 no provider 的报错。

1 前言

在此文之前，我写过一篇 《一文聊透 Dubbo 优雅停机》，这篇文章算是一个续集，优雅停机和优雅上线两者都是微服务生命周期中，开发者必须关心的环节。

优雅上线还有很多称呼：「无损上线」，「延迟发布」，「延迟暴露」。它们的对立面自然是：「有损上线」，「直接发布」。

我最近写的「一文聊透 Dubbo xx」系列文章，都有一个特点，即当你不注重文章中实践，你的 Dubbo 应用依旧可以正常运行，但总归在某些场景 case 下，你的系统会出现问题。做不到优雅上线，你的系统将会出现：在应用刚启动时，就有流量进入，而此时应用尚未初始化完毕，导致调用失败，在集群规模较大时，影响会变得很明显。

前言

如果让你在本地构建一个 Dubbo 应用，你会需要额外搭建哪些中间件呢？如果没猜错的话，你的第一反应应该是注册中心，类 Dubbo 的大多数服务治理框架都有注册中心的概念。你可以部署一个 Zookeeper，或者一个 Nacos，看你的喜好。但在 Apache Dubbo 的 2.7 版本后，额外引入了两个中间件：元数据中心和配置中心。

在今年年初 Dubbo 2.7 刚发布时，我就写了一篇文章 《Dubbo 2.7 三大新特性详解》，介绍了包含元数据中心改造在内的三大新特性，但一些细节介绍没有详细呈现出来，在这篇文章中，我将会以 Dubbo 为例，跟大家一起探讨一下服务治理框架中元数据中心的意义与集成细节。

• 准备
  • 要求
  • 机器配置
  • 测试磁盘 IO 性能
• 实验一: Buffer IO 写入
• 实验二: 4K 单次 Direct IO 写入
• 实验三: mmap 写入
• 实验四: 改进的 mmap 写入
• 结论

最近在浏览别人博客时，一个萌物给了我意外的惊喜，原来博客还可以这么玩

于是果断审查元素，发现这个萌萌哒的看板娘背后使用的是一个叫 live2d 的技术，并且凭借 Google 迅速找到对应的开源代码：https://github.com/xiazeyu/live2d-widget.js，https://github.com/EYHN/hexo-helper-live2d

你可以在我的博客中先目睹下它的实际效果：https://www.cnkirito.moe/，点击会有音效哦~

在浏览 live2-widget.js 的说明文档时，发现它对 hexo 的支持非常友好，恰好我的博客是通过 hexo 搭建的，所以本文会介绍一下如何为 hexo 集成一只看板娘。

1 前言

一年之前，我曾经写过一篇《研究优雅停机时的一点思考》，主要介绍了 kill -9，kill -15 两个 Linux 指令的含义，并且针对性的聊到了 Spring Boot 应用如何正确的优雅停机，算是本文的前置文章，如果你对上述概念不甚了解，建议先去浏览一遍，再回头来看这篇文章。这篇文章将会以 Dubbo 为例，既聊架构设计，也聊源码，聊聊服务治理框架要真正实现优雅停机，需要注意哪些细节。

本文的写作思路是从 Dubbo 2.5.x 开始，围绕优雅停机这个优化点，一直追溯到最新的 2.7.x。先对 Dubbo 版本做一个简单的科普：2.7.x 和 2.6.x 是目前官方推荐使用的版本，其中 2.7.x 是捐献给 Apache 的版本，具备了很多新的特性，目前最新的 release 版本是 2.7.4，处于生产基本可用的状态；2.6.x 处于维护态，主要以 bugfix 为主，但经过了很多公司线上环境的验证，所以求稳的话，可以使用 2.6.x 分支最新的版本。至于 2.5.x，社区已经放弃了维护，并且 2.5.x 存在一定数量的 bug，本文介绍的 Dubbo 优雅停机特性便体现了这一点。

1 前言

说道性能测试工具，你会立刻联想到哪一个？ab（ApacheBench）、JMeter、LoadRunner、wrk…可以说市面上的压测工具实在是五花八门。那如果再问一句，对 Dubbo 进行性能压测，你会 pick 哪一个？可能大多数人就懵逼了。可以发现，大多数的压测工具对开放的协议支持地比较好，例如：HTTP 协议，但对于 Dubbo 框架的私有协议：dubbo，它们都显得力不从心了。

如果不从通用的压测工具上解决 Dubbo 的压测需求问题，可以自己写 Dubbo 客户端，自己统计汇总结果，但总归不够优雅，再加上很多开发同学没有丰富的测试经验，很容易出现一些偏差。说到底，还是压测工具靠谱，于是便引出了本文的主角 —— **jmeter-plugins-for-apache-dubbo**。这是一款由 Dubbo 社区 Commiter – 凝雨 同学开发的 JMeter 插件，可以非常轻松地对 Dubbo 实现性能测试。

1 前言

回顾第一次参加性能挑战赛 – 第四届阿里中间件性能挑战赛，那时候真的是什么都不会，只有一腔热情，借着比赛学会了 Netty、学会了文件 IO 的最佳实践，到了这次华为云举办的 TaurusDB 性能挑战赛，已经是第三次参加比赛了，同时也是最“坎坷”的一次比赛。经过我和某位不愿意透露姓名的 96 年小迷妹的不懈努力，最终跑分排名为第 3 名。