配置中心是一个用于配置集中化管理目支持动态更新、分发配置文件的工具(服务)。它实现了配置的统一管理和动态同新当配置信息发生变化时配置中心可以自动通知服务实例进行配置更新这样就可以实例无需重启即可应用最新的配置从一定程度上减少了系统访问的空窗期非常灵活方便常见的配置中心Spring Cloud ConfigSpring 提供的分布式配置管理工具支持从 Git、SVN 等版本控制系统加载配置Apollo由携程开源的配置管理中心支持配置的实时推送和权限管理。Nacos阿里巴巴的配置管理和服务发现工具既支持配置中心功能又能作为注册中心使用。ConsulHashiCorp 提供的分布式系统管理工具既可以用作服务发现也可以用于存储和分发配置Etcd分布式键值存储工具常用于 Kubernetes 集群中的配置管理。ZookeeperZookeeper 是一个开源的分布式协调服务和 Nacos 一样其既可以作为注册中心又可以作为配置中心。为什么微服务需要配置中心微服务架构中的每个服务通常都需要一些配置信息例如数据库连接地址、服务端口、日志级别等。这些配置可能因为不同环境、不同部署实例或者动态运行时需要进行调整和管理。微服务的实例一般非常多如果每个实例都需要一个个地去做这些配置那么运维成本将会非常大这时候就需要一个集中化的配置中心去管理这些配置。SpringCloud可以选择哪些配置中心和注册中心一样SpringCloud也支持对多种配置中心的集成。常见的配置中心选型包括Spring Cloud Config官方推荐的配置中心支持将配置文件存储在Git、SVN等版本控制系统中并提供RESTful API进行访问和管理。ZooKeeper一个开源的分布式协调服务可以用作配置中心。它具有高可用性、一致性和通知机制等特性。Consul另一个开源的分布式服务发现和配置管理工具也可用作配置中心。支持多种配置文件格式提供健康检查、故障转移和动态变更等功能。Etcd一个分布式键值存储系统可用作配置中心。它使用基于Raft算法的一致性机制提供分布式数据一致性保证。Apollo携程开源的配置中心支持多种语言和框架。提供细粒度的配置权限管理、配置变更通知和灰度发布等高级特性还有可视化的配置管理界面。Nacos阿里巴巴开源的服务发现、配置管理和服务管理平台也可以作为配置中心使用。支持服务注册与发现、动态配置管理、服务健康监测和动态DNS服务等功能。Nacos配置中心的原理了解吗配置中心说白了就是一句话配置信息的CRUD。具体的实现大概可以分成这么几个部分配置信息存储Nacos默认使用内嵌数据库Derby来存储配置信息还可以采用MySQL等关系型数据库。注册配置信息服务启动时Nacos Client会向Nacos Server注册自己的配置信息这个注册过程就是把配置信息写入存储并生成版本号。获取配置信息服务运行期间Nacos Client通过API从Nacos Server获取配置信息。Server根据键查找对应的配置信息并返回给Client。监听配置变化Nacos Client可以通过注册监听器的方式实现对配置信息的监听。当配置信息发生变化时Nacos Server会通知已注册的监听器并触发相应的回调方法。Nacos配置中心长轮询机制一般来说客户端和服务端的交互分为两种推Push和拉PullNacos在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下有多个集群ClusterCluster下是不同的实例Instance。对应到Java代码中Nacos采用了一个多层的Map来表示。结构为MapString, MapString, Service其中最外层Map的key就是namespaceId值是一个Map。内层Map的key是group拼接serviceName值是Service对象。Service对象内部又是一个Mapkey是集群名称值是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不是一个层面的东西HTTPHypertext Transfer Protocol是一种应用层协议主要强调的是网络通信RPCRemote Procedure Call远程过程调用是一种用于分布式系统之间通信的协议强调的是服务之间的远程调用。一些RPC框架比如gRPC底层传输协议其实也是用的HTTP2包括Dubbo3也兼容了gRPC使用了HTTP2作为传输层的一层协议。如果硬要说区别的话如下HTTPRPC定义HTTP超文本传输协议是一种用于传输超文本的协议。RPC远程过程调用是一种用于实现分布式系统中不同节点之间通信的协议。通信方式基于请求-响应模型客户端发送请求服务器返回响应。基于方法调用模型客户端调用远程方法并等待结果。传输协议基于TCP协议可使用其他传输层协议如TLS/SSL进行安全加密。可以使用多种传输协议如TCP、UDP等。数据格式基于文本常用的数据格式有JSON、XML等。可以使用各种数据格式如二进制、JSON、Protocol Buffers等。接口定义使用RESTful风格的接口进行定义常用的方法有GET、POST、PUT、DELETE等。使用IDL接口定义语言进行接口定义如Protocol Buffers、Thrift等。跨语言性支持跨语言通信可以使用HTTP作为通信协议实现不同语言之间的通信。支持跨语言通信可以使用IDL生成不同语言的客户端和服务端代码。灵活性更加灵活适用于不同类型的应用场景如Web开发、API调用等。更加高效适用于需要高性能和低延迟的分布式系统。在微服务体系里基于HTTP风格的远程调用通常使用框架如Feign来实现基于RPC的远程调用通常使用框架如Dubbo来实现。那Feign和Dubbo的区别呢这两个才是适合拿来比较的东西FeignDubbo定义Feign是一个声明式的Web服务客户端用于简化HTTP API的调用。Dubbo是一个分布式服务框架用于构建面向服务的微服务架构。通信方式基于HTTP协议使用RESTful风格的接口进行定义和调用。基于RPC协议支持多种序列化协议如gRPC、Hessian等。服务发现通常结合服务注册中心如Eureka、Consul进行服务发现和负载均衡。通过ZooKeeper、Nacos等进行服务注册和发现并提供负载均衡功能。服务治理不直接提供服务治理功能需要结合其他组件或框架进行服务治理。提供服务注册与发现、负载均衡、容错机制、服务降级等服务治理功能。跨语言性支持跨语言通信可以使用HTTP作为通信协议实现不同语言之间的通信。支持跨语言通信通过Dubbo的IDL生成不同语言的客户端和服务端代码。生态系统集成了Spring Cloud生态系统与Spring Boot无缝集成。拥有完整的生态系统包括注册中心、配置中心、监控中心等组件。适用场景适用于构建RESTful风格的微服务架构特别适合基于HTTP的微服务调用。适用于构建面向服务的微服务架构提供更全面的服务治理和容错机制。需要注意的是Feign和Dubbo并不是互斥的关系。实际上Dubbo可以使用HTTP协议作为通信方式而Feign也可以集成RPC协议进行远程调用。选择使用哪种远程调用方式取决于具体的业务需求和技术栈的选择。负载均衡的意义什么在计算中负载均衡可以改善跨计算机计算机集群网络链接中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载均衡旨在优化资源使用最大化吞吐量最小化响应时间并避免任何单一资源 的过载。使用多个组件进行负载均衡可而不是单个组件可能会通过冗余来提高可靠性和可用性。负载均衡可通常涉及专用软件或硬件例如多层交换机或域名系统服务器进程。集中式与进程内负载均衡的区别目前业界主流的负载均衡方案可分成两类集中式负载均衡, 即在 consumer 和 provider 之间使用独立的负载均衡设施(可以是硬件如F5, 也可以是软件如 Nginx), 由该设施负责把 访问请求 通过某种策略转发至 provider进程内负载均衡将负载均衡逻辑集成到 consumerconsumer 从服务注册中心获知有哪些地址可用然后自己再从这些地址中选择出一个合适的 provider。Ribbon 就属于后者它只是一个类库集成于 consumer 进程consumer 通过它来获取到 provider 的地址。说说有哪些负载均衡算法常见的负载均衡算法包含以下几种内置负载均衡规则类规则描述RoundRobinRule简单轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule对以下两种服务器进行忽略1在默认情况下这台服务器如果3次连接失败这台服务器就会被设置为“短路”状态。短路状态将持续30秒如果再次连接失败短路的持续时间就会几何级地增加。2并发数过高的服务器。如果一个服务器的并发连接数过高配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限可以由客户端的clientName.clientConfigNameSpace.ActiveConnectionsLimit属性进行配置。WeightedResponseTimeRule为每一个服务器赋予一个权重值。服务器响应时间越长这个服务器的权重就越小。这个规则会随机选择服务器这个权重值会影响服务器的选择。ZoneAvoidanceRule以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。BestAvailableRule忽略那些短路的服务器并选择并发数较低的服务器。RandomRule随机选择一个可用的服务器。RetryRule重试机制的选择逻辑