什么是配置中心?有哪些常见的配置中心?

配置中心是一个用于配置集中化管理目支持动态更新、分发配置文件的工具(服务)。

它实现了配置的统一管理和动态同新，当配置信息发生变化时，配置中心可以自动通知服务实例进行配置更新，这样就可以实例无需重启即可应用最新的配置，从一定程度上减少了系统访问的空窗期，非常灵活方便

常见的配置中心：

• Spring Cloud Config：Spring 提供的分布式配置管理工具，支持从 Git、SVN 等版本控制系统加载配置
• Apollo：由携程开源的配置管理中心，支持配置的实时推送和权限管理。
• Nacos：阿里巴巴的配置管理和服务发现工具，既支持配置中心功能，又能作为注册中心使用。
• Consul：HashiCorp 提供的分布式系统管理工具，既可以用作服务发现，也可以用于存储和分发配置
• Etcd：分布式键值存储工具，常用于 Kubernetes 集群中的配置管理。
• Zookeeper：Zookeeper 是一个开源的分布式协调服务，和 Nacos 一样，其既可以作为注册中心，又可以作为配置中心。

为什么微服务需要配置中心？

微服务架构中的每个服务通常都需要一些配置信息，例如数据库连接地址、服务端口、日志级别等。这些配置可能因为不同环境、不同部署实例或者动态运行时需要进行调整和管理。

微服务的实例一般非常多，如果每个实例都需要一个个地去做这些配置，那么运维成本将会非常大，这时候就需要一个集中化的配置中心，去管理这些配置。

SpringCloud可以选择哪些配置中心？

和注册中心一样，SpringCloud也支持对多种配置中心的集成。常见的配置中心选型包括：

• Spring Cloud Config：官方推荐的配置中心，支持将配置文件存储在Git、SVN等版本控制系统中，并提供RESTful API进行访问和管理。
• ZooKeeper：一个开源的分布式协调服务，可以用作配置中心。它具有高可用性、一致性和通知机制等特性。
• Consul：另一个开源的分布式服务发现和配置管理工具，也可用作配置中心。支持多种配置文件格式，提供健康检查、故障转移和动态变更等功能。
• Etcd：一个分布式键值存储系统，可用作配置中心。它使用基于Raft算法的一致性机制，提供分布式数据一致性保证。
• Apollo：携程开源的配置中心，支持多种语言和框架。提供细粒度的配置权限管理、配置变更通知和灰度发布等高级特性，还有可视化的配置管理界面。
• Nacos：阿里巴巴开源的服务发现、配置管理和服务管理平台，也可以作为配置中心使用。支持服务注册与发现、动态配置管理、服务健康监测和动态DNS服务等功能。

Nacos配置中心的原理了解吗？

配置中心，说白了就是一句话：配置信息的CRUD。

具体的实现大概可以分成这么几个部分：

1. 配置信息存储：Nacos默认使用内嵌数据库Derby来存储配置信息，还可以采用MySQL等关系型数据库。
2. 注册配置信息：服务启动时，Nacos Client会向Nacos Server注册自己的配置信息，这个注册过程就是把配置信息写入存储，并生成版本号。
3. 获取配置信息：服务运行期间，Nacos Client通过API从Nacos Server获取配置信息。Server根据键查找对应的配置信息，并返回给Client。
4. 监听配置变化：Nacos Client可以通过注册监听器的方式，实现对配置信息的监听。当配置信息发生变化时，Nacos Server会通知已注册的监听器，并触发相应的回调方法。

Nacos配置中心长轮询机制？

一般来说客户端和服务端的交互分为两种：推（Push）和拉（Pull），Nacos在Pull的基础上，采用了长轮询来进行配置的动态刷新。 详情可以看这篇文章Nacos交互模型

在长轮询模式下，客户端定时向服务端发起请求，检查配置信息是否发生变更。如果没有变更，服务端会"hold"住这个请求，即暂时不返回结果，直到配置发生变化或达到一定的超时时间。

具体的实现过程如下：

如果客户端发起 Pull 请求，服务端收到请求之后，先检查配置是否发生了变更：

• 变更：返回变更配置；
• 无变更：设置一个定时任务，延期 29.5s 执行，把当前的客户端长轮询连接加入 allSubs 队列；

在这 29.5s 内的配置变化：

• 配置无变化：等待 29.5s 后触发自动检查机制，返回配置；
• 配置变化：在 29.5s 内任意一个时刻配置变化，会触发一个事件机制，监听到该事件的任务会遍历 allSubs 队列，找到发生变更的配置项对应的 ClientLongPolling 任务，将变更的数据通过该任务中的连接进行返回。相当于完成了一次 PUSH 操作；

长轮询机制结合了 Pull 机制和 Push 机制的优点； 通过长轮询的方式，Nacos客户端能够实时感知配置的变化，并及时获取最新的配置信息。同时，这种方式也降低了服务端的压力，避免了大量的长连接占用内存资源。

Nacos的服务注册表结构是怎样的？

Nacos采用了数据的分级存储模型，最外层是Namespace，用来隔离环境。然后是Group，用来对服务分组。接下来就是服务（Service）了，一个服务包含多个实例，但是可能处于不同机房，因此Service下有多个集群（Cluster），Cluster下是不同的实例（Instance）。

