设计阶段明确内外部实体的职责,内外部实体不必保持一致,外部实体主要传输业务方需要的字段(具有业务含义)而内部实体需要和数据库字段保持一致。
升级阶段：
升级内部逻辑：
有时候因为某些原因我们需要进对内部服务升级,这个时候我们一定要注意是否在内部服务中采用了外部实体进行传输,如果有进行外部实体进行传输的就一定注意更改内部实体影响业务方,如果时间准许应该进行内外部实体进行解耦
某个业务方需求：
如果某一个业务方有特殊需求涉及属性的更改,这个时候考虑这个需求是否合理,是否应该我们服务提供的能力,如果可以通过配置化规则来解决,如果解决不了然后升级服务版本,对返回值进行升级,但是内部一定要注意不要影响其他业务方调用
所有业务方需求：
更新pom版本升级服务,统计所有的调用方,让调用方进行升级
6、持久层捕获异常引发的线上事故背景：
持久层捕获异常并没有抛出
综上总结：
持久层中尽量不进行异常捕获,如果需要捕获接口中必须要有返回值
7、枚举使用不当引发的线上事故详情请查看https://www.cnblogs.com/LipeiNet/p/9487900.html
8、限流把控不严引起业务方资源无法添加背景：某个业务方用MQ异步调用我们的服务,但是他们是刷数据所以短时间内流量特别大,因为我们服务的限流这样一来就出现大量的数据添加异常。
问题分析：主要出现这样的问题原因有下面2个
1、业务方定时处理数据的时候没能周知我们
2、我们并没有把流量进行削峰
综上总结：
1、在服务文档上特别加上业务方定时跑数据时候提前邮件周知最大QPS,数据的量级以及操作时间
1、采用流量削峰,避免短时间的流量过来造成业务异常,主要做法将短时间多出的流量存储在MQ端,如果出现一定量级采用报警