springcloud-注册中心和配置中心

1 注册中心

1.1 为什么要用注册中心

微服务之间会相互调用，如果有两个服务orderService和userService，orderService会调用userService获取当前订单相干的用户信息，且userService部署了多个实例：

大家思索几个问题：

• order-service在发起远程调用的时候，该怎样得知user-service实例的ip地址和端口？如果代码里写死ip地址，一旦发生变化怎么办？
  
• 有多个user-service实例地址，order-service调用时该怎样选择？
  
• order-service怎样得知某个user-service实例是否依然健康，是不是已经宕机？
  

这些都可以通过注册中心来解决
1.2 注册中心的作用

以eureka注册中心为例。

答复之前的各个问题。
问题1：order-service怎样得知user-service实例地址？
获取地址信息的流程如下：

• user-service服务实例启动后，将本身的信息注册到注册中心（Eureka服务端）。这个叫服务注册
  
• eureka-server保存服务名称到服务实例地址列表的映射关系，因此我们调用的时候，不消采用ip+端口的方式，直接通过服务名称调用。
  
• order-service根据服务名称，拉取实例地址列表。这个叫服务发现或服务拉取。
  

问题2：order-service怎样从多个user-service实例中选择具体的实例？

• order-service从实例列表中利用负载均衡算法选中一个实例地址
  
• 向该实例地址发起远程调用
  

问题3：order-service怎样得知某个user-service实例是否依然健康，是不是已经宕机？

• user-service会每隔一段时间（默认30秒）向注册中心发起请求，报告本身状态，称为心跳
  
• 当超过一定时间没有发送心跳时，注册中心会认为微服务实例故障，将该实例从服务列表中剔除
  
• order-service拉取服务时，就能将故障实例扫除了
  

总结：注册中心的作用

• 服务注册：服务提供方将自身路由信息发布到注册中心，供消费方获取，用于与提供方创建连接并发起调用。
  
• 服务发现：服务消费方通过注册中心获取服务提供方节点路由信息。
  
• 确保已注册节点健康度，可以或许及时准确剔除失效节点，保证服务发现正确性
  
• 变更通知：提供方节点发生变更时，注册中心应该可以或许第一时间把变更事件或变更后的数据推送到服务订阅方。
  

1.3 常用注册中心

详细对比介绍：https://zhuanlan.zhihu.com/p/63263168
1.4 负载均衡

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。以此为例进行介绍：

注意，Spring Cloud 2020.0.0后官方抛弃了 Netflix 技能栈（Spring Cloud Netflix 进入维护模式将不会再向模块添加新功能和版本更新。只修复block级别的bug以及安全问题），Spring Cloud Netflix中的Ribbon今后版本也不再支持，官方推荐使用Spring Cloud Loadbalancer，大家使用高级别版本的SpringCloud服务要注意。

从http://userservice/user/1到http://localhost:8081，具体的实现过程是：
SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。

基本流程如下：

• 拦截服务请求方order-service的请求http://userservice/user/1
  
• RibbonLoadBalancerClient会从请求url中获取服务名称，也就是user-service
  
• DynamicServerListLoadBalancer根据user-service到注册中心拉取服务列表
  
• 注册中心返回列表，localhost:8081、localhost:8082
  
• IRule利用内置负载均衡规则，从列表中选择一个，比方localhost:8081
  
• RibbonLoadBalancerClient修改请求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，发起真实请求
  

常用的负载均衡规则：
内置负载均衡规则类规则描述RoundRobinRule简朴轮询服务列表来选择服务器。它是Ribbon默认的负载均衡规则。AvailabilityFilteringRule对以下两种服务器进行忽略：   （1）在默认情况下，这台服务器如果3次连接失败，这台服务器就会被设置为“短路”状态。短路状态将持续30秒，如果再次连接失败，短路的持续时间就会几何级地增加。  （2）并发数过高的服务器。如果一个服务器的并发连接数过高，配置了AvailabilityFilteringRule规则的客户端也会将其忽略。并发连接数的上限，可以由客户端的..ActiveConnectionsLimit属性进行配置。WeightedResponseTimeRule为每一个服务器赋予一个权重值。服务器响应时间越长，这个服务器的权重就越小。这个规则会随机选择服务器，这个权重值会影响服务器的选择。ZoneAvoidanceRule以区域可用的服务器为基础进行服务器的选择。使用Zone对服务器进行分类，这个Zone可以理解为一个机房、一个机架等。而后再对Zone内的多个服务做轮询。BestAvailableRule忽略那些短路的服务器，并选择并发数较低的服务器。RandomRule随机选择一个可用的服务器。RetryRule重试机制的选择逻辑1.5 Nacos介绍

Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。

