作者：季敏

HashiCorp BSL license 变更

在今年的 8 月份 HashiCorp 宣布所有产品和多个库的未来版本将从 Mozilla 公共许可证 v2.0 (MPL 2.0) 过渡到 Business Source License（BSL 或 BUSL）v1.1^[^1]。

近期，公司联合创始人 Mitchell Hashimoto 面向全体职员及社区发送了一封告别信，宣布他将从 HashiCorp 离职，我们无法印证这是否与近段时间变更许可协议引起的诸多纷争有关。HashiCorp 是一家专注于 DevOps 工具链的公司，其旗下明星级产品包括 Vagrant、Packer、Terraform、Consul、Nomad、Vault 等，这些产品贯穿了持续交付的整个流程。

根据 HashiCorp Licensing FAQ^[^2]显示，本次更改 Business Source 许可证的开源产品包括：HashiCorp Terraform、Packer、Vault、Boundary、Consul、Nomad、Waypoint 和 Vagrant。更改 BSL 许可证之前 Consul 的开源产品主要使用了 MPL 2.0 和 MIT 许可证。在 MPL 许可证下最新版本是 Terraform 1.5.5、Packer 1.9.2、Vault 1.14.1、Boundary 0.13.1、Consul 1.16.1、Nomad 1.6.1、Waypoint 0.11.4。MIT 许可证最新版本是 Vagrant 2.3.7。

HashiCorp BSL license 变更引发了社区的激烈讨论和反抗。知名 Terraform 增强型工具 Terragrunt 的作者 Yevgeniy Brikman 写了一篇博文《The future of Terraform must be open》^[^3]，他历数了 BSL 协议的三大问题。目前 Terragrunt 威胁发起 OpenTF（而后因为商标问题更名为 OpenTofu）项目^[^4]，创建一个仍旧遵循 MPL 2.0 协议的 Terraform 分叉。

BSL 许可证的变更不具有追溯性，也就意味着更改之前的所有源代码和版本仍处于 MPL 2.0 许可证之下。我们可以根据原始许可无限期地继续使用这些版本。虽然我们可以一直使用这些变更之前的版本，但是因为老版本无法持续迭代，所以会存在较多的问题影响到业务的稳定性。这些问题主要包括：无法使用较新版本特性和优化，无法修复老版本的 bug，无法及时处置安全漏洞问题。根据其声明，在原 MPL 许可下安全问题修复截止到 2023.12.31。

我们是否可以继续使用最新的 BSL 许可证的版本呢，下面我们一起了解下 BSL 许可证。

使用 BSL 许可证是否有风险？

BSL（Business Software License）是一种商业软件许可证，旨在平衡开源和商业利益之间的需求。BSL 许可证最新的版本是 1.1 版本，它是一种混合型许可证，结合了开源软件和闭源软件的特点，它并不属于开源协议，因为并不能满足开源定义^[^5]中关于“No Discrimination Against Fields of Endeavor”的定义。BSL 许可证规定了一段时间，在此期间内，软件被认为是商业源代码。

BSL 允许开发者在商业源代码期间提供付费支持和服务，以便在开源之前获得一些商业回报，从而鼓励开发者投入更多的精力和资源进行产品开发。期限届满后，软件许可会转变为一种新的许可证，新许可证需要跟 GPL 兼容的协议，可以是 Permissive 和 Copyleft 开源协议中的任意一个，软件的使用、修改和分发将受到更宽松的限制，更符合传统开源许可证的要求。BSL 许可证允许许可方自定义条款明确约定变更协议的期限和是否可以在附加使用条款中允许客户在其他特定生产环境下使用。

HashiCorp 并不是第一家使用 BSL 许可证的公司，在此之前 MariaDB，Couchbase，Lightbend，Cockroach Labs 和 Sentry 也采取了相同的做法。因为允许在 BSL 模板中自定义条款，每家公司对于生产环境可使用的限定条款和协议变更的期限也不尽相同，下面针对以上几家公司的 BSL 使用限制做简要的说明。

MariaDB

