• 在核心链路上，服务可以冗余它依赖的服务的数据，依赖的服务故障时，服务尽量做到自保。比如订单服务依赖库存服务。我们可以在订单服务冗余库存数据（注意控制合理的安全库存，防超卖）。下单减库存时，如果库存服务挂了，我们可以直接从订单服务取库存。可以结合熔断一起使用，作为熔断的Fallback（后备）方案
  • 服务之间调用要有熔断、线程隔离的措施    隔离的考虑可以分为  部署的隔离、数据存储的隔离、业务系统的隔离
  • 服务降级
  • 监控   数据库慢查询、服务调用异常、linux系统cpu内存、jvm监测、中间件监测
  • CDN的使用
  • 避免单点问题
  • 服务降级   
  • 数据冗余
  • 分布式事务的使用
  • 数据迁移、分库分表
开启双写，新老库同时写入（涉及到代码改动）。注意：任何对数据库的增删改都要双写；对于更新操作，如果新库没有相关记录，
先从老库查出记录更新后写入数据库；
为了保证写入性能，老库写完后，可以采用消息队列异步写入新库。同时写两个库，不在一个本地事务，有可能出现数据不一致的情况，
这样就需要一定的补偿机制来保证两个库数据最终一致。
下一篇文章会分享最终一致性解决方案
将某时间戳之前的老数据迁移到新库（需要脚本程序做老数据迁移，因为数据结构变化比较大的话，从数据库层面做数据迁移就很困难了），注意：
1，时间戳一定要选择开启双写后的时间点，避免部分老数据被漏掉；
2，迁移过程遇到记录冲突直接忽略（因为第一步有更新操作，直接把记录拉到了新库）；迁移过程一定要记录日志，尤其是错误日志
第二步完成后，我们还需要通过脚本程序检验数据，看新库数据是否准确以及有没有漏掉的数据
数据校验没问题后，
开启双读，起初新库给少部分流量，新老两库同时读取，由于时间延时问题，新老库数据可能有些不一致，所以新库读不到需要再读一遍老库。
逐步将读流量切到新库，相当于灰度上线的过程。遇到问题可以及时把流量切回老库
读流量全部切到新库后，关闭老库写入（可以在代码里加上可热配开关），只写新库
迁移完成，后续可以去掉双写双读相关无用代码。