Nacos也可以做配置中心。

2 配置中心

2.1 为什么使用配置中心

微服务架构下关于配置文件的一些问题：

• 配置文件相对分散。在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置的和管理。
  
• 配置文件无法区分环境。微服务项目可能会有多个环境，比方：测试环境，预发环境，生产环境。每一个环境所使用的配置理论上都是不同的，一旦必要修改，就必要我们去各个微服务下手动维护，这比较困难。
  
• 配置如果在代码里写死，更新维护比较困难。
  
• 配置文件无法及时更新。我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说是非常不友好的
  

2.2 配置中心的作用

配置中心的思路是：

• 配置统一管理：首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。
  
• 配置自动拉取：当各个服务必要获取配置的时候，就来配置中心的接口拉取本身的配置。
  
• 配置动态更新:当配置中心中的各种参数有更新的时候，也能通知到各个服务及时的过来同步最新的信息，使之动态更新。
  

此外，配置中心还有灰度发布、权限管理、版本管理&回滚等特点。
2.3 常用配置中心

Apollo

GitHub：https://github.com/apolloconfig/apollo
官方文档：https://www.apolloconfig.com/#/zh/development/apollo-development-guide

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，具备规范的权限、流程治理等特性。
Spring Cloud Config

GitHub：https://github.com/spring-cloud/spring-cloud-config

2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
Nacos

Nacos官网：https://nacos.io/zh-cn/docs/what-is-nacos.html

2.4 Apollo配置中心

2.4.1 Apollo介绍

Apollo（阿波罗）是一款可靠的分布式配置管理中心，诞生于携程框架研发部，可以或许集中化管理应用不同环境、不同集群的配置，配置修改后可以或许及时推送到应用端，而且具备规范的权限、流程治理等特性，实用于微服务配置管理场景。
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不必要额外安装Tomcat等应用容器。

2.4.2 Apollo特点

• 统一管理不同环境、不同集群的配置
  
  
  
  • Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
    
  • 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等
    
  • 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
    
  • 配置界面支持多语言（中文，English）
    
  
  
• 配置修改及时生效（热发布）
  
  
  
  • 用户在Apollo修改完配置并发布后，客户端能及时（1秒）接收到最新的配置，并通知到应用程序。
    
  
  
• 版本发布管理
  
  
  
  • 所有的配置发布都有版本概念，从而可以方便的支持配置的回滚。
    
  
  
• 灰度发布
  
  
  
  • 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。
    
  
  
• 权限管理、发布审核、操作审计
  
  
  
  • 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
    
  • 所有的操作都有审计日志，可以方便的追踪问题。
    
  
  
• 客户端配置信息监控
  
  
  
  • 可以方便的看到配置在被哪些实例使用
    
  
  

2.4.4 Apollo框架

• 用户在配置中心对配置进行修改并发布
  
• 配置中心通知Apollo客户端有配置更新
  
• Apollo客户端从配置中心拉取最新的配置、更新当地配置并通知到应用
  
  
  
  • 在遇到服务不可用，或网络不通的时候，依然能从当地恢复配置
    
  下图是它的所有模块：
  
  

• ConfigService
  
• 
  
  
  
  • 提供配置获取、配置推送接口
    
  • 服务于Apollo客户端
    
  
  
• AdminService
  
• 
  
  
  
  • 提供配置管理、配置修改发布接口
    
  • 服务于管理界面Portal
    
  
  
• Client
  
• 
  
  
  
  • 为应用获取配置，支持及时更新
    
  • 通过MetaServer获取ConfigService的服务列表
    
  • 使用客户端软负载SLB（比方Ribbon）方式调用ConfigService
    
  
  
• Portal
  
• 
  
  
  
  • 配置管理界面
    
  • 通过MetaServer获取AdminService的服务列表
    
  • 使用客户端软负载SLB方式调用AdminService
    
  
  
• Eureka
  
  
  
  • 用于服务发现和注册
    
  • Config/AdminService注册实例并定期报心跳
    
  
  
• MetaServer
  
  
  
  • Portal通过域名访问MetaServer获取AdminService的地址列表
    
  • Client通过域名访问MetaServer获取ConfigService的地址列表
    
  • 相称于一个Eureka Proxy（Eureka只能部署在java客户端，为了能部署在多语言环境，携程做了一个封装）
    
  
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。