MariaDB 下的 MaxScale 产品使用限制^[^6]：在生产环境中应用节点数不能超过 3 个。限制的是大规模的使用，允许个人和小规模企业用户在有限规模下免费使用，超出 3 个节点需要付费来获得商业许可。

You may use the Licensed Work when your application uses the Licensed Work with a total of less than three server instances in production.

Couchbase

Couchbase 下的 Couchbase Lite、KV engine 产品使用限制^[^7]：简单的说不允许任何方式以有偿或盈利提供服务。限制的是商业使用，使用限制在使用 BSL 许可证产品中是比较友好的。

(i) You may not prepare a derivative work based upon the Licensed Work and
distribute or otherwise offer such derivative work, whether on a standalone
basis or in combination with other products, applications, or services
(including in any "as-a-service" offering, such as, by way of example, a
software-as-a-service, database-as-a-service, or infrastructure-as-a-service
offering, or any other offering based on a cloud computing or other type of
hosted distribution model (collectively, "Hosted Offerings")), for a fee or
otherwise on a commercial or other for-profit basis.
(ii) You may not link the Licensed Work to, or otherwise include the Licensed
Work in or with, any product, application, or service (including in any Hosted
Offering) that is distributed or otherwise offered, whether on a standalone
basis or in combination with other products, applications, or services for a fee
or otherwise on a commercial or other for-profit basis. Condition (ii) shall not
limit the generality of condition (i) above.

Lightbend

Lightbend 旗下 Akka 是业内久负盛名用于构建高度并发、分布式和具有弹性的面向消息驱动的 Java 和 Scala 应用程序的工具包。BSL 许可证的信息被放置在官网的首屏，非常的显眼。

图 1.1 Akka 官网 BSL 说明

Lightbend 下的 Akka 产品使用限制^[^8]: 开发和测试不需要许可，收入小于 2500 万美元的公司可以申请免费许可在生产环境使用，其他情况需要收费许可。限制的是具有一定收入水平的中小公司使用。

HashiCorp

如文章开头提到的 HashiCorp 在 8 月 10 日宣布，旗下多款产品变更为 BSL 许可证。让我们看下具体的协议内容^[^9]。

You may make production use of the Licensed Work, provided Your use does not
include offering the Licensed Work to third parties on a hosted or embedded
basis in order to compete with HashiCorp's paid version(s) of the Licensed Work.

HashiCorp 下的 BSL 许可证产品使用限制是：不能以托管或嵌入的方式向第三方提供竞争力的产品，以与 HashiCorp 的付费版本竞争。这个描述不像前面其他几个 case 中提到的规模还是收入限制，表达得那么清晰。如果不清楚是否存在潜在的产品竞争关系，需要发邮件向 HashiCorp 咨询。我们粗略的理解是不能以任何商业的方式提供给第三方，否则就存在法务的风险，具体解释权归 HashiCorp 所有。这对于企业用户在生产环境中使用 HashiCorp 的产品带来了很大的不确定性法务风险。

HashiCorp BSL 许可证变更对企业选型带来的思考

开源=免费？无论从早期的 Copyleft 类许可证还是近些年流行起来的 BSL 许可证应用案例来看，都充分说明开源并不等于免费，使用开源软件需要遵守许可证中定义的义务。在这些许可证中有的对于分发，商业和生产使用相对宽松，有的则比较苛刻。使用开源软件需要充分理解许可证中定义的限制条款，否则冒然使用将对组织带来法务合规风险。

对于已经使用了 HashiCorp 非商业版的产品，规避以上产品最好的做法是更换产品的选型。对于目标选型的产品我们需要充分考虑两点：

功能需求。目标产品能否满足业务的需求，能否完全替代之前产品。
迁移成本。目标产品的迁移成本有多高，是否可以实现原产品到目标产品的平滑迁移。

下面我们将针对使用较多 HashiCorp Consul 产品提出一种可行的平滑替代方案，将分别从功能和迁移成本方面描述。

Consul 的替代品 Nacos

主流的注册中心的对比

