hystrix

几点说明 1、本系列Spring Cloud的博客参考了方志朋所著《深入理解Spring Cloud与微服务构建》； 2、大家如果想更加深入的理解Spring Cloud 建议多实战、多看书； Dubbo简介 介绍 Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。 Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力： 面向接口的远程方法调用:封装了长连接的NIO框架，例如:Netty、Mina等等； 智能容错和负载均衡； 服务自动注册和发现； 集成Apache的Zookeeper组件，用于用户的注册与发现； Dubbo框架的运行流程如下： 服务提供者注册进入服务注册中心； 服务消费者订阅服务； 服务消费者发现服务； 服务消费者通过远程调度来找到服务提供者进行服务的消费； 服务消费者和服务提供者定时发送心跳数据到服务监控中心用于记录调用次数和时间； Dubbo的优点： 连通性： 服务注册中心、服务提供者、服务消费者、服务监控中心都是长连接； 健壮性： 监控中心宕机不会影响其他的服务的正常进行，服务器集群配置的话，任意一个服务的宕机都不会影响整体的服务的运行状况； 伸缩性： 可以动态增减注册中心与服务的实例数量； 升级性： 服务器集群升级，不会对现有架构造成压力

文中源码基于 Spring Cloud Finchley.SR1 、Spring Boot 2.0.6.RELEASE . 本文学习了Hystrix熔断器的原理、配置和源码，包含滑动窗口、状态变化等。 简介 circuit-breaker： circuit表示电路，大家译为熔断器非常精准。 回想起小时候，家里保险丝突然被烧断，需 手工更换一根新的保险丝 ；后来，保险丝被取代，电流过大时会跳闸， 闸拉上去后立马恢复供电 ；等到上大学时，只要打开功率高一点的电吹风，砰的一声就断电，但过10分钟就 自动来电 。在电流过大时，通过熔断机制以保护电路和家电。 Hystrix 属于上面的第三种， 一种自动恢复的智能熔断器 ，区别在于它保护的是系统，且判断 “电流过大” 的方式是： 不断收集请求指标信息(sucess、failure、timeout、rejection)，当达到设定熔断条件时(默认是请求失败率达到50%)进行熔断。 在 Spring Cloud 源码学习之 Hystrix Metrics 收集 一文中，学习了 Metrics 收集，这是上文的图。 Hystrix Command 执行过程中，各种情况都以事件形式发出，再封装成特定的数据结构，最后汇入到事件流中(HystrixEventStream)。事件流提供了 observe() 方法，摇身一变，事件流把自己变成了一个数据源

前言 《复仇者联盟4》(下文《妇联4》) 将于4月24号上映了，漫威迷们是不是迫不及待了。我虽然不是漫威迷，没有看过相关漫画，但是电影确实一步都不落。不过我在想一个问题：假如《妇联4》是一个微服务，那么电影院就是一个应用。在这个微服务如此火爆的前提下，影院如何做好管理呢？以上是背景。 影院开张 老王开了一家影院，刚开始影院规模很小，只有一个售票员小李。老王将《妇联4》即将上映的广告打出去之后，来咨询的人络绎不绝。这下小李不干了：老板，这么多人咨询已经打乱了我的正常工作了，影院这么多电影我哪记得住他们什么时候上映啊。老王犯了愁。小李说：老板，我给你引荐一个人吧，他们公司专门做这个业务的。他叫 Eureka 。 服务注册和发现-电影的上映和下架 Eureka 来了之后首先在影院装了一个大显示屏幕。老板告诉 Eureka ：我们要准备上映《妇联4》了。于是 Eureka 便把《妇联4》上线了。显示屏幕展示着最近上线的电影。这样来电影院看电影的观众们就不用在咨询售票员了。显示屏幕如下： 客户端负载均衡-观众去哪个厅观看电影？ 小李开开心心的工作者，突然 8001 厅的扫地大妈不乐意了。：小李你咋回事啊，怎么我这个厅的人这么多，8002厅的人那么少，是要累死我啊。老板见了：哎呀，赵大妈您别着急，您看我这不是帮你招了个人吗，以后保证刘大妈的工作量和您保持一致。：赵大妈您好，我是 Ribbon

