暂时未有相关云产品技术能力~
热爱编程的一名小学生
这一篇文章算是补充把,之前的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的混用。
在前两章节我们学习了通过[Sentinel的限流和熔断机制](https://blog.csdn.net/u014494148/article/details/105484410)来保护微服务,提高系统的可用性,但是有一个问题,我们在Sentinel配置了限流,熔断策略,默认情况下Sentinel的数据是基于内存存储,当客户端断开,或者Sentinel重启数据就会丢失,这不是我们愿意看到的。所有我们需要的Sentinel做数据持久。 Sentinel 中支持5种持久化的方式:file、redis、nacos、zk和apollo,本片文章针对于Nacos进行持久化配置。
限流 , 限制流量,这里的流量我们可以理解成请求数量,其实就是限制服务器的请求并发数量,为什么要这么做?如果不做限流,那么在大量并发请求下我们的服务器会慢慢的变慢然后顶不住压力而挂掉(类似堵车)。并不是说并发越大越好,有的时候我们的项目规模和业务决定了我们不需要那么大的并发性,当大量的并发请求访问到服务器时我们需要把部分请求拒绝在外,这个是流量限制 - 限流。 熔断机制在在《Spring Cloud 极简入门》中有详细的解释,熔断机制是对服务调用链路的保护机制,如果链路上的某个服务不可访问,调用超时,发生异常等,服务会进行发熔断,触发降级返回托底数据。简单理解就是当服务器不可访问,可以返回一
Nacos的控制台登录账号是nacos/nacos , 在生产环境中一定需要修改密码,不然一旦服务器地址泄露Nacos就会变得不安全,后果不堪设想。在上一章节我们做Nacos集群时我们基于MySql做了Nacos的数据持久化。在Nacos的数据库中有一个user表 , 这个表就是用来记录Nacos的控制台登录账号的,我们只需要修改表中的password 字段的 值即可。如下
在《SpringCloud极简入门》中我们通过[Spring Cloud Config](https://blog.csdn.net/u014494148/article/details/105159730)作为统一配置文件管理中心,其实我们总结一下发现Spring Cloud Config使用起来总归比较麻烦。Nacos作为Spring Cloud Alibaba的一个重要组件,它不仅可以用作服务注册与发现,也可以用来替代Spring Cloud Config作为统一配置文件管理,而且他的使用更为简单和人性化。
早期在国内做分布式(微服务)应用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的解析,一张写事务的执行流程。先上一个图,待会儿可以根据这个图来看源码
这篇文章接上一篇文章属性注入讲一讲 @Autowired 注解的实现源码,这个也是面试被问的比较多的。
SortedSet(zset)有序集合可以看做是在Set集合的的基础上为集合中的每个元素维护了一个顺序值: score,它允许集合中的元素可以按照score进行排序,所以它的经典实用场景如:考生按分数排名,某游戏玩家分数排行,网站首页某数据排行,最新评论按时间排序等等。 Redis是一个内存数据库,它在保证读写速度的同时也需要考虑内存开销,那对于SortedSet有序集合而言它需要维护一个顺序值,而对于有序集合的底层实现可以选择:数组,链表,平衡树或者红黑树等结构,但是SortedSet没有选择这些结构。数组插入和删除元素性能很差,链表查询慢,平衡树或红黑树虽然查询效率高,但是在插入和删除元
Hash也是Redis中非常常用的一种存储结构了,Redis的hash底层用到了两种存储结构,ziplist压缩列表 和 hash 表,当存储的所有键值对的键和值的字符串长度都小于64字节,且元素个数少于512个,Redis会选择ziplist存储,这样会比较省内存,否则他会选择hashtable hash表去成,这里的hash表它底层结构和Java中的HashMap比较像,都是数组+链表,链表是为了解决hash冲突。
我们在项目中都是使用Spring整合Mybatis进行数据操作,而不会直接使用SqlSession去操作数据库,因为这样操作会显得特别的麻烦。Spring整合Mybatis之后,Spring对Mybatis的核心进行了封装和适配,让我们用起来更加简单。本篇文章将带你了解Spring整合Mybatis的核心原理,从此再也不用担心面试官问我“Spring是如何整合Mybatis的?”
面试官:你说一下为什么Mapper映射器是一个interface,而我们却可以直接调用它的方法,还能执行对应的SQL。额…也许你不知道,也许你知道个大概,本篇文章将带你从源码的角度彻彻底底理解Mybatis的Mapper映射器
面试官:用过pagehelper做分页把,你说一下pagehelper的分页实现原理。额…此时你只能说我不知道。如果你事先看了我接下来的这篇文章,相信你一定也把这个面试题答得很好。
一篇文章我们了解了《Nacos服务注册》客户端源码,本篇文章我们来看一下服务注册Nacos服务端的源码执行情况。首先需要下载Nacos源码, https://github.com/alibaba/nacos/releases/tag/1.4.3 ,
前面我们讲了《nacos源码分析-服务注册(客户端)》 和 《nacos源码分析-服务注册(服务端)》,主要是讲的服务注册流程,本章节我们来讲服务心跳检测机制。
Spring Cloud OpenFeign 对 Netflix Feign 进行了封装,我们通常都使用Spring Cloud OpenFeign作为服务的负载均衡,本文章主要是探讨一下OpenFeign的初始化流程,以及生成代理类注入到Spring的过程
前面我们分析了Eureka的源码,接下来这一章我们来研究一下Ribbon,本篇文章主要是对Ribbon的相关组件做一个认识,以及它的初始化配置做一个分析。