过载保护

转载自 http://blog.csdn.net/z69183787/article/details/54667579 服务熔断（过载保护、断路保护）和服务降级（不要太在意名称，理解意思就行） 伴随着 微服务 架构 被宣传得如火如荼，一些概念也被推到了我们面前（管你接受不接受），其实大多数概念以前就有，但很少被提的这么频繁（现在好像不提及都不好意思交流了）。想起有人总结的一句话，微服务架构的特点就是：“一解释就懂，一问就不知，一讨论就吵架”。 其实对老外的总结能力一直特别崇拜，Kevin Kelly、Martin Fowler、Werner Vogels……，都是著名的“演讲家”。正好这段时间看了些微服务、容器的相关资料，也在我们新一代产品中进行了部分实践，回过头来，再来谈谈对一些概念的理解。 今天先来说说“ 服务熔断 ”和“ 服务降级 ”。为什么要说这个呢，因为我很长时间里都把这两个概念同质化了，不知道这两个词大家怎么理解，一个意思or有所不同？现在的我是这么来看的： 在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。相应的，服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。 大家都见过女生旅行吧，大号的旅行箱是必备物

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 服务器过载保护（上篇）——过载介绍 http://wetest.qq.com/lab/view/?id=69 1 何为过载 “ 过载 ” 一词，在海量服务的后台开发中，基本都会遇到。何为过载，即当前负载已经超过了系统的最大处理能力。例如，系统每秒能够处理的请求是 100 个，但实际每秒的请求量却是 1000 个，就可以判定系统出现了过载。 过载的定义看似简单，但却是处理过载问题的关键。对于任何其他问题，同样得抓住问题的本质，方可不偏离问题核心，万变而不离其宗。 2 过载后果 “ 过载 ” 的出现，会导致部分服务不可用，如果处置不当，极有可能引起服务完全不可用，乃至雪崩。 我们的系统中，由于是单线程状态机的处理模式，顺序处理所有链接的缓冲区消息，当出现处理能力的下降或者请求量大幅增加，导致处理能力小于请求量的情况下，消息就会在系统缓冲区中堆积，造成消息处理的延迟会持续增加，在正式环境中，链接数目较多，系统缓冲区较大，最终会导致消息处理延迟大到不可接受的程度，最终会导致处理的都是无效消息，造成服务不可用。 当然具体的业务需要具体的分析，把握住问题的影响，才能够做到一切尽在掌握，根据 “ 墨菲定律 ” ，通常对后果的判断不应过于乐观，谨慎行事、考虑充分才能够做到胸有成竹。 3 过载原因 “ 过载 ” 的出现

原文： https://blog.csdn.net/libaineu2004/article/details/80554870 ---------------------------------------------------------- Kiev框架简介 kiev是魅族科技推送平台目前使用的Linux-C++后台开发框架。从2012年立项起，先后由多位魅族资深架构师、资深C++工程师倾力打造，到本文写就的时间为止，已经在推送平台这个千万用户级的大型分布式系统上经历了近5年的考验。如今Kiev在魅族推送平台中，每天为上百个服务完成数百亿次RPC调用。 kiev作为一套完整的开发框架，是专为大型分布式系统后台打造的C++开发框架，由以下几个组件组成： RPC框架(TCP/UDP) FastCGI框架 redis客户端(基于hiredis封装) mysql客户端(基于mysqlclient封装) mongodb客户端 配置中心客户端(Http协议, 基于curl实现) 基于zookeeper的分布式组件(服务发现、负载均衡) 日志模块 状态监控模块 核心模块是一个开源的`CSP并发模型`协程库(libgo) 并发模型 Kiev采用了很先进的CSP开发模型的一个变种(golang就是这种模型)，这一模型是继承自libgo的。