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

郑昀 最后更新于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-

时间: 2024-10-27 03:23:20

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

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

郑昀 基于李丹和刘奎的文档 创建于2014/12/5 关键词:监控.dashboard.PHP.graphite.statsd.whisper.carbon.grafana.influxdb.Python 本文档适用人员:研发和运维员工 提纲: 监控平台要做到什么程度?为什么要自己做? 几个通用技术问题 绘图所依赖的数据如何收集?如何加工?如何存储? 图形如何绘制,各种指标如何叠加? 拓扑关系如何绘制? 技术选型哲学 最终选了statsd+graphite 数据的采集 数据存储的粒度 天机的技术

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

郑昀 基于胡耀华和王超的设计文档 最后更新于2014/12/3 关键词:ElasticSearch.Lucene.solr.搜索.facet.高可用.可伸缩.mongodb.SearchHub.商品中心 本文档适用人员:研发和运维 提纲: 曾经的基于MongoDB的筛选+排序解决方案 MongoDB方案的缺陷 看中了搜索引擎的facet特性 看中了ES的简洁 看中了ES的天生分布式设计 窝窝的ES方案 ES的几次事故和教训 ES自身存在的问题 首先要感谢王超和胡耀华两位研发经理以严谨治学的研究精

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

郑昀 基于刘金鑫文档 最后更新于2014/12/1 关键词:recsys.推荐评测.Evaluation of Recommender System.piwik.flume.kafka.storm.redis.mysql 本文档适用人员:研发 推荐系统可不仅仅是围着推荐算法打转 先明确一下,我们属于工业领域.很多在学术论文里行之有效的新特奇算法,在工业界是行不通的.当年我们做语义聚合时,分词.聚类.相似性计算.实体词识别.情感分析等领域最终还都采用了工业界十几年前乃至于几十年前就流行的成熟算法.

#研发解决方案介绍#Tracing(鹰眼)

郑昀 最后更新于2014/11/12 关键词:GoogleDapper.分布式跟踪.鹰眼.Tracing.HBase.HDFS. 本文档适用人员:研发 分布式系统为什么需要 Tracing? 先介绍一个概念:分布式跟踪,或分布式追踪. 电商平台由数以百计的分布式服务构成,每一个请求路由过来后,会经过多个业务系统并留下足迹,并产生对各种Cache或DB的访问,但是这些分散的数据对于问题排查,或是流程优化都帮助有限.对于这么一个跨进程/跨线程的场景,汇总收集并分析海量日志就显得尤为重要.要能做到追踪

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

郑昀 最后更新于2014/11/11 关键词:定时任务.调度.监控报警.Job.crontab.Java 本文档适用人员:研发员工 没有JobCenter时我们要面对的: 电商业务链条很长,业务逻辑也较为复杂,需要成百上千种定时任务.窝窝的大多数定时任务其实调用的是本地或远端 Java/PHP/Python Web Service.如果没有一个统一的调度和报警,在集群环境下,我们会: 不知道哪一个定时任务执行失败或超时,不见得能第一时间知道——直到最终用户投诉反馈过来: 要求每一个定时任务输出统

[刘阳Java]_Spring AOP基于XML配置介绍_第9讲

基于注解配置的Spring AOP固然简单,但是这节我们会给大家介绍基于XML配置的AOP是如何应用的.为什么这么说了,因为后面我们还会介绍到Spring对Dao操作的事务管理(基于AOP的XML文件方式来配置事务) 1. 基于XML文件方式来配置Spring的AOP,则我们需要的一些基本元素如下 <aop:config.../>,此标签很重要.它是在XML里配置AOP功能的核心标签 all aspect and advisor elements must be placed within a

如何借助配置中心ACM加速企业IT服务快速迭代

摘要: 在5月29日召开的第二届研发效能嘉年华中,云效邀请了阿里云产品团队的伏羿和来自阿里巴巴中间件技术部的彦林带来了"如何借助配置中心ACM加速企业IT服务快速迭代"的主题分享. 分别对配置中心ACM和ACM技术进行了讲解,并且对ACM的主要应用场景进行了介绍,并进行了Demo环节. 在5月29日召开的第二届研发效能嘉年华中,云效邀请了阿里云产品团队的伏羿和来自阿里巴巴中间件技术部的彦林带来了"如何借助配置中心ACM加速企业IT服务快速迭代"的主题分享. 分别对配

SpringCloud学习系列之五-----配置中心(Config)和消息总线(Bus)完美使用版

前言 在上篇中介绍了SpringCloud Config的使用,本篇则介绍基于SpringCloud(基于SpringBoot2.x,.SpringCloud Finchley版)中的分布式配置中心(SpringCloud Config)的配置刷新和消息总线(RabbitMQ和Kafka)使用教程. SpringCloud Config Refresh 在上一篇中我们介绍了springcloud配置中心的本地使用和Git使用的用法,但是当重新修改配置文件提交后,客户端获取的仍然是修改前的信息,需

Spring Cloud构建微服务架构 分布式配置中心(加密解密)

在微服务架构中,我们通常都会采用DevOps的组织方式来降低因团队间沟通造成的巨大成本,以加速微服务应用的交付能力.这就使得原本由运维团队控制的线上信息将交由微服务所属组织的成员自行维护,其中将会包括大量的敏感信息,比如:数据库的账户与密码等.很显然,如果我们直接将敏感信息以明文的方式存储于微服务应用的配置文件中是非常危险的.针对这个问题,Spring Cloud Config提供了对属性进行加密解密的功能,以保护配置文件中的信息安全.比如下面的例子: spring.datasource.use