hystrix

软件工程领域存在一个共识：维护代码所花费的时间要远多于写代码。而整个代码维护过程中，最惊心动魄与扣人心弦的部分，莫过于问题排查（Trouble-shooting）了。特别是那些需要 7x24 小时不间断维护在线业务的一线服务端程序员们，大大小小的问题排查线上救火早已成为家常便饭，一不小心可能就吃成了自助餐 —— 竖着进躺着出，吃不了也兜不住。 本文分享作者在服务端问题排查方面的一些经验，包括常见问题、排查流程、排查工具，结合实际项目中发生过的惨痛案例进行现身说法。 一 、问题排查 1、常见问题 Know Your Enemy：知己知彼，百战不殆。 日常遇到的大部分问题，大致可以归到如下几类： 逻辑缺陷：e.g. NPE、死循环、边界情况未覆盖。 性能瓶颈：e.g. 接口 RT 陡增、吞吐率上不去。 内存异常：e.g. GC 卡顿、频繁 FGC、内存泄露、OOM。 并发/分布式：e.g. 存在竞争条件、时钟不同步。 数据问题：e.g. 出现脏数据、序列化失败。 安全问题：e.g. DDoS 攻击、数据泄露。 环境故障：e.g. 宿主机宕机、网络不通、丢包。 操作失误：e.g. 配置推错、删库跑路（危险动作，请勿尝试..）。 上述分类可能不太完备和严谨，想传达的点是：你也可以积累一个这样的 checklist，当遇到问题百思不得其解时，耐心过一遍，也许很快就能对号入座。 2、排查流程

项目名称 piggymetrics 转发+关注，然后私信回复关键字 “项目”即可获得《 piggymetrics 》的源码地址 项目简介 这是一个教程项目，演示了使用Spring Boot，Spring Cloud和Docker的微服务架构模式。顺便说一下，拥有漂亮的用户界面。 功能服务 PiggyMetrics被分解为三个核心微服务。它们都是围绕某些业务领域组织的可独立部署的应用程序。 开户服务 包含一般用户输入逻辑和验证：收入/支出项目，储蓄和账户设置。 统计服务 对主要统计参数执行计算，并捕获每个账户的时间序列。数据点包含以标准化为基础货币和时间段的值。此数据用于跟踪账户生命周期中的现金流动态。 通知服务 存储用户的联系信息和通知设置（如提醒和备份频率）。计划工从其他服务收集所需的信息，并将电子邮件发送给订阅的客户。 笔记 每个微服务都有自己的数据库，因此无法绕过API并直接访问持久性数据。 在这个项目中，作者将MongoDB用作每个服务的主数据库。具有多语言持久性体系结构（选择最适合服务需求的db类型）也可能是有意义的。 服务到服务的通信已大大简化：微服务仅使用同步REST API进行通话。实际系统中的常见做法是使用交互样式的组合。例如，执行同步GET请求以检索数据，并通过消息代理使用异步方法进行创建/更新操作，以使服务和消息分离。但是，这将我们带到了最终的一致性世界。

1、什么是 Spring Cloud？ Spring cloud 流应用程序启动器是 于 Spring Boot 的 Spring 集成应用程序，提供与外部系统的集成。Spring cloud Task，一个生命周期短暂的微服务框架，用于快速构建执行有限数据处理的应用程序。 2、使用 Spring Cloud 有什么优势？ 使用 Spring Boot 开发分布式微服务时，我们面临以下问题 （1）与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。 （2）服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。 （3）冗余-分布式系统中的冗余问题。 （4）负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。 （5）性能-问题 于各种运营开销导致的性能问题。 （6）部署复杂性 evops 技能的要求。 3、服务注册和发现是什么意思？Spring Cloud 如何实现？ 当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能 会发生变化。手动更改属性可能会产生问题。Eureka

