带你轻松过——SpringcloudNetflix微服务第一代

本文链接：https://blog.csdn.net/qq_54354111/article/details/141537669

为什么有了微服务一代之后会有微服务二代？

历史缘故：2014年才有微服务的概念，各方面功能组件很齐全风靡全球，至此出来很久都没有更新，最终阿里自研一套，才作为了微服务二代。（阿里对技术提供的支持贡献巨大）

应用架构的演变：

什么是单体应用？

前端和后端都是用同一个tomcat来运行。

单体应用缺陷：

1.开发和维护成本高

2.运行效率慢

3.不支持高并发访问（一个tomcat它理论上支持最大并发量500，实际也就200-300）解决办法：集群可以解决高并发问题

4.代码冗余度较高

什么是集群？

简单理解就是拷贝。把A项目所有的文件代码，原封不动拷贝一份。

缺陷：因为拷贝的是全部，如果我只用到了其中一个模块呢↓

集群解决了高并发问题，但是依然解决不了（开发维护成本高，代码冗余度高，运行效率慢）。

思考：虽然集群有效提升了并发，但是认真思考一下（如果一个项目里面，仅仅只是支付模块高并发比较大，其它模块基本上没有访问，这个集群方案，其实提升效率没有达到上线↓

解决方案：采用分布式↓

什么是分布式？

简单理解就是把一个项目拆分成多个模块，并且每个模块都单独使用一个服务器来运行。

解决的问题：

1.提升了开发和维护成本

2.降低了代码的冗余度

3.提升了项目的运行效率

案例来解释集群和分布式：

我开了一家饭店（集群思想） 1.买菜---洗菜---炒菜---上菜---洗碗（员工1）

                                                2.买菜---洗菜---炒菜---上菜---洗碗（员工2）

                                                3.买菜---洗菜---炒菜---上菜---洗碗（员工3）

                                                …【这样有些人不适合炒菜或者洗碗等呢】

我开了一家饭店（分布式思想） 1.买菜（员工1）

                                                    2.洗菜（员工2）

                                                    3.炒菜（员工3）

4.上菜（员工4）

5.洗碗（员工5）

…【这样每个人只做擅长自己的事情就可以了】

问题：光有集群思想行不行？不行，因为专业的人做专业的事情，不擅长事情的让他做   效率更慢。

光有分布式思想也不行？比如：员工3（炒菜）忙不过来，就需要再招一个人（炒   菜），这就是集群的思想了。

总结：分布式和集群他们两个不能单独分开，都是两个相辅相成。光有集群思想和分布式思想都是不行的，我们都是应该有分布式+集群思想，如   果洗菜工，洗不过来，我就再招一个人来洗菜，那这个时候，我就相当于对洗菜   进行集群。

SOA是面向服务的架构。也是分布式架构。

简单理解SOA把分布式架构划分为表示层（可以理解之前的控制层）和服务层（可以理解之前的业务层和持久层）。

微服务架构：建立在SOA架构基础上。采用的基于HTTP的restful（它是以url地址定位多个资源，已请求方式定位具体的资源）风格进行通信的。

单体项目用多数据也是可以的，但很麻烦。微服务很顺其自然。

微服务是一种思想，spring cloud基于springboot是具体的落地方案（落地思想有spring cloud 和Dubbo（它前两年用得多，但有段时间没更新就被spring cloud取代了））。

Springcloud常见的几大组件：

1.EurekaServer：注册中心？

比如有服务A、B、C，就服务和服务之间怎么通讯→服务A调用B和C，第一步会把他们全部的IP、端口号注册到EurekaServer注册中心里面，EurekaServer也就有了A、B、C服务的IP和端口号，然后EurekaServer提供了一个功能服务拉取→它可以在注册中心里面拉取A、B、C服务的IP和端口号，至此服务之间就能互相调用了。【注册中心的具体作用：就是把所有的微服务IP和端口号放到注册中心里面，也可以向注册中心拉取其它微服务的IP和端口号】

2.ConfigServer：配置中心？

就一个微服务就会有一个核心配置文件，那这样维护起来麻烦，就需要把所有的配置文件放到配置中心里面，然后又因为它是配置文件，就可以放在nacos里面，最后启动项目的时候，直接配置中心在nacos里面拉取下来。

3.zuul：网关？

思考：不同的服务端口号不一样，A：8081，B：8082,C：8083，对于用户来说需要发送一个请求，那到底访问哪一个呢→难道前端发起请求的时候，还在想我的端口号是8081、8082还是8083呢？不需要，统一发给网关，然后由网关分发给不同的服务。

思考一个问题：网关有没有负载均衡的能力？有

4.Ribbon：它是干什么用的呢？

服务与服务之间，存在一个调用，服务A有可能调用服务B，怎么调呢？需要用一个工具，这个工具是Ribbon。支持负载均衡。

5.Feign：注意，后面不会用Feign，会用openfeign。Feign的底层是基于Ribbon实现的，也是服务与服务之间的调用。支持负载均衡。

6.Hystrix：熔断器？

为什么需要Hystrix呢，比如：我调用服务A再调服务B，服务A可能挂了，会导致服务一直访问不了，它还不是最恐怖的，发一个请求不会立即报错的，会出现一直加载转圈，再提示请求失败，因为有服务挂了。如果有成千上万个请求，就会出现一个请求等5秒，后面排队的请求需要不知等多久，这不是最恐怖的，由于其中一个服务挂了之后，它会导致其它正常的一个服务也会挂，因为比如我的带宽只有固定大小，但是现在源源不断的一个请求，由于你这个请求一直访问不了，就会请求出现大量堵塞，它会把正常的通口堵完，那么后面的请求一直等，你这服务器就全挂了，所以需要熔断器，它的好处：比如我第一次请求，我可以设置，让它最多等两秒，两秒没成功，我就直接失败，返回兜底数据（服务正在维护中，请稍后再试）…，如果前面三个请求，都没有访问通，第四个请求过来就立刻返回兜底数据说（服务正在维护中，请稍后再试）就不需要再等了，直接立刻返回，其它的微服务就正常返回，就不会出现堵塞。那如果这个服务修好了呢？比如等个十秒之后，再发少许请求真正的去访问，如果发现还是访问不通，我就继续熔断，如果能访问通正常请求立刻。

7.BUS：消息总线，叫做广播？

就是发一个公告，所有的微服务都能接收。比如：发一个请求，所有的微服务都能接收到。

8.Sleuth：链路追踪？

比如调用A服务的时候，A服务调B 服务，B服务调用C服务，但是C服务报错了，它报错了会出现一个什么情况？一条链路上的微服务都可能会报错，那怎么判断具体错误是哪一个微服务呢源头不知道啊？它会给弄成一个界面，这个见面会有一个通道标志，A→B（OK） →C（fault）{就知道是这个服务出现了问题}，避免服务太多了之后找不到源头，方便排错。