志豪的博客

4-Alibaba-Seata(个人事务原理)学习笔记2020.10.28前言: (官网工作流程)在整个架构中, 重点的概念就是: TC(事务协调者, 相当于Seata的服务器)、 TM(事务管理者, 控制全局事务的提交与回滚的, 相当与电脑中的鼠标, 项目里面就是标记了@GlobalTransactional)、 RM(本地资源, 相当项目里面的本地事务操作数据库, 参与全局事务者)。工作流程TM也就是标记了@GlobalTransactional注解的, 向TC申请开启一个全局事务

3-Alibaba-Seata(事务测试)学习笔记2020.10.28前言:前面, 已经将工程搭建完成, 下面进行项目的分布式事务测试, 看看结果是怎么样?根据业务流程进行调用: 下订单 - 减库存 - 扣余额1.0 进行测试1.1.1 数据库造数据为了测试方便直接在数据库中的库存与账户表里面造一条数据。顺便查看nacos管理中心是否应用服务都成功注册上去[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-hwN4F2nJ-1603880663352)(h

2-Alibaba-Seata(数据库与微服务准备)学习笔记2020.10.27前言: (官网)根据官网用例: 我们需要创建3个数据库, 分别是: 仓储服务(对应仓储) 、 订单服务(对应订单库) 、 帐户服务(对应订单库)业务流程是: 订单服务根据采购需求创建订单然后去调用仓储服务去扣减库存, 扣减库存成功在去从用户帐户中扣除余额要保证要么一起成功然后提交, 要么一起失败大家都进行回滚, 不能出现扣除账户余额失败了, 但库存与订单没回滚或者其他事务范围中间某一步失败了没回滚的情况。在以往单机

1-Alibaba-Seata(分布式事务解决方案)学习笔记2020.10.26前言: (官网)分布式事务的由来: 随着网络时代的不断发展, 由从前的单机服务部署(也就是一个应用对应一个数据库), 这种情况是没有分布式问题的, 到现在演变成多个应用与多个数据库多个实例部署(关系成为了多对多)分布式的问题就出现了, 如何保证不同应用中对应操作不同数据库的事务ACID, 要么统一成功, 要么统一失败, 下面进行学习阿里巴巴出品的分布式事务解决方案SeataSeata 是一款开源的分布式事务解决方案，致力

6-CloudAlibaba-Sentinel(规则持久化)学习笔记2020.10.25前言: (官网 、动态规则)之前我们学习配置的规则都是临时的, 只要微服应用重启后, 规则就消失了, 需要重新配置。这样服务多了只后, 后续麻烦的事情会越来越多, 下面进行配置Push 模式规则持久化解决规则是临时的问题。规则管理及推送一般来说，规则的推送有下面三种模式:推送模式说明优点缺点原始模式API 将规则推送至客户端并直接更新到内存中，扩展写数据源（WritableDat

5-CloudAlibaba-Sentinel(热点参数与系统限流)学习笔记2020.10.25前言:何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量

4-CloudAlibaba-Sentinel(整合OpenFeign)学习笔记2020.10.24前言: (Cloud官网 、GitHub官网)Sentinel与OpenFeign组件兼容。要使用它，除了引入sentinel-starter依赖关系之外，还需要完成以下两个步骤：在属性文件中启用伪装的Sentinel支持。 feign.sentinel.enabled=true添加openfeign starter依赖项以触发并启用sentinel starter：1.0 引入spring

3-CloudAlibaba-Sentinel(@SentinelResource注解)学习笔记2020.10.23前言: (官网)Hystrix有@HystrixCommand指定条件与降级方法来进行服务降级, 返回自定义信息。Sentinel类似的注解就是@SentinelResourceSentinel 提供了 @SentinelResource 注解用于定义资源，并提供了 AspectJ 的扩展用于自动定义资源、处理 BlockException 等。使用 Sentinel Annotat

2-CloudAlibaba-Sentinel(熔断降级)学习笔记2020.10.22前言: (官网)除了流量控制以外，对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一。一个服务常常会调用别的模块，可能是另外的一个远程服务、数据库，或者第三方 API 等。例如，支付的时候，可能需要远程调用银联提供的 API；查询某个商品的价格，可能需要进行数据库查询。然而，这个被依赖服务的稳定性是不能保证的。如果依赖的服务出现了不稳定的情况，请求的响应时间变长，那么调用服务的方法的响应时间也会变长

1-CloudAlibaba-Sentinel(限流)学习笔记2020.10.21前言: (Cloud的官网 、GitHub官网 、Sentinel官网)阿里巴巴的Sentinel对比奈飞的Hystrix 有什么不同, 有什么优势? (下面是官网复制的, 更为详细看官网)Sentinel 具有以下特征:丰富的应用场景：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

3-CloudAlibaba-Nacos(集群)学习笔记2020.10.19前言: (官网)生产环境都是要保证高可用, 所以需要搭建Nacos集群, 来保证不会由于只有一个注册中心情况下挂了, 整个微服都出现问题, 由于Nacos默认使用的是内置嵌入式数据库derby, 如果搭建集群会出现数据一致性问题, 每个Nacos中数据库数据都不同。所以需要使用自定义MySQL数据库, 目前也仅支持MySQL。 (前面笔记1-注册中心中配置过自定义数据库进行持久化配置)从官网上的集群部署架构图上看,

2-CloudAlibaba-Nacos(配置中心)学习笔记 2020.10.15前言:以前项目单独使用CloudConfig, 只能实现配置文件从云端(git、svn)拉取下来,作为项目启动使用。没有集成CloudBus的情况下, 更改了配置文件只能重新启动项目使其生效。现在使用Nacos的配置中心功能就能非常简单实现CloudConfig+CloudBus 云端拉取配置文件作为项目启动, 并实时更新配置文件。下面进行快速入门。1.0 新建模块/引入依赖<!--nacos-conf

1-CloudAlibaba-Nacos(注册中心)学习笔记 2020.10.13前言:阿里的Nacos 为什么要使用他, 而不使用Eureka 或者 Consul 这些微服常用的注册中心。阿里的Nacos优势在于更易于构建原生应用的动态服务发现、配置管理和服务管理平台。简单的相当Nacos 拥有了注册中心(类似Eureka )与配置中心(CloudConfig) 加上CloudBus(实时刷新配置属性,生效)、3个功能技术的集合。同时支持CP数据强一致性模式, 支持注册持久化实例, 该模式注