#研发解决方案介绍#基于持久化配置中心的业务降级

郑昀 最后更新于2014/4/18

关键词：业务降级，配置中心，基本可用性，diamond

---

A.业务降级的背景知识：

  淘宝就双十一课题曾经讲过：

『

所谓业务降级，就是牺牲非核心的业务功能，保证核心功能的稳定运行。简单来说，要实现优雅的业务降级，需要将功能实现拆分到相对独立的不同代码单元，分优先级进行隔离。在后台通过开关控制，降级部分非主流程的业务功能，减轻系统依赖和性能损耗，从而提升集群的整体吞吐率。

』

主动关闭系统功能的场景：

  我们更新系统或数据库刷库时，可能会提出，某天凌晨几点到几点不能下单，几点到几点不能验证，如果都靠人工手动调整、手动开关跳转页面或提示文字的话，非 常不方便。而我们的理念是，日常发生的事情，不能有心理负担，不能成为一件很麻烦甚至需要临时修改代码的事情。所以停服引发的降级，需要方便快捷地做到。

  于是，一个集中存储的开关控制这些核心功能全线关闭，可以有。

 

被动关闭系统功能的场景：

  我们都知道，某东在2011年，某客在2012年，某美在2013年，耗费了很多人财物为大促销做准备，结果时间到了，网站宕机宕得死死的。

  此时，限制连接数可能会让网站暂时性活过来了，但是能进来的人不多，销售额上不去，其实还是公司损失。

  在这种被动的场景下，可以力保核心购买流程能走通，保证基本可用性，即确保能够下单和提交支付，保证钱能流进来，同时保证消费验证。

  所以业务降级的做法是，逐一全局关闭非核心流程的业务功能。

 

B.窝窝业务降级的实操：

  与之前窝窝实现的业务降级不同，研发1部的明骏把 降级功能配置 与 降级项目配置 分开，如下图1所示：

图1 业务降级配置管理的菜单项

  即：

一，降级的最小单位是 功能 

我可以单独针对“（首页右侧栏）热门专卖店（列表）”功能。如下图2所示，配置状态为“未过滤”代表该功能未被拦截。

图2 功能配置实例

  1.1.可以获知该（URL/class拦截）功能在哪些项目里生效。如上图2中的“所含项目配置”列所示。

  1.2.可以配置跳转地址，如下图3所示。第一，如果功能过滤启用了，当拦截到目标后，需要引导浏览器跳转到哪一个页面，譬如跳到停服公告页上。第二，可以定义启用时间，比如明天凌晨1点。

图3 功能配置详情页

  1.3.如果一个功能被多个项目包含，比如“（通栏）广告”功能被 aether 和 mars 包含，那么当这个功能处于“已过滤”时，aether 和 mars 上的通栏广告就会都消失，即使这两个项目的配置状态为“未过滤”。

  1.4.过滤某个功能，点击配置状态列的按钮即可，启用状态如下图4所示。

图4 功能处于已过滤

 二，功能 之上是 项目 

  2.1.项目 的出现，是为了更灵活多样地降级。

  2.2.你既可以过滤横跨多个项目的一个功能，一关全关。你也可以只关某个项目里的功能集合，比如你可以只关闭 aether 工程里的通栏广告和推荐列表。

  2.3.当 项目 处于“已过滤”状态时，不想过滤某个功能，那就勾掉它，如下图5所示。

图5 项目配置详情页

  2.4.在 被动关闭系统功能场景 里，由于目前还没有开发 预案级降级，所以最快的办法是，到 降级功能配置管理 里，把相关功能的开关全部打开。

  2.5.有了基于 功能和项目 的降级配置管理，下一步就可以基于（远端）服务质量做自动降级了。

 

三，项目 之上是 预案 

  3.1.举例，红色预警预案将关闭所有 下单、支付、充值 等功能，橙色预警预案将关闭所有 推荐、评价、积分 等功能。

  3.2.预案 级别的降级控制目前还没有实现。

 

C.持久化配置中心的背景知识：

  diamond是淘宝内部使用的一个管理持久配置的系统，它的特点是简单、可靠、易用，目前淘宝内部绝大多数系统的配置，由diamond来进行统一管理。

  diamond为应用系统提供了获取配置的服务，应用不仅可以在启动时从diamond获取相关的配置，而且可以在运行中对配置数据的变化进行感知并获取变化后的配置数据。

  持久配置是指配置数据会持久化到磁盘和数据库中。

  diamond的特点是简单、可靠、易用：

简单：整体结构非常简单，从而减少了出错的可能性。

可靠：应用方在任何情况下都可以启动，在承载淘宝核心系统并正常运行一年多以来，没有出现过任何重大故障。

易用：客户端使用只需要两行代码，暴露的接口都非常简单，易于理解。

 

  值得一提的是 diamond 的容灾机制，这也是阿里系不少开源中间件的容灾通用思路。

C.1.diamond的容灾机制

  diamond之所以表现的稳定可靠，除了架构简单之外，另一个重要原因是diamond具有一套完备的容灾机制，容灾机制涉及到client和server两部分，主要包括以下几个方面：

c.1.1.server存储数据的方式

  server存储数据是“数据库 + 本地文件”的方式，集群间的数据同步我们在之前的文章中讲过（请参考专题二的原理部分），client订阅数据时，访问的是本地文件，不查询数据库，这样即使数据库出问题了，仍然不影响client的订阅。

c.1.2.server是一个集群

  这是一个基本的容灾机制，集群中的一台server不可用了，client发现后可以自动切换到其他server上进行访问，自动切换在client内部实现。

c.1.3.client保存snapshot

  client每次从server获取到数据后，都会将数据保存在本地文件系统，diamond称之为snapshot，即数据快照。当client下次启动发现在超时时间内所有server均不可用（可能是网络故障），它会使用snapshot中的数据快照进行启动。

c.1.4.client校验MD5

  client每次从server获取到数据后，都会进行MD5校验（数据保存在response body，MD5保存在response header），以防止因网络故障造成的数据不完整，MD5校验不通过直接抛出异常。

c.1.5.client与server分离

  client可以和server完全分离，单独使用，diamond定义了一个“容灾目录”的概念.

  client在启动时会创建这个目录，每次主动获取数据（即调用getAvailableConfigInfomation()方法），都会优先从“容灾 目录”获取数据，如果client按照一个固定的规则，在“容灾目录”下配置了需要的数据，那么client直接获取到数据返回，不再通过网络从 diamond-server获取数据。

  同样的，在每次轮询时，都会优先轮询“容灾目录”，如果发现配置还存在于其中，则不再向server发出轮询请求。 以上的情形， 会持续到“容灾目录”的配置数据被删除为止。

 

根据以上的容灾机制，我们可以总结一下diamond整个系统完全不可用的条件：

1. 数据库不可用。 
2.  所有server均不可用。 
3.  client主动删除了snapshot。
4.  client没有备份配置数据，导致其不能配置“容灾目录”。 

同时满足以上4个条件的概率，在生产环境中是极小的。

 

D.窝窝配置持久化的实操：

  窝窝把各种业务限流、各种白名单放在 diamond 里了。其实就是 key/value 存储。如下图6所示.

 

图6 放入 diamond 统一管理的各种配置项

 

-over-