单机服务到分布式架构的演变，有了它，面试再也不慌了！

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注Java）

正文

• 负载均衡

• 断路器

• 分布式消息传递

这是分布式的优点，这样看起来可能比较抽象，举个例子来说，对于单体服务来说，如果我想更新订单中的某个功能，我是不是需要重启整个服务，这个时候就会导致整个项目都处于不可用状态，或者在处理订单的时候由于程序代码写的有问题，导致死锁了，这个时候也会导致整个服务处于宕机专改，容错率很差，但是分布式不同，如上图所示，订单服务、售后服务、用户服务都是独立的服务，如果需要更新订单服务或者订单服务发生死锁，受影响的只会是订单服务，售后服务与用户服务还是可以正常工作的，这就是分布式相对单体来说最大的优势之一。

技术总监：想不到我们这个团队人才辈出啊，不错不错，看来我都没有讲下去的必要了啊，大家对分布式都相当熟悉了啊，那分布式架构存在缺点或者不足吗？

同事D：

这是我平时刷博客的时候看到的，觉得总结的不错，这张图出自：什么是分布式系统！以及分布式系统架构的优缺点！

分布式基础组件

---

技术总监：既然大家对分布式都这么熟悉了，那我也就不在多说了，我们接下来直接来说说关于分布式组件的选型吧，大家有什么意见都可以提出来，首先谁来说一下分布式组件都有哪些？请开始你们的表演。

同事E：那我就不客气了，由于我们都是对springcloud比较熟悉，现在他也是比较主流，那我介绍一下cloud的基础组件吧。

• Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git以及Subversion。

• Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。

• Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务，以实现云端中间层服务发现和故障转移。

• Hystrix：熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

• Zuul：Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。

• Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。

• Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。

• Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。

• Spring Cloud Sleuth：日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。

• Spring Cloud Data Flow：大数据操作工具，作为Spring XD的替代产品，它是一个混合计算模型，结合了流数据与批量数据的处理方式。

• Spring Cloud Security：基于spring security的安全工具包，为你的应用程序添加安全控制。

• Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务发现和配置管理。

• Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。

• Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

• Ribbon：提供云端负载均衡，有多种负载均衡策略可供选择，可配合服务发现和断路器使用。

• Turbine：Turbine是聚合服务器发送事件流数据的一个工具，用来监控集群下hystrix的metrics情况。

• Feign：Feign是一种声明式、模板化的HTTP客户端。

• Spring Cloud Task：提供云端计划任务管理、任务调度。

• Spring Cloud Connectors：便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。

• Spring Cloud Cluster：提供Leadership选举，如：Zookeeper, Redis, Hazelcast, Consul等常见状态模式的抽象和实现。

• Spring Cloud Starters：Spring Boot式的启动项目，为Spring Cloud提供开箱即用的依赖管理。

我们常用的组件：Spring Cloud Config、Spring Cloud Bus、Hystrix、Zuul、Ribbon、Feign。

技术总监：

不错，组件分析的不错，但是你的讲解比较官方，下面我们来一个一个的讲解一下我们经常使用的这些组件。

Eureka

Eureka属于Spring Cloud Netflix下的组件之一，主要负责服务的注册与发现，何为注册与发现？在刚刚我们分析的分布式中存在这一个问题，那就是订单服务与用户服务被独立了，那么他们怎么进行通信呢？比如在订单服务中获取用户的基础信息，这个时候我们需要怎么办？如果按照上面的架构图，直接去数据库获取就可以了，因为服务虽然独立了，但是数据库还是共享的，所以直接查询数据库就能得到结果，如果我们将数据库也拆分了呢？这个时候我们该怎么办呢？有人想到了，服务调用，服务调用是不是需要ip和端口才可以，那问题来了，对于订单服务来说，我怎么知道用户服务的IP和端口呢？在订单服务中写死吗？如果用户服务的端口发生改变了呢？这个时候Eureka就出来了，他就是为了解决服务的通信问题，每个服务都可以将自己的信息注册到Eureka中，比如ip、端口、服务名等信息，这个时候如果订单服务想要获取用户服务的信息，只需要去Eureka中获取即可，请看下图：

这就是Eureka的主要功能，也是我们使用中的最值得注意的，他让服务之间的通信变得更加的简单灵活。

代码实现：springcloud（一）注册中心eureka

Spring Cloud Config

Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。使用Config Server，您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念映射与Spring Environment和PropertySource抽象相同，因此它们与Spring应用程序非常契合，但可以与任何以任何语言运行的应用程序一起使用。随着应用程序通过从开发人员到测试和生产的部署流程，您可以管理这些环境之间的配置，并确定应用程序具有迁移时需要运行的一切。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。可以轻松添加替代实现，并使用Spring配置将其插入。

