SpringCloud微服务详解（springcloud alibaba）
文章目录
-
- 一、前言
- 二、架构图
- 三、过程详解
-
- 3-1、服务的调用方
- 3-2、负载均衡（Nginx）
- 3-3、网关
- 3-4、注册中心
- 3-5、服务负载均衡调用
- 3-6、服务提供方
- 3-7、服务熔断、降级、限流、监控
-
- 3-7-1、熔断
- 3-7-2、降级
- 3-7-3、限流
- 3-7-4、监控
- 3-8、统一配置文件
- 3-9、分布式事务
- 四、其它
一、前言
截止目前来说微服务架构算是Java程序员的最后一站了（就我所理解是这样的）。初学者对它会有些恐惧，它的架构图很复杂，也很庞大，但只要你明白了其中的逻辑，代码的编写就不那么难了，就像写代码最难的是不知道写什么，并不是怎么写，这篇文章就是帮助你来理解微服务。
具体的学习可以去B站上面看阳哥的SpingCloud第二季，可能初看会有些迷茫，但是看两遍应该可以了解其中精髓，然后就是自己上手去写了。
技术的更新迭代属实是快，阳哥的SpringCloud第一季是18年录制，第二季是20年录制的。稍微了解一点微服务就知道里面有很多的组件，而第二季基本上替换了第一季的全部组件，不过好在思想不变。
二、架构图
我搜索了很多架构图都写的很好，但是不好理解，因为他们都画的大而全，所以我就按照执行的流程图去画了一个简单的，理解之后再去加上：集群概念就好了。
每一个过程都有多种具体实现，而现在最火的微服务是springcloud alibaba，我把相关匹配的组件都标红了。（当然了每个过程还有其它组件就不一一写出了）
三、过程详解
3-1、服务的调用方
我们写了一个查看当前时间的服务，谁需要使用，谁就通过接口去查询，这个就是服务的调用方，一般我们都是通过浏览器来访问的。
3-2、负载均衡（Nginx）
在微服务中，我们的服务入口是网关。微服务每一个过程都是部署多份的，每个网关提供的服务也是一样的。
如果所有的请求都去访问一个网关，那这个网关也是遭不住的，所以这时候我们可以使用nginx做负载均衡。
Nginx实现负载均衡Linux版本（六种负载策略）
3-3、网关
我们会提供很多服务，用户服务、账单服务、消息服务、订单服务…
每一个服务都会部署N份，每一份都有单独的ip、port，我们不可能让调用者去记录每一个ip、port，这时候就产生了网关的概念。
调用方只需要去请求我们的网关，网关再去调用具体的服务。（网关先去注册中心找到对应的服务信息，然后再通过负载均衡策略去调用）
3-4、注册中心
同上面，我们有很多的服务，每个服务能做什么。这是一个庞大的信息量，网关很难去找到对应的服务，这时候我们就需要一个注册中心。
把所有的服务信息都放到注册中心里面，然后我们的网关直接查询请求所对应的服务信息就好了。
3-5、服务负载均衡调用
每一种服务，比如消息服务，都是会提供多份的，所以我们需要使用某种负载策略去调用。
3-6、服务提供方
具体的服务提供者，比如消息服务、账单服务。
3-7、服务熔断、降级、限流、监控
3-7-1、熔断
当大量请求过来之后，我们服务被击溃了，这时候就需要一种自我保护机制，也就是服务熔断。服务熔断之后我们的请求都会立马返回错误的结果。
hystrix：服务熔断之后会有一个半熔断状态，这时候它会去尝试通过少量的请求看服务是否可用，如果可以，服务恢复，不可以则继续熔断
sentinel：没有半熔断状态，只有熔断和恢复两种
3-7-2、降级
可以理解成提供一个计划B，我们的服务是计划A，B是一个兜底的服务。
本来正常情况下，我们的服务应该返回结果Axxxxx，但是现在我们的服务不可用了，如果直接返回错误十分不友好，所以我们可以返回Bxxxx。
3-7-3、限流
如果请求量过大，服务定然击垮，这样所有的请求过来都会得到错误的结果。这时我们应该进行限流，让一部分请求是可以得到正确的结果，肯定是好过所有的请求都失败。
3-7-4、监控
我们要看到每个服务，在某个时间段请求的情况，比如成功次数、失败次数、超时次数，等等。
我们的微服务很少是调用一个服务就能返回结果的，通常都是一个请求过来，然后服务A > 服务B > 服务C，如果我们想要看到完整的服务调用链路呢？
还有很多其它的监控场景，这时候我们就需要搭建一个服务监控了。
3-8、统一配置文件
我们的微服务会有很多的个服务，每个服务都有自己的配置文件，比如说我们的服务A，部署了18份，现在我们要修改里面的一个配置文件，我们要怎么去做呢？
很显然，我们可以去手动的修改这18个配置文件，但也很显然，这是一个傻叉的做法。
所有我们需要一个统一配置文件的功能，最终实现我们在总配置里面修改一下，然后每一个小的服务都可以收到了。
3-9、分布式事务
我们在还没有学习微服务的时候，相比也遇到了分布式事务的问题。
比如我们的服务A去调用服务B，怎么保证服务A、B的事务呢？
如果A、B必须要是原子性，也不是不可以，但会很复杂。
分布式事务就是来解决这个痛点，我们只要使用简单的注解即可实现分布式事务的一致性。
四、其它
- 微服务嘛，反正就是拆分拆分、再部署多份就好了
- 虽然技术更新迭代的很快，但是思想原理是不变的
- 微服务是一种架构，实现它的技术很多，springcloud alibaba只是其中一种
- 后续我也会先按照单机模式（上面的图）基于cloud alibaba搭建一个
- 也想过搭建一个完整的技术链，但是电脑内存不足，所以后面会拆分成一个个，把每个过程都单独的搭建集群部署
- cloud alibaba 是中国出的，所以每种技术都有中文文档，这点简直不要太爽
- 这篇博客是我对微服务的初步理解，后面在具体的实践中可能存在差异，我也会修改此博客
- 可能有人觉得微服务那么复杂那么难，这写的那么简单，其实如果你真正理解了上面的组件，并且在脑海中模拟调用的链路图，微服务应该是了解了30%+
小伙伴可以关注我的公众号，一个不务正业的程序员，可以和我一起交流技术、生活。
小道仙97