Consul 具有注册中心，配置中心和流量管理等功能^[^10]，注册中心功能是国内用户使用最多的功能。寻找其替代品，首先要对市面上主流的注册中心做一个选型的调研对比。以下选取了用户使用较多的注册中心包括：Nacos、Consul、Eureka 和 Zookkeeper。

选取的指标主要涵盖以下几个方面：

license 许可

是否存在商用或生产限制，上文我们已经讲到 HashiCorp BSL 许可证变更给用户生产使用带来了比较大的限制。

CAP 支持

CAP 是分布式系统中重要的理论依据，在设计系统时，需要根据业务需求和特定的场景来权衡一致性、可用性和分区容错性的关系，组件要根据业务的属性要求来满足 AP 或 CP 能力。比如金融系统要求更高的一致性保证数据的安全，社交系统可能牺牲一致性来更好的满足用户交互的可用性要求。对注册中心的 AP 或 CP 模型深入理解，大家可以参考文章《阿里巴巴为什么不用 ZooKeeper 做服务发现？》^[^11]。

高可靠

是否具备基本的服务实例健康检查能力，对非健康实例是否能及时注销通知客户端并收敛时间可控，对并发大流量是否具备过载保护能力，是否满足企业的多数据中心容灾的要求，是否支持多个注册中心之间跨区域和同区域同步。

生态支持

服务调用框架和注册中心共同构成微服务架构的最小内核，注册中心需要对主流的服务调用框架生态有完善的支持。另外，微服务是云原生架构的基石，而 Kubernetes 已成为云原生架构的标准操作界面，能否与 Kubernetes 生态集成进一步释放技术的红利对于整个 DevOPS 链路至关重要。

图 2.1 注册中心选型对比

通过上述表格对比来看，Nacos 相对于 Consul、Eureka 和 Zookkeeper 在license、CAP 支持、高可靠和生态上都要胜一筹。下面通过 Nacos 的简要介绍，来揭开 Nacos 的神秘面纱。

Nacos 简介

Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台，通过提供简单易用的动态服务发现、服务配置、服务共享与管理等服务基础设施，帮助用户在云原生时代，在私有云、混合云或者公有云等所有云环境中，更好的构建、交付、管理自己的微服务平台，更快的复用和组合业务服务，更快的交付商业创新的价值^[^12]。

Nacos 架构如下图所示，其架构在客户端接入、通讯层、连接层、功能层、一致性协议和存储层做了抽象，同时通过插件化设计满足不同用户对各类场景的扩展需求。

图 2.2 Nacos 架构

根据微服务领域问卷调研，国内使用 Nacos 的占有率达到 50% 以上，目前在国内服务注册中心及配置管理领域中市场占有率排名第一，并且各大云厂商纷纷开始提供 Nacos 云服务，侧面印证着 Nacos 用户基础以及快速增长。

Nacos 社区保持着高速的迭代，Nacos 多次获得 Github 中国区活跃度前十项目，目前已累计发行超过 60 个版本，社区斩获了多项开源大奖。包括 Nacos 被评为云原生领域人气指数 Top5 的项目、InfoQ 2022 年度十大开源新锐项目，近期 Nacos 也荣获由开放原子基金会主办的 “2023 年度生态开源项目”奖项，以及由中国科协科学技术传播中心、中国计算机学会、中国通信学会、中国科学院软件研究所共同主办 “2023 开源创新榜的优秀开源项目” 奖项。并且 Nacos 社区发布电子书《Nacos 架构与原理》收获 19w+ 阅读，5w+ 下载量，现已被大量各行各业的公司选型作为其注册配置中心。

图 2.3 Nacos 开源获奖图

如何将 Consul 平滑迁移至 Nacos

如何将 Consul 平滑迁移至 Nacos，Nacos Sync 为迁移提供了工具支持。

为什么需要 Nacos Sync？

