Consul 留给你的时间不多了

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

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

根据HashiCorpLicensingFAQ[2]显示，本次更改BusinessSource许可证的开源产品包括：HashiCorpTerraform、Packer、Vault、Boundary、Consul、Nomad、Waypoint和Vagrant。更改BSL许可证之前Consul的开源产品主要使用了和MIT许可证。在MPL许可证下最新版本是、、、、、、。MIT许可证最新版本是。

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

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

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

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

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

MariaDB

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

YoumayusetheLicensedWorkwhenyourapplicationusestheLicensedWorkwithatotaloflessthanthreeserverinstancesinproduction.

Couchbase

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

(i)YoumaynotprepareaderivativeworkbasedupontheLicensedWorkanddistributeorotherwiseoffersuchderivativework,whetheronastandalonebasisorincombinationwithotherproducts,applications,orservices(includinginany"as-a-service"offering,suchas,bywayofexample,asoftware-as-a-service,database-as-a-service,orinfrastructure-as-a-serviceoffering,oranyotherofferingbasedonacloudcomputingorothertypeofhosteddistributionmodel(collectively,"HostedOfferings")),forafeeorotherwiseonacommercialorotherfor-profitbasis.(ii)YoumaynotlinktheLicensedWorkto,orotherwiseincludetheLicensedWorkinorwith,anyproduct,application,orservice(includinginanyHostedOffering)thatisdistributedorotherwiseoffered,whetheronastandalonebasisorincombinationwithotherproducts,applications,(ii)shallnotlimitthegeneralityofcondition(i)above.

Lightb

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

图1.1Akka官网BSL说明

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

HashiCorp

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

YoumaymakeproductionuseoftheLicensedWork,providedYourusedoesnotincludeofferingtheLicensedWorktothirdpartiesonahostedorembeddedbasisinordertocompetewithHashiCorp'spaidversion(s)oftheLicensedWork.

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

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

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

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

功能需求。目标产品能否满足业务的需求，能否完全替代之前产品。

迁移成本。目标产品的迁移成本有多高，是否可以实现原产品到目标产品的平滑迁移。

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

主流的注册中心的对比

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

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

license许可

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

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.2Nacos架构

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

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

图2.3Nacos开源获奖图

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

为什么需要NacosSync？

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

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

整体迁移过程如下：

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

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

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

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

NacosSync简介

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

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

Nacos数据同步到Nacos

Zookeeper数据同步到Nacos

Nacos数据同步到Zookeeper

Eureka数据同步到Nacos

Consul数据同步到Nacos

图3.2Consul同步Nacos架构图

如何使用NacosSync平滑迁移

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

评估规格。确定MSENacos的容量规则满足业务的使用需要。

迁移上云。安装NacosSync工具，白屏化配置源端Consul到MSENacos的配置，完成服务的平滑同步。

步骤一：评估规格

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

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

图3.3MSE注册中心评估图

步骤二：迁移上云

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

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

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

图3.4NacosSync配置参数图

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

clusters:-clusterName:dstconnectKeyList:-{}:8848clusterType:NACOS-clusterName:srcconnectKeyList:-{}:8500clusterType:CONSULnamespace:''tasks:-source:srcdestination:dst

c.在实施迁移阶段，执行控制台的操作步骤。

通过以上简单两步就完成了Consul至Nacos的服务同步。服务Consumer和Provider择期完成直接使用Nacos注册中心的代码配置改造。

本文主要介绍了HashiCorpBSLlicense变更对于用户商业或生产使用带来的潜在风险，注册中心的选型对比，如何使用MSENacos替换Consul消除潜在的风险。欢迎对微服务架构感兴趣的小伙伴加入钉钉群与我们一起交流微服务的架构和使用心得。（钉钉群号：34754806）

最后，提醒正在使用HashiCorp旗下开源产品如Consul（原遵循MPL许可证）的用户，这些产品将不再继续维护，留给你的时间已经不多了。

[1]BusinessSourceLicense（BSL或BUSL）

[2]HashiCorpLicensingFAQ

[3]《ThefutureofTerraformmustbeopen》

[4]OpenTofu项目

[5]开源定义

[6]MaxScale产品使用限制

[7]CouchbaseLite、KVengine产品使用限制

[8]Akka产品使用限制

[9]协议内容

[10]Consul具有注册中心，配置中心和流量管理等功能

[11]《阿里巴巴为什么不用ZooKeeper做服务发现？》

[12]Nacos

[13]NacosSync

[14]微服务引擎MSE