1：Spring Boot

让我们先从Spring Boot讲起吧！

我个人认为，Spring Boot与其说是说是spring框架的一部分，不如说是spring的简化打包工具。

如果你做过不使用spring boot的项目，你会发现，你需要自己准备tomcat的服务部署，同时还需要导入一大堆依赖库，这些依赖库有一部是你需要的，也有一部分会是你依赖的某个工具需要的依赖。除此之外你可能还需要配置一大堆xml配置文件用来保证你的服务能够顺利的执行与部署。

而Spring Boot大大简化了Spring服务的创建、部署、引用依赖的流程。
如果你对大大简化没有概念的话，你可以在一个没有任何环境说明的裸机器上部署一个引用了很多依赖的python工程，你就可以理解spring boot简化了多少引用依赖的流程了。

事实上，Spring Boot的使用基本是无感的。如果你是新的工程，你仅仅需要的是创建一个Spring Boot工程，然后使用就可以了。如果你是旧的maven工程改造，你也只需要添加简单的依赖，并增加一些初始代码就可以了。

1.1：新建Spring Boot工程

这个我们可以很简单的通过Spring官网的文档的指导来完成创建。具体的步骤无非就是选择一个合适的依赖，然后点击创建按钮就可以了，网上也有很多相似的示例，这里不再赘述。

因为Spring Boot将所有项目运行的依赖，包括tomcat这些服务全部集成在了一起，使用spring boot打包后，你会得到一个包含了所有运行所需的jar包。
基于java跨平台的特性，使得程序可以在任何具有java环境的机器下使用"java -jar xxx.jar"的命令，将服务部署起来。
随着单个服务部署和开发成本的降低，另一种思想边自然便有了用武之地。没错，它就是----微服务。

2：Spring cloud xx

Spring cloud 是什么？这是我开始最为困惑的问题。
当时看了一篇文章说，Spring cloud就是Spring版的微服务,虽然不太好意思，但我当时被这种误人子弟的说法困住了好久。
不过在理解Spring Cloud之前，我们确实需要了解一下微服务。
准确的说是我们需要了解一下，下面的这四个问题。

• 什么是微服务?
• Spring Cloud是什么？
• 微服务和Spring Cloud是什么关系？
• 怎么使用Spring Cloud？

2.1：什么是微服务？

微服务是一种思想，它本身并不涉及技术细节。

实际上，如果说只需要你掌握微服务，那么你根本就不必要在意什么是Spring Cloud。

微服务的本身只是一种思想，一种概念。
它是指将一个很大的工程，按照功能、模块等的维度，拆成很多个小的工程。从而保证不会因为某一个功能的更新或是损坏导致整个系统的崩溃。

当然，如果往深了说，怎么拆是更好的？应该将一个大服务拆分多少个小服务？在拆分服务的时候应该遵循怎样的原则？怎么保证微服务系统的稳定性？这些都是掌握微服务应该掌握的技能。

而在将大的程序拆分成多个小服务的的时候我们通常会遇到一些常见的问题：

1：服务的维护发现：当我们把大的服务拆分后，我们怎么让不同服务之间相互调用？万一某一个服务崩溃了，别的服务怎么得到这个消息？

2：服务级联崩溃： 上面说如果某个服务崩溃了还不是最坏的情况。很明显的是，将大的服务拆分后，不同模块之间仍会频繁相互调用，而如果某个服务崩溃，或者濒临崩溃，导致返回等待时间过长。那么调用它的模块便会存在大量请求的堆积，从而调用它的模块的资源占用也会增加，从而继续崩溃。在极端情况下，崩溃可能会不断互相传递，导致整个系统的不可用。这种情况怎么处理？

3：服务的网关：在整个服务是一个大服务的时候，我们对外提供服务的往往是一个统一的接口，拆分成多个服务后，不同的服务可能在不同的机器上，怎么依旧通过统一的接口对外提供服务呢？

4：服务配置： 在未拆分微服务时，我们可能只需要配置一个大服务相关的配置文件，即使有更新也往往只需要更新一份。但当服务拆分后，每个服务都需要单独维护各自的配置文件，如果每个服务还部署了多份，那么当配置文件更新时应该怎么保障每个服务的配置文件都进行了更新呢？怎么统一管理不同服务的配置文件更新呢？

如果让开发人员自己解决上面的问题，显然是成本过高的。

这时就要提到我们的spring cloud了。

2.1：Spring Cloud是什么？

Spring Cloud是微服务思想中，关键问题的一种技术解决方案。

需要注意的是，虽然微服务本身与语言无关，但是spring cloud却只支持java语言。

当然，如果使用别的语言，也有相应的微服务实现方案。例如：如果你想用python等实现微服务，也可以使用k8s+nacos+flask的方案来实现微服务。

