Spring Cloud

后端架构师图鉴 作者：星晴（当地小有名气，小到只有自己知道的杰伦粉） 忽略：我准备从博客园（ https://www.cnblogs.com/pingping-joe/ ）转移到公众号了！！！ 从2017年开始写博客到现在，经历了几家公司，碰到不少有趣的人，人也成长不少，褪去幼稚的面孔，只剩下越发后移的发际线；一路坎坷，唯一还在坚持的就只剩下写博客了，虽然不知道为什么坚持，但是感觉还不错。 今天第一天发公众号推文，作为搞java的，还是给大家准备了架构师的学习路线。当然如果大家都知道，可以忽略。 架构师学习路线大致分为五个部分： 互联网运维 Git，Maven，Gradle，jenkins，linux 框架源码分析 Spring , Mybatis 并发编程 并发包 性能调优 JVM调优，Mysql调优，Nginx调优，Tomcat调优 分布式框架 分布式服务治理：Dubbo, Zookeeper, SpringCloud-Alibaba,SpringCloud-NetFliex 分布式消息：RocketMq, RabbitMq, Kafka 分布式数据缓存：Redis 分布式数据存储：Sharding-sphere 分布式通信：Netty 分布式搜索引擎：ELK 如果想要完整的学习路线，请关注公众号，并且回复【1】，谢谢支持 本文分享自微信公众号 - 喜欢奶茶的星晴（code

1. Hystrix 断路器 Hystrix是一个用于处理分布式系统的延迟和容错的开源库,在分布式系统里,许多依赖不可避免的会调用失败, 比如超时,异常等,Hystrix能够保证在一个依赖出问题的情况下,不会导致整体服务失败,避免级联故障,以提高分 布式系统的弹性; "断路器"本身是一种开关装置,当某个服务单元发生故障之后,通过断路器的故障监控(类似熔断保险丝),向调用方 返回一个符合预期的,可处理的备选响应(FallBack),而不是长时间的等待或者抛出调用方无法处理的异常,这样就 保证了服务调用方的线程不会被长时间,不必要地占用,从而避免了故障在分布式系统中的蔓延,乃至雪崩。 1.1 服务熔断 熔断机制是应对雪崩效应的一种微服务链路保护机制; 当扇出链路的某个微服务不可用或者响应时间太长时,会进行服务的降级,进而熔断该节点微服务的调用,快速返回"错误" 的响应信息;当检测到该节点微服务调用正常后恢复调用链路; 新建microservicecloud-provider-dept-hystrix-8001 // 参考 microservicecloud-provider-dept-8001 // pom.xml <!-- hystrix --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId

参考借鉴：http://www.cnblogs.com/chry/p/7279856.html SpringCloud Netflix实现了断路器库的名字叫Hystrix. 在微服务架构下，通常会有多个层次的服务调用. 下面是微服架构下, 浏览器端通过API访问后台微服务的一个示意图： 一个微服务的超时失败可能导致瀑布式连锁反映，下图中，Hystrix通过自主反馈实现的断路器， 防止了这种情况发生。 图中的服务B因为某些原因失败，变得不可用，所有对服务B的调用都会超时。当对B的调用失败达到一个特定的阀值(5秒之内发生20次失败是Hystrix定义的缺省值), 链路就会被处于open状态， 之后所有所有对服务B的调用都不会被执行， 取而代之的是由断路器提供的一个表示链路open的Fallback消息. Hystrix提供了相应机制，可以让开发者定义这个Fallbak消息. open的链路阻断了瀑布式错误， 可以让被淹没或者错误的服务有时间进行修复。这个fallback可以是另外一个Hystrix保护的调用, 静态数据，或者合法的空值. Fallbacks可以组成链式结构，所以，最底层调用其它业务服务的第一个Fallback返回静态数据. 下面，进入正题，在之前的两HELLO WORLD服务集群中加入断路器， 防止其中一个Hello world挂掉后， 导致系统发生连锁超时失败。 1.

