简单了解微服务--黑马(在更)

认识微服务

单体架构

不适合大型复杂项目

微服务架构

将单体结构的各个功能模块拆分为多个独立的项目

拆取的独立项目分别开发,在部署的时候也要分别去编译打包,分别去部署,不同的模块部署在不同的服务器上,对外提供不同的功能,相当于每个模块都是一个小的服务,即微服务。

另外还需要做到数据库的数据隔离,每个服务有各自的数据库,互不影响

好处:单体架构在编译部署时要花费大量的时间,微服务拆分开之后,打包编译的速度非常快

坏处:复杂度提升,运维成本变高

SpringCloud

OpenFeign

微服务的远程调用

只需定义接口,无需去实现,底层会帮我们完成跨服务的远程调用,包括服务的拉取,负载均衡,发送请求等等复杂的代码。

网关

网络的关口,负责请求路由转发身份校验

类比

网关:小区开门的老大爷

微服务:小区的各个住户

前端:相当于某人要来小区找人

检查:身份校验

告诉某某某xxx住在xxx号:路由

找不着带你过去:转发

小区可以看成是微服务的集群,小区的住户看成各个微服务

网关(开门的大爷)就能解决微服务太多,前端不知道请求谁的问题,前端只需要知道网关的地址即可,网关根据前端的请求来判断由哪个微服务来处理请求。

判断的过程-->路由,网关将请求转发的过程-->转发

思考:微服务很多,网关如何知道每个微服务的实例ip地址和端口?

注册中心。所有微服务一经启动,都会将信息注册到注册中心,此时注册中心就会有微服务的所有信息,网关也是微服务,启动之后可以去注册中心拉取所有微服务地址。

微服务不需要暴露给前端,只需要将网关暴露给前端即可

配置路由规则

微服务的治理

服务治理包含两部分:

part1:所有微服务在启动时都应该提交自己的服务信息到nacos-->服务的注册

part2:服务的调用者去注册中心拉取服务列表进行服务的调用-->服务的发现

注册中心原理

核心用于微服务的治理-->治理过程复杂-->使用注册中心的组件Nacos

Nacos注册中心组件

服务注册

服务治理包含两部分:

part1:所有微服务在启动时都应该提交自己的服务信息到nacos-->服务的注册

服务发现

part2:服务的调用者去注册中心拉取服务列表进行服务的调用-->服务的发现

步骤1,2和服务的注册是通用的,需要单独完成服务发现的列表拉取

总结(一)

在对单体架构进行微服务的拆分过程中,发现的问题,利用微服务组件进行问题的解决。

**远程调用:**例如,服务拆分之后,每个服务进行单一的职责,复杂服务会出现服务之间的调用(如查询),即远程调用,使用OpenFeign进行解决。

**服务治理:**远程调用有很多,调用关系错综复杂,需要对微服务地址进行维护,并知道它们的健康状态,即服务的治理,使用Nacos组件进行实现。

**网关:**服务很多,前端不知道调用谁,引入网关进行解决。

**配置管理:**微服务越来越多,每个服务都有自己的配置文件,配置太多太复杂,并且配置出现变更需要重新启动服务,服务的可用性降低,使用Nacos组件进行问题解决,可以对配置进行抽取和共享,简化微服务的配置,还可以实现微服务配置的热更新,服务无需重启,提高服务的可用性

RabbitMQ

相关推荐
天天摸鱼的java工程师几秒前
假设你在开发订单系统时遇到高并发下库存扣减出错,如何解决?由浅入深分析
java·后端·面试
都叫我大帅哥2 分钟前
Redis的ZSet:从“青铜”到“王者”的排序神器
java·redis
肖笙XiaoSheng13 分钟前
使用Gemini2.5 pro 优化我的定时任务(二)
java·后端·代码规范
小小霸王龙!15 分钟前
互联网大厂Java面试实录:Spring Boot与微服务在电商场景中的应用
java·spring boot·redis·微服务·电商
深栈解码17 分钟前
JUC并发编程 CAS运行机制详解
java·后端
草履虫建模18 分钟前
Postman - API 调试与开发工具 - 标准使用流程
java·测试工具·spring·json·测试用例·postman·集成学习
深栈解码18 分钟前
JUC并发编程 ThreadLocal解析
java·后端
衍生星球25 分钟前
Maven 3.9.6的下载和配置
java·maven·springboot
缘来是庄33 分钟前
设计模式之代理模式
java·设计模式·代理模式
都叫我大帅哥39 分钟前
向量数据库Milvus:非结构化数据的救星,AI开发者的瑞士军刀
java·python