啥是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和端口，并且能自动感知到服务注册、服务故障、服务下线。
未完待续… …
