这个就是我们常说的一致性,我们现在并没有完全解决这个问题,目前我对于跨单消耗我采用的是占位思想进行解决,也就是先会更新资源然后出现异常进行返点。并没有采用最终一致性来解决,因为最终一致性会出现数据被多扣,比如我得资源第一次扣除失败然后放入队列,在队列进行扣除,但是恰恰新的请求过来同样会获取这条资源进行扣除,这样一来就出现数据安全问题,目前我们采用的是三次重试,所以严格来讲我们服务的一致性并没有完全解决.关于一致性问题在以后的文章会继续和大家聊。
6、服务的接入方当业务方需要调用我们服务的时候自己一定慎重搞不好就掉坑里了,下面我说2个例子
第一个例子：
有一个业务方告诉我们他们要做活动需要每天添加资源,然后我就问了他每天的量级,经过评估后我发现量级没太大问题,但是当我要审批的时候发现有新的问题,因为活动期间添加资源会出现大量零碎的订单,如果过期时间过久那么可能数据库每种资源达到几百或者上千条,那么带来的后果就是我们在查询或者消耗时候会非常慢,而且以前因为查询过多订单导致服务超时问题,所以后续我们就这问题沟通,他们要过期时间设置1个月,然后我在做压力测试确认无误后才审批。
第二个例子：
我们提供定制化接口给业务方,这个给我们带来了特别多痛,我们提供一个消耗接口,但是这个业务方需要消耗详情,我们同样提供了,这样就导致他的消耗和别人不一样,做技术升级的时候还需要单独考虑这个接口,因为我的忽略导致几次没有考虑清楚都出现线上事故,后来我们去问他们要消耗详情干嘛,他说他业务其实不用需要把这些消耗详情存入他们的库,我们听后觉得特别无语,这样的数据直接走离线数据即可,这也是早期没聊明白需求导致一个毒瘤接口。
综上总结：
1、业务方的需求我们必须聊清楚,明白我们服务应该提供的能力,对于不合理的需求直接拒绝
2、拒绝提供定制化的接口,如果某个业务方需求影响整体同样我们必须拒绝或者找到其他兼容方案
3、对于每次业务方的接入必须邮件写的非常明白包括背景、量级、QPS等
二：基础服务过程中case汇总 1、数据迁移和数据转换引发事故关于数据迁移和转换引起的事故请参考这篇文章https://www.cnblogs.com/LipeiNet/p/7809567.html
2、线上操作数据库表结构引发的事故关于这个事故请查看这篇文章https://www.cnblogs.com/LipeiNet/p/9182454.html
3、重构引发的线上事故重构我们一共出过两次事故,一个代码整合,一个是删除已废弃逻辑.
代码整合带来的问题：
背景：
刚进入公司的时候我看到项目中有大量代码重复,就想着重构,把相同的代码用函数的方式合并,最后经过审批后也这么干了,但是上线以后一线反馈自己添加的资源无法查询,最后排查日志中发现在重构代码中有一处代码的资源订单的开始生效日期是当前日期并不采用用户传入的日期。
删除已废弃逻辑带有的问题：
背景：
由于我们服务的和外部服务解耦其中的一个数据库字段被废弃,所以我们在代码中去除掉这个字段的逻辑信息,上线后业务方反馈资源消耗异常,排查后我们发现返回实体中去除字段应该是0但是我们去掉逻辑后变成null,这样一来别的业务方判断空指针异常
综上总结：
1、项目重构前一定另外拉分支,修改项目的版本号,便于回滚
2、严格测试,用测试账号测试线上接口保留返回值,然后同样的操作用于被重构后的接口,比对连个返回值是否相同,如果不同,那么就需要弄明白是否对线上业务造成影响
4、慢查询引发的线上事故一次我上线了一个查询接口,但是不久被反馈线上服务部分出现超时,经过排查后发现sql的字段没有加索引。
总结：当我们上线新的服务时候必须经过沙箱严格测试包括性能指标。
5、内外部实体未解耦引发的线上事故背景：
我们在新开发一个功能的时候在数据库中增加了一个int类型的字段,而这个字段主要用于服务内部,并不会对外进行提供,但是在更新库存的时候并没有分离内外部实体,然后在更新的时候讲这个字段值覆盖成为0导致了线上的bug。
修复过程：
内外部实体彻底解耦,内部接口不采用任何外部接口进行传输
综上总结：
设计阶段：