为什么需要服务注册发现？
为什么需要服务注册发现？
回答重点
在分布式系统中，服务的数量通常会有很多，而且规模还不是一般地大，与此同时，服务的部署和变化也会很频繁。因此，如果要依赖人工去维护这些服务的关系，实现服务的管理以及调用就会变得非常困难。
服务注册与发现的作用就是为了解决这个问题，它通过注册中心来维护服务生产者以及服务消费者之间的关系。当服务启动之后，其就会向注册中心注册自己的信息，比如服务名称、服务端口、服务的 IP 地址等，当服务消费者需要调用某个服务的时候，它会向注册中心发起查询请求，获取对应服务的信息，然后向生产者服务发送请求。
如果一些服务上线或者下线，注册中心都可以主动通知消费者，这就动态地实现了服务的上下线，在高峰期加机器，低峰期减机器，减少了管理的成本，十分方便。
也可以方便实现服务的监控、管理等等。
扩展知识
应用架构演进流程
单体多模块模型架构
在传统的数据请求模型中，没有服务注册与发现这样的说法，因为请求的模型足够简单，也就是咱们的单体多模块应用程序，如下图所示：
多服务器单应用模型架构
随着时代的变化，人均手机电脑流量日益增长，渐渐地单体应用撑不下去了。根据负载均衡概念，考虑使用多台服务器来承担流量的压力。
但这个时候还是没有服务注册和发现的需求，因为架构还是简单清晰，不断增加 server 服务还是可以扛住一定的流量。
更新和维护也比较简单，如下图所示：
那么大家都会想，如果一个系统过于庞大不好维护怎么办？这时候微服务时代来了，分布式架构，服务注册与发现可以使用起来了。
微服务时代
在微服务时代，我们所有的服务都被尽量拆分成最小的粒度，原先所有的服务都混在 1 个 server 里，现在就被按照功能或者对象拆分成 N 个服务模块。
这样做的好处是深度解耦，1 个模块只负责自己的事情，能够实现快速的迭代更新。
坏处是服务的管理和控制变得异常复杂和繁琐，人工维护难度变大。如下图所示：
比如上图中，我们将原先 1 个 server 的服务进行了拆分，拆出了用户服务，订单服务，商品服务等等。
每个服务里有 4 台机器来实例化。每个服务还相互关联和调用。这种错综复杂的网络架构，使得这种服务的维护成本比之前困难了很多。
在不使用服务注册之前，我们可以想象一下，怎么去维护这种复杂的关系网络呢？
答案是：写在代码里，能访问就可以。将其他模块的 IP 和端口写死在自己的配置文件里，甚至写死在代码里。每次要去新增或者移除一个服务的实例时，就得通知所有相关联的服务修改。这样频繁更新，还需要考虑机器减少的情况，太难受了。
我苦呀！！！下面就开始引入服务注册了。
服务注册
每个实例服务在启动时都根据自身的名称向服务注册中心写入自己的实例信息如名称、IP、端口。如下图所示：
实例注册到名字服务上之后，接下来就是服务发现了。
服务发现
每个服务的机器实例注册到服务注册中心服务器上之后，接下来，我们如何发现需要调用的服务信息呢？这就是服务发现。
用户服务可以根据订单服务注册的名称从注册中心获取订单服务的详细信息，然后根据负载均衡策略选择一个 IP 调用即可，都不用自己做选择，如下图所示：
