【springcloud合集】02：微服务架构理论基础

2021-07-27 05:05:25

基于分布式的微服务架构满足哪些维度？

服务注册与发现

服务调用

服务熔断

负载均衡

服务降级

服务消息队列

配置中心管理

服务网关

服务监控

全链路追踪

自动化构建部署

服务定时任务调度操作

什么是springcloud？

官方：

分布式服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶。

个人理解：

以前的服务器就好像，一个会语数外全能的老师，为学生提供服务，这个老师生病了，那全校停课。现在微服务流行后，学校有了数学教研组，语文教研组，外语教研组，每个教研组有一群老师具体负责某科的教学，缺了谁，学校都照样运转。

而这个变化中，那些改变历史的程序员就是把一个服务器中的众多服务，或好几台服务器中的众多服务，分类出来，解耦合出来，把他们类似的功能交给同一个集群来做，把互相耦合在一起的功能剥离出来，按业务，按功能来把他们作为一个个微服务放在服务器上，而这个服务器就只提供一个服务，或较少的服务。让一个超大的服务逻辑，解耦合为一个个小服务，均匀的分布在各自的服务器中。微服务就微在这。

每个教研组就是一个微服务集群。他们提供同样的服务，而注册中心Eureka就是这个存放这个教研组老师名单的地方，学生们想先访问这个注册中心获取教师名单，然后根据相应的负载方法去访问各自老师。不至于让集群中某一老师累死也不至于让某一老师闲死。

Zuul网关呢，就是学校的门卫，某些学生来学校找谁，它负责指引（路由），并且通过一些非常简单的配置，达到阻拦一些人进入（身份验证），或者控制想学数学的人只能去数学教研组，不能去核能教研组学怎么造原子弹（权限验证）。

Hystrix熔断器呢，可以把它当成学校的志愿者，当一个教研组集体罢课后，学生找不到老师了，这些志愿者及时的告诉来访问的学生，相应的结果，异常信息等，免得大量的学生在学校等待，这些志愿者赶快把这些等待的学生梳理出去，学生一直在学校等待，那其他需要学生的学校，也会等待学生，最后造成大面积的学校瘫痪。这里学生我们看成一个个请求。熔断器就是把某事故的蔓延即使熔断了。

当然这些组件也是微服务需要注册到Eureka注册中心

Spring Cloud 就可以看成是这个学校了。众多上面提到的组件相当于都是这个学校的各职能部门。