理解服务升降级

    ​    ​首先讲一下开关的由来,例如东京在6月18日做店庆促销活动,在交易下单环节,可能需要调用A、B、C三个接口来完成,但是其实A和B是必须的,C只是附加的功能(例如在下单的时候做一下推荐),可有可无,在平时系统没有压力,容量充足的情况下,调用下没问题,但是在类似店庆之类的大促环节,系统已经满负荷了,这时候其实完全可以不去调用C接口,怎么实现这个呢?改代码?no,no,no,这样太不敏捷,此时开关诞生了,开发人员只要简单执行一下命令或者点一下页面,就可以关掉对于C接口的调用,在大促过去之后,再把开关恢复回去即可。

 

    ​    ​问题一:在单个java系统中如何实现开关功能?

    ​    ​其实对于开关来说,对应Java中的类型,很好映射,就是一个boolean值,在需要做开关操作的地方,调用这个属性,判断状态,然后走相应的逻辑即可。这个类是一个单例,保证全局唯一(代码就不写了,单例模式一般是学习设计模式中最开始接触的呵呵)。

 

    ​    ​问题二:单个java系统中,如何实现开关值变更的操作呢?

    ​    ​在单机系统中,改变开关的状态很简单(留一个口子,外部可以改变属性的值,例如改为true或者false),这时候,可以是页面来维护开关,通过页面的点击类改变这个全局唯一的属性,从而实现开关动作的触发。

 

    ​    ​问题三:多个同构java系统,如何实现开关状态的同步呢?

    ​    ​通过一和二的介绍,在单机情况下,开关的变更可以了,但是在多个同构(这里的同构,值得是部署的同一套代码,逻辑完全相同,类似Master和Slaver的模式)系统中,如何保持一致呢?单例模式,开关属性是被加载到本地缓存,就是说java一直持有的对象,在FullGC的时候回收不走的那种。这个时候,如果要保持各个系统中开关属性状态的一致,就需要从第三方外部系统中加载这个数据。

    ​    ​什么系统能充当第三方外部系统呢?可以是一个数据库访问系统,我们暂且称之为MetaServer,开关的属性防止在DB中,然后MetaServer提供页面来修改数据,同时提供接口读取开关的数据,在应用启动的时候,通过MetaServer来读取数据,加载到本地缓存中。这时候就有个问题,就是我通过MetaServer的页面改变了值,各个应用如何知道我改变了属性呢?这个时候就需要通过一些办法(办法很多,可以是消息系统,可以是zookeeper,可以是页面触发)来清理一下开关属性的缓存,让缓存重新加载一下,从而实现最新的状态获取。

    ​    ​总体思路就是:metaServer维护开关数据--应用读取DB中的数据到本地缓存--DB中数据变更--触发开关属性缓存重新加载。

    ​    ​这个是不是有点复杂,有没有更加简单的办法?当然有了,之前淘宝开源了一个系统diamond(持久化配置管理系统,http://code.taobao.org/p/diamond/wiki/index/),其实可以理解为“配置信息的伪推送服务”,例如我变更了一个开关的属性,不再需要做清理缓存的事情,diamond帮你做掉了(原理很简单,例如系统A订阅了在diamond中的开关信息,这时候A会启动一个线程,每隔一段时间来轮循diamond的服务端,看看开关属性的数据有没有变更,如果有变更,在diamond服务端来加载最新的数据)。

    ​    ​总体思路是:在diamond中维护配置信息--系统订阅开关属性--系统轮循配置是否有变更,有变更直接就变掉了。

 

    ​    ​问题四:开关设计的几个坑

    ​    ​有时候,我们为了方便,没有借助问题三种的MetaServer或者diamond的方式,就是留了一个HTTP的接口来触发修改开关(多台机器的话,可以写批量脚本),这时候其实需要我们在apache或者nginx中,把这个URL的访问禁止掉,防止恶意用户在外部拼凑链接来进行开关的变动,这时候只能在服务器上通过linux的curl来触发操作了。

    ​    ​还有一个,就是如果通过HTTP的形式来修改开关的属性,有个是需要注意的,就是开关的执行要幂等操作,这样方便操作,避免出现集群中数据不一致的状态(就是执行开,开关就是开,不能第一次执行是开,第二次执行是关)。

 

    ​    ​问题五:开关组合情况下怎么搞?

    ​    ​上面的几种情况,仅仅是执行单个开关,应该比较简单。但是我同时又A、B、C三个开关,在不同的业务场景下,可能需要关闭A和B开关,在另外一个场景下,可能需要关闭A和C开关,这时候认为操作有可能会有遗漏或者疏忽,怎么搞呢?在单独属性开关的基础上做封装,例如A和B上面增加一层属性,暂且叫“AB”,修改AB的值,对应的系统修改A和B的值,这样就避免人肉记住一些组合。

 

    ​    ​问题六:如何实现自动升降级?

    ​    ​上面的情况,都是在提起可以预知的情况下,我们做一些人为的操作,这个能不能自动化?当然可以,就是这一小节讨论的自动升降级。

    ​    ​举例子,现在东京和作的外部物流公司有多家,会调用它们的系统或者物流节点的状态,这个时候,物流公司系统是不稳定的,如果挂了或者响应时间慢了,对于自身的系统会影响比较大,比较理想的办法是,在物流公司系统出现问题的时候,这块逻辑自动降级处理,然后等物流公司系统好了之后,再把这部分逻辑自动升级,整个过程没有人为参与,自动保持系统稳定性。这里说一下总体思路:

    ​    ​第一步:搞一个计数器,记录接口,暂定A的调用成功次数、失败次数以及响应时间;

    ​    ​第二步:将这些信息放入队列中,同时设置阀值(例如RT超过5秒就降级,1秒就升级)以及阀值触发改动的开关;

    ​    ​第三部:异步启动一个线程,扫描队列,达到我们的条件,就触发做变更(有个问题,就是加入业务降级了,这时候就没有调用量,也就没有了自动升级的条件了,怎么搞呢?这时候业务降级,并不是完全100%的停掉,可以预留一部分流量继续调用A,把A调用的信息放入队列中,根据这些信息,就能实现升级了);

 

    ​    ​总结:

    ​    ​上面这些是在陆续的系统维护中尝试或者看到的处理办法,通过开关的方式,实现系统的升降级,从而更好的保护系统。这篇文章只是阐述了大体的思路,没有涉及到具体的代码,希望能够达到抛砖引玉的作用。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值