对于服务来说分为服务 Provider 和服务 Consumer 两种角色，这两种角色如下图都对注册中心产生了依赖，对于微服务的 Provider 和 Consumer 往往由两个团队来维护，无法做到同步迭代做改造。另外，服务的发布也往往无法做到同时发布，如果任意一方直接迁移到 Nacos，另外一方未及时完成改造和发布，将会对业务的连续性造成影响。Nacos Sync 可以将服务的注册和发现两个过程实现对同一注册中心的解耦。

图 3.1 服务注册和发现模型图

整体迁移过程如下：

1. 安装 Nacos Sync 完成 Consul 至 Nacos 的服务同步。

2. 服务 Consumer 改造配置，服务发现指向 Nacos。若出现问题，回滚服务 Consumer 的发布。

3. 服务 Provider 改造配置，服务注册指向 Nacos。若出现问题，回滚服务 Provider 的发布。

4. 确认无问题后，下线 Nacos Sync 和 Consul。

Nacos Sync 简介

Nacos Sync 是一个支持多种注册中心的同步组件，基于 Spring boot 开发框架，数据层采用 Spring Data JPA，遵循了标准的 JPA 访问规范，支持多种数据源存储^[^13]。

Nacos Sync 使用了高效的事件异步驱动模型，支持多种自定义事件，使得同步任务处理的延时控制在 3s，8C16G 的单机能够支持 6K 的同步任务。目前已支持以下注册中心源端到目标端的同步：

Nacos 数据同步到 Nacos
Zookeeper 数据同步到 Nacos
Nacos 数据同步到 Zookeeper
Eureka 数据同步到 Nacos
Consul 数据同步到 Nacos

图 3.2 Consul 同步 Nacos 架构图

如何使用 Nacos Sync 平滑迁移

MSE 注册配置中心提供了 Nacos 的全托管集群，您无需关注引擎的资源购买、监控、运维和容灾问题，只需专注于业务开发，无需部署运维^[^14]。MSE 控制台提供了 Consul 至 Nacos 迁移的白屏化支持，使用户简单的两步操作即可完成服务的同步。

从 Consul 至 MSE Nacos，主要分为两个步骤：

评估规格。确定 MSE Nacos 的容量规则满足业务的使用需要。
迁移上云。安装 Nacos Sync 工具，白屏化配置源端 Consul 到 MSE Nacos 的配置，完成服务的平滑同步。

步骤一：评估规格

1. 登录 MSE 注册配置中心管理控制台，并在顶部菜单栏选择地域。

2. 在左侧导航栏，选择注册配置中心 > 迁移上云。

3. 在迁移上云页面，单击规格评估，在规格评估面板，配置相关参数，然后单击评估规格。

图 3.3 MSE 注册中心评估图

在当前的规格评估页面顶部，系统将根据评估结果，生成购买链接和推荐购买的实例规格。

4. 单击购买 MSE 实例链接，在购买页面配置 VPC 和网络等信息，在仔细确认信息无误后，单击立即购买。

步骤二：迁移上云

1. 登录 MSE 注册配置中心管理控制台，并在顶部菜单栏选择地域。

2. 在左侧导航栏，选择注册配置中心 > 迁移上云。

3. 在迁移上云页面，单击迁移配置，在迁移配置面板，根据页面向导配置参数。

a. 在部署工具阶段，根据控制台操作步骤部署迁移工具。完成迁移工具部署后，单击下一步。
迁移工具可通过容器或 Tar 包两种方式部署。具体部署详情，请参见 MSE Sync 迁移方案。
b. 在创建配置阶段，配置相关参数，然后单击下一步。

图 3.4 Nacos Sync 配置参数图

通过以上白屏化参数的配置，将为 Nacos Sync 自动生成 Consul 到 MSE Nacos 的同步配置，也可以自行通过 Nacos Sync 控制台手动导入同步配置。配置格式如下：

clusters:
  - clusterName: dst
    connectKeyList:
      - {nacos.endpoint}:8848
    clusterType: NACOS
  - clusterName: src
    connectKeyList:
      - {consul.endpoint}:8500
    clusterType: CONSUL
    namespace: ''
tasks:
  - source: src
    destination: dst