大话SpringCloud---服务注册中心是个啥?

软件开发的趋势慢慢偏向分布式开发，随着模块越来越多，它们之间依赖调用关系开始错中复杂。我们就需要一个东西去解决这一问题，今天就来记录一下。

---

问题来了

正如前言所言，现在一个系统内部被打散，不同的功能放入不同的模块里。而一个模块难免会去远程调用别的模块。如果只是几个模块的调用还可以自己捋清，但是往往一个系统开发到后期，会有几十个模块出现，这个时候再自己一个一个去管理调用，那是很耗费精力的事情。

在传统的rpc远程调用框架中，每个服务与服务之间依赖关系比较复杂，管理起来也比较复杂，所以需要使用服务治理，管理服务与服务之间的依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册。

而SpringCloud封装了Netflix公司开发的Eureka模块来实现服务治理的。

什么是服务注册与发现?

这里先举一个例子，我们平时看病去私人诊所看病往往不需要排队，直接走进去找医生看病即可。但是医院规模大了之后，每一个患者都不排队，直接走进去找医生，那不乱套了吗?先不说这样效率低下，医生也很累呀。所有人都往诊室门口站，安保压力也山大。

如果这时有一堵"墙"把他们隔开，怎么讲呢?

有一个门诊，患者来了之后先去那里挂号，然后排队，门诊系统上会显示当前的患者人数信息、医生今天所接诊的人数、医生的就诊情况，比如哪些医生刚刚就诊完，现在是空闲状态等等。可以一目了然的看到医院的情况。

这么一看有内味了，很符合我们程序员经常讲的高内聚低耦合，将患者与医生隔开，中间通过门诊调度再将他们相连。服务注册与发现就是扮演门诊的一个角色。

在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务器的信息，比如服务地址通信地址等以别名的方式注册到注册中心上。另一方（消费者｜服务提供者），以该别名的方式去注册中心上获取到实际的服务通讯地址，然后在实现本地RPC调用。RPC远程调用框架核心设计思想：在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系（服务治理概念)。在任何一个RPC远程框架中，都会有一个注册中心（存放服务地址相关信息）。

这个过程就像是，小明医生今天来上班，上班前先把自己的信息填入到门诊系统中(服务注册)。等于告诉全世界，我开始接诊了！之后有患者来看病，他总要先去挂号吧？挂号时系统发现“嘿，这里小明医生有空闲，那先安排他接诊吧”(服务发现)。于是患者拿到了小明医生的号，上面写着小明所在的诊室信息。患者照着上面的信息来到所在诊室，开始就诊(rpc调用)。

服务注册中心的技术栈

有了这么一个东西，可以很好的解决在分布式系统中出现的模块与模块间的管理问题。而到现在服务注册与发现还只是个"天上飞"的概念，还需要有"落地"的实现。

有人说这简单，不就是一个注册中心嘛，我手写一个出来！其实知道原理后并不困难，但是还要考虑各种问题，比如在分布式系统中注册中心突然故障了怎么办？那不是整个系统都跟着瘫痪了嘛。还有你服务提供者总要有一个集群吧，那你注册中心要怎么解决负载均衡的问题呢？

诸如此类的问题，但是已经有人帮我们解决了。市面上有许多常用的服务注册中心技术。就比如Eureka、Zookeeper、Consul还有Nacos。

其中Eureka在SpringCloud的老项目中用的比较多，为啥是老项目呢？因为它后面停止更新了。比较新的项目用别的技术偏多。关于Zookeeper的之前在另外几篇博客中介绍到了。有兴趣的可以去看一下。也算是一个比较老的技术了。但好像还是挺多公司在使用的

最近也是刚刚开始学习微服务有关的知识，望各位共勉，感谢观看🙏