SpringCloud微服务详解（springcloud alibaba）

一时失言乱红尘 2022-11-17 15:00 306阅读 0赞

### 文章目录 ###

*   *  一、前言
     *  二、架构图
     *  三、过程详解
     *   *  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，我把相关匹配的组件都标红了。（当然了每个过程还有其它组件就不一一写出了）

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RvbXdpbGRib2Fy_size_16_color_FFFFFF_t_70]

## 三、过程详解 ##

### 3-1、服务的调用方 ###

我们写了一个查看当前时间的服务，谁需要使用，谁就通过接口去查询，这个就是服务的调用方，一般我们都是通过浏览器来访问的。

### 3-2、负载均衡（Nginx） ###

在微服务中，我们的服务入口是网关。微服务每一个过程都是部署多份的，每个网关提供的服务也是一样的。

如果所有的请求都去访问一个网关，那这个网关也是遭不住的，所以这时候我们可以使用nginx做负载均衡。

[Nginx实现负载均衡Linux版本（六种负载策略）][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**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RvbXdpbGRib2Fy_size_16_color_FFFFFF_t_70_pic_center]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RvbXdpbGRib2Fy_size_16_color_FFFFFF_t_70]: /images/20221022/2f809e33a0f046f1a613408558c5549d.png
[Nginx_Linux]: https://www.xdx97.com/article/793503147019468800
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1RvbXdpbGRib2Fy_size_16_color_FFFFFF_t_70_pic_center]: /images/20221022/d68695e7937e43c0899c38d1d370cf0b.png