微服务系统错误码设计

目标

那么错误码能为我们带来什么？

首先，通过错误码我们能识别出系统到底出了什么问题？ 

其次，通过错误码我们应当能识别出哪个系统出了问题？

再次，通过错误码需要知道对应的定位问题和解决问题的方法。

最后，通过错误码我们可以决策出该给客户显示出了什么问题？（前端）

使用方

• PaaS集成商，负责运维我们的服务；
• SaaS应用层服务；
• 部署人员、客服人员；

错误码分类

类型编号	错误类型	解释
1	系统错误	主要指和操作系统交互的错误，如socket绑定失败，创建新文件失败，申请内存空间失败
2	业务错误	主要是业务系统内部错误，如超出licence限制使用资源，超出运行提取特征的最大图片个数
3	参数解析错误	如get请求query字段为空，缺少必选字段，字段取值错误等
4	依赖基础服务错误	如写zk读写出错等/mongo连接的错误

当前错误码存在的问题

1. 不全或概况性较高，可以根据上述的类型进一步识别
2. 不能定位到问题服务
3. 描述信息文字不易理解（偏专业）
4. 每个服务都自定义错误码规范

错误码

方式一：

{   code : xxx, // http协议相关错误码，200表示正常   msg : ,   data : {     code : xxx, // 安防业务系统错误码，0表示正常     msg : ,          // 业务数据 object result   } }

方式二：

{   code : xxx, // http协议相关错误码和安防业务系统错误码，0和200都表示正常   msg : xxx, // 英文   data : {  } }

 

错误码传递设计

• 对于下游返回的致命错误，直接传递该错误码和error msg；
• 对于下游返回的非致命错误，请求继续执行。服务可以有三种处理方式：1、忽略之前的错误，返回code=0并且err_msg为空；2、将下游的错误码和错误信息与本服务的错误码与错误信息进行一次映射后返回；3、将下游的错误码和错误信息接着向上传递；
• error msg中需要保留服务名称；
• PaaS OpenApi需要对交付给客户的错误码整体负责，需要屏蔽下游系统的变化，特别是对应下游返回的实现细节方面的错误码进行抽象后暴露给用户；
• 下游系统需要向上游系统提供（并及时更新） 错误码描述，应对措施和对应的接口名称（可能是多个）；上游系统（非顶端的PaaS OpenApi）需要整合下游系统提供的错误码，和自身的错误码一起提供给自己的上游系统使用；

错误码统一设计

一共由8位数字进行表示：

• 前两位表示不同服务名称，统一分配数字
• 后续两位表示模块名称，由服务负责人统一分配数字（paas openapi、xid内部均涉及多服务/模块）
• 后续一位表示错误类型
• 后续三位表示具体错误原因

sample： 4011005按照上面的的规则，可划分为04，01，1，005。04标识xfr，01标识xfr-proxy（假定），1标识系统级错误，005是业务错误。