前段时间,总结了一篇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
- 安装并运行consul (有点像tomcat(运行在8080 ) ,运行在8500 ngnix也需要手动启动 在springboot中自动封装了tomcat故不需要手动启动tomcat)
- 在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从入门到大牛》