【自我总结】分布式微服务框架springcloud相关技术总结（上）

前段时间，总结了一篇http请求的发送，那段时间正在学习springcloud框架，还没有完全学完，因此还没有对RPC框架中的请求方式进行总结，本文将对springcloud框架里边涉及到的技术进行相关的总结归纳，然后将其中发送http请求的方式进行展示，作为对上一篇文章的补充。

前言：分布式和微服务的关系

·分布式系统：
       分布式系统是指一个由多台计算机（或节点）组成的系统，这些计算机通过网络互相通信和协作，共同完成一个或多个共同的任务。
       分布式系统的设计目标是将一个大型系统拆分成多个子系统或模块，并将这些模块分布在不同的计算机上，以实现更高的性能、可扩展性、容错性和可靠性。
       分布式系统通常涉及到复杂的通信协议、数据一致性机制、容错处理等技术，例如远程过程调用（RPC）、消息队列、分布式事务等。
       分布式系统的范围很广泛，可以包括各种类型的系统，例如集群计算、分布式数据库、分布式文件系统等。
·微服务架构：
       微服务架构是一种基于分布式系统思想的软件架构风格，它将一个大型的单体应用拆分成多个小型的、独立部署的服务，这些服务可以被独立地开发、部署和扩展。
       每个微服务都是一个独立的进程，通常运行在自己的容器中，并且通过轻量级的通信机制（例如 HTTP 或消息队列）来进行通信。
       微服务架构强调服务的自治性、独立性和可替换性，使得开发团队可以更快地迭代开发、部署和维护单个服务，从而提高整体系统的灵活性和可维护性。
微服务架构通常伴随着一系列的技术实践，例如容器化、自动化部署、服务发现和治理、分布式追踪等。
       综上所述，分布式系统是一种范式或架构模式**，而微服务是基于分布式系统思想的一种软件架构风格。微服务架构可以看作是一种实现分布式系统的方式之一，它在设计和开发上更加关注服务的粒度和自治性，以及开发团队的独立性和快速交付能力。因此，虽然分布式系统和微服务有一定的关联，但它们并不是同一个概念。
补：其他实现分布式系统的方法：
1、消息传递模型：节点之间通过消息传递进行通信。这可以是点对点通信，也可以是发布/订阅模式或队列模式。
2、远程过程调用（RPC）：允许一个程序调用另一个程序上的过程或函数，就像调用本地函数一样，但实际上是在远程执行的。
3、分布式共享内存：允许不同节点之间共享内存，使它们可以访问和修改共享的数据结构。
4、分布式数据库：将数据存储在多个节点上，通过复制、分片或其他技术实现数据的分布和冗余存储。
5、分布式文件系统：允许在多台计算机上存储和访问文件，提供文件共享和冗余存储。
6、分布式计算框架：提供分布式计算的基础设施和工具，如Apache Hadoop、Apache Spark等。
7、分布式锁和协调服务：用于协调多个节点之间的并发访问，确保数据的一致性和正确性。
8、区块链技术：提供了一种去中心化的分布式系统架构，用于实现安全的数据交换和智能合约。

一、springcloud/springcloud alibaba 主流技术

注：加粗的是springcloud alibaba
服务注册与发现：consul，nacos
分布式配置管理：consul,nacos
服务调用与负载均衡：LoadBalancer，OpenFeign（集成了LoadBalancer）
服务熔断/服务降级：Resilience4j,Sentinel
分布式链路追踪：Micrometer Tracing
网关：GateWay
分布式事务：Seata

2024年已经逐渐被淘汰的技术：
服务注册与发现 eureka
服务负载与调用 ribbon feign
服务熔断升级 hystrix
服务网关 zuul
服务分布式配置 spring cloud config

二、微服务的构建方式

通用的步骤是：

• 建moudule
• 改pom（添加必要的依赖）
• 写yml（添加必要的配置信息 比如端口号，服务注册中心的相关配置）
• 修改主启动类
• 写业务类

其他需要进行的步骤：

• 定义统一返回对象格式（包含code状态值，message 描述，data数据），全局异常处理（自定义异常返回值）
• 抽取公共代码，然后打包成jar包，在pom中调用，减少代码重复书写，例如：上述的两个类，还有下边要用到的openfeign对外暴露的接口

三、分模块介绍相关技术

以下部分将带着如下几个问题进行介绍：

• 是什么？解决什么样的痛点？有什么好处？
• 大致的使用步骤

3.1 服务注册与发现/分布式配置管理

服务注册与发现：
服务注册：当一个服务启动时，它将自己的信息（如网络地址、端口号、版本号等）注册到一个中心化的服务注册表中，以使其他服务能够发现和访问它。
服务发现：其他服务需要与某个服务进行通信时，它们会向服务注册表查询所需服务的信息，以获取其网络地址和其他必要的信息，然后直接与该服务进行通信。这种机制使得服务之间能够在动态环境中相互发现和通信，而不需要硬编码或静态配置服务的位置。
分布式配置管理：
在分布式系统中，配置管理变得更加复杂，因为系统由多个独立运行的组件组成，这些组件可能部署在不同的机器上，并且配置可能需要根据环境变量、部署环境等动态调整。
分布式配置管理是一种用于集中管理和分发配置信息的机制。它通常包括将配置信息存储在中心化的存储系统（如数据库、键值存储或配置服务）中，并提供一种机制来动态地将配置信息分发给系统中的各个组件。
这种机制可以帮助确保系统中所有组件都使用相同的配置信息，并且可以灵活地在系统运行时更新配置，而不需要重新部署或重启服务。

