注册中心cp和ap 注册中心是干嘛的

一、服务注册中心

1. 什么是服务注册中心

服务注册中心是服务实现服务化管理的核心组件，类似于目录服务的作用，主要用来存储服务信息，譬如提供者 url 串、路由信息等。服务注册中心是微服务架构中最基础的设施之一。注册中心可以说是微服务架构中的“通讯录”，它记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用。

简单理解就是：在没有注册中心时候，服务间调用需要知道被当服务调方的具体地址（写死的 ip:port）。更换部署地址，就不得不修改调用当中指定的地址。而有了注册中心之后，每个服务在调用别人的时候只需要知道服务名称（软编码）就好，地址都会通过注册中心根据服务名称获取到具体的服务地址进行调用。

举个现实生活中的例子，比如说，我们手机中的通讯录的两个使用场景：

1. 当我想给张三打电话时，那我需要在通讯录中按照名字找到张三，然后就可以找到他的手机号拨打电话。—— 服务发现
2. 李四办了手机号并把手机号告诉了我，我把李四的号码存进通讯录，后续，我就可以从通讯录找到他。—— 服务注册 通讯录

总结：服务注册中心的作用就是「服务的注册」和「服务的发现」。

2. 为什么需要注册中心
   了解了什么是注册中心，那么我们继续谈谈，为什么需要注册中心。在分布式系统中，我们不仅仅是需要在注册中心找到服务和服务地址的映射关系这么简单，我们还需要考虑更多更复杂的问题：

1. 服务注册后，如何被及时发现
2. 服务宕机后，如何及时下线
3. 服务如何有效的水平扩展 服务发现时，如何进行路由
4. 服务异常时，如何进行降级
5. 注册中心如何实现自身的高可用

这些问题的解决都依赖于注册中心。简单看，注册中心的功能有点类似于 DNS 服务器或者负载均衡器，而实际上，注册中心作为微服务的基础组件，可能要更加复杂，也需要更多的灵活性和时效性。所以我们还需要学习更多 Spring Cloud 微服务组件协同完成应用开发。

注册中心解决了以下问题：

1. 服务管理
2. 服务之间的自动发现
3. 服务的依赖关系管理

3. 常见的注册中心

1. Netflix Eureka
2. Alibaba Nacos
3. HashiCorp Consul
4. Apache ZooKeeper
5. CoreOS Etcd
6. CNCF CoreDNS

主要的注册中心的异同：

二、服务配置中心

配置中心：顾名思义，就是用来统一管理项目中所有配置的系统。虽然听起来很简单，但也不要小瞧了这个模块。如果一个中型互联网项目，不采用配置中心的模式，一大堆的各类配置项，各种不定时的修改需求，一定会让开发同学非常头疼且管理十分混乱。我认为甚至可以直接用 “一个项目中是否有无采用「配置中心」” 这一粗略的条件，来判断一个互联网研发团队是否规范和成熟。

1. 为什么需要「配置中心」

我们先来看看在没有「配置中心」的传统项目中，我们是怎么处理各类配置参数问题的：

1. 一般是静态化配置。大多数在项目中单独写一个配置文件，例如 “config.conf”，然后将各类参数配置、应用配置、环境配置、安全配置、业务配置 都写到这个文件里。当项目代码逻辑中需要使用配置的时候，就从这个配置文件中读取。这种做法虽然简单，但如果参数需要修改，就非常的不灵活，甚至需要重启运行中的项目才能生效。相信大多数开发同学都深有体会。
2. 配置文件无法区分环境。由于配置文件是放在项目中的，但是我们项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置参数理论上都是不同的，所以我们在配置文件中根据不同环境配置不同的参数，这些都是手动维护，在项目发布的时候，极其容易因开发人员的失误导致出错。
3. 配置文件过于分散。如果一个项目中存在多个逻辑模块独立部署，每个模块所使用的配置内容又不相同，传统的做法是会在每一个模块中都放一个配置文件，甚至不同模块的配置文件格式还不一样。那么长期的结果就是配置文件过于分散混乱，难以管理。
4. 配置修改无法追溯。因为采用的静态配置文件方式，所以当配置进行修改之后，不容易形成记录，更无法追溯是谁修改的、修改时间是什么、修改前是什么内容。既然无法追溯，那么当配置出错时，更没办法回滚配置了。

上面只是拿配置文件的形式来举例，有的项目会采用数据库配置，虽然灵活一点，但是依旧不能完全解决上述问题。既然传统的项目配置有这么多弊端，那我们看看「配置中心」的方案是如何解决这些痛点的：
「配置中心」的思路就是把项目中各种配置、各种参数、各种开关，全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。当各个服务需要获取配置的时候，就来「配置中心」的接口拉取。当「配置中心」中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

