序言

李艳林（彦林） Nacos PMC

阿里做开源大概有两个阶段，第一个阶段是 2018 年之前，取之于开源，反哺于社区，开源是一种情怀，是一种文化，是一种展示技术影响力和技术实力的方式，包括我在内很多阿里技术人都是因此影响加入。阿里凭借着互联网场景和规模的优势走在了时代的前列，完成了去 IOE ，创造了企业级互联网架构等壮举，并且开源了很多自主产品如 Dubbo、RocketMQ、Tengine、Jstorm 等，产生了巨大的影响力，在互联网行业广泛使用，但是这一阶段的开源除了情怀和展示技术影响力之后很难量化对公司的价值，因此也比较难以持续发展。第二个阶段是 2018 年开始，随着云计算发展，开源作为一种标准加速云计算发展，尤其 K8s 迅速崛起给我们很多启示，作为一家云计算公司，阿里巴巴也在 2018 年制定了一个全面开源，加速企业数字化转型，影响 100w 开发者的战略目标，这个阶段的开源发生了本质的两个变化，第一更重视社区和生态建设，第二更注重自研、开源、商业化三位一体，讲清开源的价值，能够持续投入开源，解决第一阶段难以持续的问题。 Nacos 也是在这个大势下应运而生，并且快速成为国内首选。
2018 年产品规划会一起到舟山小岛上，关于是否开源的时候面临几个核心问题进行深度讨论，第一个是我们开源是否晚了，如何定位和打造竞争力；第二是内部有三个产品（Configserver 非持久注册中心，VIPServer 持久化注册中心，Diamond 配置中心），是开源三个产品还是合成一个产品开源；第三个问题是开源产品跟商业化产品的关系是什么，是否会削弱商业化产品的竞争力。围绕这几个问题，我们吵到深夜两点。。

六点出海打渔，清晨冰冷的海风，摇曳的小船，撒出大网后我们忍受着寒冷，焦急和期望的等待着，收网时刻只有一些小鱼小虾，当然还有螃蟹。

2018 年开源是否晚了？是否要做？如何定位和打造竞争力？
相比当时比较流行的竞品，我们确实开源晚了一些，但是相比于整个行业其实不晚，因为当时云原生和微服务整个普及度还很低；还有我主管当时还强调两个点，第一个点是我们当时是一个闭源的一个软件，经常有业务方跳出来说你看 Eureka 多好，你们哪里哪里不行，如果我们不开源去打一打，怎么更好的证明我们更好，还有一个点是当时我们有商业化产品的，虽然我们知道我们更好，但是奈何用户选择的是 Eureka，我们只能兼容，而且我们不出去，不成为默认标准，不知道未来还要被迫兼容更多不如我们的产品，这对我们来说是一个灾难。因此我们决定开源。
迎面而来的是第二个问题，开源的定位和竞争力是什么？内部三个产品的开源策略是什么？
由于当时 Spring-cloud 的崛起，微服务多个模块逐步被划分，包括注册中心、配置中心，如果从产品定位上，期望定位简单清晰，利于传播，我们需要分别开源我们内部产品，这样又会分散我们品牌和运营资源。另外大部分客户没有阿里这么大的体量，模块拆分过细，部署和运维成本都会成倍上涨，而且阿里巴巴也是从最早一个产品逐步演化成 3 个产品的，因此我们最终决定将内部三个产品合并统一开源。定位为：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。由于我们在阿里内部发展了 10 年，在易用、规模、实时、稳定沉淀了核心竞争力，围绕阿里 Dubbo 和 Spring-cloud-alibaba 生态进行推广，建立阿里 DNS（Dubbo+Nacos+Spring-cloud-alibaba/Seata/Sentinel）微服务最佳实践。
随着我们选择三合一的开源模式，又面临另外一个问题，未来内部和商业化关系是什么，代码关系是什么？
这个问题应该说一直持续，但是我们定下来开源、自研、商业化三位一体的战略，以开源为内核，以商业化为扩展；开源做生态，商业化做企业级特性，阿里内部做性能和高可用；开源做组件，商业化做解决方案；并且随着时间推移，基本按照这思路完成的正循环，全面系统的打造了 Nacos 各个维度的能力。

随着 Nacos 日益强大，我们一直想写一个 Nacos 电子书系统介绍 Nacos 架构与原理，让小伙伴深度了解国产的微服务架构设计思想，面对失败设计的设计思想，了解 Nacos 的设计思路。