初学SpringCloud：探讨一下为什么要使用微服务？，为什么要使用服务注册中心？怎样理解服务注册中心，服务提供者，服务调用者三者之间的关系？

目录

1、本篇博客的背景

2、为什么要使用微服务？

3、为什么要使用服务注册中心

4、怎样理解服务注册中心，服务提供者，服务调用者三者之间的关系？

---

1、本篇博客的背景

我目前正在学习微服务的一些知识，处于刚起步的阶段，已经学习了半个多月了，今天我想停下来，仔细思考总结一下。

（本人码龄尚浅，可能思考的很片面，或者认识不足，敬请各位看官谅解）

2、为什么要使用微服务？

我看网上的前辈们说，在原先的上古时代，当时的需求本来就是很少的，对软件的要求也没有那么的高。那么当时主要就是采用单体应用的开发方法。就包括我们计算机有关专业的学生在学校学习的时候，我们自己写的也都是单体应用，只创建一个项目，然后项目内创建很多的包（文件夹），进行一定的规范分层。由于我们的需求本来就比较的小，数据库的设计也不是很复杂，因此这种作坊式的单体应用的开发方式我们还可以使用，并且觉得使用的理所当然。

转眼间，时间来到了如今。在如今的生活中，每一个软件需要处理的业务范围越来越广，人们的需求也越来越多样化，需求也越来越复杂。因此，为了更加规范的进行软件开发，为了提高软件的健壮性，为了提高软件的开发效率，为了满足高并发的场景，为了不使得一个小模块的崩溃直接带崩我们的整个应用（这有点类似于进程和线程之间的关系），我们引入了微服务的软件设计开发框架。

3、为什么要使用服务注册中心

我们可以简单的理解，微服务就是将原先的单体应用的设计模式进行合理且必要的模块化，并且将数据库也进行一定的分离。（其实这样也是符合 软件设计的  高内聚低耦合   的要求的）。但是 低耦合不代表没有耦合， 各个微服务之间还是有交流的，或者说是有数据交换，有相互调用的。

这里就存在一个问题，当我们的微服务的数量越来越多的时候，他们之间的调用关系也是越来越复杂的。就像是一张渔网一样。这个时候，服务注册中心的概念就被提出来了。我理解的，服务注册中心，起初最简单的设计原因就是规范各个微服务之间的调用。举一个形象一点的例子，就像我们去医院看病一样，病人是服务调用者，医生是服务提供者，随着医院的规模的逐渐变大，不可能让病人直接就跑到医生所在的地方看病，然后医生再去需要的地方取药。所以每个医院都有挂号的地方。医院挂号的地方，就类似于我们这里的服务注册中心。

当然啦，随着技术的更新迭代，随着需求的不断的增多，服务注册中心也集成了，包含了很多的其它的一些功能。比如说，采用轮询实现负载均衡...........等。

4、怎样理解服务注册中心，服务提供者，服务调用者三者之间的关系？

在这里，我以比较经典的Eureka服务注册中心技术作为例子。

打个比方吧：

服务注册中心就类似于我们城市中的写字楼的物业。我们很多学生毕业以后或者大四的时候去的培训机构就像是服务的提供者。这些培训机构需要入驻到这个写字楼，也就是需要入驻到这个物业中去，需要到这个物业公司去注册，然后占据这个写字楼内的一席之地。

然后我们学生呢，当去参加培训的时候，就只需要到这个写字楼的一楼大厅，去查看一下我们需要到的培训机构叫什么名字，在那个楼层，然后就可以去了。

当然啦，写字楼，那些培训机构可以入驻，我们去哪里上课的学生也是可以入驻进去的呀。我们可以自己开一个空壳公司嘛！ 哈哈哈哈，开个玩笑。

以上只是打个比方，方便理解。

无论是服务的调用者，还是服务的提供者，他们的地位是平等的，都可以注册到服务中心上去。或许，在这个关系中，A服务是服务调用者，但是，在另一个关系中，A服务就成为了服务提供者。

从某种意义上来说，服务注册中心也是一个微服务模块，毕竟，在我们的实际编码中，服务注册中心也是需要代码的。那么这样的话，服务注册中心完全可以自己把自己注册到自己的身上（说起来有点拗口了）。

在这里，我给大家贴一张图，方便大家理解（图片不是很清晰）：

多说一下：

这里的Eureka包含两个组件：Eureka Server和Euraka Client。

除了服务注册中心以外的，都是Euraka Client。这个区别，在我们实际的编码中，会通过使用的注解的不一样，application文件的内容不一样而得到体现的。