简单点来说集中来管理每个服务的配置文件，将配置文件与服务分离，这么多的目的是什么？举个简单的栗子，我们配置文件中肯定会存在数据库的连接信息，redis的连接信息，我们的环境是多样的，有开发环境、测试环境、预发布环境、生产环境，每个环境对应的连接信息肯定是不相同的，难道每次发布的时候都要去修改一下服务中的配置文件？我能不能将这些变动较大的配置集中管理，不同环境的管理者分别对他们进行修改，就不需要再服务中做改动了，Config他就做到了。

这就是config的大致架构，所有的配置文件都集中交给config管理，拿config怎么管理这些配置文件呢？你可以将每个环境的配置文件存放再一个位置，比如Lgitlab、svn、本地等等，config会根据根据你设置的位置读取配置文件进行管理，然后其他服务启动的时候直接到config配置中心获取对应的配置文件即可，这样开发人员只需要关注-dev的配置文件，测试人员只需要关注-test的配置文件，完全和服务解耦，你值得拥有。

代码实现：springcloud（二）配置中心config

Netflix Zuul（网关）

这个时候技术总监突然提了一个问题，他说：既然我们将一个服务拆分成了很多微服务，那岂不是要暴漏很多接口给浏览器？这样会不会造成安全隐患呢？有谁可以来说说这个问题。

同事A：我们可以通过nginx反向代理，开放二级域名，然后将域名映射到微服务中。

技术总监：这个方案也可以，也是不需要使用的，但不是最完善的，还有没有更好的方案？nginx虽然把端口隐藏了，如果我们的服务都是需要一些权限的校验，nginx是无法替我们完成的，这个时候我们难道要在每个服务中都添加一套权限校验的逻辑吗？

同事B：我觉得我们可以使用网关，它既可以做分流转发，也可以做权限控制，使用nginx+网关，我觉得是比较好的一种方案，以下是网关zuul的介绍。

路由在微服务体系结构的一个组成部分。例如，/可以映射到您的Web应用程序，/api/users映射到用户服务，并将/api/shop映射到商店服务。Zuul是Netflix的基于JVM的路由器和服务器端负载均衡器。

Netflix使用Zuul进行以下操作：

• 认证

-洞察

• 压力测试

• 金丝雀测试

• 动态路由

• 服务迁移

• 负载脱落

• 安全

• 静态响应处理

• 主动/主动流量管理

其实我们在日常开发过程中并不会使用那么多，基本上就是认证、动态路由、安全等等，我画了一张关于网关的架构图，请看：

技术总监：你们真的太优秀了，没错，nginx只能为我们做反向代理，不能做到权限认证，网关不但可以做到代理，也能做到权限认证、甚至还能做限流，所以我们要做分布式项目，少了他可不行。

代码实现：springcloud（三）网关zuul

Spring Cloud Bus

application.yml

spring:

datasource:

username: root

password: 123456

url: jdbc:mysql://localhost:3306/test

driver-class-name: com.mysql.cj.jdbc.Driver

技术总监：比如上面这行配置大家都应该很熟悉，这是数据库的连接信息，如果它发生改变了怎么办呢？我们都知道，服务启动的时候会去config配置中心拉取配置信息，但是启动完成之后修改了配置文件我们应该怎么办呢，重启服务器吗？

同事C：我们可以通过spring cloud bus来解决这个问题，Spring Cloud Bus将轻量级消息代理链接到分布式系统的节点。然后可以将其用于广播状态更改（例如，配置更改）或其他管理指令。该项目包括AMQP和Kafka经纪人实施。另外，在类路径上找到的任何Spring Cloud Stream绑定程序都可以作为传输工具使用。

这个需要我们有一点的mq基础，不管是rabbitmq还是kafka，都可以，bus的基本原理就是：配置文件发生改变时，config会发出一个mq，告诉服务，配置文件发生改变了，并且还发出了改变的哪些信息，这个时候服务只需要根据mq的信息做实时修改即可，这是一个很简单的原理，理解起来可能也不会怎么难,画个图来理解一下

大致流程就是这样，核心就是通过mq机制实现不重启服务也能做到配置文件的改动，这方便了运维工程师，不用每次修改配置文件的时候都要去重启一遍服务的烦恼。

代码实现：springcloud（四）消息总线Bus

Feign

技术总监：漂亮，和你们将技术就是省事，刚才我们说到了注册中心可以方便服务于服务之间的通信，但是他们具体是怎么通信的你们有谁知道吗？

同事D：由于我们刚刚讲的分布式架构是springcloud，所以这里推荐使用：Feign

