在一个由众多服务组成的系统中，确保系统在发生故障时能够以可控的方式降级是至关重要的。而这种降级不仅仅是技术手段上的熔断与降级，更需要考虑整体的可降级设计，涉及到业务层面的决策。
很多产品在面临故障时采取直接挂维护页、整体下线的策略，虽然简单，但是也显得过于粗暴。这种做法不仅会导致业务损失，还可能对产品的品牌声誉造成严重影响，甚至可能引发公司破产。特别是在金融领域，一些经营状况良好的企业也因为没有可降级的设计，在面临局部Bug或恶意攻击时系统整体瘫痪，导致用户恐慌和挤兑，进而影响了企业的生存状况。
企业规模较大，更不能忽视系统停运可能带来的资金流动性问题。因此，技术的服务于业务需要提供强有力的保障，而业务设计中的可降级方案就显得尤为关键。技术和业务相辅相成，为业务提供保障的同时，也能够为公司的生死存亡提供一定的保障。
在面对Bug时，我们虽然无法完全避免其发生，但可以通过降低Bug的发生几率和减少其影响范围来进行控制。前者多涉及到对工程质量的要求，而后者则需要我们认真思考系统架构的降级方案。在系统设计中，我们应当谨慎考虑如何在发生故障时，以可控的方式对系统进行降级，保障核心业务的正常运行，同时最小化用户和公司的损失。
在考虑系统降级的场景时，我们可以将其主要分为以下两种情况：
严重Bug导致的故障： 当某个接口或服务发生了严重的Bug时，我们需要考虑如何应对。一种情况是，如果该服务有适应当前生产系统的早期版本，我们可以选择执行回滚操作，将系统恢复到一个稳定的状态。另一种情况是，如果无法适配早期版本，就需要考虑降级操作。在这种情况下，我们可能需要关闭依赖于出问题接口或服务的上层业务，以确保整体系统的稳定性。
并发压力过高导致系统负载问题： 当系统面临并发压力过高、负载问题严重影响业务操作时，我们通常首先考虑的是限流措施。通过限制请求的流量，我们可以有效控制系统的压力，保护核心业务的正常运作。然而，如果限流措施无法解决问题，那么就需要考虑降级操作。在这种情况下，降级是一种权衡，我们可能需要自动或手动地关闭一些非必须的服务，以确保核心业务的稳定运行。这种方式相当于丢弃一些棋子，保住最关键的棋子（核心业务）。
在设计可降级方案时，明确各个服务的业务边界、依赖关系和重要度是至关重要的。让我们以车贷系统为例，将其分成了渠道服务、贷款服务、风控服务、贷后服务、基础服务、数据分析服务、营销服务等子系统。这样的服务划分粒度足够清晰，但在进行降级处理时，我们需要深入到接口级别进行考虑。
以风控系统为例，可能包含多个服务，其中有一个叫做风控预演服务。该服务仅为风控建模评估使用，不参与风控审核流程。因此，如果这个服务宕机，对信贷整体业务并没有实质影响。为了有效管理服务接口的依赖关系，我们可能需要通过人工标注的方式，形成一个应急响应手册，供运维查阅。在发生故障时，可以通过这个手册迅速确定受影响的范围，并有针对性地下线部分服务。此外，在一些页面上给出维护提示也是一个常见的做法。
然而，实际情况可能更为复杂，因为一些接口本身可能已经内建了降级流程。在这种情况下，受影响的接口并不一定需要下线，而可能会触发其内部的降级处理。这需要在设计降级方案时考虑更多的情况，确保降级策略不仅仅能够对整个服务进行下线，也能够灵活应对接口层面的降级需求。
以下是部分车贷系统的服务之间依赖关系:
通过示例我们可以看到，某些接口的故障可能对整个系统产生广泛的影响，而且其中一些接口可能具有高优先级的业务依赖关系，例如短信发送接口和风控审核授信服务。另一方面，有些接口可能对业务的要求并不那么高，比如福利提醒的push。
从中，我们可以得出以下降级设计的指导方向：
重点关注关键接口/服务： 针对那些对整个系统影响较大且有高优先级业务依赖的接口，进行更严格的容错设计和质量测试。这包括确保这些接口具有高可用性、鲁棒性，并能够在异常情况下进行快速的恢复。
明确业务依赖关系： 对于每个接口，明确其所依赖的业务。针对性地进行降级处理，即使在系统资源紧张的情况下，也可以根据业务优先级选择性地关闭或降级某些不是核心业务的接口或服务。例如，可以临时下线风控预演系统，因为它对核心业务的影响相对较小。
紧急通告与措施： 在某些关键接口出现异常的情况下，可以采取及时的紧急通告与措施。例如，当短信发送接口异常时，可以关闭各关联业务的入口请求，并向相关用户发送通知，同时采取必要的补救措施。
在设计可降级方案时，确实需要更细致地考虑接口之间的依赖关系。理想情况下，我们应该找出诸如短信发送接口异常影响的所有接口，而不仅仅是这些接口对应的服务。然而，这是一个相当复杂的任务，目前尚未看到成熟的案例。一种设想是通过线上系统的接口调用跟踪，自动发现接口依赖关系，结合人工标注、优先级设定以及对应的降级处理，从而实现智能化的降级流程。当然，要实现这一点，还有许多待解决的问题需要克服。
上文所谓的降级主要指发生异常的情况，但在实际项目中，更多的情况是计划内的停服维护，即正常降级。例如，银行支付网关升级导致支付系统无法正常服务，或者某些服务需要进行分库分表而不得不停服等情况。对于这些可预测的降级，首先需要有上述的依赖关系说明，明确影响范围。然后，与业务和产品进行充分沟通，达成一致，制定详细的预案，包括降级的业务范围、时间、时长、公告内容、客服话术、回滚方案等。
优雅的降级设计是一个复杂而系统性的工程。技术为降级提供了可能，但要实现真正意义上的可降级架构，更需要业务人员明确各业务版块，产品人员根据业务形态合理地设计产品，确保在顶层设计上不会出现边界不清晰、责任不明确的情况。在整个降级流程中，技术、业务、产品三者需要协同合作，才能够有效地保障系统的稳定性和业务的连续性。
