前言

近日，有报道称在 HashCorp 的商业软件试用协议上发现，旗下所有商业产品禁止在中国境内使用、部署、安装，这其中就包含了 Terraform, Consul, Vagrant 等众多知名软件，其中 Consul 是一个在微服务领域的开源软件，可以用于做注册发现、配置管理等场景。

该新闻在国内发酵后，有人在 Twitter上咨询了HashCorp 公司的创始人，得到的回复是影响的软件仅限于 Vault 这款加密软件，目前 HashCorp 公司的官方网站上已经更新了相关的条款，明确了受影响的产品仅限 Vault 这一款产品。

Consul 开源版是否收到影响？

上面的条款里只提到了商业软件，那么开源的 Consul 是否受到影响呢？在 Github 的 Consul 仓库上，可以得知项目的 license 是 Mozilla Public License 2.0 ，这款许可证在 Apache 官网上是 Category B , 属于 Weak Copy Left 许可，那么它有哪些特点呢？

1. 任何可以使用，复制，修改，重新分发该代码，包括商业目的使用。
2. 如果修改了 MPL 协议许可下的源码，再重新发布这部分源码的话，必须保留原来 MPL 许可证不得更换。
3. 如果基于该项目衍生出更大的项目，那么这部分工作可以使用新许可证的方式进行分发，只要没有修改原来 MPL 许可下的代码。（这也是为什么 Apache 项目的分发的源码中可以包含 MPL 协议下二进制文件的原因）

可以看到，MPL 通常被认为是介于 Apache License 和 GPL/LGPL 之间的一个折中方案。相对于 Apache License，MPL 2.0 要求修改了源码必须保持相同协议；相对于 GPL/LGPL, MPL 2.0 可以商用，同时衍生的作品在一定条件下也可以更换许可证类型。

总体来看的话，开源版 Consul 无论是私用还是商用都是不受限制的。但这也可能是一个警钟，如果对 Consul 还是有所顾忌的话，如何替代掉它呢？

在微服务领域，Consul 主要被用来做充当注册中心和配置中心，例如 Dubbo 和 SpringCloud 都有对应的支持。本文便以这个事为一个引子，介绍如何平滑地迁移 Dubbo 服务，达到替换注册中心的效果。

前言

本文是 Arthas 系列文章的第三篇。

本文主要介绍 trace 指令，用于定位两种类型的问题：

1. 线上服务 RT 比较高，但没有打印日志，无法确定具体是哪个方法比较耗时
2. 线上服务出现异常，需要追踪到方法的堆栈

前言

本文是 Arthas 系列文章的第二篇。

Dubbo 线程池满异常应该是大多数 Dubbo 用户都遇到过的一个问题，本文以 Arthas 3.1.7 版本为例，介绍如何针对该异常进行诊断，主要使用到 dashboard/thread 两个指令。

阿里巴巴中间件技术部 - aPaaS 产品团队春招意向沟通正式开始啦！三月前我们会完成和同学的意向沟通，三月初正式进入招聘流程。

简历投递：jingfeng.xjf@alibaba-inc.com

意向沟通联系微信：xiayimiaoshenghua

前言

本文是我介绍 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 写入
• 结论