一、简介什么是服务降级？当服务器压力急剧增大时，根据实际业务情况和流量，策略性地不处理或简单处理一些服务和页面，从而释放服务器资源，以保证核心交易的正常运行或高效运行。如果你还不明白，那么你可以举个例子：如果有很多人要给我付费，但是我的服务器除了付费服务之外还运行着其他服务，例如搜索和计划任务以及详情等。但是，这些不重要的服务占用了JVM大量的内存和CPU资源。为了收齐所有的钱（钱是目标），我设计了一个动态开关，把这些不重要的服务直接放在最外层。拒绝，这样处理后的后端处理服务会有更多的资源来收钱（收钱会更快），这是一个简单的服务降级的使用场景。2、服务降级主要用于哪些场景？当整个微服务架构的整体负载超过预设上限阈值或者即将到来的流量预计会超过预设阈值时，为了保证重要或者基础服务的正常运行，我们可以设置一些不重要或者非紧急的延迟使用或暂停使用服务或任务。3.核心设计3.1分布式交换机根据以上需求，我们可以搭建一个分布式交换机实现服务降级，然后集中管理交换机的配置信息。具体方案如下：ServiceDowngrade-DistributedSwitch3.2AutomaticDowngradeTimeoutDowngrade-主要配置超时时间，超时重试次数和机制，使用异步机制检测恢复失败次数Downgrade-主要是一些不稳定的API，当数量失败调用达到一定阈值，自动降级。还需要使用异步机制来检测回复。exception），可以直接降级限流降级——当超过限流时，可以使用临时屏蔽的方式进行短期屏蔽。如果太大导致系统崩溃，开发者会使用限流来限制访问量。当达到限流阈值时，后续请求将被降级；降级后的解决方案可以是：排队页面（引导用户在排队页面稍等片刻重试），缺货（直接告知用户缺货），错误页面（如果活动太火爆，稍后再试）。3.3配置中心微服务降级后的配置信息集中管理，然后通过可视化界面进行友好操作。配置中心与应用之间需要进行网络通信。因此，由于网络中断或网络重启等因素，可能导致配置推送信息丢失、重启或网络恢复后无法接受、变更不及时等，从而导致服务质量下降。中心需要实现以下特性，以保证配置变更尽可能的实现：服务降级——配置中心启动主动拉取配置——用于初始化配置（减少第一次定时拉取周期）发布订阅配置——使用来实现配置变更及时（可解决90%左右的配置变更）定时拉取配置——用于解决发布订阅失败或消失（可解决9%左右的发布订阅无效消息变更）离线文件缓存配置——用于暂时解决重启后无法连接配置中心的问题。可编辑的配置文件——用于直接编辑文件，实现配置的定义提供Telnet命令更改配置——用于解决配置中心故障，无法更改通用配置3.4新事务时的处理策略触发服务降级后再次到达，我们应该如何处理这些请求？从整体微服务架构来看，我们通常有以下几种常见的降级方案：writedowngrades——直接禁止写操作相关的服务请求。阅读降级——直接禁止相关服务请求。缓存降级——使用缓存降级一些经常读取的服务接口。那么对于降级处理我们通常采用以下处理措施：抛出异常并返回NULL调用Mock数据并调用Fallback处理逻辑4.高级特性我们已经为每个服务准备了一个降级开关，并通过了在线验证。感觉完全没问题。场景一：有一天，运营商举办活动，突然跑过来说流量快到上限了。有没有办法批量降级所有不重要的服务？开发人员看着发呆。这不是操作数据库。没有批处理操作。场景二：有一天，运营又乱了，说等会儿搞个活动，让我们提前把所有不重要的服务快速降级，开发很迷茫，怎么知道降级哪些服务？.反思：虽然实现了服务降级的功能，但是没有考虑实现过程中的体验。服务太多，不知道降级哪些服务，单次操作降级速度太慢...4.1分级降级当微服务架构出现不同程度的情况时，我们可以根据需要选择放弃以服务比较（即丢车保帅原则），进一步保障核心服务的正常运行。如果等到在线服务快要失效的时候，你再选择哪些服务应该降级，哪些服务不能降级，一一选择。但是，如果有成百上千的服务在线，肯定会在降级来不及之前就被拖垮。同时，在大促或限时抢购等活动之前，会有大量工作需要梳理。因此，建议在开发期间需要架构师或核心开发人员提前梳理。是否可以降级的初始评估值，即是否降级默认值。为了便于微服务架构中服务在批量操作中的降级，我们可以建立一个全局视角的服务重要性评估模型。如果条件允许，建议使用层次分析法（AHP）的数学模型。建模模型（或其他模型）进行定性和定量评估（绝对比架构师直接拍脑袋决定是否降级好很多倍，当然难度和复杂度会高很多，就是你需要一个数学建模人才），AHP的基本思想是人们对于一个复杂的决策问题的思考和判断过程基本一致。以下是个人给出的最终评价模型，可以设计为服务降级的评价参考模型：我们采用数学建模或者架构师直接拍脑袋的方式，结合服务是否可以降级的优先原则，并根据台风预警（均属于风暴预警级别）进行参考设计，微服务架构的所有服务可分为以下四种故障风暴级别：评估模型：蓝色风暴——表示非coreservicesneedtobedowngradedonasmallscaleYellowstorm——表示非核心服务需要在中等规模降级Orangestorm——表示非核心服务需要在大规模redstorm上降级——表示必须降级所有非核心服务可以用八个原则来划分服务：80%非核心服务+20%核心服务以上模型只是服务降级整体微服务架构的离子评估模型。对于特定的促销或限时抢购，建议针对特定的主题（不同主题的活动，因为依赖不同的服务，降级使用不同的比较合理）。当然模型可以用同一个，但是它的数据需要不同。最好建立一套模型库，然后在执行的时候只需要输入相关的服务就可以输出最终的降级方案，也就是在这次大促的时候出现蓝色风暴的时候输出需要降级的服务列表或者秒杀，当出现黄色风暴时，随时需要降级的服务列表...4.2降级权重微服务架构中有一个服务权重的概念，主要用于加载时的权重选择。同样，服务降级权重也类似，主要用于细粒度的服务降级选择Prioritization。所有的业务直接使用上面简单的四级划分方式统一处理。很明显，粒度太粗了，或者同级多个服务需要降级时，降级顺序是什么？即使我想要一个基于人工智能的自动降级，我怎么能有更细粒度的控制呢？基于上述基于AI的需求，我们可以为每个服务分配一个降级权重，以方便更智能地实现服务治理。其评价值也可以通过数学模型进行定性和定量评价，也可以由建筑师根据经验直接确定。五、总结与展望以上提供了半实践半理论的服务降级方案，用户可以根据自己公司的实际情况进行适当的选择，目前笔者还没有找到完整的已经实现的方案，但是可以建议有长期服务治理计划的大厂进行完整的解决方案的研究和实施，在未来人工智能和万物互联的时代会有更好的治理价值（个人观点）。小厂出于成本和价值的考虑，不建议使用如此复杂的方案，但可以实现分布式切换和简单分级降级的功能特性。本文主要以服务退化为核心来进行更理想的治理微服务架构，建议在数学领域使用合适的模型来实现定性和定量的分析和治理微服务，为未来的人工智能治理微服务（ArtificialIntelligenceGovernanceMicroService），简称AIGMS）提供程序支持。
