做了一个简单但是很有效的优化，怎样表达出它的价值？

作者编程一生

来源公众号编程一生

背景

公司的某个核心业务由于业务量迅猛增长遇到稳定性问题，临危受命，把一个经常出故障造成资金损失的系统，经过架构优化变更一个有条不紊运行的系统。那自己不用多说什么，业绩都看得见。而一个系统本身业务量和增长量不大，做一个优化，实际的效果是解决系统的隐患。而由于这个优化系统从而就没有出现这些问题，效果不是那么显而易见的。这时候，要怎样表达出它的价值呢？

具体场景描述

现在有一个系统，平时的业务量一天交易量(TPS)十万左右，属于一个相对普通的项目。一听起来就输了气场，不像现在各种演讲和文章里的动辄千亿级别的项目，不管做了什么优化，都能吸引眼球，因为人家做的数据级别业界也没有几个。本身的业务也很简单，就是一个通道类系统，做个数据透传。

本次优化的目标是通过流程标准化和工具化，提升运维效率。目标明确了那就根据目标来梳理：

1>为了从根本上避免《服务运行过程中磁盘坏道引起的思考》里提到的问题，为了避免将应用部署到有问题的服务器上，同时还要解决手动进行检查的繁琐和容易疏漏。服务发布或者重启时，需要加上一些前置检查，比如：cpu、内存等系统属性检查、安全防御进程和监控进程等必要辅助进程是否存活的检查。要做的事情就是在发布平台上加上前置脚本即可。

2>应用还有其他手动运维操作，要说明这个先来看一下简单的架构，如下图所示：

作为一个通道系统，应用功能是上游接收RPC请求，发送到MQ中。MQ收到消息进行处理后，会异步返回处理结果。

从应用角度来看，需要做三种控制：

1) 接收请求控制，一旦应用有问题或者功能灰度上线，需要控制接收请求流量。这个因为我们使用了dubbo，所以可以通过dubbo的服务治理平台来管控，无需开发。

2) MQ处理结果消息接收，这个MQ客户端提供这个功能接口，可以通过对单台机器调用此接口来进行接收的启动或停止，这就是上面图中标红的消息消费开关。因为这个服务是主备类应用，主应用要打开开关，备应用不能打开开关。所以现有功能是将这个开关是否打开放到配置文件里控制。如果需要手动调整，直接调用将这个接口封装成的http接口。

现在的逻辑是有运维操作风险的。如果主备切换了，或者主机器有故障，启动时不能打开消费开关，则需要人工处理，如果人工处理不及时或者出错，则会造成运维事故。

3) A的MQ集群有N台机器，如果MQ出现问题或者积压了，需要进行运维处理，可以暂时停用这台机器，等它恢复或者将消息处理完。就是图中标红的MQ发送开关。目前都是通过人工发现和处理的。

优化方案

重点来看标红的两个开关的优化方案。

消息消费开关

这个开关控制的是本机的消费状态。优化目标是将调用http接口的紧急操作EOP转变成流程可把控、可审核的标准操作SOP。当我分析需要运维的场景时，我发现自己并不需要消息消费开关，只需要一个集中存储的配置告诉我当前哪个是主服务器。

在机器正常发布时，或者主备切换，或者主机器有故障时，使用主服务器配置开关怎么来进行处理。

如果机器是完好的，那主机房服务器，就该完整提供服务，消费消息。如果是备用机器服务器，就不承接流量，不消费消息。如果机器是故障的，那就该停掉服务，而不只是消费开关。

MQ发送开关

消息消费开关控制的是本机。MQ发送开关判断是连接的MQ是否有能力把消息正确的发送给对方。有这个能力就用，没有这个能力就改用其他MQ。所以实际配置的并不是某台MQ是否发送消息的配置，而是需要一个整体的配置，表明哪些MQ可以发送消息。

与上面的是否消费判断不同，上面用的主配置，主备切换通过的是公司或者部门整体的一个控制。但是MQ集群里可用的MQ需要业务自己来判断的。判断的指标是MQ是否可用和MQ是否有消息积压。

最好理想的情况是每次发送消息前都做一个判断，使用目前状况两行，积压最小的来发送消息。但是每次发送都判断会极大的增加请求耗时。并且这样还违背了架构优化的一个软性原则：现有架构可以稳定支撑业务时，优化不要改变核心逻辑，只在外围做事情。

所以最好是使用旁路的检测任务，定时检测MQ是否可用和MQ是否有消息积压。MQ的可能状态就有：

1>正常

2>手动停用

3>检测不可用

4>检测消息积压

这四种，手动停用的优先级最高。检测不可用优先级高于检测消息积压。据此，可确定有限状态机的状态流转。由于状态流转图用画图表示，很乱。这里用图表表示：

这里有个最小正常数判断，这是一个功能熔断值。熔断功能是旁路的标配。熔断值就是就算探测这个功能有问题，也因为这个熔断值不会影响正常业务。

价值表达

做了不说等于0。

我和很多人一样，喜欢埋头干活。但是做了一些事情，特别是优化，一定需要跟很多人沟通。最好拉会让所有和优化系统有关的其他系统负责人一起评审。第一，专家可以提供更好的思路，让优化更合理。第二，确保优化不影响到其他系统。第三，让更多的人了解做这件事情的目的意义，将来维护的人也知道做这件事情的初衷，便于维护。第四，自己做的优化，其他系统可能也需要做，只是之前没有想到或者没有时间把细节想好，这个评审可以帮助他们。