都202x年了，你还不知道什么是注册中心？

啥是eureka？

eureka是用于服务注册与服务发现的微服务组件，是微服务架构中不可或缺的，也就是我们常说的注册中心。

同类型的工具还有Consul、Nacos等，大名鼎鼎的Zookeeper也能实现注册中心的功能。

假如没有注册中心？

什么是注册中心，以及为什么需要注册中心？

先来看看没有注册中心的情况下，我们的服务之间的通信会出现什么问题。

现在我们有一个A服务，A服务的某些操作需要调用B服务。

此时我们会从A服务发送一个http请求，调用B服务提供的接口，请求的url是http://192.168.1.100:8081/getUsers

在A服务的application.properties的配置文件中，有这样一行配置：service.b.url=192.168.1.100:8081，我们通过配置可以在代码中获取B服务的ip和端口。

刚开始，我们新上线的系统访问量还很小，两台服务器部署完全能够支撑。

但渐渐的，随着产品不断推广，用户渐渐多了起来，两台服务器变得吃力起来，所以不得不扩容两台。

此时我们的服务变成了A1、A2、B1、B2，因为要扩容，所以我们必须修改A服务的配置文件。

新的配置为：service.b.url=192.168.1.100:8081,192.168.1.101:8081

简单修改一下配置文件，很容易就搞定了。

可没想到，过了两天，用户量突然暴增，第二次扩容随之而来，部署的服务数量再次翻倍，变为了：A1、A2、A3、A4、B1、B2、B3、B4。

这时，服务A的配置文件，再次经历了一次修改。

新的配置为：service.b.url=

192.168.1.100:8081,192.168.1.101:8081,

192.168.1.102:8081,192.168.1.103:8081

虽然麻烦了一些，但是我们还是没有太大的感觉，不就是修改一下配置文件嘛，小意思。

然而… …噩梦才刚刚开始。

就在还有五分钟就可以打卡下班的时候，运营的同事突然在群里@攻城狮：“系统xx功能不能使用，请尽快排查原因”。

你心里一惊，赶紧登陆系统查看，发现接口报404异常，你立刻想到，会不会是服务B宕机了。

一通排查后，确定B1宕机了，并且重启失败，为了临时解决问题，最快的办法，就是将服务A的配置文件修改，排除掉不能访问的url。

新的配置为：

service.b.url=192.168.1.101:8081,192.168.1.102:8081,192.168.1.103:8081

修改完配置后，赶紧打包，重新部署A1、A2、A3、A4。

当你重新打包部署完成后，四十分钟已经过去了。偏偏就在这时，你发现B2也宕机了，没办法，只好再次修改服务A的配置文件。

新的配置为：service.b.url=192.168.1.102:8081,192.168.1.103:8081

又是一次打包部署上线，一气呵成，行云流水… …

总算可以舒一口气了，你想，但旁边的女同事只说了一句话，就让你差点把嘴里没咽下去的水给吐了出来。

”服务B的问题修复了，麻烦你把配置文件里的服务B地址给加上呗？“她说着，脸上带着人畜无害的微笑。

虽然是女同事，虽然她对你微微一笑，但是你还是忍不住在心里骂娘，这哪是人干的事儿啊… …

于是你又去修改服务A的配置文件，然后重新打包、部署、上线，一条龙服务，键盘啪啪作响，技术十分娴熟。嗯，没错，能看出来是个很干练的、老练的、熟练的、资深的程序猿了。

看到此处，想必你已经发现问题了，这样的开发方式也太麻烦了叭？

况且上文中还只有两个服务，实际中的项目开发往往更加复杂，莫非… …依靠专人专员来解决这一问题？专门派一个哥们每天什么事都别干，就在那检查每个服务是否工作正常？

emmm… …思考的方向错了，换一个思路，我们就不能让代码自动搞定这个繁琐的步骤？

答案是：能。

注册中心就是为了解决这一的痛点应运而生的：统一管理所有服务的地址，让所有连接上注册中心的服务，都能够自动获取彼此的ip和端口，并且能自动感知到服务注册、服务故障、服务下线。

未完待续… …