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

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

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

---

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-

窝窝的解决方案介绍列表：

#研发解决方案#基于StatsD+Graphite的智能监控解决方案

#研发中间件介绍#定时任务调度与管理JobCenter

#研发解决方案介绍#Recsys-Evaluate（推荐评测） 

#研发解决方案介绍#Tracing（鹰眼）

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

#研发中间件介绍#异步消息可靠推送Notify

#研发解决方案介绍#IdCenter（内部统一认证系统）

#研发解决方案介绍#基于ES的搜索+筛选+排序解决方案

#数据技术选型#即席查询Shib+Presto，集群任务调度HUE+Oozie