Feign是一个声明式的Web服务客户端。这使得Web服务客户端的写入更加方便 要使用Feign创建一个界面并对其进行注释。它具有可插入注释支持，包括Feign注释和JAX-RS注释。Feign还支持可插拔编码器和解码器。Spring Cloud增加了对Spring MVC注释的支持，并使用Spring Web中默认使用的HttpMessageConverters。Spring Cloud集成Ribbon和Eureka以在使用Feign时提供负载均衡的http客户端。

feign基于rest风格，简单易懂，他的底层是对HttpClient进行了一层封装，使用十分方便。

技术总监：不错，那如果服务的调用出现问题怎么办？比如调用超时，这个时候后我们如何处理？

代码实现：springcloud（五）远程调用Feign(含源码跟踪)

Netflix Hystrix（熔断）

同事E：这个cloud也给我们考虑到了，我们只需要引入熔断即可。

Hystrix支持回退的概念：当电路断开或出现错误时执行的默认代码路径。要为给定的@FeignClient启用回退，请将fallback属性设置为实现回退的类名。

我们可以改造一下刚刚的调用架构

在这里我部署了一台备用服务器，当用户服务宕机了之后，订单服务进行远程调用的时候可以进入备用服务，这样就不会导致系统崩溃。

技术总监：分布式大致架构差不多了，还有一些组件这里也不做做介绍了，使用的时候可以自己了解一下，不是很难，我们接着往下说，我现在这里有一个需求，修改密码，修改密码需要发送短信验证码，发送短信再短信服务中，修改密码再用户服务中，这个时候就会出现服务调用，而且我们知道，发送短信一般都是调用第三方的接口，那比如阿里的，既然牵扯到调用，那么就会存在很多不确定因素，比如网络问题，假如，用户再点击发送短信验证码到时候用户服务调用短信服务，但是在短信服务中执行调用阿里的接口花费了很长的时间，这个时候就会导致用户服务调短信服务超时，会返回给用户失败，但是，短信最后又发出去了，这种问题怎么解决呢？

MQ（消息中间件）

---

同事B：我们可以通过消息中间件来实现，使用异步讲给用户的反馈和发送短信分离，只要用户点了发送短信，直接返回成功，然后再启动发送验证码，60秒重发一下，就算发送失败，用户还可以选择重新发送。

分布式事务

---

技术总监：漂亮，mq不但可以解耦服务，它还可以用来削峰，提高系统的性能，是一个不错的选择，既然我们使用了分布式架构，那么有一点是我们必须要注意的，那就是事务问题，如果一个服务的修改依赖另外一个服务的操作，这个时候如果操作不慎，就会导致可怕的后果，举个例子，两个服务：钱包服务（用于充值提现）、交易钱包服务（用于交易），我现在想从钱包服务中转1000元到交易钱包服务中，我们应该如何保证他们数据的一致性呢？

同事C:我这里有两种方案，第一种是通过MQ来保证一致性，另外一种就是通过分布式事务来确保一致性。

Mq确保一致性

钱包服务：

第一步：生成一个订单表，记录着转入转出的状态。

第二步：向mq发送一条确认消息。

第三步：开启本地事务，执行转出操操作，并且提交事务。

交易钱包服务：

接收mq的消息，进行转入操作（此操作需要ack确认机制的支持）。

系统中会一直定时扫描订单中状态，没有成功的就做补偿机制或者重试机制，这个不是唯一要求。

以上就是mq确保分布式事务的大致思路，不是唯一，仅供参考。

seata（分布式事务）

Seata有3个基本组成部分：

• 事务协调器（TC）：维护全局事务和分支事务的状态，驱动全局提交或回滚。

• 事务管理器TM：定义全局事务的范围：开始全局事务，提交或回滚全局事务。

• 资源管理器（RM）：管理分支事务正在处理的资源，与TC进行对话以注册分支事务并报告分支事务的状态，并驱动分支事务的提交或回滚。

Seata管理的分布式事务的典型生命周期：

• TM要求TC开始一项新的全球交易。TC生成代表全局事务的XID。

• XID通过微服务的调用链传播。

• RM将本地事务注册为XID到TC的相应全局事务的分支。

• TM要求TC提交或回滚XID的相应全局事务。

• TC驱动XID对应的全局事务下的所有分支事务以完成分支提交或回滚。

完整的分布式架构

---

最后

每年转战互联网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。

如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
网行业的人很多，说白了也是冲着高薪去的，不管你是即将步入这个行业还是想转行，学习是必不可少的。作为一个Java开发，学习成了日常生活的一部分，不学习你就会被这个行业淘汰，这也是这个行业残酷的现实。

如果你对Java感兴趣，想要转行改变自己，那就要趁着机遇行动起来。或许，这份限量版的Java零基础宝典能够对你有所帮助。

[外链图片转存中…(img-nTbBXZCg-1713104946452)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注Java）
[外链图片转存中…(img-kjn1451o-1713104946453)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！