启动config-server，启动成功后就不需要在管了; 在config-client做些修改： 在使用的controller或service的类上加上一个注解 @RefreshScope 在pom中加入依赖： < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-actuator </ artifactId > </ dependency > 至此，准备工作完毕 接下来修改配置文件中的属性值， 无需重启congif-server，他会自动更新值； 接下来调用config-client的refresh方法， curl -X POST http://127.0.0.1:9020/refresh 在config-client控制台会有日志刷新，大意思是重新连接config-server，刷新取值；接下来就可以验证结果，期间无需重启服务； { "timestamp": 1545295648687, "status": 401, "error": "Unauthorized", "message": "Full authentication is required to access this resource", "path": "

最近看了一个开源项目RuoYi-Vue，感觉挺不错的 所以，你学到了啥？ emmm，学会了前后端分离，多数据源运用？好像没其它了… 嗐，这么好的一个开源项目你就学了这点东西？ 你有啥好建议呀，怎么学习开源项目？ 我给你几个主流项目笔记，是一个大神整理和分享的，你可以参考学习，提高效率！ 项目一： cloud-platform 学习重点： 服务鉴权中心 用户间鉴权 服务之间鉴权 springcloud组件大回顾 图文笔记： 视频讲解： 项目二： Guns 学习重点： map+warpper模式 Api数据传输安全 数据范围限定 多数据源、jwt 图文笔记： 视频链接： 项目三： bootshiro 学习重点： restful接口设计 前后端分离 数据传输动态秘钥加密 jwt过期自动刷新 图文讲解： 项目四： vueblog 学习重点： 如何搭建一个脚手架 前后端分离如何对接 如何开发Vue+element-ui项目 从0到1开发一个项目的完整教程 图文讲解： 视频讲解： 项目五： renren-fast 学习重点： 项目技术框架分析 前后端分离-token机制 安全防范模块--预防xss攻击与sql注入 多数据源的使用分析总结 如何Docker部署项目 图文文档目录： 项目六： miaosha 学习重点： 秒杀系统场景特点与设计要点分析 高并发优化方向 秒杀限流处理

涉及平台：平台管理（包含自营店面）、商家端（PC端、手机端）、买家平台（PC端、H5/公众号、小程序、APP端（IOS/Android）、微服务平台（业务服务） 核心架构：Spring Cloud、Spring Boot、Mybatis、Redis、SFTP 前端框架：VUE、Uniapp、Bootstrap/H5/CSS3、IOS、Android、小程序 核心思想：分布式、微服务、云架构、模块化、原子化、持续集成、集群部署、前后端分离、支持阿里Docker 开发模式：前后端分离、微服务开发 社交模式：VR全景虚拟现实、直播带货、短视频带货、分销分润、代跑腿配送等 源码来源 来源： oschina 链接： https://my.oschina.net/u/3613013/blog/4952492

许久之前便听到了springcloud如雷贯耳的大名，但是不曾谋面，其主要应用于微服务的相关架构。笔者对微服务并不是很了解，但其既然比较出众，遂也稍微接触研究下 springcloud特性 springcloud作为spring团队的微服务架构，其有如下的特性(摘自官方文档) Distributed/versioned configuration(分布式/版本化配置) Service registration and discovery(服务注册与发现) Routing(路由) Service-to-service calls(服务间远程调用) Load balancing(负载均衡) Circuit Breakers(熔断器) Distributed messaging(分布式消息) 应该就是微服务的相关特性，笔者不对上述的概念进行阐述，读者可相应的查阅相关 文档 springcloud config springcloud板块下有很多的分支，根本看不过来，就挑笔者比较感兴趣的配置管理 springcloud config 作为分析的入口把。具体的使用以及概念本文就不展开了，在官方文档上都有，笔者喜欢从源码角度看下springcloud是如何整合springboot进行扩展的 MAVEN依赖 根据官方的例子，笔者最后还是通过IDEA开发工具引入 Spring Initializr

