关于微服务引入注册中心的目的
什么是注册中心
服务提供者
启动的时候向注册中心上报自己的网络信息；
服务消费者
启动的时候向注册中心上报自己的网络信息，拉取provider的相关网络信息 ；
注册中心
在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用；服务管理,核心是有个服务注册表，心跳机制动态维护；如下图：
参考：[https://microservices.io/patterns/service-registry.html]
[https://microservices.io/patterns/client-side-discovery.html]
[https://www.redhat.com/zh/topics/integration/what-is-a-service-registry]
[https://www.baeldung.com/cs/service-discovery-microservices]
引入注册中心的目的
下面以Dubbo官网的图来作以下说明；[https://dubbo.apache.org/zh/docs/v2.7/user/preface/background/]
在分布式架构下，当服务越来越多，规模越来越大时，对应的机器数量也越来越大，单靠人工来管理和维护服务及地址的配置信息会越来越困难， 单点故障的问题也开始凸显出来，服务消费方与，一旦服务路由或者负载均衡服务器宕机，依赖提供方它的所有服务均将失效 ；因此，RPC框架需要的不仅是服务与服务地址的映射关系，需要考虑如下问题：
- 服务注册/下线后，服务如何被被发现；
- 服务异常时，服务如何进行降级；
- 服务发现时，服务如何进行路由；
- 当有多台提供方的服务，消费方如何进行负载均衡消费；
此时，需要一个能够动态注册和获取服务信息的地方来统一管理服务名称和其对应的服务器列表信息（服务配置中心），注册中心，也可以叫分布式协调器；
服务提供方在启动时，将其提供的服务名称、服务器地址注册到服务配置中心，服务消费方通过服务配置中心来获得需要调用的服务的机器列表，这样的处理可以使得服务消费方和服务提供方不需要互相通信协调/人工来进行服务与服务地址的映射，消费方服务和提供方服务之间得到了解耦；
当服务提供方有多台，服务消费方如何调用？
服务消费方从注册中心获取服务提供方列表，之后按照负载均衡算法，选择一台发起请求；
当服务器宕机或者下线时，相应的机器需要能够动态地从服务配置中心里面移除，并通知相应的服务消费方，否则服务消费方就有可能因为调用到已经失效服务而发生错误，在这个过程中，服务消费方只有在第一次调用服务时需要查询服务配置中心， 然后将查询到的信息缓存到本地，后面的调用直接使用本地缓存的服务地址列表信息，而不需要重新发起请求到服务配置中心去获取相应的服务地址列表，直到服务的地址列表有变更（机器上线或者下线）；这种无中心化的结构解决了之前负载均衡设备所导致的单点故障问题，并且大大减轻了服务配置中心的压力 ；
微服务应用和机器越来越多，调用方需要知道接口的网络地址，如果靠配置文件的方式去控制网络地址，对于动态新增机器，维护带来很大问题 ；
注册中心应具备的功能
- 服务注册与发现；服务在启动时，将自己的信息注册到注册中心的过程为服务注册；查询可用的微服务列表及网络地址的机制为服务发现；
- 服务健康检查；注册中心使用一定的机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册列表移除该实例；
- 提供查询和管理服务注册列表的对外接口；用来记录各个微服务的信息为服务注册列表，列表中包含如服务的名称、IP、端口等；提供查询和管理服务注册列表的对外接口，查询用于查询可用的微服务实例，管理用于服务的注册与注销；
服务间通信状态
每个微服务可以是无状态的或有状态的；使用微服务的系统通常具有使用无状态和/或有状态服务的无状态 Web 和/或移动应用程序；
无状态微服务不会跨调用维护服务内的任何状态，它们接受一个请求，处理它，并在不保留任何状态信息的情况下发回响应；有状态微服务以某种形式保留状态以使其正常运行；
微服务不应在内部存储此状态，而应在某种类型的数据存储中将状态信息存储在外部，持久化状态的数据存储包括关系型数据库、NoSQL 数据库等；
[https://blog.swim.ai/stateful-vs.-stateless-microservices-whats-the-difference]
为什么需要无状态化？
服务间通信无状态是冗余部署的多个服务进程，也就是部署多个相同服务进程，请求到任一服务的处理结果是一样的；这些服务进程不存储业务的上下文信息（比如Session），只会根据每次请求携带的数据进行相应的业务处理；与业务相关的信息可以放在外部统一的缓存中；
一般说来，微服务架构的目的之一，是通过多进程承载高并发，根据并发的压力用多个副本共同承担流量；阻碍单体架构变为分布式架构的关键点就在于状态的处理——如果状态全部保存在本地，无论在内存还是硬盘，都会给架构的横向扩展带来瓶颈，因为这样新启动的进程根本无法处理那些保存在原来进程的用户的数据；
