网上各种介绍注册中心的文章，但是都是只告诉你如何去用它，我们按照方法也一直在用！但是却少有人思考，我们为什么要使用注册中心。接下来我们就来探讨下，为什么要使用注册中心，关于这篇文章，我也是在dubbo的官网（https://dubbo.apache.org/zh/docs/v2.7/user/preface/requirements/）找到的答案。下面我们就来聊一聊；
首先我们需要知道互联网架构的一个发展历史：

互联网架构发展历史

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，提升效率的方法之一是将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

注册中心产生原因

以下几个问题是导致，注册中心产生的主要原因：

1、服务越来越多

 分布式架构下，服务越来越多，单靠人工来管理和维护服务及地址的配置信息会越来越困难

2、服务间依赖关系复杂

 服务越来越多，也就意味着服务间的依赖关系越来越复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。

3、服务调用量增大扩容

服务的调用量越来越大，服务容量问题暴露出来，这个服务需要多少机器支撑，什么时候改增加机器？为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。

4、单点故障时

一旦服务路由或者负载均衡服务器宕机，依赖它提供方服务的所有服务均将失效。

以上的弊端导致的注册中心的产生：因此，RPC框架需要的不仅是服务与服务地址的映射关系，也需要考虑如下问题：

（1）服务注册/下线后，服务如何被被发现；
（2）服务异常时，服务如何进行降级；
（3）服务发现时，服务如何进行路由；
（4）当有多台提供方的服务，消费方如何进行负载均衡消费；

此时，需要一个能够动态注册和获取服务信息的地方来统一管理服务名称和其对应的服务器列表信息（服务配置中心），注册中心，也可以叫分布式协调器；
　　服务提供方在启动时，将其提供的服务名称、服务器地址注册到服务配置中心，服务消费方通过服务配置中心来获得需要调用的服务的机器列表，这样的处理可以使得服务消费方和服务提供方不需要互相通信协调/人工来进行服务与服务地址的映射，消费方服务和提供方服务之间得到了解耦；
　当服务器宕机或者下线时，相应的机器需要能够动态地从服务配置中心里面移除，并通知相应的服务消费方，这样服务消费方就可以减少调用失效服务的的错误。服务方在第一次调用服务时，将服务列表缓存在本地，后面调用直接从本地获取，直到配置中心服务列表发生变更，才重新调用服务配置中心，更新本地缓存服务列表。

注册中心列表及对比

目前主流的注册中心有Nacos、Eureka、Consul、Zookeeper、CoreDNS、Zookeeper.(具体简单对比入下图)