单体架构
:
1.项目过于臃肿,所有服务在一起,一个业务挂了,整个项目就不能用了;
2.资源不能隔离,所有业务用一个资源,共享一个数据库,如果说一个业务突然增大——>导致数据库宕机了,那么其他业务就会受到影响;
3.扩展不灵活,如果我们要对一个服务进行扩展,会将整个系统水平扩展;
4.所有功能得一起上线,一起部署;
分布式:
1.数据一致性:我们先说有个最明显的案例:之前我们的单体架构中,数据库是多个服务共享的,所以事务是ACID的,但是分布式中,每个微服务都有自己独立的数据库,你一个业务串了多个服务,那么分布式下的微服务链路原子性就不能保证了——>比如下面:
例子
:创建订单,扣减用户余额,扣减库存(涉及三个服务),在订单业务中远程调用两个服务,我们创建一个订单,假设库存为10,我们下单11个,按道理来说我们是想库存服务和订单服务还有账户服务是会回滚的,因为下单超过库存数,但是实际上只有库存服务会回滚自己的数据库,其余的账户服务和订单服务都会成功;
原因:每个服务都是独立的,有自己的数据库,所以事务也是独立的;
**2.需要考虑网络问题,**因为服务的调用十分依赖网络,尤其是节点非常多,链路非常长的情况下
**3.异步:**引入了各种中间件,GateWay,mq,nacos,seata等等,异步通信增加了功能实现的复杂度;
**4.运维成本:**一个系统被拆成多个服务,每个服务都得配置,部署;
总得来说,就是将原本一个系统分成多个互相调用通信的服务;
分布式
的意思是多个模块共同完成一件事情(也可以是一个模块分多个部署),每个节点可以单独完成任务;(分开不同机器部署)
微服务
的意思也是多个模块共同完成一件事情,(不管应用部署在哪里)
总结:
微服务和分布式都是拆分单体应用的产物,可以理解为,微服务只是对服务拆分的形容词,分布式是对服务部署方面的考量,微服务是可以包含分布式的,但是分布式不一定是微服务;
分区:因为网络故障导致分布式中部分节点与其他节点失去连接,从而形成独立分区——>一定会有的;
解决:
让node03节点等待网络的恢复,在恢复之前不允许访问;——>满足了一致性,不满足可用性
因为分布式系统中,我们的服务节点一定是通过网络连接的,那么就一定会出现分区问题,毕竟你网络是不能保证百分百良好的
思考:
因为es集群,当有一个节点宕机时,过了一定时间它会被剔除,那么我们就访问不到它了,牺牲了可用性,但是节点上的数据会被分到其他节点上,从而保证了一致性,所以是CP;
这里回顾一下es集群:
elasticsearch搭建集群-CSDN博客
突然想到了EureKa和Nacos中的区别里面也涉及AP、CP
区别:
Nacos支持服务端主动检测服务提供者状态:临时实例采用心跳模式,非临时实例采用服务器主动访问模式;
临时实例心跳不正常会被踢出,非临时实例则不会被剔除;
Nacos支持服务列表消息推送模式,即时更新;
补充 nacos、EureKa涉及ap、cp模式
CP和AP是什么?有什么区别?-CSDN博客
牛逼之处:部分的损失可用(A),临时的不一致——>最终的一致性(C),权衡
目的:解决分布式系统的事务问题
1.首先TC是维护协调整个全局的事务的,帮助事务进行提交和回滚,相当于分布式事务一个总的大杂烩
——>2.而作为分布式系统,是有个入口的,因为我们的微服务之间的调用,每调用一个服务就是一个事务出现,也就是说我们这个入口管理了整个服务调用的一个范围,所以说TM事务管理器就相当于全局事务的入口,定义了事务范围,然后开启全局事务
——>3.TC,它会判断我们的全局服务是否进行提交与回滚
——>4.但是在此之前,因为全局事务里面有分支事务,分支事务提交就与RM有关,管理分支事务处理,向TC进行注册事务,并且执行对应的sql,然后报告状态给TC(但是RM此时是没有回滚和提交效果的,说白了也就是执行了服务而已,但是并没有提交)
——>5.TC会进行验证服务状态来判断最后是提交还是回滚,由TM处理;
总结:TM和RM是和业务有关的,对服务进行管理,而TC是独立出来的,维护分支服务状态的
新建配置中+配置内容:
# 数据存储方式,db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true
store.db.user=root
store.db.password=123456
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
# 事务、日志等配置
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000
# 客户端与服务端传输方式
transport.serialization=seata
transport.compressor=none
# 关闭metrics功能,提高性能
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898
以上我们数据存储的数据库为seata,我们还需要定义一个全局事务表和一个分支事务表
SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;
-- ----------------------------
-- 分支事务表
-- ----------------------------
DROP TABLE IF EXISTS `branch_table`;
CREATE TABLE `branch_table` (
`branch_id` BIGINT(20) NOT NULL,
`xid` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` BIGINT(20) NULL DEFAULT NULL,
`resource_group_id` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`resource_id` VARCHAR(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`branch_type` VARCHAR(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`status` TINYINT(4) NULL DEFAULT NULL,
`client_id` VARCHAR(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`application_data` VARCHAR(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` DATETIME NULL DEFAULT NULL,
`gmt_modified` DATETIME NULL DEFAULT NULL,
PRIMARY KEY (`branch_id`) USING BTREE,
INDEX `idx_xid`(`xid`) USING BTREE
) ENGINE = INNODB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;
-- ----------------------------
-- 全局事务表
-- ----------------------------
DROP TABLE IF EXISTS `global_table`;
CREATE TABLE `global_table` (
`xid` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
`transaction_id` BIGINT(20) NULL DEFAULT NULL,
`status` TINYINT(4) NOT NULL,
`application_id` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_service_group` VARCHAR(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`transaction_name` VARCHAR(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`timeout` INT(11) NULL DEFAULT NULL,
`begin_time` BIGINT(20) NULL DEFAULT NULL,
`application_data` VARCHAR(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
`gmt_create` DATETIME NULL DEFAULT NULL,
`gmt_modified` DATETIME NULL DEFAULT NULL,
PRIMARY KEY (`xid`) USING BTREE,
INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
) ENGINE = INNODB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;
SET FOREIGN_KEY_CHECKS = 1;
seata部署成功
目的:完成分布式事务管理,形成TM,RM,代理我们的分布式事务;
<dependency>
<groupId>com.alibaba.cloudgroupId>
<artifactId>spring-cloud-starter-alibaba-seataartifactId>
<exclusions>
<exclusion>
<artifactId>seata-spring-boot-starterartifactId>
<groupId>io.seatagroupId>
exclusion>
exclusions>
dependency>
<dependency>
<groupId>io.seatagroupId>
<artifactId>seata-spring-boot-starterartifactId>
<version>${seata.version}version>
dependency>
seata-tc-server服务的确定需要再nacos注册中心中进行寻找:服务地址+namespace默认值+分组group+application+事务组+集群
**事务组:**相当于管理分布式系统中里面的微服务(订单,库存…),这些服务把他们进行管理,这些管理的大组为事务组,我们可以根据这个获取TC节点
seata:
registry:
type: nacos
nacos:
server-addr: 127.0.0.1:8848
namespace: ""
group: DEFAULT_GROUP
application: seata-tc-server
username: nacos
password: nacos
#事务组名称
tx-service-group: seata-demo
service:
#配置映射关系
vgroup-mapping:
seata-demo: SH