关于java分布式系统开关功能设计(服务升降级)

首先讲一下开关的由来，例如东京在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（持久化配置管理系统），其实可以理解为“配置信息的伪推送服务”，例如我变更了一个开关的属性，不再需要做清理缓存的事情，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调用的信息放入队列中，根据这些信息，就能实现升级了）；

    ​    ​总结：

​    ​上面这些是在陆续的系统维护中尝试或者看到的处理办法，通过开关的方式，实现系统的升降级，从而更好的保护系统。