Spring Cloud是很多组件的集合，Spring将常用的技术框架进行包装和整合，如mybatis zookeeper rabbitmq redis等等，还有一些科技公司贡献出来的一些经过生产环境验证的组件如奈飞公司贡献出的eureke（服务发现） Hystrix（监控与隔离） Feign（声明式服务调用） Ribbon（负载均衡） Zuul（网关） 等等，详情移步官网 SpringCloud Spring Cloud是目前比较流行的微服务开发框架，可以与容器技术如docker一起使用，提高生产力。但是组件过多也有一定的学习曲线，而且适合大公司的架构不见得适合我们的业务，要根据实际情况灵活运用。 Spring Cloud Config是基于git/svn仓库来管理配置，然后有一个ConfigServer来负责拉取配置，ConfigClient是使用配置的应用，比如现在有很多微服务应用，如订单管理，用户管理，地址管理，库存管理等等，在这些微服务的pom中增加ConfigClient就可以自动从ConfigServer拉取配置。我们还希望配置更新之后可以实时获取，这时候需要用到spring cloud中的bus组件，bus其实就是基于amqp的一个消息总线，spring对rabbitmq和kafka支持的比较好。常见的场景是： 1、更改配置 2、push到远程仓库 3

微服务化的基石——持续集成 转载： 刘超 http://dockone.io/article/3660 一、持续集成对于微服务的意义：拆之前要先解决合的问题 在很多微服务化的文章中，很少会把持续集成放在第一篇，因为大多数的文章都会将如何拆的问题，例如拆的粒度，拆的时机，拆的方式。 为什么需要拆呢？因为这是人类处理问题的本质方式：将一个大的复杂问题，变成很多个小问题解决。 所以当一个系统复杂到一定程度，当维护一个系统的人数多到一定程度，解决问题的难度和沟通成本大大提高，因而需要拆成很多个工程，拆成很多个团队，分而治之。 然而当每个子团队将子问题解决了，整个系统的问题就解决了么？你可以想象你将一辆整车拆成零件，然后再组装起来的过程，你就可以想象拆虽然不容易，合则更难，需要各种标准，各种流水线，才能将零件组装称为车。 我们先来回顾一下拆的过程。 最初的应用大多数是一个单体应用 一个Java后端，后面跟一个数据库，基本上就搞定了。 随着系统复杂度的增加，首先Java程序需要做的是纵向的拆分。 首先最外面是一个负载均衡，接着是接入的nginx，做不同服务的路由。 不同的服务拆成独立的进程，独立部署，每个服务使用自己的数据库和缓存，解决数据库和缓存的单点瓶颈。 数据库使用一主多从的模式，进行读写分离，主要针对读多写少的场景。 为了承载更多的请求，设置缓存层

转载请标明出处： https://www.fangzhipeng.com 本文出自 方志朋的博客 在高并发的系统中，往往需要在系统中做限流，一方面是为了防止大量的请求使服务器过载，导致服务不可用，另一方面是为了防止网络攻击。 常见的限流方式，比如Hystrix适用线程池隔离，超过线程池的负载，走熔断的逻辑。在一般应用服务器中，比如tomcat容器也是通过限制它的线程数来控制并发的；也有通过时间窗口的平均速度来控制流量。常见的限流纬度有比如通过Ip来限流、通过uri来限流、通过用户访问频次来限流。 一般限流都是在网关这一层做，比如Nginx、Openresty、kong、zuul、Spring Cloud Gateway等；也可以在应用层通过Aop这种方式去做限流。 本文详细探讨在 Spring Cloud Gateway 中如何实现限流。 常见的限流算法 计数器算法 计数器算法采用计数器实现限流有点简单粗暴，一般我们会限制一秒钟的能够通过的请求数，比如限流qps为100，算法的实现思路就是从第一个请求进来开始计时，在接下去的1s内，每来一个请求，就把计数加1，如果累加的数字达到了100，那么后续的请求就会被全部拒绝。等到1s结束后，把计数恢复成0，重新开始计数。具体的实现可以是这样的：对于每次服务调用，可以通过AtomicLong#incrementAndGet(