Authors: 何煦

概述​

Nacos 是阿里巴巴今年7月份开源的项目，如其名， Naming and Configuration Service ，专注于服务发现和配置管理领域。本系列文章，将从 5W1H（What、Where、When、Who、Why、How）全面剖析 Nacos，希望对开发者们在服务发现和配置管理开源方案选型的时候，有所帮助。

本文作为 Nacos 系列文章的开篇，从 “What” 开始。我们开始关注一个开源项目的时候，通常最先冒出的 2 个问题是：

• 它是什么？
• 它帮我们解决什么问题？

Nacos 是什么？

Nacos 是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 能帮我们解决什么问题？

本文将先围绕其“配置管理”功能来解答。配置，作为代码如影随形的小伙伴，伴随着应用的整个生命周期，我们当然对它也非常的熟悉，想想配置一般都通过哪几种形式存在？

• 硬编码
• 配置文件
• DB 配置表

硬编码​

配置项作为类字段的形式存在，如：

public class AppConfig {

    private int connectTimeoutInMills = 5000;

    public int getConnectTimeoutInMills() {
        return connectTimeoutInMills;
    }

    public void setConnectTimeoutInMills(int connectTimeoutInMills) {
        this.connectTimeoutInMills = connectTimeoutInMills;
    }
}

这种形式主要有三个问题：

如果配置是需要动态修改的话，需要当前应用去暴露管理该配置项的接口，至于是 Controller 的 API 接口，还是 JMX ，都是可以做到。

另外，配置变更都是发生在内存中，并没有持久化。因此，在修改配置之后重启应用，配置又会变回代码中的默认值了，这是一个坑啊，笔者就曾经掉进去过，爬了好一会才上岸。

最后一个问题，就是当你有多台机器的时候，要修改一个配置，每一台都得去操作一遍，运维成本可想而知，极其蛋疼。

配置文件​

Spring 中常见的 properties、yml 文件，或其他自定义的，如，“conf”后缀等：

# application.properties
connectTimeoutInMills=5000

相比“硬编码”的形式，它解决了第二个问题，持久化了配置。但是，另外两个问题并没有解决，运维成本依旧还是很高的。

配置动态变更，可以是通过类似“硬编码”暴露管理接口的方式，这时，代码中会多一步持久化新配置到文件的逻辑。或者，简单粗暴点，直接登录机器上去修改配置文件，再重启应用，让配置生效。当然，你也可以在代码中增加一个定时任务，如每隔 10s 读取配置文件内容，让最新的配置能够及时在应用中生效，这样也就免去了重启应用这个“较重”的运维操作。

通过增加“持久化逻辑”、“定时任务”让“配置文件”的形式比“硬编码”前进了一小步。

DB 配置表​

这里的 DB 可以是 MySQL 等的关系型数据库，也可以是 Redis 等的非关系型数据库。数据表如：

