SpringCloud入门【一】——技术栈的关系

一、技术栈的关系图

二、项目创建的基本流程

首先应该创建注册中心，然后创建服务网关、客户端（微服务的提供者和消费者），服务网关和客户端到服务中心注册服务，互相访问时到注册中心发现服务。服务之间通过远程服务调用的方式交流。

三、技术栈解释（括号中的是常用的技术）

 1. Niginx

 niginx是一个高性能的HTTP和反向代理web服务器，类比Tomcat，但两者有明显的区别，Nginx 是HTTP Server，一个 HTTP Server 关心的是 HTTP 协议层面的传输和访问控制，客户端通过 HTTP Server 访问服务器上存储的资源（HTML 文件、图片文件等等）。通过 CGI 技术，也可以将处理过的内容通过 HTTP Server 分发，但是一个 HTTP Server 始终只是把服务器上的文件如实的通过 HTTP 协议传输给客户端。Tomcat本质上是一个Servlet/JSP应用的容器，它首先需要支持开发语言的Runtime环境（对于 Tomcat 来说，就是 Java），保证应用能够在应用服务器上正常运行。总结来说就是niginx只负责数据的收发，而Tomcat是可以使用java程序的，所以在低并发的情况下，用户可以直接访问tomcat服务器，然后tomcat服务器返回消息给用户。但是如今前后端分离（前端只负责数据的发送和接收显示，后端负责应用）的项目越来越成熟，面对各种高并发的需求，niginx的使用越来越多。
 此处niginx的功能是将服务请求经负载均衡处理后发送到服务网关

 2. 服务网关（SpringCloudGateway、Zuul）

在实际的项目中，一个项目可能会包含很多个服务，每个服务的端口和 IP 都可能不一样。那么，如果我们以这种形式提供接口给外部调用，代价是非常大的。从安全性上考虑，系统对外提供的接口应该进行合法性校验，防止非法请求，如果按照这种形式，那每个服务都要写一遍校验规则，维护起来也很麻烦。
这个时候，我们需要统一的入口，接口地址全部由该入口进入，而服务只部署在局域网内供这个统一的入口调用，这个入口就是我们通常说的服务网关。
网关是系统的唯一对外的入口，介于客户端和服务器端之间的中间层，处理非业务功能，提供身份认证和权限校验、服务路由、负载均衡、请求限流的功能。
此处网关的功能是收到请求后，核对身份之后对请求进行过滤，过滤可以是判断路由是否可以访问和在服务请求的请求头、请求体里加东西，然后去注册中心根据路由发现服务、通过负载均衡处理后发送到对应的服务（微服务中称为客户client）

 3. 注册中心（Nacos、Eureka）

 微服务中首先启动的应该是注册中心（微服务中称为服务service），因为就连网关都是一个client，需要注册到注册中心。微服务在启动的时候会将自己的信息（服务名称、iP、端口）注册到注册中心（微服务中称为服务注册）、微服务自己不用记录信息，访问其他服务时先到注册中心拉取服务列表（微服务中称为服务发现），然后经过负载均衡处理后发送到对应的微服务。

 4. 服务提供者与消费者

服务提供者：一次业务中，被其他微服务调用的服务（提供接口给其他微服务）
服务消费者：一次业务中，调用其他微服务的服务（调用其他微服务提供的接口）
提供者与消费者的角色其实是相对的，一个服务可以同时是服务提供者和服务消费者

 5. 远程服务调用（Dubbo、Feign）