Spring Cloud 是一组Spring工具的统称，并不特指某一个具体Spring框架。

我在标题上写的是Spring Cloud xx，就是因为我认为，单独介绍Spring Cloud只能陷入介绍微服务这个概念的陷阱中。

而Spring cloud 本质上，是为了解决我们上面提到微服务中那些问题的现成框架。

在Spring cloud 下面本身存在多个项目，有兴趣的各位可以在(Spring 文档)详细查看，我这里只挑选一些典型的项目说明一下：

• Spring Cloud Eureka: 其实这个框架现在文档上应该叫做Spring Cloud Netflix，Eureka是这个项目下的一部分。
  准确来说，Eureka分为Eureka Server和Eureka Clinet，关于这个项目我会在下一篇文章中详细讲解，之所以在这里写成eureka，也是担心新手朋友在Spring文档上找不到这个项目的文档，所以特意说明一下。
  这个项目其实就解决了我们上面说的第一个问题“服务的维护发现”，它也就是所谓的注册中心。它会自动在不同服务之间维持心跳检测，来监听不同服务的存活状态。并且支持注册服务名，让不同服务之间可以直接通过服务名访问彼此的接口等功能。

• Spring Cloud Nacos：这个项目是Spring Cloud Alibaba下的一部分，它也可以用来解决我们上述所说的问题一“服务的维护发现”，所以也可叫它注册中心。
  这里可能有人会有疑问了，那不是和上面的Eureka的重复了吗？
  没错！就是重复了！
  各位可以将这种情况近似理解为IOS和安卓系统上的软件，虽然它们在两台手机上的功能是相同的，但是因为各自属于不同软件生态，所以并不能混用。
  从名字上我们也可以略窥一二，Nacos是阿里巴巴提供一个工具，而Eueka是奈飞提供的工具。
  这也是我上面提及的，微服务本身是一种概念，而Spring cloud是为了解决实现这个概念时一些问题的技术方案。
  既然是技术方案，那自然可能存在多种实现，甚至我们也可以不用Spring cloud，使用Spring Boot+k8s也一样可以实现微服务架构，这些后面我有时间的话会再写一些文章介绍。

• Spring Cloud GateWay: 这个项目的作用对应了服务的网关的问题，也就是所谓的服务网关。所有外部的请求都只请求gateway便可以了，然后再由gateway转发到各个微服务下面。
  既然所有的请求都经过gateway，那么自然而然的可以想到，通过gateway可以管理请求进行负载均衡、身份验证等功能。
  说到负载均衡、转发请求，可能会有朋友想到nginx，这么一看它们的功能也有很多重叠之处。
  那可以用nginx代替GateWay吗？先说结论，可以！
  可能会有人说nginx是流量网关，gateway是业务网关，业务网关放在流量网关之后什么的。但是需要注意的是，这两者之间在技术实现上却并没有明确的界限，业务网关确实需要放在流量网关之后，但是我们也可以部署两个nginx，一个做流量网关，一个做业务网关。当然细说的话，两者在Spring Cloud生态下的使用难度，支持程度是完全不同的，有时间的话我也会单独写文章说明。

• Spring Cloud Circuit Breaker: 这个项目对应解决的是服务级联崩溃问题，也就是所谓的断路器。</br为什么不说Hystrix?如果你在中文互联网上搜索spring cloud 断路器，你可能会得到一大堆讲解Hystrix的文章，但是请注意，在2020年Hystrix已经被移除出Spring cloud了，截止现在2024年，最新的spring文档上Circuit Breaker才是Spring cloud提供的断路器。
  断路器的作用也很明确，为了防止级联崩溃，可以使用它来进行重试和降级。所谓降级指的是，通过提前实现的一些降级策略的方法，当接口的某个参数到阈值时，请求将不再发送原本的接口，而是转向处理降级的策略，由它们给出相应的返回值。
  关于这个项目的具体使用我也会在下一篇文章讲解。

• Spring Cloud Cinfig/Nacos: 这个项目对应解决的是服务配置的问题，具体使用方式我会放在下一个文章中。这里可能会有人疑惑的是Nacos不是用来解决服务的维护发现的问题的吗？实际上Nacos及时服务配置中心，也是服务注册中心，也就是说某一个项目也可能会对应多个解决方案。

其实除了上面提到的那些，微服务常常提到的五大组件中还包括一个服务调用的Feign，但我个人认为Feign与其说是解决了某个分解微服务时导致的问题，不如说它是一个可以更方便使用其他组件功能的模块。这个我后面会单独讲一下它，但我不认为它是必要的模块，只能说有它的话更方便，而且等理解了别的模块后，可能你就会自然而然的理解这个模块了。

那么~敬请期待下一篇