那么，按照上述思路，我们理想中的「配置中心」应该具备如下特点：

1. 配置集中管理、统一标准
2. 配置与应用分离
3. 实时更新
4. 高可用

具有上述特性的「配置中心」是如何解决上面传统配置所面临的问题的呢？分别对应以下的解决方法。

1. 采用“配置集中管理”，可以很好的解决传统的“配置文件过于分散”的问题。所有的配置都集中在配置中心这一个地方管理，不需要每一个项目都自带一个，这样极大的减轻了开发成本。
2. 采用“配置与应用分离”，可以很好的解决传统的“配置文件无法区分环境”的问题，配置并不跟着环境走，当不同环境有不同需求的时候，就到配置中心获取即可，极大的减轻了运维部署成本。
3. 具备“实时更新”的功能，就是用来解决传统的“静态化配置”的问题。线上系统需要调整参数的时候，只需要在配置中心动态修改即可。
4. 既然配置都统一管理了，那配置中心在整个系统中的地位就非常重要了，一旦配置中心不能正常提供服务，就可能会导致项目整体故障，因此“高可用”就是配置中心又一个很关键的指标了。

2. 「配置中心」的原理与应用？

通过上面的介绍，其实就可以了解到「 配置中心 」的原理不是很复杂。其核心功能也不多，主要是：

1. 实现配置的记录
2. 实现配置的读取、更新、取消
3. 实现配置的查看

但是围绕着这几个核心功能，我们还需要保障高可行、要实现实时更新、要能方便的使用，还希望有权限管理的功能、操作审计的功能等等，加上这些周边辅助功能之后，一个完善的「 配置中心 也就不那么简单了。

我们再来看一下在实际项目中如何去选型和应用：

虽然配置中心的核心原理并不复杂，我们可以根据原理自己去实现一个配置中心，但是如果没有特殊需求，还是不建议重复造轮子了，毕竟业内已经有很多成熟的开源方案可以直接选用了。下面就列举几个比较热门的配置中心开源组件给大家参考：

• Apollo

Apollo是由携程开源的分布式配置中心。

Apollo的特点有很多，比如：配置更新之后可以实时生效，还可以支持灰度发布功能。并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。另外由于Apollo使用的人很多，所以网上的资料也非常的丰富，并且github上资料也写的很详细。

上面即是Apollo的基础模型，看结构很简单。但是其功能很多，之前说过配置中心对高可用的要求很高。下面可以继续看一下Apollo的架构：

更多的Apollo资料可以直接去github上查看。

• Spring Cloud Config

看名字就知道，这是Spring Cloud中带的配置中心组件。也正是这个原因，所以它和Spring是无缝集成，使用起来非常方便。并且它的配置存储支持Git，不过它没有可视化的操作界面，配置的生效也不是实时的，需要重启或去刷新。所以比较适用于小型项目快速上手。

Spring Cloud Config包含了Config Client和Config Server两部分，Config Server 实现配置文件的存储，对外以接口的形式提供获取配置文件，然后Config Client通过这些接口获取数据。

• Disconf

Disconf是由百度开源的分布式配置中心。其实很多一线大厂都有开源自己的配置中心组件，这里挑出百度的Disconf也是因为网上比较火热，易用性也还不错，项目也是托管在github上很容易找到。它是基于Zookeeper来实现配置变更后实时通知和生效的。

• nacos

nacos是allibaba开源的，重写文章介绍，因为nacos集成了服务注册，服务配置，和消息总线一系列功能 。

三、SpringCloud Bus消息总线（多个服务的配置文件一次性推送更新）

我们知道：如果需要客户端获取到最新的配置信息需要执行refresh，当客户端越来越多的时候，需要每个客户端都执行一遍，这种方案就不太适合了。那么使用Spring Cloud Bus可以完美解决这一问题

1. 什么是Bus 消息总线

Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改或者服务之间的通讯，也可以用于监控。Spring cloud bus被国内很多都翻译为消息总线。可以将它理解为管理和传播所有分布式项目中的消息既可，其实本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka和RabbitMQ 一张图来描述bus在配置中心使用的机制

这时Spring Cloud Bus做配置更新步骤如下:

1. 提交代码触发post请求给bus/refresh
2. server端接收到请求并发送给
3. Spring Cloud Bus Spring Cloud bus接到消息并通知给其它客户端
4. 其它客户端接收到通知，请求Server端获取最新配置
5. 全部客户端均获取到最新的配置

总结就是：消息总线就是为了解决多服务时，配置文件有更新时，需要一个个服务refresh窘况，使用消息中间件RabbitMQ，Kafka等直接进行推送就好，无须一个个refresh。