SpringCloud的Hoxton版本，和之前的版本相比，用新的组件替换掉了原来大部分的组件，老的组件现在处于 停更不停用 的状况。 详情见下图（ × 的表示之前的组件，现在停更了的； √ 的表示新的替换后的组件）： 描述： 服务注册中心： Eureka：官方停止更新，并且已经有更好的替代产品了，可以使用，但是官方已经不建议使用了（重度患者）。 Zookeeper：某些老系统，以前是用的Zookeeper + Dubbo，后来做技术升级，结果发现SpringCloud的Eureka停更了，然后就用了最少的技术切换，那么就用了Zookeeper做注册中心。 Consul：go语言开发的，也是一个优秀的服务注册框架，但是使用量较少，风头都被Nacos抢了。 Nacos：来自于SpringCloudAlibaba，在企业中经过了百万级注册考验的，不但可以完美替换Eureka，还能做其他组件的替换，所以强烈建议使用，是学习的重点。 服务调用： Ribbon：也进入了维护状态，停止更新了，但是Spring官方还在使用（轻度患者）。 LoadBalancer：Spring官方推出的一个新的组件，打算逐渐取代掉Ribbon，但是现在还处于萌芽状态。 服务调用2： Feign：Netflix 公司产品，也停止更新了。 OpenFeign：Spring社区等不了Netflix更新了

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ SpringCloud微服务 微服务的模式和形式我在前面已经进行部分的提及，但是一直没落实到技术层面，这段时间我也在次研究了一下微服务，下面我先贴出SpringCloud整体涉及的结构： 上面展示的这些是SpringCloud整体的结构 先对这些空间做一个初步的介绍： Ribbon，客户端负载均衡，重试机制。 Hystrix，客户端容错保护，服务熔断、请求缓存、请求合并、依赖隔离。 Feign，声明式服务调用，本质上就是Ribbon+Hystrix（优化代码，避免直接使用RestTemplate的混乱）Bus，消息总线，配合Config仓库修改的一种Stream实现，独自启动不需要依赖其它组件。 Eureka，服务注册中心，特性有失效剔除、服务保护。 Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。Zuul，API服务网关，功能有路由分发和过滤。还有其它服务空间，包括configuration等等 那么什么是注册中心呢？ 注册中心，是服务的提供者发布自己服务的地方，传统手写的restful接口提供的服务会涉及到服务发布者的端口IP等等，通过注册中心可以直接调用已经发布在上面的服务，只需要通过服务名即可 从图中可以看出

一、sentinel是什么 sentinel的官方名称叫分布式系统的流量防卫兵。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。在Spring Cloud项目中最开始我们使用的是Hystrix，目前已停止更新了。现在Spring Cloud官方推荐的是rensilience4j。当然还有我们今天学习的sentinel。 Sentinel 具有以下特征: 丰富的应用场景 ：Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。 完备的实时监控 ：Sentinel 同时提供实时的监控功能。您可以在控制台中看到接入应用的单台机器秒级数据，甚至 500 台以下规模的集群的汇总运 行情况。 广泛的开源生态 ：Sentinel 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合。您只需要引入相应的依赖并进行简单的配置即可快速地接入 Sentinel。 完善的 SPI 扩展点 ：Sentinel 提供简单易用、完善的 SPI 扩展接口。您可以通过实现扩展接口来快速地定制逻辑。例如定制规则管理、适配动态数据源等。 二、sentinel实现限流 2.1

本文源码： GitHub·点这里 || GitEE·点这里 一、流量控制 1、基本概念 流量控制的核心作用是限制流出某一网络的某一连接的流量与突发，使这类报文以比较均匀的速度流动发送，达到保护系统相对稳定的目的。通常是将请求放入缓冲区或队列内，然后基于特定策略处理请求，匀速或者批量处理，该过程也称流量整形。 流量控制的核心算法有以下两种：漏桶算法和令牌桶算法。 2、漏桶算法 基础描述 漏桶算法是流量整形或速率限制时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。 漏桶算法基本思路：请求（水流）先进入到容器（漏桶）里，漏桶以一定的速度出水，这里就是指流量流出的策略，当流量流入速度过大容器无法承接就会直接溢出，通过该过程限制数据的传输速率。 核心要素 通过上述流程，不难发现漏桶算法涉及下面几个要素： 容器容量 容器的大小直接决定能承接流量的多少，容器一但接近饱和，要么溢出，要么加快流速； 流出速度 流量流出的速度取决于服务的请求处理能力，接口支撑的并发越高，流速就可以越大； 时间控制 基于时间记录，判断流量流出速度，控制匀速模式， 注意：需要一个基本的判定策略，漏桶算法在系统能承接当前并发流量时，不需要启用。 3、令牌桶算法 基础描述

