架构反模式
- 在模块设计中，避免这种自带大cache的模块。涉及到cache，将cache功能从频繁升级的模块中剥离出来，采用旁路式cache，或者cache 服务化。
- 同上述cache相同原理，对于自带大字典的模块，需将字典功能剥离，字典服务化。
- 主次不分的模块。比如说某产品线的模块，处于上下游的必经之路上，它集成了下游各种服务，包括重要的和不重要的，平均耗时长的和平均耗时短的。针对不同语言做不同处理
- 疯狂的重试&合理的超时值。这块特别适用于模块交互较多的情况，不合理的超时值和重试策略，危险性极大，很容易造成线上事故。从系统整体考虑，从上层到下层分配超时，上层分配大一点，下层小一点，并且要考虑重试和本模块计算时间的影响。
- 做性能测试以及上线评估时，需要考虑并发度对网络IO模型的影响。常用的IO模型包含xpool,epool,apool,cpool。选取IO模型时，需要避免以下两种情景
- 高并发场景选用xpool
- 长连接场景选用cpool
- 容错处理。容错处理时需要考虑以下异常情况：
- “陌生”的数据：因为数据源的更新频率远大于程序，所以难保什么时候有新的格式的陌生数据进来
- “奇葩”的数据：例如某些字段长度特别长，多了一些字段，少了一些字段，字段之间出现矛盾等
- 数据处理过程失败：要区分多种情况，比如是请求第三方服务失败，还可以区分是网络交互失败，还是第三方服务处理失败；比如是处理过程中失败。根据不同的情况，采取不同的恢复措施
- 写更新目标失败：还是要小心区分多种情况，是网络交互，还是更新目标写不进去等
- 如果是一个更新程序更新多个目标，需要考虑部分更新成功，部分更新失败的情况
- 考虑更新程序运行到一半正high时，被kill掉的情况，重新开始会不会有副作用，会不会太慢等
上述这些情况下的容错处理，包括以下，需要具体选择
- 重试几次
- 直接跳过
- 记录并且跳过，根据记录，能够手工修复
- 暂停然后报警
- 停止然后报警
- 接收到报警之后，人工介入的方法
- 业务升级导致的不一致性问题。这块需要加强对业务和架构的理解
- 对外接口缺少请求来源字段。这种不利于定位问题
编码反模式
- 函数接口升级未考虑返回值的兼容性
- 不检查其他模块传来的数据
- 重复实现基础库已经实现的代码
运维反模式
- 上线时用cp更新bin和so文件。最好是用mv
- 同机部署不同重要性的服务
- 重要数据无权限控制
- 不清理过期数据