全局异常码，用到最后崩溃了，各种重复，无人维护

点击上方蓝色字体，选择“设为星标”

今天跟大家聊一个比较实用的话题，就是全局的异常码要怎么维护？

我个人觉得如果对于小团队来讲，其实还是比较好维护的，因为人少，可控性更高一点。反而稍微大一点的团队，如果没有专门的人去维护，到最后肯定是乱糟糟的结果。

关于异常码的格式不做过多讲解，每个公司定义的都不太一样。比如我们异常码用 9 位数字来定义：

示列：10000100

• 前 3 位 100 代表业务域，比如订单，商品，库存等。
• 中间 2 位 00 代表业务划分，比如订单可以分为确认订单，创建订单等子模块。
• 最后 3 位代表具体的异常，比如库存不足，商品已停售等。

最开始的时候一切都很规范，大家在一起开会，然后定义出了异常码的规范。后面也是这么做的，当公司快速发展，业务越来越多，被拆分的服务也越来越多。

但是这个异常码也没有定义由哪个部门来维护，导致后面新增加的业务想要加异常码，没办法梳理出当前的现状。

也就是不知道当前异常码用到了哪个段，自己随便加又怕重复，不随便加又梳理不出来，难受。如果一开始就人统一去维护这个码，哪怕只是简单的创建一个公共的文档，大家也可以自己往里面添加，也不至于搞成今天的局面。

用文档来维护

用文档来维护是最低的成本，只需要创建一个公共的文档。把异常码定义的规范写清楚，然后目前各个业务域已经在使用的码有哪些。当然这个不用把所有的码都写在文档上，只需要写前面的段即可。

比如：
订单 100
  00 确认订单
  01 创建订单
  02 取消订单
商品 101
库存 102

如果此时划分了新的业务服务，加了个购物车，如果购物车划分到订单预的话那么就加二级段就行了，加一个 03 段。

文档维护虽然成本低，但是最严重的问题就是怕文档更新不及时或者压根很多新加的码段都没更新到文档上，那么最终还是会出现脱节的现象。

用代码来维护

文档其实是采用人工的形式来进行维护的，有很大的可能性会漏掉。那么我们是否可以用程序来维护呢？

程序只要没 Bug 那么永远不会出问题，所以用程序来维护是一个非常好的选择。下面介绍下具体实现的思路，代码大家自己去写哦！

定义一个异常码的表用于存储所有的异常码。

定义一个异常码的配置表，用于限制随便自定义异常码的段。

如果要做的更好点，可以再加一个申请表，将异常码段的申请做到后台里面，可以进行申请和审批。简单点就直接手动插入数据得了。

表结构定义好之后，我们可以写一个通过框架让每个业务项目依赖。在这个框架中需要做下面几件事情：

• 项目启动时初始化所有的异常码到数据库，没有才初始化，如果有重复（码相同，业务域不同）的直接报错提示。
• 初始化之前还需要判断当前项目能够申明哪些段的异常码，所以要有一个配置，这个配置标识这个项目属于哪个业务域。

总结

关于细节就不详细写了，其实思路很简单，就是通过代码的方式将异常码统一存到表里面，这样就可以判断异常码有没有重复定义了。

当然在这个实现过程中还有很多东西要考虑，比如：

• 每个业务方定义的异常枚举类都不一样，想要统一收集，就必须得知道是哪个类，可以采用配置的方式定义。
• 异常码统一存储的数据源肯定是独立的，不可能用业务方自己的数据源，否则就不是集中存储了，也需要定义配置单独指定。
• 其他..........

然后就是每个业务域能够申明的码段是必须在数据库里存在的，也就是提前配置好的。前面也讲到了可以做成功能，让使用者进行申请，只有申请了，项目启动的时候才不会报错。否则你直接定义一个新的异常码，在启动的时候就拦截了。

而且异常码统一存储后，也可以做成后台功能，通过异常码直接查询当前的异常是什么问题，归哪个业务域处理。

思路比编码更重要，如果对你有用，来个转发呗！

关于作者：尹吉欢，简单的技术爱好者，《Spring Cloud 微服务-全栈技术与案例解析》, 《Spring Cloud 微服务 入门 实战与进阶》作者, 公众号猿天地发起人。

后台回复 学习资料 领取学习视频