微服务的一些实践

• 在核心链路上，服务可以冗余它依赖的服务的数据，依赖的服务故障时，服务尽量做到自保。比如订单服务依赖库存服务。我们可以在订单服务冗余库存数据（注意控制合理的安全库存，防超卖）。下单减库存时，如果库存服务挂了，我们可以直接从订单服务取库存。可以结合熔断一起使用，作为熔断的Fallback（后备）方案
• 服务之间调用要有熔断、线程隔离的措施    隔离的考虑可以分为  部署的隔离、数据存储的隔离、业务系统的隔离
• 服务降级
• 监控   数据库慢查询、服务调用异常、linux系统cpu内存、jvm监测、中间件监测
• CDN的使用
• 避免单点问题
• 服务降级   
• 数据冗余
• 分布式事务的使用
• 数据迁移、分库分表

  开启双写，新老库同时写入（涉及到代码改动）。注意：任何对数据库的增删改都要双写；对于更新操作，如果新库没有相关记录，
  先从老库查出记录更新后写入数据库；
  为了保证写入性能，老库写完后，可以采用消息队列异步写入新库。同时写两个库，不在一个本地事务，有可能出现数据不一致的情况，
  这样就需要一定的补偿机制来保证两个库数据最终一致。
  下一篇文章会分享最终一致性解决方案
  将某时间戳之前的老数据迁移到新库（需要脚本程序做老数据迁移，因为数据结构变化比较大的话，从数据库层面做数据迁移就很困难了），注意：
  1，时间戳一定要选择开启双写后的时间点，避免部分老数据被漏掉；
  2，迁移过程遇到记录冲突直接忽略（因为第一步有更新操作，直接把记录拉到了新库）；迁移过程一定要记录日志，尤其是错误日志
  第二步完成后，我们还需要通过脚本程序检验数据，看新库数据是否准确以及有没有漏掉的数据
  数据校验没问题后，
  开启双读，起初新库给少部分流量，新老两库同时读取，由于时间延时问题，新老库数据可能有些不一致，所以新库读不到需要再读一遍老库。
  逐步将读流量切到新库，相当于灰度上线的过程。遇到问题可以及时把流量切回老库
  读流量全部切到新库后，关闭老库写入（可以在代码里加上可热配开关），只写新库
  迁移完成，后续可以去掉双写双读相关无用代码。