CREATE TABLE `config` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `key` varchar(50) NOT NULL DEFAULT '' COMMENT '配置项',
  `value` varchar(50) NOT NULL DEFAULT '' COMMENT '配置内容',
  `updated_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `created_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_key` (`key`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='配置信息';

INSERT INTO `config` (`key`, `value`, `updated_time`, `created_time`) VALUES ('connectTimeoutInMills', '5000', CURRENT_TIMESTAMP, CURRENT_TIMESTAMP);

它相对于前两者，更进一步，将配置从应用中抽离出来，集中管理，能较大的降低运维成本。

那么，它能怎么解决动态更新配置的问题呢？据我所知，有两种方式。

其一，如同之前一样，通过暴露管理接口去解决，当然，也一样得增加持久化的逻辑，只不过，之前是写文件，现在是将最新配置写入数据库。不过，程序中还需要有定时从数据库读取最新配置的任务，这样，才能做到只需调用其中一台机器的管理配置接口，就能把最新的配置下发到整个应用集群所有的机器上，真正达到降低运维成本的目的。

其二，直接修改数据库，程序中通过定时任务从数据库读取最新的配置内容。

“DB 配置表”的形式解决了主要的问题，但是它不够优雅，带来了一些“累赘”。

Nacos 配置管理​

Nacos 真正将配置从应用中剥离出来，统一管理，优雅的解决了配置的动态变更、持久化、运维成本等问题。

应用自身既不需要去添加管理配置接口，也不需要自己去实现配置的持久化，更不需要引入“定时任务”以便降低运维成本。Nacos 提供的配置管理功能，将配置相关的所有逻辑都收拢，并且提供简单易用的 SDK，让应用的配置可以非常方便被 Nacos 管理起来。

如果是在 Spring 中使用 Nacos，只需三个步骤即可：

1. 添加依赖

<dependency>
    <groupId>com.alibaba.nacos</groupId>
    <artifactId>nacos-spring-context</artifactId>
    <version>${latest.version}</version>
</dependency>

2. 添加 @EnableNacosConfig 注解启用 Nacos Spring 的配置管理服务。以下示例中，我们使用 @NacosPropertySource 加载了 dataId 为 example 的配置源，并开启自动更新：

@Configuration
@EnableNacosConfig(globalProperties = @NacosProperties(serverAddr = "127.0.0.1:8848"))
@NacosPropertySource(dataId = "example", autoRefreshed = true)
public class NacosConfiguration {

}

3. 通过 Spring 的 @Value 注解设置属性值。

注意：需要同时有 Setter方法才能在配置变更的时候自动更新。

public class AppConfig {

    @Value("${connectTimeoutInMills:5000}")
    private int connectTimeoutInMills;

    public int getConnectTimeoutInMills() {
        return connectTimeoutInMills;
    }

    public void setConnectTimeoutInMills(int connectTimeoutInMills) {
        this.connectTimeoutInMills = connectTimeoutInMills;
    }
}

以上的三个步骤，对应用本身几乎没有任何的侵入，1 个依赖 2 注解，寥寥数行，就把配置通过 Nacos 管理起来了。

关于配置的动态更新，对 Nacos Spring 的用户来说，在自身应用中就只是设置 “autoRefreshed” 的一个布尔值。然后在需要修改配置的时候，调用 Nacos 修改配置的接口，或使用 Nacos 的控制台去修改，配置发生变更后， Nacos 就会把最新的配置推送到该应用的所有机器上，简单而高效。

想想之前，为了实现此功能，写了多少冤枉代码，做了多少冤枉的运维工作。要是早一点认识 Nacos，该有多好呀！

总结​

本文作为 Nacos 5W1H 系列文章的开篇，从“What” 讲述了 Nacos 配置管理能帮我们解决的问题：以简单、优雅、高效的方式管理配置，实现配置的动态变更，大大降低运维成本，让开发同学早点下班。

当然，Nacos 的配置管理，不单单只有上述的那些功能，还有诸如“灰度发布”、“版本管理”、“快速回滚”、“监听查询”、“推送轨迹”、“权限控制”、“敏感配置（如，数据库连接配置）的加密存储”等等，这些有的已经在 Nacos 中开源实现了，有的在 Nacos 配置管理的阿里云免费产品 ACM 中提供了，当然，后续也会慢慢开源到 Nacos 中，敬请期待。

本系列文章，会持续为大家讲述 Nacos 的点点滴滴，不单单讲述 “Nacos 能帮我们解决什么问题？”，还会深入源码分析“Nacos 是如何做到简单而强大的？”。同时，如果小伙们有兴趣的话，我们还会给大家八卦一下 Nacos 的 稗官野史，关于 Nacos 在阿里内部的历史，关于 Nacos 服务端口的寓意等等。总之，一句话：我有故事，也有美酒，君还何求？

Nacos是阿里巴巴中间件部门最近开源的一款用于服务发现和配置管理的产品。在既0.1版本发布基本功能和0.2版本发布与Spring生态结合的功能后，0.3版本将释放全新的控制台界面。配置管理功能相关的控制台，将会由阿里云商业产品ACM控制台改造而来，而服务发现的控制台界面，则将以首次露面的姿态，开放给开源社区。本文就将服务发现控制台相关的界面UI初版设计公布，欢迎大家参与讨论，希望通过大家的批评和建议，将服务发现控制台这块的功能和界面，设计的更加美观和易用。

服务发现控制台的主要功能是服务列表的展示和搜索，以及服务配置、集群配置、实例配置的查询和更新。在0.3版本中，主要会有两个页面：服务列表和服务详情。

服务列表

服务列表页面主要展示已经在Nacos注册的服务列表，以及服务的基本信息，服务的基本信息有：服务的名称、服务下集群的数目、服务下实例的数目、服务的健康程度以及进入服务详情的按钮。同时右上角还有一个支持根据服务名搜索服务的搜索框和搜索按钮。

服务详情

在服务列表页面点击“detail”按钮，就会进入服务详情页面。服务详情页面展示的是一个服务的所有关键信息，包括服务的配置和元数据、集群列表和示例列表，以及一些操作的按钮。

在该页面的上方，是服务的配置和元信息，目前包含服务名、保护阈值、健康检查模式以及元数据metadata。右上方是编辑服务按钮，点击后会有对话框弹出，可以对服务的配置进行编辑。

服务详情的下方，是集群列表和集群下的实例列表。每个集群会显示一个集群名，和相应的查看&更新集群详情按钮。点击该按钮后，会是一个更新集群的对话框。

图4和图5分别展示了对集群更新的两种对话框展示，两者的区别是选择了不同的健康检查方式。TCP健康检查方式可以配置检查的端口；HTTP健康检查方式可以配置检查的端口、检查的路径和HTTP头部信息。同时还可以配置是否采用实例的端口进行健康检查，如果配置为true，则健康检查将使用实例注册的端口进行通信。该对话框还可以编辑集群的元信息。

每个集群下面都会有实例列表，实例列表将会分页展示该集群下注册的所有实例，展示的信息有IP、端口、权重、是否健康、元信息和对应的编辑及下线按钮。下线按钮点击后，该实例将不会返回给订阅端，无论该实例是否健康。“下线”文本会改成“上线”，用于对应的实例上线操作。点击编辑按钮，则会进入编辑实例对话框。

编辑实例对话框，可以编辑的信息有实例的权重、是否上下线和元信息。

0.3版本的服务发现页面，基本就是这样，欢迎大家的反馈。服务注册客户端也可以编辑服务、集群、实例元信息，这些可能会和控制台的编辑相冲突，目前的机制是，不管是控制台更新和客户端更新，都将被Nacos服务端所接受，这点也欢迎大家给出自己的看法。最后也预祝大家国庆放假愉快！

在近期的Aliware Open Source 成都站的活动上，阿里巴巴高级工程师邢学超（于怀）分享了Nacos v0.2的规划和进度，并对Nacos v0.3的控制台进行了预览。Nacos v0.2将进一步融入Duboo和Spring Cloud生态，帮助开发者更好的在微服务场景下使用服务发现和动态配置管理。

嘉宾介绍：邢学超（于怀），Nacos开源项目主要推动者，负责阿里巴巴内部 configserver、skywalker和taokeeper产品的架构和研发，爱好代码、篮球、吉他和摇滚，还记得超哥给盲人小朋友写的那首超温暖的歌么？传送门：给你们的歌

1. Nacos开源介绍​

Nacos是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台，脱胎于承载整个阿里巴巴集团的软负载产品，并于今年7月对外开源。开源以来，获得了来自社区的积极反馈，star数突破 1k 。

Nacos旨在将阿里巴巴在建设共享服务体系中使用的服务发现、配置及服务管理平台贡献给开源社区，通过打造Dubbo + Nacos的经典组合进一步释放Dubbo在云原生及Service Mesh时代中，在大规模微服务治理、流量治理、服务集成与服务共享等服务平台能力建设上的威力，同时Nacos关注对主流开源社区，如Spring Cloud和Kubernetes云原生体系的无缝对接与支持。该项目预计在7月中旬开放首个测试预览版本，并计划在0.8版本上，达到生产可用的状态。此外，Nacos支持注册中心和配置中心的分离部署，也关注上云的saas化部署，实现云下到云上的平滑迁移。

Github项目主页： https://github.com/alibaba/nacos Nacos官网： http://nacos.io/ 

2. Nacos v0.2进度和规划​

Nacos + Dubbo， 双中心重构，释放威力 Dubbo2.7将对注册中心和配置中心进行重构。注册中心将只用于Endpoint的同步，进一步减轻注册中心的存储压力，提高地址同步效率，同时缓解当前由于URL冗余在大规模推送时造成的Consumer端内存计算压力。配置中心将解决当前配置和地址信息耦合的问题，通过抽象动态配置层，让开发者可以对接微服务场景下更常用的、更专业的配置中心。这使得Nacos和Dubbo的完美融合成为可能，进一步释放Dubbo在服务治理、流量治理、服务运营和管理等方面的威力。

Nacos + Spring Cloud，多层融入，无缝贴合 Nacos在技术社区已经启动Nacos + Spring Cloud的工程，可无缝支持Spring Cloud，为Spring Cloud用户提供更简便的配置中心和注册中心的解决方案，使用Nacos不用再仅仅为服务和配置就需要在生产上hold住 Eureka，Spring Cloud Config Server，Git，Consul 起码四个开源产品。

Nacos v0.2，全方位注解，实现平滑迁移 在 Java 生态系统中，以 Spring Boot 和 Spring Cloud 为代表的微服务框架，引入了全新的编程模型，包括： o 注解驱动（Annotation-Driven） o 外部化配置（External Configuration） o 自动装配（Auto-Configure）

Nacos将在v0.2支持原生Spring、Spring Boot、Spring Cloud中关于服务发现、配置管理的原生配置，适配Spring Boot、Spring Cloud标准，此外Nacos还是支持以下注解。

3. Nacos 代码演示 & v0.3控制台预览​

在分享中，于怀现场演示了如何快速运行一个Nacos应用、调用Nacos API、如何使用注解来运行Nacos。

同时，Nacos v0.3加入了控制台的功能，控制台分为两个内容，并会融合在一起：

1. 服务发现模块，包括服务上下线管理、服务权重、服务打标、服务健康信息和服务元信息的展现;
2. 配置模块，提供配置列表、监听查询、推送轨迹等功能。

4. Nacos 社区介绍和招募计划​

Nacos强调社区化的发展与社区的多样性，采取PMC和Committer机制来管理社区，鼓励热情、注重细节、积极参与社区活动、对项目感兴趣的开发者参与到开源项目中来，希望在第一年就吸收至少超过5名来自其它公司的PMC，至少10名的外部Committer，依托于社区将产品做得更好，并计划在19年年初和CNCF基金会或apache基金会沟通捐赠适宜，社区贡献者会随之进入基金会体系。

画外音：我们准备了40个Nacos限量版纪念品，用于奖励参与“Nacos有奖活动”的开发者。 活动链接： https://nacos.io/zh-cn/docs/activity.html

导读​

Consul是目前业界比较火的服务发现与配置产品，它率先将服务发现和配置管理等分布式服务当中使用到的基础服务进行整合，对外提供分布式及高可用的服务。Consul目前有开源版本和商业化版本同时演进，这也是国内可以借鉴的一种开源策略。同时，Consul对于新技术趋势的跟进和整合，也是值得我们学习和参考的。

本文翻译了Consul对于Kubernetes的整合所发布的公告文章（原文地址）。Consul通过支持Service Mesh，并提供对Kubernetes的无缝支持，与目前最受社区热捧的产品进行绑定，并通过功能预告的形式，来达到对产品宣传效果的最大化。

与Consul产品对应的，阿里巴巴在近期开源了其服务发现与配置管理产品Nacos。Nacos是阿里巴巴集团内部VIPServer、ConfigServer和Diamond三个支撑双十一的重要中间件产品整合而来。Nacos主要关注产品的极致易用以及与云原生的深度整合，主要支持服务发现、配置管理等功能。很快，Nacos也会与Service Mesh进行整合，同时在集团内部和开源进行发布，利用阿里巴巴丰富的场景和开源社区的力量，将Nacos打造成云原生生态中不可或缺的基础产品。

我们很高兴地宣布HashiCorp Consul与Kubernetes深度整合的多项功能。 这篇文章将分享将在未来几周内发布的一系列初步功能。

这些功能包括用于在Kubernetes上安装Consul的官方Helm Chart，与Consul自动同步Kubernetes服务（反之亦然），外部Consul Agent自动加入Kubernetes中的集群，用于Connect自动保护pod的注入器，以及对Envoy的支持。

除了与Kubernetes本地集成之外，这些功能还有助于解决多个Kubernetes集群之间以及Kubernetes服务与非Kubernetes服务交互多项重要跨集群挑战。 我们很高兴与您分享这项工作。

功能点​

以下是将在未来几周内公布和发布的功能列表。后续公告博客将详细介绍每个项目，每个项目都将链接到该公告帖子。

• Helm Chart。用于在Kubernetes上安装，配置和升级Consul的官方Helm Chart。此Helm Chart还将支持Kubernetes的其他功能的自动安装和配置，例如目录同步。
• Kubernetes自动加入。Consul的云自动加入功能将更新，以支持发现和加入基于Kubernetes的Agent代理。这将使外部Consul Agent加入在Kubernetes中运行的Consul集群。
• 服务目录同步：从K8S到Consul。适当的Kubernetes服务将自动同步到Consul目录，使非Kubernetes服务能够发现并连接到Kubernetes中运行的服务。
• 服务目录同步：从Consul到K8S。Consul服务将同步到Kubernetes服务，以便应用程序可以使用Kubernetes本地服务发现来发现和连接在Kubernetes之外运行的服务。
• Connect自动注入。部署在Kubernetes中的Pod可以配置为自动使用Connect通过TLS进行安全通信。
• 支持Envoy Proxy。配置为使用Connect自动注入的Pod可以使用Envoy Proxy进行第4层通信，通过Connect进行保护。 Envoy也将用于非Kubernetes的Connect部署。

与Kubernetes整合​

我们目前正在与Kubernetes在多个产品上进行密切整合。通过使我们的产品更易于运行以及集成和增强Kubernetes功能，我们看到了解决纯Kubernetes用户挑战的机会。

这种集成的核心原则是增强现有功能而不是替换。服务、ConfigMaps及Secrets等功能是Kubernetes核心工作流程的一部分。更高级别的工具和扩展利用这些核心原语。因此，我们也在整合和增强这些核心原语。例如，Consul目录同步将Consul目录中的外部服务转换为一级的Kubernetes服务资源。然后，在Kubernetes中运行的应用程序可以发现并连接到非Kubernetes服务。

除了使我们的产品在Kubernetes中更易用和更自然之外，这些集成还允许用户在与非Kubernetes工作负载共享的环境中更好地工作。 虽然新用户很容易在纯Kubernetes环境中启动，但大多数部署必须与在云计算环境中运行的外部服务，本地数据中心等进行交互。 像Consul这样的HashiCorp产品专为这些异构环境而设计。 通过实现更自然的Kubernetes体验，非Kubernetes应用程序与Kubernetes应用程序交互变得同样自然。

下一步

我们很高兴地宣布第一批HashiCorp Consul和Kubernetes的功能。 这些功能使得在Kubernetes上运行Consul，与非Kubernetes服务进行交互，在Kubernetes内外进行安全通信等等更加容易。 这些功能中的每一项都将在未来几周内全面公布和发布，从下周的Helm Chart开始。

Terraform和Vault也与Kubernetes紧密集成。 Terraform Kubernetes提供商现在拥有一名专职工程师，并且在未来几个月内应该会迅速改进。 Vault正在开发新的集成，也将很快公布。

如果您对Kubernetes，我们的工具以及改进这些集成感兴趣，请加入我们！ 我们有一些针对Kubernetes集成的生态系统工程师岗位需求。

当前，微服务架构已经成为企业尤其是互联网企业技术选型的一个重要参考。微服务架构中涉及到很多模块，本文将重点介绍微服务架构的服务注册与发现以及如何基于DNS做服务发现。最后，简单介绍下阿里巴巴内部是如何基于DNS做服务发现的。

服务注册与发现​

微服务体系中，服务注册与服务发现是两个最核心的模块。服务A调用服务B时，需要通过服务发现模块找到服务B的IP和端口列表，而服务B的实例在启动时需要把提供服务的IP和端口注册到服务注册中心。一个典型的结构如下图：

服务注册​

目前，流行的注册中心比较多，常见的有zookeeper、ectd、consul、eureka等。服务注册通常有三种：自注册、第三方注册、注册中心主动同步。

• 自注册 自注册，顾名思义，就是服务提供方在启动服务时自己把提供服务的IP和端口发送到注册中心，并通过心跳方式维持健康状态；服务下线时，自己把相应的数据删除。典型的像使用eureka客户端发布微服务。
• 第三方注册 第三方注册是指，存在一个第三方的系统负责在服务启动或停止时向注册中心增加或删除服务数据。典型的用法是devops系统或容器调度系统主动调注册中心接口注册服务；
• 注册中心主动同步 与第三方注册方式类似，主动注册方式是指注册中心和调度或发布系统打通，主动同步最新的服务IP列表；一个例子是kubernetes体系中，coredns订阅api server数据。

服务发现​

在真正发起服务调用前，调用方需要从注册中心拿到相应服务可用的IP和端口列表，即服务发现。服务发现从对应用的侵入性上可以分为两大类：

• SDK-Based 这类的服务发现方式，需要调用方依赖相应的SDK，显式调用SDK代码才可以实现服务调用，即对业务有侵入性，典型例子如eureka、zookeeper等。
• DNS-Based DNS本身是一种域名解析系统，可以满足简单的服务发现场景，如双方约定好端口、序列化协议等等。但是，这远远不能满足真正的微服务场景需求。近几年，基于dns的服务发现渐渐被业界提了出来。后面将重点介绍基于DNS的服务发现及阿里巴巴的实践。

基于DNS的服务发现​

DNS协议是目前最为通用的协议之一，几乎所有操作系统都会有DNS客户端实现。所以，其天然具有跨语言特性。这也是快速接入微服务体系最快的一个方式。要基于DNS做服务发现，首先注册中心的数据应该可以以DNS的数据格式暴露出来。让任何系统的DNS 客户端都可以通过DNS协议获取服务列表。

基于DNS的服务发现方式，大致可以归结两类：

独立DNS服务器​

独立DNS Server模式的基本架构如下图：

如上图所示，这种架构中，需要独立的DNS服务器。DNS服务器从注册中心获取所有已注册的服务及对应的IP端口列表。调用方Service A 通过DNS查询某个服务下的IP列表，然后发起调用。

这种类型的服务发现方式优缺点分别如下：

• 优点
  • 集中的DNS服务器，便于升级维护
• 缺点
  • 对DNS服务器性能要求高
  • 这种情况下一般需要LVS设备为DNS服务器集群做请求转发，存在单点问题

DNS Filter​

DNS Filter模式我们定义为把DNS服务器集成到服务调用方机器或容器里，如下图所示：

这种模式中，首先要保证ServiceA的DNS查询都被拦截到本机的DNS服务器上（127.0.0.1:53），在获取到服务的IP列表后发起调用。由于这种方式把DNS服务器前置到实际调用的机器上，所以它解决了独立DNS服务器模式的单点问题，完全P2P的模式。但由于需要在应用机器上安装DNS服务器，其维护和升级成本较前者高一些。

阿里基于DNS的服务发现实践​

阿里巴巴早在2014年就开始了基于DNS做服务发现的尝试了，现在已经形成了较为成熟的模式。阿里内部以VIPServer作为注册中心，并开发了DNS Filter，部署在应用容器内。目前已经有超过20w个机器或容器上安装了DNS Filter，支持了几乎所有REST服务发现。

注册中心 VIPServer​

VIPServer是阿里中间件软负载团队自研的服务注册中心，按照第一章的分类，VIPServer同时支持三种模式的服务注册，并且均有相当规模的应用。除此之外，VIPServer具备如下特性：

• 主动与被动健康检查 VIPServer同时支持主动与被动健康检查。主动健康检查是指VIPserver服务端主动定期发送健康检查探测包，探测服务提供方是否可以正常提供服务。用户可以配置多种健康检查方式，自定义探测端口和探测URL（HTTP）。主动探测的好处在于服务提供方不用做任何改动即可快融入微服务架构。被动健康检查则是指服务提供方主动注册自己的IP、端口和服务名等信息，并通过心跳方式保持活性。
• 多种负载均衡策略 同时，VIPServer支持多种负载均衡策略，包括权重、同机房、同地域、同环境等等，是阿里异地多活项目的核心系统之一。后面会有专门的文章介绍如何基于VIPServer实现异地多活，这里不再赘述。
• 多重容灾保护策略 VIPServer提供了多种容灾保护策略，可以有效减少人为或者底层系统（网络等）异常带来的影响。这些容灾保护包括：
  • 客户端缓存，即使VIPServer服务端挂掉也不影响应用的正常调用；
  • 服务端保护阈值，有效防止应用因压力过大而发生雪崩；
  • 客户端容灾目录，提供人工干预服务IP列表的能力；
  • 客户端空列表保护，有效防止人为误删IP列表操作或VIPServer服务端异常

DNS-F客户端​

出于性能的考虑，我们采用了第二种DNS Filter的服务发现模式。为此，我们单独开发了DNS-F客户端，DNS-F客户端跟应用部署在同一个主机或容器内。其工作原理如下图所示：

• 首先，应用ServiceA通过DNS查询获取到ServiceB的可用IP列表
• DNS-F会拦截到ServiceA的查询请求，判断自己是否该查询的答案，如果有（服务已在VIPServer中注册）则直接返回IP列表；
• 如果查询的服务在VIPServer中没有注册，DNS-F把DNS查询转发给系统的nameserver，由真正的DNS系统解析；

总结​

本文介绍了微服务架构中如何基于DNS做服务发现。首先，介绍了服务法注册与发现的概念、服务注册与发现的几种方式及其优缺点；然后，介绍基于DNS的服务发现的两种方式及其优缺点；最后，介绍了阿里巴巴基于DNS做服务发现的实践，主要是基于自研的软负载系统VIPServer。基于DNS的服务发现要解决的问题远不止本文描述的这些，敬请期待后续系列文章（：。

贡献Dubbo生态，阿里Nacos开源计划​

在上周六的Aliware技术行上海站Dubbo开发者沙龙上，阿里巴巴高级技术专家郭平(坤宇)宣布了阿里巴巴的一个新开源计划，阿里巴巴计划在7月份开启一个名叫Nacos的新开源项目, 在活动演讲中，坤宇介绍了这个开源项目的初衷，他表示 “将通过Nacos项目将阿里巴巴在建设共享服务体系中使用的服务发现、配置及服务管理平台贡献给开源社区，通过打造Dubbo + Nacos的经典组合进一步释放Dubbo在云原生及Service Mesh时代中，在大规模微服务治理、流量治理、服务集成与服务共享等服务平台能力建设上的威力，同时Nacos会非常关注对主流开源社区，如Spring Cloud和Kubernetes云原生体系的无缝对接与支持”。该项目预计在7月中旬之前开放首个测试预览版本，并计划在未来6~8个月release的0.8版本开始达到生产可用的状态。

活动的 视频回放

什么是 Nacos /nɑ:kəʊs/?​

Nacos 是阿里巴巴的新开源项目，其核心定位是 “一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台”。

Nacos 有三大主要功能:

• 服务发现与服务管理

在采用以“服务(Service)”为中心的诸如微服务及云原生方式的现代应用架构时，动态服务发现至关重要。 Nacos同时支持基于DNS和基于RPC（如Dubbo/gRPC）的服务发现，并为您提供服务的实时的健康检查以防止将请求发送给不健康的主机，基于Nacos您也可以更方便的实现服务断路器。Nacos提供的强大的服务的元数据管理，路由及流量管理策略也能够帮助您更好的构建更强壮的微服务平台。

• 动态配置管理

动态配置服务允许您在所有环境中以集中和动态的方式管理所有应用程序或服务的配置。动态配置消除了配置更新时重新部署应用程序和服务的需要。可以更方便的帮助您实现无状态服务，更轻松地实现按需弹性扩展服务实例。

• 动态DNS服务

支持权重路由的动态DNS服务使您可以更轻松地在数据中心内的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务，帮助您更容易的实现DNS-based服务发现。

为什么开源 Nacos​

阿里巴巴为什么选择这么一个时间点开源Nacos，其背后的思考是什么，坤宇也给出了详细的解读，在演讲中，坤宇表示主意基于以下几点:

• 围绕着Service为中心的分布式基础设施正在变的越来越重要

世界正在变的更快，创新和市场竞争的节奏正在变得愈发剧烈，如何超快速实现业务增长成为商业竞争的主旋律，几乎一夜之间共享单车就火遍全国，不到几年滴滴就改变了我们的打车方式，腾讯三班倒实现全民“吃鸡”，现在企业估值在从0到100亿所需的时间越来越短，而企业的平均寿命从标普的数据来看却从上世纪60年代的60年下降到了今天的15年，一切都表示创新和竞争的速度和烈度在加强。

另一方面技术基础设施的敏捷和有效性在商业成功的要素上占据的比重越来越大，云计算在资源和服务交付模式上的变革，带来了效率的革命性提升，带来了更敏捷的基础设施（创业不用再买机器并找机房托管，从以前的半年准备周期到现在在云上的小时级创建全套服务），而在应用架构层面，微服务架构模式带来的灵活性、韧劲，快速组合和聚合原子服务从而创新，给业务快速创新和试错提供了条件，已经被越来越多的应用平台证明其有效性，技术基础设施的更敏捷，给商业的敏捷和商业的竞争优势提供了基础。

在今天，无论是云计算，微服务还是围绕Kubernetes为中心的云原生，都在强调以“服务”为内核的应用架构模式，如果说15年前我们在讨论“一切皆是对象”构建单体系统，那么今天我们就是在谈论“一切皆是服务”，10年前淘宝服务化改造顺应了这种趋势，8年前微服务架构思想也顺应了这个趋势，今天面向“服务”的各种分布式基础设施正在变得越来越重要，站在阿里巴巴10年的服务化发展经验上看，在大规模服务发现和服务治理和服务共享领域现有的开源解决方案是不是都已经非常完美了呢？根据阿里巴巴服务化走过的这些年的生产经验来看，我们觉得并没有。

• 阿里巴巴在 "共享服务体系" 建设上的经验可以在各个行业大规模复用

阿里巴巴中台理念和体系，与云原生在精神的“道”上完全契合，即“厚技术平台，薄应用” 支持业务的快速创新与试错，从而赢得市场，中台体系倡导双引擎架构，略过“大数据”不谈，但看业务中台，就是一个大的以“服务”为中心的共享服务平台，在线服务沉淀业务数据，同步到大数据平台计算和挖掘，大数据平台则通过数据回馈，指导业务及服务的创新，支成可沉淀和可共享“服务”体系的服务注册与服务治理平台是这个体系的关键要素之一。

• “服务治理，服务沉淀、服务共享和服务的可持续发展”是“共享服务体系”的核心价值主张

支持创新从小苗长成参天大树，服务平台不断演进，这一切需要一个强大的服务平台和服务基础设施的支撑。

• 阿里巴巴将通过Dubbo + Nacos以及一系列开源项目打造服务发现、服务及流量管理、服务共享平台

Nacos 与 主流开源生态的关系​

Nacos 不会是个封闭的体系，除了对于阿里开源生态体系如Dubbo等自身的支持，也非常强调融入其它的开源生态，这里就包括Java的微服务生态体系Spring Cloud，Kubernetes/CNCF云原生生态体系，正如Nacos的未来全景图展示的那样

• Dubbo + Nacos， 专为Dubbo而生的注册中心与配置中心

在阿里巴巴生产环境上，Dubbo和Nacos天然就是长在一起的，因为Nacos的缺失，传统的注册中心解决方案让Dubbo在服务治理、流量治理、服务运营和管理等方面的威力被限制和削弱了，Nacos的开源和开放会在采用Dubbo的用户环境中释放这些威力

• Nacos 会完全兼容Spring Cloud

Nacos会无缝支持Spring Cloud，为Spring Cloud用户其提供更简便的配置中心和注册中心的解决方案，使用Nacos不用再仅仅为服务和配置就需要在生产上hold住 Eureka，Spring Cloud Config Server，Git，RabbitMQ/Kafka 起码四个开源产品。

• Nacos 支持Kubernetes DNS-based Service Discovery

在演讲中坤宇也表示，阿里巴巴这么多年在VIPServer DNS-based Service Discovery上的实践证明，在云原生时代，应用会更关注与基础设施的解耦合、多语言乃至多云的诉求，服务发现的未来一定是基于标准的DNS协议做，而不是像Eureka或者像ZooKeeper这样的私有API或者协议做, 同时在云上，在服务发现场景中，注册中心更关注的是可用性而不是数据一致性，所以Nacos会首推DNS-based Servcie Discovery，并优先关注可用性，而这也正是Nacos可以无缝融合进Kubernetes服务发现体系的原因所在

• Nacos 会填补Spring Cloud 体系与 Kubernetes 体系的鸿沟

未来会有越来越多java生态的用户会选择 Kubernetes+Spring Cloud 组合，但不幸的是，在服务发现和配置管理的解决方案上，这2个体系都采用了完全不同的方案，这给同时采用2个体系的用户在注册中心和配置中心的需求上带来了非常大的不必要的复杂性。Nacos会尝试填补2者的鸿沟，以便在2套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。

• Nacos 与 Service Mesh

Nacos 部分特性预览​

同时在会上，坤宇对Nacos 1.0版本的部分特性给大家做了预览

每个产品都有自己的风格和标签，坤宇在演讲中表示，团队会通过持续的贡献和努力，希望未来给Nacos贴上四个方面的标签

在部署形态上，Nacos会支持多种部署形态，包括注册中心与配置中心的分离部署，同时在阿里云上提供Nacos的SaaS化部署服务，感兴趣的可以直接在阿里云上开通账户免费体验Nacos服务，在开源与商业化版本差别上，商业化的ACM以及EDAS ANS更强调与阿里云其它云服务以及其它Aliware PaaS的商业产品的集成体验以及提供商业服务。

Nacos 的主要产品里程碑及计划​

罗马不是一天建成的，吾将上下而求索

因为Nacos是脱胎于阿里巴巴的生产代码，整体体系非常庞杂，在代码梳理、重构和剥离与内部的耦合上是一个渐进的过程，所以@坤宇特别提醒社区在Nacos 0.8达到生产可用状态前，不建议用于生产，不过可以在开发和测试环境尝试使用，在0.8版本开始，大家可以放心的用于生产环境，Nacos整体研发计划是在未来6-8个月将达到生产可用的状态，未来会很快启动将Nacos贡献给开源基金会进一步社区化发展。

Nacos 与相关开源产品的对比​

君子和而不同

如上面对整体业务及技术形式的判断，我们可以看到 Nacos 与同类竞品的主要不同主要在于理念，@坤宇介绍说，严格来说这些市面上的产品并不与Nacos完全对标，只是与Nacos里面的服务发现部分对标，Nacos的未来更看重在这些产品的基础上构建服务平台的能力，而不仅仅是在基础的服务发现能力上。

社区化发展，欢迎加入并贡献社区​

DISS is cheap, show me your hand 比吐槽更重要的是搭把手，参与社区一起发展Nacos

与阿里巴巴早期的开源不同，阿里巴巴新一轮的开源包括RocketMQ，Pouch Container，Dubbo, Nacos等开源产品更强调社区化的发展与社区的多样性，鼓励更多的公司和更多的开发者参与到开源项目中来，依托于社区将产品做得更好，同时一开始就会关注国际化，与国外同类产品的直面竞争。

Nacos初步计划，在第一年就吸收至少超过5名来自其它公司的PMC,至少10名的外部Committer, 而且Nacos处在项目开源的初期，有大把的空间让有想法、有热情、有能力的开发者参与进来，Nacos本身在很多方面都急需要社区的帮助，这里面就急需包括前端及UI建设，Spring Cloud、Kubernetes、Service Mesh体系融合与集成，多语言客户端等各方面的技术领导者的参与，如果您对Nacos这个开源项目感兴趣，欢迎加入Nacos社区。你可以通过扫“超哥”的微信二维码，让“超哥” 帮你加入 “Nacos社区交流群”

感谢所有未来给我们帮助的朋友​

References​

• 阿里巴巴为什么不用 ZooKeeper 做服务发现？
• 现代应用架构中的配置管理面临的挑战和应对之道
• 章文嵩博士和他背后的负载均衡帝国
• VIPServer：阿里智能地址映射及环境管理系统详解

作者：阿里巴巴高级技术专家，许真恩(慕义)

文章概要：本文简单描述了Eureka1.0存在的架构问题，Eureka2.0设想的架构。详细回顾了阿里巴巴的服务注册中心ConfigServer产品从2008年建设元年至今经历的关键架构演进。通过这个文章你会对基于AP模式的注册中心在技术发展过程中将会碰到的问题有所感知。

Eureka1.0架构存在的问题

Eureka作为Netflix公司力推和SpringCloud微服务标配的注册中心开源解决方案，其Eureka 2.0 (Discontinued)的消息在社区引起了不小的骚动；其实早在2015年社区就已经放出了2.0架构的升级设想，但是3年的时间过去，等到的确是Discontinued的消息，虽然2.0的代码在github的主页上也已经放出，但是告诫用户要自行承担当中的使用风险。我想不会有人真的把2.0直接投入到生产中使用。

对于为什么要做Eureka2.0，其官方的wiki中的Why Eureka 2.0和Eureka 2.0 Improvements做了如下的说明

• Only support homogenous client views: Eureka servers only expects the client to always get the entire registry and does not allow to get specific applications/VIP addresses. This imposes a memory limitation on all clients registering with Eureka, even if they need a very small subset of the Eureka’s registry.
• Only supports scheduled updates: Eureka client follows a poll model to fetch updates from the server routinely. This imposes an overhead on the client of doing a scheduled call to the server, even if there are no changes and also delays the updates by the poll interval.
• Replication algorithm limits scalability: Eureka follows a broadcast replication model i.e. all the servers replicate data and heartbeats to all the peers. This is simple and effective for the data set that eureka contains however replication is implemented by relaying all the HTTP calls that a server receives as is to all the peers. This limits scalability as every node has to withstand the entire write load on eureka.

Although Eureka 2.0 provides a more richer feature set, the above limitations are the major driving factors for the changes proposed in this version. Based on the above motivations, Eureka 2.0 achieves the following improvements:

• Interest based subscription model for registry data: A client of Eureka is able to select a part of the instance registry in which it is interested in and the eureka server only sends information about that part of the registry. Eg: A client can say I am only interested in application “WebFarm” and then the server will only send information about WebFarm instances. Eureka server provides various selection criterions and a way to update this interest set dynamically.
• Push model from the server for any changes to the interest set: Instead of the current pull model from the client, Eureka servers pushes updates for changes to the interest set, to the client.
• Optimized replication: As Eureka 1.0, Eureka 2.0 also follows a broadcast replication model i.e. every node replicates data to all other nodes. However, the replication algorithm is much more optimized eliminating the need of sending heartbeats for every instance in the registry. This drastically reduce the replication traffic and achieves much higher scalability.
• Auto-scaled Eureka servers: Eureka 2.0 divides the read (discovery of data) and write (registration) concerns into separate clusters. Since, the write load is predictable (proportional to the number of instances in a region), the write cluster is pre-scaled. On the other hand, read load is unpredictable (proportional to subscriptions from clients) and hence the read farm is auto-scaled.
• Audit log: Eureka 2.0 provides an elaborate audit log for any change done to the registry. This helps Eureka owners as well as users to get insight into debugging the state of individual application instances as exists in Eureka. The audit log by default is persisted to a log file, but different persistent storages can be plugged-in.
• Dashboard: Eureka 2.0 provides a rich dashboard (as opposed to very rudimentary dashboard of Eureka 1.0) with insights into Eureka internals with respect to registry views, server health, subscription state, audit log, etc.

 简单翻译总结，也就是Eureka1.0的架构主要存在如下的不足：

• 订阅端拿到的是服务的全量的地址：这个对于客户端的内存是一个比较大的消耗，特别在多数据中心部署的情况下，某个数据中心的订阅端往往只需要同数据中心的服务提供端即可。
• pull模式：客户端采用周期性向服务端主动pull服务数据的模式（也就是客户端轮训的方式），这个方式存在实时性不足以及无谓的拉取性能消耗的问题。
• 一致性协议：Eureka集群的多副本的一致性协议采用类似“异步多写”的AP协议，每一个server都会把本地接收到的写请求（register/heartbeat/unregister/update）发送给组成集群的其他所有的机器（Eureka称之为peer），特别是hearbeat报文是周期性持续不断的在client->server->all peers之间传送；这样的一致性算法，导致了如下问题
  • 每一台Server都需要存储全量的服务数据，Server的内存明显会成为瓶颈。
  • 当订阅者却来越多的时候，需要扩容Eureka集群来提高读的能力，但是扩容的同时会导致每台server需要承担更多的写请求，扩容的效果不明显。
  • 组成Eureka集群的所有server都需要采用相同的物理配置，并且只能通过不断的提高配置来容纳更多的服务数据

Eureka2.0主要就是为了解决上述问题而提出的，主要包含了如下的改进和增强

• 数据推送从pull走向push模式，并且实现更小粒度的服务地址按需订阅的功能。
• 读写分离：写集群相对稳定，无需经常扩容；读集群可以按需扩容以提高数据推送能力。
• 新增审计日志的功能和功能更丰富的Dashboard。

Eureka1.0版本存在的问题以及Eureka2.0架构设想和阿里巴巴内部的同类产品ConfigServer所经历的阶段非常相似（甚至Eureka2.0如果真的落地后存在的问题，阿里巴巴早已经发现并且已经解决），下面我带着你来回顾一下我们所经历过的。

阿里巴巴服务注册中心ConfigServer技术发现路线

阿里巴巴早在2008就开始了服务化的进程，在那个时候就就已经自研出服务发现解决方案（内部产品名叫ConfigServer）。

当2012年9月1号Eureka放出第一个1.1.2版本的时候，我们把ConfigServer和Eureka进行了深度的对比，希望能够从Eureka找到一些借鉴来解决当时的ConfigServer发展过程中碰到的问题（后面会提到）；然而事与愿违，我们已经发现Eureka1.x架构存在比较严重的扩展性和实时性的问题（正如上面所描述的），这些问题ConfigServer当时的版本也大同小异的存在，我们在2012年底对ConfigServer的架构进行了升级来解决这些问题。

当2015年Eureka社区放出2.0架构升级的声音的时候，我们同样第一时间查看了2.0的目标架构设计，我们惊奇的发现Eureka的这个新的架构同2012年底ConfigServer的架构非常相似，当时一方面感慨“英雄所见略同”，另一方也有些失望，因为ConfigServer2012年的架构早就无法满足阿里巴巴内部的发展诉求了。

下面我从头回顾一下，阿里巴巴的ConfigServer的技术发展过程中的几个里程碑事件。

2008年，无ConfigServer的时代​

借助用硬件负载设备F5提供的vip功能，服务提供方只提供vip和域名信息，调用方通过域名方式调用，所有请求和流量都走F5设备。

遇到的问题：

• 负载不均衡：对于长连接场景，F5不能提供较好的负载均衡能力。如服务提供方发布的场景，最后一批发布的机器，基本上不能被分配到流量。需要在发布完成后，PE手工去断开所有连接，重新触发连接级别的负载均衡。
• 流量瓶颈：所有的请求都走F5设备，共享资源，流量很容易会打满网卡，会造成应用之间的相互影响。
• 单点故障：F5设备故障之后，所有远程调用会被终止，导致大面积瘫痪。

2008年，ConfigServer单机版V1.0​

单机版定义和实现了服务发现的关键的模型设计（包括服务发布，服务订阅，健康检查，数据变更主动推送，这个模型至今仍然适用），应用通过内嵌SDK的方式接入实现服务的发布和订阅；这个版本很重要的一个设计决策就是服务数据变更到底是pull还是push的模式，我们从最初就确定必须采用push的模式来保证数据变更时的推送实时性（Eureka1.x的架构采用的是pull的模式）

当时，HSF和Notify就是采用单机版的ConfigServer来完成服务的发现和topic的发现。单机版的ConfigServer和HSF、Notify配合，采用服务发现的技术，让请求通过端到端的方式流动，避免产生流量瓶颈和单点故障。ConfigServer可以动态的将服务地址推送到客户端，服务调用者可以知道所有提供此服务的机器，每个请求都可以通过随机或者轮询的方式选择服务端，做到请求级别的负载均衡。这个版本已经能很好的解决F5设备不能解决的三个问题。

但是单机版本的问题也非常明显，不具备良好的容灾性；

2009年初，ConfigServer单机版V1.5​

单机版的ConfigServer所面临的问题就是当ConfigServer在发布/升级的时候，如果应用刚好也在发布，这个时候会导致订阅客户端拿不到服务地址的数据，影响服务的调用；所以当时我们在SDK中加入了本地的磁盘缓存的功能，应用在拿到服务端推送的数据的时候，会先写入本地磁盘，然后再更新内存数据；当应用重启的时候，优先从本地磁盘获取服务数据；通过这样的方式解耦了ConfigServer和应用发布的互相依赖；这个方式沿用至今。（我很惊讶，Eureka1.x的版本至今仍然没有实现客户端磁盘缓存的功能，难道Eureka集群可以保持100%的SLA吗？）

2009年7月，ConfigServer集群版本V2.0​

ConfigServer的集群版本跟普通的应用有一些区别：普通的应用通过服务拆分后，已经属于无状态型，本身已经具备良好的可扩展性，单机变集群只是代码多部署几台；ConfigServer是有状态的，内存中的服务信息就是数据状态，如果要支持集群部署，这些数据要不做分片，要不做全量同步；由于分片的方案并没有真正解决数据高可用的问题（分片方案还需要考虑对应的failover方案），同时复杂度较高；所以当时我们选择了单机存储全量服务数据全量的方案。为了简化数据同步的逻辑，服务端使用客户端模式同步：服务端收到客户端请求后，通过客户端的方式将此请求转发给集群中的其他的ConfigServer，做到同步的效果，每一台ConfigServer都有全量的服务数据。

这个架构同Eureka1.x的架构惊人的相似，所以很明显的Eureka1.x存在的问题我们也存在；当时的缓解的办法是我们的ConfigServer集群全部采用高配物理来部署。

2010年底，ConfigServer集群版V2.5​

基于客户端模式在集群间同步服务数据的方案渐渐无以为继了，特别是每次应用在发布的时候产生了大量的服务发布和数据推送，服务器的网卡经常被打满，同时cmsgc也非常频繁；我们对数据同步的方案进行了升级，去除了基于客户端的同步模式，采用了批量的基于长连接级别的数据同步+周期性的renew的方案来保证数据的一致性（这个同步方案当时还申请了国家专利）；这个版本还对cpu和内存做了重点优化，包括同步任务的合并，推送任务的合并，推送数据的压缩，优化数据结构等；

这个版本是ConfigServer历史上一个比较稳定的里程碑版本。

但是随着2009年天猫独创的双十一大促活动横空出世，服务数量剧增，应用发布时候ConfigServer集群又开始了大面积的抖动，还是体现在内存和网卡的吃紧，甚至渐渐到了fullgc的边缘；为了提高数据推送能力，需要对集群进行扩容，但是扩容的同时又会导致每台服务器的写能力下降，我们的架构到了“按下葫芦浮起瓢”的瓶颈。

2012年底，ConfigServer集群版V3.0​

在2011年双十一之前我们完成了V3架构的落地，类似Eureka2.0所设计的读写分离的方案，我们把ConfigServer集群拆分成session和data两个集群，客户端分片的把服务数据注册到session集群中，session集群会把数据异步的写到data集群，data集群完成服务数据的聚合后，把压缩好的服务数据推送到session层缓存下来，客户端可以直接从session层订阅到所需要的服务数据；这个分层架构中，session是分片存储部分的服务数据的（我们设计了failover方案），data存储的是全量服务数据（天生具备failover能力）；

data集群相对比较稳定，不需要经常扩容；session集群可以根据数据推送的需求很方便的扩容（这个思路和Eureka2.0所描述的思路是一致的）；session的扩容不会给data集群带来压力的增加。session集群我们采用低配的虚拟机即可满足需求，data由于存储是全量的数据我们仍然采用了相对高配的物理机（但是同V2.5相比，对物理机的性能要求已经答复下降）

这个版本也是ConfigServer历史上一个划时代的稳定的大版本。

2014年，ConfigServer集群版V3.5​

2013年，阿里巴巴开始落地了异地多活方案，从一个IDC渐渐往多个IDC跨越，随之而来的对流量的精细化管控要求越来越高（比如服务的同机房调用，服务流量的调拨以支持灰度能力等），基于这个背景ConfigServer引入了服务元数据的概念，支持对服务和IP进行元数据的打标来满足各种各样的服务分组诉求。

2017年，ConfigServer集群版V4.0​

V3版本可见的一个架构的问题就是data集群是存储全量的服务数据的，这个随着服务数的与日俱增一定会走到升级物理机配置也无法解决问题的情况（我们当时已经在生产使用了G1的垃圾回收算法），所以我们继续对架构进行升级，基于V3的架构进行升级其实并不复杂；session层的设计保持不变，我们把data进行分片，每一个分片同样按照集群的方式部署以支持failover的能力；

Nacos

作为同属于AP类型的注册中心，Eureka和ConfigServer发展过程中所面临的诸多问题有很大的相似性，但是阿里巴巴这些年业务的跨越式发展，每年翻番的服务规模，不断的给ConfigServer的技术架构演进带来更高的要求和挑战，我们有更多的机会在生产环境发现和解决一个个问题的过程中，做架构的一代代升级。我们正在计划通过开源的手段把我们这些年在生产环境上的实践经验通过Nacos(链接)产品贡献给社区，一方面能够助力和满足同行们在微服务落地过程当中对工业级注册中心的诉求，另一方面也希望通过开源社区及开源生态的协同发展给ConfigServer带来更多的可能性。

炎炎夏日，在Eureka 2.0 (Discontinued) 即将结束的时候，在同样的云原生时代，Nacos却正在迎来新生，技术演进和变迁的趣味莫过于此。

Nacos将努力继承Eureka未竟的遗志，扛着AP系注册中心的旗帜继续前行，不同的是Nacos更关注DNS-based Service Discovery以及与Kubernetes体系的融会贯通。

我们看不透未来，却仍将与同行们一起上下求索，砥砺前行。

最后附上Nacos的架构图。