大致的使用步骤:
1)consul

1. 安装并运行consul （有点像tomcat（运行在8080 ） ,运行在8500 ngnix也需要手动启动 在springboot中自动封装了tomcat故不需要手动启动tomcat）
2. 在pom中引入以下依赖
   
   修改对应微服务的yml文件
   
   上图中 spring application name 定义了该服务的名字，8001和8002都属于这个名字，然后还配置了cloud的consul在consul中配置了服务发现 ：意思是当服务名字叫spring application name启动的时候这个服务就会被发现，就可以在consul的页面中显示出来（localhost:8500

在主启动类上添加@EnableDiscoveryClient，启动服务发现
在业务类上的微服务URL改为下边的形式 “http：//cloud-payment-service”

服务配置动态刷新：
服务配置：consul服务器KV配置填写，配置三个文件，分别如下

dev表示开发环境，prod表示生产环境
这个配置信息是在consul上配置的，当application配置文件中修改当前工作环境的时候 就会读取相对应的配置文件

动态刷新：在主启动类上加上@Reshape

consul数据持久化：
1）新建一个文件夹mydata （KV键值对数据会保存到这里，以文件形式保存到这里（下次开机可以自动调用该文件）
2）新建一个脚本文件 consul_start.bat
3）内容

这个配置内容含义就是 将mydata数据自动配置到consul中
4）注册为window服务，这样window关机了都不会消失，开机后consul开机自启并且将相关配置自动注册进consul
2)nacos (Dynamic Naming and Configuration Service 动态服务注册和配置管理)
nacos = eureka+config+bus
nacos = consul
使用过程类似于consul
nacos独特的部分：nacos的数据模型 Namespace-Group-DataID

类似于包名，类名，泛型名
说明：
类似Java里面的package名和类名，
最外层的Namespace是可以用于区分部署环境的，
Group和DatalD逻辑上区分两个目标对象

默认情况:Namespace=public，
Group=DEFAULT GROUP

Nacos 的数据模型 Namespace-Group-DataId 可以用于对配置信息进行更细粒度的管理和组织，适用于以下一些应用场景：
1、多环境管理：
·Namespace 可以用来区分不同的环境，如开发环境、测试环境、生产环境等。
·Group 可以用来区分不同的应用或服务，如订单服务、用户服务等。
·DataId 可以用来指定具体的配置信息，如数据库连接、日志级别等。
这样可以在不同环境下管理同一组服务的不同配置，方便了配置的管理和部署。
2、团队与项目管理：
·Namespace 可以用于区分不同团队或项目的配置信息。
·Group 可以用于区分不同模块或子系统的配置信息。
·DataId 可以用于指定具体的配置项。
这样可以在一个 Nacos 实例上管理多个团队或项目的配置信息，提高了配置的管理效率和安全性。
3、灰度发布与版本管理：
·可以使用 Namespace 区分不同的版本或分支。
·Group 可以用于区分不同的灰度发布组。
·DataId 可以用于指定具体的配置项。
这样可以在灰度发布过程中管理不同版本的配置信息，确保新版本的服务在灰度发布期间可以正常运行。
4、配置优先级管理：
·可以通过命名空间的优先级来管理不同配置的优先级。
·可以使用 Group 或 DataId 来管理同一配置下的不同版本或实例的优先级。
这样可以根据需要灵活地管理配置信息的优先级，确保高优先级的配置能够覆盖低优先级的配置。

3.2 服务调用/负载均衡

       服务调用是指在分布式系统中，一个服务实例通过网络请求调用另一个服务实例的过程。这种调用可以是同步的，也可以是异步的，通常是通过远程过程调用（RPC）或者 HTTP 请求来实现。
负载均衡是指在分布式系统中，将请求分发到多个服务实例上，以实现资源的均衡利用和提高系统的可用性和性能。负载均衡可以分为两种类型：
       服务端负载均衡：请求先到达负载均衡器，负载均衡器根据一定的策略将请求分发到多个服务实例上，然后由服务实例来处理请求并返回结果。常见的服务端负载均衡器有 Nginx、Envoy、Zuul 等。
       客户端负载均衡：请求直接发送到服务实例，但是在发送之前，客户端会通过负载均衡算法选择目标服务实例，然后将请求发送到选定的服务实例上。常见的客户端负载均衡器有 Ribbon、Spring Cloud LoadBalancer 等。
       服务调用和负载均衡是分布式系统中常见的两个概念，通常结合使用以实现系统的高可用性、可扩展性和性能。通过负载均衡器，请求可以被分发到多个服务实例上，从而减轻单个服务实例的压力，提高系统的整体性能和稳定性。
简单理解：Nginx是服务器负载均衡，客户端所有请求都会交给nginx，然后由nginx实现转发请求，即负载均衡是由服务端实现的。(由服务器做负载均衡)
loadbalancer本地负载均衡，在调用微服务接口时候，会在注册中心上获取注册信息服务列表之后缓存到JVM本地，从而在本地实现RPC远程服务调用技术。（自己去找哪个是空闲的）
（自己有眼力见 见服务器人多就不去了）

大致的使用步骤：
以订单微服务为例
订单微服务模块80调用支付模块8001/8002
在公共模块中新建一个payFeignApi，里边写上支付微服务模块对外暴露的接口

调用过程：
订单80 - commons里的payFeignApi （支付模块对外暴露的接口放到common模块里）- 支付8001/8002

未完待续。。。

3.3 / 3.4 / 3.5 / 3.6部分见下篇

参考资料：bilibili《尚硅谷2024最新SpringCloud教程，springcloud从入门到大牛》