Feign 是一个声明式的 HTTP 客户端，它简化了 HTTP 客户端的开发。使用 Feign，只需要创建一个接口并注解，就能很轻松的调用各服务提供的 HTTP 接口。Feign 默认集成了 Ribbon，默认实现了负载均衡。feign用作微服务之间的调用，比如说获取用户的订单，订单要显示用户信息，那么在请求订单信息时，处理订单的微服务会先去注册中心拉取处理用户的微服务，然后负载均衡处理后向其中一个发送请求。
刚接触微服务，可能会有疑惑，服务请求到达网关这里时，网关要根据路由从注册中心拉取服务，然后负载均衡处理（注册中心做的）后发送到对应的微服务，而微服务之间的交流（服务远程调用）是自带负载均衡的，这样去拉取服务的时候注册中心又会负载均衡一次，岂不是有冗余或是冲突么，但其实注册中心的负载均衡默认只对网关进来的请求有效

 6. 消息队列（MQ）

在微服务项目中,有些请求是需要同步的，比如说创建订单时要显示库存，需要向处理商品信息的微服务发送请求，肯定要等待收到库存是否够的信息才能判断是否可以创建订单，但是有些请求采用同步请求的话只会增加等待时间，占用资源，比如说修改用户信息，我改了之后并不一定马上就要查看，可以把请求发出之后就跳转到其他页面，这个时候消息就可以采用异步请求，发送到消息队列之后就不管了，请求会排队，对应的微服务有空会自己去把请求拿出来处理。

 7. 配置中心（SpringCloudConfig、Nacos）

上述服务网关、注册中心、微服务的提供者与消费者都算是整个微服务中的组件，每个组件都创建了一个工程，而每个工程都会有一个配置文件，并且有些配置是一样的。例如：在实际项目中，我们创建了用户和订单两个服务，这两个服务是同一个数据库，那么我们在这两个服务的配置文件都会配置相同的数据源，一旦我们的数据库地址发生改变（只是一种情况），用户和订单两个服务的配置文件都需要改，这还是只是两个服务，在一个大型系统（比如淘宝），将会有成千上万个服务，按照这种方式代价无疑是巨大的。
不过无需担心，正所谓上有政策，下有对策，既然有这个问题，就一定会有解决方案，那就是创建一个配置中心，专门用于管理系统的所有配置，也就是我们将所有配置文件放到统一的地方进行管理。在不同环境（开发环境、测试环境、项目发布之后的正式运行环境）选择不同的配置方案（.yml、.properties文件）即可统一修改。

四、springcloud各组件版本依赖关系

Spring Boot Version	Spring Cloud Version	Spring Cloud Alibaba Version
3.0.2	Spring Cloud 2022.0.0	2022.0.0.0-RC2*
3.0.0	Spring Cloud 2022.0.0	2022.0.0.0-RC1
2.6.13	Spring Cloud 2021.0.5	2021.0.5.0*
2.6.11	Spring Cloud 2021.0.4	2021.0.4.0
2.6.3	Spring Cloud 2021.0.1	2021.0.1.0
2.4.2	Spring Cloud 2020.0.1	2021.1
2.3.12.RELEASE	Spring Cloud Hoxton.SR12	2.2.10-RC1*
2.3.12.RELEASE	Spring Cloud Hoxton.SR12	2.2.9.RELEASE
2.3.12.RELEASE	Spring Cloud Hoxton.SR12	2.2.8.RELEASE
2.3.12.RELEASE	Spring Cloud Hoxton.SR12	2.2.7.RELEASE
2.3.2.RELEASE	Spring Cloud Hoxton.SR9	2.2.6.RELEASE
2.2.5.RELEASE	Spring Cloud Hoxton.SR3	2.2.1.RELEASE
2.2.X.RELEASE	Spring Cloud Hoxton.RELEASE	2.2.0.RELEASE
2.1.13.RELEASE	Spring Cloud Greenwich.SR6	2.1.4.RELEASE
2.1.X.RELEASE	Spring Cloud Greenwich	2.1.2.RELEASE
2.0.X.RELEASE	Spring Cloud Finchley	2.0.4.RELEASE(停止维护，建议升级)
1.5.X.RELEASE	Spring Cloud Edgware	1.5.1.RELEASE(停止维护，建议升级)