个人背景： 开发4年，坐标杭州 金九银十已经过去了，写这篇文章的目的就是与大家谈谈面试方面的经验，心得，就个人方面而言，我之前做过的很多的工作都是面试造核弹，工作拧螺丝。但是不要因为自己是个拧螺丝的就不学哪些难啃的技术。当项目出问题的时候，就是考验技术沉淀的时候。我也迷茫过好长一段时间，学了忘，学了没用， 到底应该怎么成长才能成为一个别人眼中的大神，大牛。 关于面试，关于技术的，我只能说有些路只能靠自己去走，没人可以帮到自己，哪怕偶尔帮一到两次，但是技术的路这么长，总归需要自己独自成长的。 我们遇到每一次面试我们都应该认真对待，有机会一定要多面试，面试是一种非常锻炼自己的方式，不要错过任何—场面试，你 在面试的过程中，和对方讲自己所学，通过对方提问弥补自己的不足，这对自己提升会非常大。 下面我会为大家分享一下我最近的一次面试经历希望对大家有所帮助。总结的不全的地方也请各位海涵，欢迎在评论区留言指正。 下面就是我这次某C轮金融科技公司的面试经历了，总共是四面： 一面（技术面） 重点聊了Java各种集合的实现原理，以及使用场景，主要包括不限于，ArrayList，LinkedList，HashMap，HashSet，TreeMap 线程池的实现原理，线程池中的等待任务只有一个队列，如果线程池中的线程比较多，竞争会比较大，怎么解决？ Java中实现高并发的几种策略(COW, cas, 锁

随着微服务的流行，服务之间的调用可能变得越来越复杂，一个业务流程可能需要调用五六个甚至更多服务，这就会导致，假设某个服务出现问题，严重可能出现服务器负载过高，导致服务雪崩的现象。 因此为了防止此现象的发生，决定了解下服务熔断机制，根据自身业务的需求，将其应用到服务中。 什么是熔断：可以联想到我们家里的电表的保险丝，当电压负载过高后，保险丝熔断，确保家里的电器等其他安全。 在我们的服务中，当我们当用第三方服务时失败到达一定的失败次数或者超时等问题时，我们将熔断机制融入到我们的客户端调用方，当失败次数等达到阈值时，开启熔断器，及时进行弥补处理，或者给上层友好提示。 在熔断器中有三种状态： 关闭：让请求通过的默认状态。如果请求成功/失败但低于阈值，则状态保持不变。可能出现的错误是超过最大并发数和超时错误。 打开：当熔断器打开的时候，所有的请求都会被标记为失败；这是故障快速失败机制，而不需要等待超时时间完成。 半开：定期的尝试发起请求来确认系统是否恢复。如果恢复了，熔断器将转为关闭状态或者保持打开 hystrix内部处理逻辑 go-hystrix example: package main import ( "fmt" "github.com/afex/hystrix-go/hystrix" "net/http" "time" ) func main() { hystrix

在微服务架构里，服务与服务之间的调用一般用feign就可以实现，它是一种可视化的rpc，并且集成了ribbon的负载均衡能力，所以很受欢迎。 授权服务 在授权服务里，用户通过用户名密码，或者手机和验证码等方式登陆之后，在http头里会有 授权 的标识，在客户端调用时，需要添加当时有效的token才可以正常访问被授权的页面。 Content-Type:application/json Authorization:Bearer d79c064c-8675-4047-a119-fac692e447e8 而在业务层里，服务与服务之间使用feign来实现调用，而授权的代码我们可以通过拦截器实现，在feign请求之前，把当前服务的token添加到目标服务的请求头就可以了，一般是这样实现的。 /** * 发送FeignClient设置Header信息. * http://www.itmuch.com/spring-cloud-sum/hystrix-threadlocal/ * Hystrix传播ThreadLocal对象 */ @Component public class TokenFeignClientInterceptor implements RequestInterceptor { /** * token放在请求头. * * @param requestTemplate 请求参数 *

1. 导语 近期公司孵化了一个互联网产品，随着业务发展，产品运营后用户数据量（过亿）、业务数据量（过100亿）较大，技术团队配合产品、运营快速定制化开发， 还要考虑产品涉及的资金安全、消息的及时性、业务的制动化处理，我们选择鸿鹄cloud分布式云架构平台作为公司产品核心企业架构。 2. 产品平台规划 微服务注册中心（分布式集群部署）、微服务配置中心（分布式集群部署）、服务网关平台（分布式集群部署）、 微服务监控平台、SSO单点登录平台（分布式集群部署）、微服务相关组件（分布式集群部署）、后台管理平台、 定时调度平台（按照业务分库、分表部署）、业务微服务（分布式集群部署、超过20个微服务）、MQ消息中间件业务平台（分布式集群部署） MySql主从、读写分离（高可用部署）、Redis分布式缓存（高可用） 3. 源码结构： commonservice 通用服务：对spring Cloud组件的使用&封装，是一套完整的针对于分布式微服务云架构的解决方案 Component 通用组件：对系统常用组件的封装，包括对象存储包、工具包、缓存包、MQ相关、API调用包的封装等。 SAAS微服务 SAAS服务：针对通用业务如：会员、消息、支付等 快速开发管理平台 企业级快速开发平台，封装了用户、角色、权限、数据字典、菜单、日志、机构、部门等管理功能，针对于业务服务做了统一管理。 4. 分布式、微服务

前言 Spring Cloud是微服务架构开发的完美解决方案，它是一套分布式服务治理的框架，专注于全局微服务协调整理，可以将各个单独的微服务整合并管理起来，为各个微服务之间提供配置管理、服务发现、断路器、路由、消息代理、事件总线、决策竞选、分布式会话等集成服务。 Spring Cloud本身不提供具体功能性的操作，更专注于服务之间的通信、熔断和监控等，因此就需要很多组件来支持完整功能。 开发、部署和运营云应用程序应该像本地应用程序一样简单。这应该是任何云平台、库或工具背后的管理原则。Spring Cloud可以轻松地为云开发JVM应用程序。 本文将介绍Spring Cloud并帮助开发人员掌握其功能。 本文首先介绍如何配置Spring Cloud服务器并运行Eureka服务器以启用服务注册和发现;然后再深入剖析与负载均衡和断路相关的技术，包括利用Feign客户端的所有功能; 最后讨论和研究高级主题，包括如何为Spring Cloud实现分布式跟踪解决方案并构建消息驱动的微服务架构。 本文将带大家从零开始一步步精通springcloud微服务架构，能够灵活运用到工作中，不断地提升自己的技术深度和宽度，让自己变得更有价值，也希望本文能够帮助到大家的学习！！ 目录 主要内容 本文详细阐述了与Spring Cloud微服务框架相关的基本解决方案，主要包括微服务简介、使用微服务的Spring

原文：https://4m.cn/hXBqK 我们先认识一下SpringCloud的各个组件，然后知其所以然。 原理讲解前，先看一个最经典的业务场景，如开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 如上，微服务的应用场景和核心竞争力： 降低耦合：每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。 选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。 容错机制：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好

前言 ❝ Hello，everybody，我是asong，今天与大家一起来聊一聊面试中几个常见的缓存问题。为什么会突然想做一篇这个文章呢，今天翻了一下我当初准备面试时整理的一些资料，发现缓存在面试中占比还是很高的，当初为了面试也是背了好久的，不过因为都是背的，现在也有点忘了，今天就想着好好整理一下这一部分，好好记录一下。因为自己能力有限，这一篇主讲通俗易懂，不涉及太难的缓存使用场景。好啦，我们开始吧。 ❞ 缓存应用 缓存在我们平常的项目中多多少少都会使用到，缓存使用的使用场景还是比较多的，缓存是分布式系统中的重要组件，主要解决高并发、大数据场景下，热点数据访问的性能问题。提高性能的数据快速访问。一提到缓存，这些是我们都能想到的一些缓存应用场景，但是我们是不太清楚缓存的本质思想是什么的。缓存的基本思想就是我们非常熟悉的空间换时间。缓存也并不是那么的高大上，虽然他可以为系统的性能进行提升。缓存的思想实际在操作系统或者其他地方都被大量用到。比如 「CPU Cache 缓存的是内存数据用于解决 CPU 处理速度和内存不匹配的问题，内存缓存的是硬盘数据用于解决硬盘访问速度过慢的问题。」 「再比如操作系统在 页表方案 基础之上引入了 快表 来加速虚拟地址到物理地址的转换。我们可以把快表理解为一种特殊的高速缓冲存储器（Cache）。」 上面简单介绍了缓存的基本思想，现在回到业务系统来说：*