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

谁借莪１个温暖的怀抱￠ 2022-09-11 05:08 55阅读 0赞

**背景**

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

**具体场景描述**

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

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

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

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

![e92da9e513f30a204382f03d364efe6f.png][]

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

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

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

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

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

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

**优化方案**

**![04962f7ad04b9e61cc0618e1aa0159c3.png][]**

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

**消息消费开关**

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

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

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

![1a04267ba0b666f0561851c70e31c4b3.png][]

MQ发送开关

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

![bd204bd912889d75cc25506dd3302c0d.png][]

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

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

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

1>正常

2>手动停用

3>检测不可用

4>检测消息积压

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

<table> 
 <thead> 
  <tr> 
   <th>状态</th> 
   <th>可转换状态</th> 
   <th>转换条件</th> 
   <th>触发方式</th> 
  </tr> 
 </thead>       
 <tbody> 
  <tr> 
   <td>正常<br><br></td> 
   <td colspan="1">手动停用</td> 
   <td colspan="1">界面操作审核通过后生效</td> 
   <td colspan="1">手动触发</td> 
  </tr> 
  <tr> 
   <td colspan="1">探测不可用</td> 
   <td colspan="1">检测实际这台MQ实际状态为不可用 &amp; 状态正常的MQ数&gt;最小正常数</td> 
   <td colspan="1">任务触发</td> 
  </tr> 
  <tr> 
   <td colspan="1">探测超过积压阈值</td> 
   <td colspan="1">检测实际这台MQ实际状态为可用 &amp; 其他MQ状态均为正常 但 队列积压超过阈值</td> 
   <td colspan="1">任务触发</td> 
  </tr> 
  <tr> 
   <td>手动停用</td> 
   <td>正常</td> 
   <td><p>界面操作审核通过后生效</p></td> 
   <td>手动触发</td> 
  </tr> 
  <tr> 
   <td>探测不可用</td> 
   <td colspan="1">正常</td> 
   <td colspan="1">检测实际这台MQ实际状态为可用且队列积压不超过阈值</td> 
   <td colspan="1">任务触发</td> 
  </tr> 
  <tr> 
   <td colspan="1">探测超过积压阈值</td> 
   <td colspan="1">检测实际这台MQ实际状态为可用但队列积压超过阈值</td> 
   <td colspan="1">任务触发</td> 
  </tr> 
  <tr> 
   <td>探测超过积压阈值</td> 
   <td colspan="1">正常</td> 
   <td colspan="1">检测实际这台MQ实际状态为可用且队列积压不超过阈值</td> 
   <td colspan="1">任务触发</td> 
  </tr> 
  <tr> 
   <td colspan="1">探测不可用</td> 
   <td colspan="1">检测实际这台MQ实际状态为不可用 &amp; 状态正常的MQ数&gt;最小正常数</td> 
   <td colspan="1">任务触发<br><br></td> 
  </tr> 
 </tbody> 
</table>

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

**价值表达**

做了不说等于0。

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

**推荐阅读**

# [阿里巴巴编码规范（Java）证明][Java] #

# [程序员父母对孩子学习没要求，孩子却成绩名列前茅，这熊孩子怎么做到的？][Link 2] #

# [设置默认的超时和重试是一个基础设施的基本素养][Link 3] #

# [测测你是《花千骨》里的谁-业务代码里常用的设计模式][-] #

[Link 1]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafde3f4cd8a6ae294bd90fcc390786fb7394f3bc003c4df7dfa7c7944736ad0be2497f80aac&idx=1&mid=2247485786&scene=21&sn=713472ac7aa83b8b91a3012b2b8a7be8#wechat_redirect
[e92da9e513f30a204382f03d364efe6f.png]: /images/20220828/c8d7c8a8cb674488866902201924c59e.png
[04962f7ad04b9e61cc0618e1aa0159c3.png]: /images/20220828/018b609fb5a44af4af2da79ec0bd35b5.png
[1a04267ba0b666f0561851c70e31c4b3.png]: /images/20220828/84ac904d23684b64a98402e579a19881.png
[bd204bd912889d75cc25506dd3302c0d.png]: /images/20220828/ba8e4e6696384abfa1f1b0afb919bb5e.png
[Java]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafded91cd8a6487ff3a43390b87d7e55e75ca97b26446a4264d93a60b34a8d03378c9f1bca6&idx=1&mid=2247485247&scene=21&sn=62cbc747bea99d91b45104863640f95b#wechat_redirect
[Link 2]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafdec13cd8a6505d4006a18ae91d4091e923bea823fd4062adc8b329cf9ffa7b77e77fa2351&idx=2&mid=2247485117&scene=21&sn=b5872b3695309e40bd82317c70eb307a#wechat_redirect
[Link 3]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafde964cd8a6072aaf01d87d4391b9178d3cfac0eb88cc55590c8fb5be81d846fc4d70ef06e&idx=1&mid=2247484362&scene=21&sn=741629424adc436b02af25e7a0667087#wechat_redirect
[-]: http://mp.weixin.qq.com/s?__biz=MzUzNjAxODg4MQ%3D%3D&chksm=fafde876cd8a6160c8c80921772d58e6142e66f18cf7c6520c41ccfd337f24daa8585af8bcca&idx=1&mid=2247484120&scene=21&sn=af28a1222042cd4bd6903eae1678e297#wechat_redirect