从变更 license 协议，到联合创始人离职，是时候考虑 Consul 的国产化平替方案了...

作者：季敏：开源项目 Seata 创始人。

HashiCorp BSL license 变更

• 8月，HashiCorp 宣布所有产品和多个库的未来版本将从 Mozilla 公共许可证 v2.0 (MPL 2.0) 过渡到Business Source License（BSL 或 BUSL）v1.1[1]，旨在平衡开源和商业利益之间的需求。

• 12月，公司联合创始人 Mitchell Hashimoto 面向全体职员及社区发送了一封告别信，宣布他将从 HashiCorp 离职。

我们无法求证，Mitchell Hashimoto 的离职是否与近段时间变更许可协议引起的诸多纷争有关。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，这意味着在此日期之后，使用 MPL 2.0 许可的旧版本不会再收到来自任何官方的安全更新，如果决定继续使用旧版本，您可能需要自行承担维护责任，包括修复 bug 和处理安全漏洞。

那我们是否可以继续使用最新的 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个版本，社区获得过多项开源荣誉。

如何将 Consul 平滑迁移至 Nacos

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

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？

对于服务来说分为服务 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。

结语

本文主要介绍了 HashiCorp BSL license 变更对于用户商业或生产使用带来的潜在风险，注册中心的选型对比，如何使用 Nacos 替换 Consul 消除潜在的风险。

参考

1. https://www.hashicorp.com/blog/hashicorp-adopts-business-source-license

2. https://www.hashicorp.com/license-faq

3. https://blog.gruntwork.io/the-future-of-terraform-must-be-open-ab0b9ba65bca

4. https://opentofu.org/

5. https://opensource.org/definition-annotated/

6. https://mariadb.com/projects-using-bsl-11/

7. https://github.com/couchbase/couchbase-lite-core/blob/master/licenses/BSL-Couchbase.txt

8. https://akka.io/

9. https://github.com/hashicorp/consul/blob/main/LICENSE

10. https://developer.hashicorp.com/consul/docs/intro

11. https://developer.aliyun.com/article/601745

12. https://nacos.io/zh-cn/

13. https://nacos.io/zh-cn/docs/v2/ecology/use-nacos-sync.html

14. https://www.aliyun.com/product/aliware/mse

参考阅读：

• 爬虫与反爬-B站接口安全的风控介绍
  

• RocksDB 在 vivo 消息推送系统中的实践
  

• 如何用 Nacos 构建服务网格生态

• 基于Consul服务注册中心：一次故障分析及优化
  

本文由高可用架构转载。技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