前几天看了一篇介绍1号店架构演进的文章，其中给我印象最深的是他们的日志系统，非常完善，我之前所在的大公司，和现在创业中的小公司都没有做到，日志是一种重要思维方式，值得关注 日志思维已经深入融入1号店的架构理念，成为重要的基础设施 早期的1号店，也是用简单的MVC架构，控制层处理业务逻辑、数据库交互，在初期，方便快捷，成本低响应快 随着业务变得复杂、人员规模爆发式增长，这种强耦合结构成了巨大的瓶颈，代码耦合度高互相冲突、出错概率和事故概率明显提升，业务需求不能快速响应，于是Service化成为第一前提 Service化的第一步首先考虑什么？ 有人先想到的是采用什么RPC框架、采用什么技术，怎么让性能更高 也有人首先想的是业务怎么拆分，怎么才能更合理 1号店首先想到的是如何做监控和问题定位 怎么提前发现问题、出现问题后如何快速定位，这只能依赖日志，这是监控和问题定位的基础 仅一个下单接口就定义了135个错误编码，接口上线后至今出现的错误编码在50-60个，也就是说有50-60处不合理或错误的地方被捕获修正，这个不合理或错误既有业务的 又有程序的 也有对编码定义的不合理 对于极少出现的错误，日志是非常有用的，例如在下单接口上线近2年后，一个之前从未出现过的错误编码跳出来了，是一个很难出现的业务场景，但通过这个编码，可以马上定位问题 永远不能保证系统没有bug，bug可以藏的很深很久，但日志就像伏兵一样，一直都在，bug一出来，可以很快定位解决 一号店日志系统的设计原则： （1）进数据库 （2）分类化、层次化、错误code唯一，可以瞬间定位问题位置，可以从各个维度去做监控预警 错误编码示例 -- GOS-10111001 第一组为前3位，代表service名称，例如 101 代表createOrder 第二组为3、4位这两位，代表错误类型，大类和小类，例如 1 - 系统级错误 2 - 应用级错误（前端参数错误） 3 - 业务级错误（service自身错误） 4 - 依赖级错误（service调用第三方服务错误） 5 - 交互级业务提醒（正常业务逻辑，非错误，需告知用户，如库存不足） 99 - 未知异常
第三组为后3位，代表错误明细，如001代表参数为空