对应到Java代码中，Nacos采用了一个多层的Map来表示。结构为Map<String, Map<String, Service>>，其中最外层Map的key就是namespaceId，值是一个Map。内层Map的key是group拼接serviceName，值是Service对象。Service对象内部又是一个Map，key是集群名称，值是Cluster对象。而Cluster对象内部维护了Instance的集合。

Nacos中的Namespace是什么？如何使用它来组织和管理微服务

Nacos中的Namespace是用于隔离不同环境或应用之间的配置和服务信息的概念。通过使用Namespace，可以将不同的环境（例如开发、测试和生产）或不同的应用程序（例如Web应用和移动应用）的配置和服务信息分离开来，以避免冲突和错误。

在Nacos中，每个Namespace都有自己独立的配置和服务注册表。这意味着，如果有多个应用程序需要使用Nacos，可以将它们分别放置在不同的Namespace中。每个Namespace都有自己的命名空间ID，用于标识该Namespace。要使用Namespace，在Nacos客户端初始化时，需要指定要使用的Namespace ID。

通过使用Namespace，可以对不同Namespace下的服务进行分组和管理，例如可以使用Nacos提供的Group功能对同一Namespace下的服务进行分组，方便管理和查找。同时，使用Namespace还可以对不同环境下的配置进行隔离，避免不同环境之间的配置冲突。

SpringCloud Config 是什么?

SpringCloud Config 为分布式系统外部化配置提供了服务端以及客户端的支持，简单来说就是一个配置中心，其主要包括以下两个部分的内容：Config Sever和 Config Cient 。

• ConfigServer是一个可横向扩展，并且集中式配置的服务器，主要用于集中管理服务各种环境下的配置，然后默认使用 Git进行存储配置的内容，因此可以很方便地实现配置的版本控制
• Config Client 是 Config Server 的客户端，主要用于操作存储在 Config Server 中的配置信息。

远程调用

说说微服务之间是如何独立通讯的？

远程过程调用（Remote Procedure Invocation）

也就是我们常说的服务的注册与发现，直接通过远程过程调用来访问别的service。

优点：简单，常见,因为没有中间件代理，系统更简单

缺点：只支持请求/响应的模式，不支持别的，比如通知、请求/异步响应、发布/订阅、发布/异步响应，降低了可用性，因为客户端和服务端在请求过程中必须都是可用的。

消息

使用异步消息来做服务间通信。服务间通过消息管道来交换消息，从而通信。

优点：把客户端和服务端解耦，更松耦合，提高可用性，因为消息中间件缓存了消息，直到消费者可以消费， 支持很多通信机制比如通知、请求/异步响应、发布/订阅、发布/异步响应。

缺点：消息中间件有额外的复杂。

说说 RPC 的实现原理

首先需要有处理网络连接通讯的模块，负责连接建立、管理和消息的传输。其次需要有编 解码的模块，因为网络通讯都是传输的字节码，需要将我们使用的对象序列化和反序列化。剩下的就是客户端和服务器端的部分，服务器端暴露要开放的服务接口，客户调用服 务接口的一个代理实现，这个代理实现负责收集数据、编码并传输给服务器然后等待结果返回。

能说下HTTP和RPC的区别吗？

严格来讲，HTTP和RPC不是一个层面的东西：

• HTTP（Hypertext Transfer Protocol）是一种应用层协议，主要强调的是网络通信；
• RPC（Remote Procedure Call，远程过程调用）是一种用于分布式系统之间通信的协议，强调的是服务之间的远程调用。

一些RPC框架比如gRPC，底层传输协议其实也是用的HTTP2，包括Dubbo3，也兼容了gRPC，使用了HTTP2作为传输层的一层协议。

如果硬要说区别的话，如下：

在微服务体系里，基于HTTP风格的远程调用通常使用框架如Feign来实现，基于RPC的远程调用通常使用框架如Dubbo来实现。

那Feign和Dubbo的区别呢？

这两个才是适合拿来比较的东西：

需要注意的是，Feign和Dubbo并不是互斥的关系。实际上，Dubbo可以使用HTTP协议作为通信方式，而Feign也可以集成RPC协议进行远程调用。选择使用哪种远程调用方式取决于具体的业务需求和技术栈的选择。

负载均衡的意义什么？

在计算中，负载均衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。

负载均衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源 的过载。使用多个组件进行负载均衡可而不是单个组件可能会通过冗余来提高可靠性和可用性。负载均衡可通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

集中式与进程内负载均衡的区别

目前业界主流的负载均衡方案可分成两类：

1. 集中式负载均衡, 即在 consumer 和 provider 之间使用独立的负载均衡设施(可以是硬件，如F5, 也可以是软件，如 Nginx), 由该设施负责把 访问请求 通过某种策略转发至 provider；
2. 进程内负载均衡，将负载均衡逻辑集成到 consumer，consumer 从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的 provider。Ribbon 就属于后者，它只是一个类库，集成于 consumer 进程，consumer 通过它来获取到 provider 的地址。

说说有哪些负载均衡算法？

常见的负载均衡算法包含以下几种：