学习技术的路上不断沉淀自己

1. 分布式事务问题在单机单库的时候, 有本地事务可以保证数据的一致性; 但在分布式架构中, 原来的单体应用被拆分成多个微服务应用且都有各自独立的数据源, 一个业务场景的完成可能需要不同微服务模块和不同的库来完成. 此时每个微服务模块内部的数据一致性由本地事务来保证, 但是全局的数据一致性问题没有办法协调保证.比如: 用户购买商品的业务逻辑, 需要由3个微服务提供支持.仓储服务: 对给定的商品扣除仓储数量.订单服务: 根据采购需求创建订单.账户服务: 从用户账户中扣除余额.架构图:一句

1. Sentinel简介1.1 Sentinel是什么?随着分布式系统变得越来越流行，服务之间的可靠性变得比以往任何时候都更加重要。Sentinel, 是一个强大的流控组件，以“流”为切入点，涵盖流控、并发限制、熔断、自适应系统保护等多个领域，保障微服务的可靠性, 简单理解就是流量哨兵, 类似SpringCloud里的熔断器Hystrix, 且比Hystrix更加强大.轻量级的流量控制、熔断降级的Java库→Sentinel的GitHub开源→Sentinel官方介绍→Sentinel官

1. Nacos是什么Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。前四个字母分别为Naming和Configuration的前两个字母，最后的s为Service。( Nacos: Dynamic Naming and Configuration Service )从上面对Nacos名称分解可以看出, Nacos就是 注册中心 + 配置中心的组合, 即 Nacos = Eureka+ Spring Cloud Config + Spring Cloud Bus. 替代Eu

1. 应用背景在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。如果在这个过程中出现了异常，就很难去定位问题。所以，必须要实现一个分布式链路跟踪的功能，直观的展示出完整的调用过程。如果想要诊断复杂操作，通常的解决方案是在请求中传递唯一的ID到每个方法来识别日志。Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案 ,

1. 什么是SpringCloudStream→官网 , 官网doc , Spring Cloud Stream中文指导手册Spring Cloud Stream是一个构建事件消息驱动的微服务框架, 提供了灵活的编程模型。它构建在SpringBoot上，提供了Kafka，RabbitMQ等消息中间件的个性化配置，引入了发布订阅、消费组和分区的核心概念.2. 为什么使用Spring Cloud Stream2.1 问题场景在实际开发过程中，服务与服务之间通信经常会用到消息中间件, 比

1. why上篇中的配置中心服务端可以实现从远程仓库拉取实时变更的配置, 但是客户端无法直接实现配置更新, 需要向客户端发送一个post请求刷新配置(/actuator/refresh), 客户端微服务少的时候还能接受, 一旦有成百上千个客户端微服务, 不可能让运维工程师向每个客户端发送一次post请求手动刷新配置. 那么, 可否通过一种广播技术大范围的自动刷新,实现一次通知, 处处生效呢? 那就是下面我要写的消息总线技术.2. 什么是消息总线在微服务架构的系统中，通常会使用轻量级的消息代理来构建一

1. 为什么需要配置中心微服务要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，每一个微服务自己带着一个application.yml，成千上百个配置文件的管理就比较头疼了. 所以一套集中式的、动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题.2. 是什么官网资料→SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不

1. 为什么放弃Zuulspring-cloud之前整合的Netflix公司的Zuul网关用的好好的 , 为什么spring官方又推荐使用gateway网关呢? 有以下几点原因.(1) 上一代Zuul-1.x已经停止更新维护, 意味着bug没有更好的解决.(2) Zuul-1.x 采用的是Tomcat容器，是一个基于阻塞 I/ O的 API网关, 使用Servlet 2.5阻塞架构, 它不支持任何长连接(如 WebSocket).Zuul 的设计模式和Nginx较像，每次 I/ O 操作

OpenFeign是什么OpenFeign与Feign的区别→GitHub开源链接→官网解释→Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单。它的使用方法是定义一个服务接口, 然后在上面添加注解@FeignClient。Feign也支持可拔插式的编码器和解码器。Spring Cloud对Feign进行了封装，使其支持了Spring MVC标准注解和HttpMessageConverters , Feign可以与Eureka和Ribbon

Why微服务为什么需要API网关, 因为在微服务架构中，后端服务往往不直接开放给客户端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方客户端和后端服务之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，而后将请求均衡分发给后台服务端。Spring Cloud提供了解决方案: zuul网关.Zuul简介Spring Cloud Zuul路由是微服务架构的不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JV

雪崩效应复杂的分布式体系结构中的应用程序很多都有依赖调用关系, 每个依赖关系有些时候会出现不可避免的失败(异常,超时,网络故障等).这种多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。如果下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。服

简介在分布式微服务架构中, 微服务应用多是以集群的方式部署来保证微服务的高可用性. 那么服务消费方是通过什么方式的负载均衡策略调用到集群中的微服务提供方的呢? Spring Cloud给我们提供了解决方案: Ribbon.Ribbon的负载均衡策略Ribbon提供了轮询, 随机, 权重等多种负载均衡策略供我们使用, 默认是轮询策略.com.netflix.loadbalancer.*包下面有我们常用的负载均衡策略类.RoundRobinRule : 轮询策略,默认负载均衡策略RandomRul

简介Eureka作为微服务注册中心, Eureka-Server可以搭建多台服务注册中心实例, 并相互进行注册, 形成高可用的集群.创建Eureka注册中心微服务创建微服务应用microservicecloud-eureka, 导入依赖.<dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-clou

简介在学习Eureka过程中, 发现Eureka控制台注册的微服务实例列表中, 微服务地址可以点击访问微服务的info端点, 但是会跳转到SpringBoot默认的异常信息界面, 这是因为微服务没有暴露info端点. 下面就Eureka实例命名和info端点信息访问给出案例.搭建微服务微服务设计这里搭建微服务的过程就省略了, 我创建了三个微服务:eureka微服务注册中心: microservicecloud-eureka微服务提供方: microservicecloud-provider微服

SpringCloud入门1. 环境介绍IDEA 2019.3.4SpringBoot 2.0.1.RELEASESpring Cloud Finchley.M92. 微服务快速入门2.1 应用架构对比2.1.1 单体应用单体应用架构单体应用架构的优缺点单体模式的优势易于开发易于测试易于部署单体模式的不足应用工程变得又大又复杂敏捷开发和部署举步维艰启动时间长可靠性差难以采用新技术新语言2.1.2 微服务应用微服务分布式架构微服务架构的特点由