微服务：迁移开关的设计。
本文介绍在应用微服务架构的过程中，对迁移场景下不一致问题的解决方案。
在大多数企业里，新项目和老项目一般会共存，大家都在努力的去掉老项目，但是由于种种原因总是去不掉，如果要彻底的去掉老项目，就必须有非常完善的迁移方案。
在迁移过程中必须使用开关，开关一般都会基于多个维度来设计，例如：全局的、用户的、角色的、商户的、产品的，等等。如果在迁移过程中遇到问题，则我们需要关闭开关，迁移回老的系统，这需要我们的新系统兼容老系统的数据，老系统也兼容新系统的数据。从某种意义上来讲，迁移比实现新系统更加困难。
有的开关设计在应用层次，通过一个curl语句调用，没有权限控制，这样的开关在服务池的每个节点中都有可能是不一致的；还有的系统将开关配置在中心化的配置系统、数据库或者缓存等中，处理的每个请求都通过统一的开关来判断是否迁移等，这样的开关有一个致命缺点：在服务请求的处理过程中，开关可能会有变化，各节点之间的开关可能不同步、不一致，导致重复的请求可能既走到新逻辑又走了老逻辑，如果新逻辑和老逻辑没有保证幂等，则这个请求就被重复处理了，如果是金融行业的应用，则可能会导致资金损失，电商系统可能会发生法活和退款同时进行等问题。
这里推荐使用订单开关，不管我们在什么维度上设计了开关，在接收到服务请求后，在请求创建的关联实体（例如：订单）上标记开关，对于以后的处理流程，包括同步的和异步的处理流程，都通过订单上的开关来判断，而不是通过全局的或者基于配置的开关来判断，这样在订单创建时，开关已经确定，不再变更，若一份数据不再发生变化，那么他永远是并发安全的，并且不会有不一致的问题。
这种模式在生产中的使用比较频繁，建议每个企业都把这种模式作为设计评审的一项，如果不检查这一项，则很多开发人员都会偷懒，直接在配置或者数据库中做个开关就上线了。