前言 随着微服务的流行，单体应用被拆分成一个个独立的微进程，可能一个简单的请求，需要多个微服务共同处理，这样其实是增加了出错的概率，所以如何保证在单个微服务出现问题的时候，对整个系统的负面影响降到最低，这就需要用到我们今天要介绍的线程隔离。 线程模型 在介绍线程隔离之前，我们先了解一下主流容器，框架的线程模型，因为微服务是一个个独立的进程，之间的调用其实就是走网络io，网络io的处理容器如tomcat，通信框架如netty，微服务框架如dubbo，都很好的帮我们处理了底层的网络io流，让我们可以更加的关注于业务处理； Netty Netty是基于java nio的高性能通信框架，使用了 主从多线程模型 ，借鉴 Netty系列之 Netty线程模型 的一张图片如下所示： 主线程负责认证，连接，成功之后交由从线程负责连接的读写操作，大致如下代码： EventLoopGroup bossGroup = new NioEventLoopGroup( 1 ); EventLoopGroup workerGroup = new NioEventLoopGroup(); ServerBootstrap b = new ServerBootstrap(); b. group (bossGroup, workerGroup); 主线程是一个单线程，从线程是一个默认为cpu*2个数的线程池

在Spring Cloud微服务体系中，由于限流熔断组件Hystrix开源版本不在维护，因此国内不少有类似需求的公司已经将眼光转向阿里开源的Sentinel框架。而以下要介绍的正是作者最近两个月的真实项目实践过程，这中间被不少网络Demo示例级别水文误导过，为了以正视听特将实践过程加以总结，希望能够帮到有类似需要的朋友！(PS：此文有点长，看下概念部分后可以点击关注+收藏，以备需要) 一、Sentinel概述 在基于Spring Cloud构建的微服务体系中，服务之间的调用链路会随着系统的演进变得越来越长，这无疑会增加了整个系统的不可靠因素。在并发流量比较高的情况下，由于网络调用之间存在一定的超时时间，链路中的某个服务出现宕机都会大大增加整个调用链路的响应时间，而瞬间的流量洪峰则会导致这条链路上所有服务的可用线程资源被打满，从而造成整体服务的不可用，这也就是我们常说的“ 雪崩效应 ”。 而在微服务系统设计的过程中，为了应对这样的糟糕情况，最常用的手段就是进行 ”流量控制“ 以及对网络服务的调用实现 “熔断降级” 。所谓流量控制就是根据服务的承载能力指定一个策略，对一定时间窗口内的网络调用次数进行限制，例如1s内某个服务最多只能处理10个请求，那么1s内的第11+的请求会被被限制丢弃；而熔断降级的概念则是说在A服务→B服务调用过程中

缓存雪崩 : 缓存同一时间大面积的失败,所以后面的请求都会落到数据库上,造成数据库短时间内承受大量请求而崩掉 解决方案: 事前:尽量保证整个redis集群的高可用性,发现机器宕机尽快补上 事中:本地ehcache缓存+hystrix限流&降级,避免MySQL崩掉 事后:利用redis持久化机制保存的数据尽快恢复缓存 缓存穿透 : 简答点说就是大量请求的Key根本不存在于缓存中,导致请求直接到了数据库上,根本没有经过缓存这一次层. 解决方案: 最基本的就是首先做好参数校验,一些不合法的参数请求直接抛出异常信息返回给客户端.比如查询的数据库id不能小于0,传入的邮箱格式不对的时候直接返回错误消息给客户端等等. 来源： oschina 链接： https://my.oschina.net/u/4234912/blog/4496696