暂时未有相关云产品技术能力~
热爱编程的一名小学生
这一篇文章算是补充把,之前的Spring Cloud Gateway 是以Eureka为注册中心进行整合的,见《服务网关Gateway》,现在讲一下Spring Cloud Gateway 和Nacos的整合,该文章只介绍了Gateway和Nacos整合部分,请结合《服务网关Gateway》一起看你的收获会更大
服务网关在微服务架构中充当了请求访问入口的角色,是非常重要的一个部分,在高并发的系统中我们通常会在网关层通过流控降级等手段把多余的请求拒绝在外来防止微服务被高并发请求打垮,在之前我们有讨论过《服务网关Spring Cloud Gateway》和 《Sentinel流控》,一个是服务网关,一个是流控降级,本篇文章要讨论的是如何使用Sentinel对Gateway进行流控
因为在搞项目,需要对接一下OSS,所以一时兴起就做一下整理,本文章讲述的是如何使用阿里云的对象存储作为文件服务器,您需要登录阿里云,注册一个账号。
在之前 《什么是 Spring Cloud Alibaba》一文中我们有介绍过Dubbo,除了SpringCloud以外,Dubbo它也是用来作为微服务架构落地的成熟解决方案,并且它在服务通信上比SpringCloud性能更高,这取决于它的底层实现是基于原生的TCP协议,它的定位就是一款高性能的RPC(远程过程调用)框架,所以在国内很多的企业都选择Dubbo作为微服务框架,本文章的目的是帮助同学们将Dubbo这款高性能的RPC框架集成到SpringCloud中,真正实现SpringCloud 和 Dubbo的混用。
在单体应用中通常情况下只有一个数据库(单数据源),集成事务是一个非常容易的工作。Spring对事务做了很好的管理,我们只需要通过简单的注解@Transactional就可以完成本地事务管理。 但是在微服务项目中事务的管理变得困难,因为微服务项目往往有很多的数据库组成,如果在一个业务中涉及到了对多个微服务以及多个数据库的写操作(跨多个数据源),那么要如何才能保证多个数据库组件的读写一致呢?即:同时操作两个数据库,数据库A写操作成功过,数据库B写操作失败要怎么样让数据库A的写操作回滚?很显然用本地事务管理是不能实现了。 我们知道,虽然Spring对事务做了很好的管理和封装,但是最终都是调用数据
在前两章节我们学习了通过[Sentinel的限流和熔断机制](https://blog.csdn.net/u014494148/article/details/105484410)来保护微服务,提高系统的可用性,但是有一个问题,我们在Sentinel配置了限流,熔断策略,默认情况下Sentinel的数据是基于内存存储,当客户端断开,或者Sentinel重启数据就会丢失,这不是我们愿意看到的。所有我们需要的Sentinel做数据持久。 Sentinel 中支持5种持久化的方式:file、redis、nacos、zk和apollo,本片文章针对于Nacos进行持久化配置。
Spring Cloud Alibaba是Spring Cloud的一个子项目,OpenFeign是Spring Cloud的客户端负载均衡器,使用Spring Cloud Alibaba依然可以很方便的集成OpenFeign,如果要使用OpenFeign作为服务客户端负载均衡,那么我们需要考虑OpenFeign开启Sentinel进行服务熔断降级。
在上一章节我们探讨了Sentinel的流控(限流)功能,Sentinel除了流控还提供了服务熔断和降级机制,服务之间的调用关系错综复杂,微服务的调用链上的某些服务资源不稳定(宕机,异常,超时)可能会导致可能请求的失败和请求的堆积,调用链产生连锁反应可能会导致整个微服务架构瘫痪。服务熔断降级机制是保障高可用的重要措施之一。
限流 , 限制流量,这里的流量我们可以理解成请求数量,其实就是限制服务器的请求并发数量,为什么要这么做?如果不做限流,那么在大量并发请求下我们的服务器会慢慢的变慢然后顶不住压力而挂掉(类似堵车)。并不是说并发越大越好,有的时候我们的项目规模和业务决定了我们不需要那么大的并发性,当大量的并发请求访问到服务器时我们需要把部分请求拒绝在外,这个是流量限制 - 限流。 熔断机制在在《Spring Cloud 极简入门》中有详细的解释,熔断机制是对服务调用链路的保护机制,如果链路上的某个服务不可访问,调用超时,发生异常等,服务会进行发熔断,触发降级返回托底数据。简单理解就是当服务器不可访问,可以返回一
Nacos的控制台登录账号是nacos/nacos , 在生产环境中一定需要修改密码,不然一旦服务器地址泄露Nacos就会变得不安全,后果不堪设想。在上一章节我们做Nacos集群时我们基于MySql做了Nacos的数据持久化。在Nacos的数据库中有一个user表 , 这个表就是用来记录Nacos的控制台登录账号的,我们只需要修改表中的password 字段的 值即可。如下
在《Spring Cloud极简入门》应用架构演变一文中我们有提到,我们可以通过集群手段来实现来提高应用的作业能力,防止单节点故障。在之前的Nacos案例中我们玩的都是单机版的, 本片文章我们来探讨一下Nacos的集群部署。 在Nacos中数据默认是基于内存存储的,当Nacos重启数据(服务列表,配置列表)将会丢失,在Nacos中支持将数据持久到数据库。那么当我们对Nacos做了集群部署之后,多个Nacos节点之间是需要数据同步(数据共享)的,而正好Nacos节点之间的数据同步也是基于数据库来实现。所以我们要多Nacos做集群操作得向对Nacos做数据持久化。 这里我演示的是在centos
在《SpringCloud极简入门》中我们通过[Spring Cloud Config](https://blog.csdn.net/u014494148/article/details/105159730)作为统一配置文件管理中心,其实我们总结一下发现Spring Cloud Config使用起来总归比较麻烦。Nacos作为Spring Cloud Alibaba的一个重要组件,它不仅可以用作服务注册与发现,也可以用来替代Spring Cloud Config作为统一配置文件管理,而且他的使用更为简单和人性化。
在《Spring Cloud 极简入门》中我们学习了netflix 的 Eureka 组件作为微服务的服务发现。Nacos和Eureka有着相同的能力,甚至更为强大,作为Dubbo 生态系统中重要的注册中心实现。官方对它有如下定义: Nacos致力于帮助您发现,配置和管理微服务。它提供了一组简单有用的功能,使您能够实现动态服务发现,服务配置,服务元数据和流量管理。 Nacos使构建,交付和管理微服务平台变得更容易,更快捷。它是通过微服务或云原生方法支持以服务为中心的现代应用程序体系结构的基础架构。 这里我们看到Nacos不仅是服务发现组件,同时也是一个配置管理组件,也就是说它不仅可以用来取
早期在国内做分布式(微服务)应用Dubbo是比较热门的框架,被许多互联网公司所采用,并产生了许多衍生版本,如网易,京东,新浪,当当等等,奈何在2014年10月Dubbo停止维护,在Dubbo停更的时间里Spring Cloud快速追赶上。在2017年9月,阿里宣布重启Dubbo项目,计划对Dubbo进行持续更新维护。2018.2月,阿里将Dubbo捐献给Apache基金会,Dubbo成为Apache孵化器项目。 所以当前微服务架构,Dubbo和SpringCloud比较火,另外还有Thrift、gRPC等等 。很多人把SpringCloud 和Dubbo进行对比,其实两个框架并没有太大的可比
上一篇《[Transactional源码解析](https://blog.csdn.net/u014494148/article/details/118398677)》我们介绍了Spring对Transactional的解析,也就是事务的初始化工作,这一篇我们接着来分析事务的执行流程。
在上一章我们分析了Spring的AOP的源码,本篇文章是对事务的源码分析,我们都知道事务的管理是基于AOP实现的,所以有了上一篇的铺垫这一章会比较简单一点。 事务的源码我会分两章写,一张写Transcational的解析,一张写事务的执行流程。先上一个图,待会儿可以根据这个图来看源码
IOC/DI , AOP 是Spring最重要的两个特性 ,也是面试高频被问到的部分,前面我们已经分析了Spring的IOC相关源码以及DI依赖注入相关源码,从本篇文章开始我们着手分析Spring的AOP源码 。 开始之前,你需要对AOP 原理,JDK动态代理,CGLIB动态代理有一定的理解。这里先上一个图,后面源码分析的时候可以看着图来
这篇文章接上一篇文章属性注入讲一讲 @Autowired 注解的实现源码,这个也是面试被问的比较多的。
喜欢我的文章的话就给个好评吧,你的肯定是我坚持写作最大的动力,来吧兄弟们,给我一点动力 这一章节我们来讨论创建Bean过程中的属性注入,在Spring的IOC容器启动过程中,会把定义的Bean封装成BeanDefinition注册到一个ConcurrentHashMap中,Bean注册完成后,就会对单利的且lazy-init=false 的Bean进行实例化。创建Bean的代码在 AbstractAutowireCapableBeanFactory#doCreateBean 中,当Bean创建成功之后,会调用AbstractAutowireCapableBeanFactory#populat
前面系列章节我们分析了Spring的IOC的启动流程,包括:容器创建,配置加载,配置解析,Bean注册等几个阶段,所以Bean注册其实就是把Bean的相关属性,依赖关系等封装成BeanDeafinition对象,然后注册到一个ConcurrentHashMap中。要注意的是这个BeanDeafinition只是对Bean的一个定义封装而已,并不是真正的Bean的实例,那Bean的实例是在什么时候创建的?有三种情况 如果是单利Bean,且lazy-init=false 急切初始(即时,立即,迫切,饥饿都是一个意思)的情况,在IOC容器启动之后就会根据BeanDeafinition对Bean进行
在上一篇文章我们分析了一下基于注解的IOC启动流程的第一种方式,根据指定的BeanClass启动,这篇文章我们分析另外一种方式,扫描一个包路径来启动。
SortedSet(zset)有序集合可以看做是在Set集合的的基础上为集合中的每个元素维护了一个顺序值: score,它允许集合中的元素可以按照score进行排序,所以它的经典实用场景如:考生按分数排名,某游戏玩家分数排行,网站首页某数据排行,最新评论按时间排序等等。 Redis是一个内存数据库,它在保证读写速度的同时也需要考虑内存开销,那对于SortedSet有序集合而言它需要维护一个顺序值,而对于有序集合的底层实现可以选择:数组,链表,平衡树或者红黑树等结构,但是SortedSet没有选择这些结构。数组插入和删除元素性能很差,链表查询慢,平衡树或红黑树虽然查询效率高,但是在插入和删除元
Hash也是Redis中非常常用的一种存储结构了,Redis的hash底层用到了两种存储结构,ziplist压缩列表 和 hash 表,当存储的所有键值对的键和值的字符串长度都小于64字节,且元素个数少于512个,Redis会选择ziplist存储,这样会比较省内存,否则他会选择hashtable hash表去成,这里的hash表它底层结构和Java中的HashMap比较像,都是数组+链表,链表是为了解决hash冲突。
Redis中的set和java中的set集合有相似之处,它的元素不会按照插入的向后顺序而存储,且元素是不允许重复的。set内部使用到了intset(整数集合)和hashtable(哈希表)两种方式来存储元素,如果set存储的元素是整数,且当元素个数小于512个会选择intset存储,目的是减少内存空间,遇到两种情况会发生变化,就是当存储的元素个数达到512(通过set-max-intset-entries 配置)或者添加了非整数值时如:‘b’,set会选择hashtable作为存储结构。
我们在项目中都是使用Spring整合Mybatis进行数据操作,而不会直接使用SqlSession去操作数据库,因为这样操作会显得特别的麻烦。Spring整合Mybatis之后,Spring对Mybatis的核心进行了封装和适配,让我们用起来更加简单。本篇文章将带你了解Spring整合Mybatis的核心原理,从此再也不用担心面试官问我“Spring是如何整合Mybatis的?”
面试官:你说一下为什么Mapper映射器是一个interface,而我们却可以直接调用它的方法,还能执行对应的SQL。额…也许你不知道,也许你知道个大概,本篇文章将带你从源码的角度彻彻底底理解Mybatis的Mapper映射器
面试官:用过pagehelper做分页把,你说一下pagehelper的分页实现原理。额…此时你只能说我不知道。如果你事先看了我接下来的这篇文章,相信你一定也把这个面试题答得很好。
对于Mybatis的缓存在上一章节《吃透Mybatis源码-Mybatis执行流程》我们有提到一部分,这篇文章我们对将详细分析一下Mybatis的一级缓存和二级缓存。
上一篇文章我们分析了一下Mybatis的初始化流程,跟踪了一下Mybatis的配置解析过程,SqlSessionFactory和SqlSession的创建过程,这篇文章我们来分析一下SqlSession的执行流程
Mybatis是Java 项目开发使用率非常高的一款持久层框架,它支持自定义 SQL、存储过程以及高级映射。MyBatis 免除了几乎所有的 JDBC 代码以及设置参数和获取结果集的工作。MyBatis 可以通过简单的 XML 或注解来配置和映射原始类型、接口和 Java POJO(Plain Old Java Objects,普通老式 Java 对象)为数据库中的记录。 同时Mybatis也是面试过程中被高频问到的一门技术,今天我就带大家一起来对Mybatis的重要原理及其源码进行一个分析。
一篇文章我们了解了《Nacos服务注册》客户端源码,本篇文章我们来看一下服务注册Nacos服务端的源码执行情况。首先需要下载Nacos源码, https://github.com/alibaba/nacos/releases/tag/1.4.3 ,
前面我们讲了《nacos源码分析-服务注册(客户端)》 和 《nacos源码分析-服务注册(服务端)》,主要是讲的服务注册流程,本章节我们来讲服务心跳检测机制。
经过前面几章的学习,我们对Zuul的的详细执行流程,以及内置的Filter都有了一些认识,本篇文章是针对RibbonRoutingFilter做一个详细的分析,跟一下它是如何使用Ribbon对下游的微服务进行负载均衡的。注意:这篇文章是在 《zuul的执行流程》基础上进行延伸的,另外Ribbon的原理见:《Ribbon负载均衡原理》
在上一章节我们大致了解了Zuul的Filter的执行流程和核心的Filter,这一章节我们消息分析一下Zuul的自动配置,以及每个Filter的实现细节,这需要你有一定的耐心
Spring Cloud OpenFeign 对 Netflix Feign 进行了封装,我们通常都使用Spring Cloud OpenFeign作为服务的负载均衡,本文章主要是探讨一下OpenFeign的初始化流程,以及生成代理类注入到Spring的过程
前面我们分析了Eureka的源码,接下来这一章我们来研究一下Ribbon,本篇文章主要是对Ribbon的相关组件做一个认识,以及它的初始化配置做一个分析。
取消注册(服务下线)指的是EureakClient正常关闭之前,微服务会主动向EurekaServer发送下线请求,EureakServer接收到请求从注册表中剔除下线的服务