跨项目组项目开发，错误码设计
引言
当项目还是大单体的时候，当项目还是一个项目组开发的时候，当项目还是自给自足不需要对外提供服务接口的时候，当项目还不涉及多个业务部门甚至部门是跨国的部门的时候，你也许都不需要考虑错误和故障的快速定位，你的服务接口中甚至不存在错误码。
那么在银行，当这些情况都发生了，你要怎么做？
以广发行的贷中业务需求为例，在进行已有卡信贷过程的风险控制，数据流就经历了5个系统，无论那个系统出现错误，都将影响整个业务流程。调用链路是A-B-C-D-E-F。
A：新工单系统-核心系统
B：柜面网关系统
C：大数据统一前置
D：大数据风控
E：信用卡客户决策
F：广发征信管理系统
问题
- 如果风控数据流中某个环节报错，如何根据业务系统收到的报文快速定位到是哪个系统报错并知道具体错误信息。
- 错误信息传递过程中，如何防止错误码对系统的入侵性。错误快速定位
错误快速定位，需要良好的错误码设计，需要提供全局的追踪编号。
错误码设计
分析下，系统的错误往往分为三大类：成功返回、系统服务不可用&网络通信错误、系统内部错误。
报文结构如下：
{
Header:{
},
Body:{
/*具体的报文字段*/
}
}
提供两个错误码字段 errorCode、sourceErrorCode。前者用于放置本系统的错误码，后者用于整合外部系统的错误码。
- 要求对于一个系统而言，errorCode需添加前缀，能避免和sourceErrorCode的值重叠。
- sourceErrorCode的值集合为外部服务的errorCode、sourceErrorCode的取值的并集。
假设每个系统的errorCode取值是：
| 前缀+0000 |
成功 |
| 前缀+1000 |
系统内部错误 |
| … |
… |
假设每个系统的sourceErrorCode取值是：
| 前缀+2001 |
外部服务接口不可用或超时 |
| 前缀+2002 |
外部服务接口内部错误 |
| 前缀+2003 |
外部服务接口返回格式错误 |
| … |
… |
则
EC1=errorCode
EC2=sourceErrorCode
实际上，内部错误码或外部错误码都并不仅有这么少。当错误码很多的时候，这样的设计就避免了外部错误码与内部错误码的转换或映射，而只需要进行错误码的并集逻辑。避免了对系统入侵。
小小错误码如果设计得当，可以避免中间系统频频被找茬，原因却出在外部系统。
Traceid或全局流水号
Traceid或全局流水号。一般而言，traceID应用在一个系统内部并且这个系统本身也是分布式架构。而全局流水号，可以由源系统一直传送到各个叶子系统后再返回，可以作为全局错误排查的线索。但本文主要聊错误码，此处不赘述。
最后
金融行业仅仅是个举例，随着服务化架构的普及，很多公司都注重架构的优良特性，很多项目都会遇到以上的情况，则以上所写可供参考。