Spring 微服务实战（第 2 版），2022

《Spring 微服务实战（第 2 版）》一开头就讲，在软件开发领域做出了非凡贡献的架构师都在使用“微服务”。比如作者本人。 作者他说，微服务架构其实是大型单体应用程序不断扩大时在软件开发社区的自然产物。在我们的社会上有央企国企还有大厂类似的集团化都在按照这种大规模在运作着。只不过在业务规模小的场景中，架构技术的选型是单体还是微服务框架可能不会面临这样的问题。经过多年迭代发展，使用 Spring 开发微服务是软件工程师的必备技术。那么，要怎样学习微服务架构技术呢？ 众所周知，光看那些网上零散的微服务框架的介绍，并不能提升实战能力。微服务的理论难懂，教学严重脱离项目实战而不能学以致用。微服务架构体系大，组件多，因此需要通过本书有章法的学习才有效率。

这是本书中使用的服务和技术的架构概述图，有可能很多人学了几个月都不知道 Spring Cloud 框架里面这些内容，所以需要有人总结出来。你会使用 Spring Cloud，就能成为拿高薪 offer 的Java 工程师。

Spring Cloud 由以下核心组件构成：

1. 服务注册与发现
2. 配置中心
3. 服务通信与负载均衡
4. 熔断与限流
5. 服务网关

Spring Cloud 是什么？其实就是远程调用框架。远程调用就是在分布式系统中，某个节点的甲模块调用乙模块，或者乙模块调用甲模块。理解所谓的“调用”就是通过 HTTP 发送的请求。正好本书讲的 Spring 微服务就是 Spring Cloud。而 Dubbo 只有大厂才用，一般的项目用不到。 服务注册与发现：假设O-stock 应用程序中有甲模块、乙模块、丙模块这 3 个模块，甲模块是用户功能，乙模块是订单功能，丙模块是消息功能。也就是说，每个模块的功能是不同的，在项目中是分布式的情况。这种情况就是为了解耦合。如果在之前的项目是使用单体架构，那么整体就会包含了很多个模块。而现在使用分布式的话，甲模块是用户可以在注册时上报自己所在的 IP 地址和端口；丙模块也可以上报自己所在的 IP 地址和端口。结果问题来了：这些数据是怎样保存的呢？在书中讲的 Spring Boot，就跟它一样的原理。这些模块把自己所在的 IP 地址和端口上报到服务注册后，比如甲模块调用乙模块时，会通过乙模块它所在的 IP 地址和端口的列表去随机选一个，就实现了甲模块调用乙模块。 服务通信与负载均衡：假设甲模块要调用乙模块接口，乙模块上报了 2 个 IP 地址和端口，这样乙模块的 IP 地址和端口的那个列表就有 2 个。那么它可能调用乙1节点，也可能调用乙2节点，问题是怎么知道调用了是哪个呢？因此需要进行负载均衡。 熔断与限流：先说熔断功能。假设甲模块要调用乙模块接口时，如果乙模块的服务压力大，下单接口只能同时有 1000 个请求，而甲模块调用乙模块发了 10000 个请求，这乙模块的服务就挂了。所以，就有了熔断这功能。 10000 个请求过来只允许前 1000 个请求，后面的请求返回给甲模块，报系统错误，或者是友好的消息。 分布式限流：限流就是限制流量。与上面熔断的例子是一样的，只不过解决方案是用Redis。先在Redis 中查有没有这个 key。如果没有的话，就把key 加进去，value 值为 1 表示 1 个请求，并将过期时间设置为 1 秒。再来一个人就加 1 , value的值为 2。然后以此类推，value 一直累加，当加到 1000 这个阈值的时候，如果 value 值大于 1000，下单接口就直接返回。 这就是限流。因为设置了过期时间为 1 秒，就是在 1 秒内最多 1000 个请求。所以超过 1000 的那些请求就返回了，不再进行后续的操作。 服务网关：用户通过网关，统一把发送到模块的请求分发到对应的模块。服务网关除了这个核心功能，还有做了一些日志打印和权限校验，以及解码等操作。