公司在项目开发中，生产环境的数据库是不能直接进行新增、修改、删除操作，只有查询的权限。包括
我们的负责人在内也是同样的权限。这就导致一个问题，如果出现问题，是不能直接操作数据库进行处理的。
如果出现问题的时候，不能直接操作数据库就很麻烦，而且规矩就是规矩，得遵照执行。可是生产问题也不能
放任不管，得想办法解决，这些问题是需要在开发阶段都需要考虑到的。下面就来聊聊项目开发中的备用接口。
.a.数据迁移的备用接口。
真实的应用场景1：随着项目的开发，需要新增表，可能会通过SQL语句复制原有的数据到新表当中。比如新增一张草稿表，
需要将原有的数据复制到草稿表当中。在项目发布新版本的时候，可以执行一次SQL。可是如果执行这一次SQL之后，原有的
业务逻辑还是按照原来的方式执行，旧表可能会有新的数据。这时候就需要再次全量执行或者是按条件执行复制数据的操作，
这时候就只能通过接口来触发这个操作。
真实的应用场景2：原来设计的表已经不能满足现有的需求，重新设计原有的表之间的关联关系，并且还新增几张表。这时候
处理原有的旧数据时，就需要按照一定的规则将原有的数据插入到新表当中。同样的，发布新版本时可以执行一次SQL语句，
如果后期出现问题，不能再次执行SQL。这时候就需要使用运维接口，使用接口来执行相应的SQL语句，解决问题。
.b.缓存恢复接口。
应用场景：系统迁移时，原有的缓存数据并不会一起迁移，比如做信创改造的时候，操作系统和各种软件都要求使用国内
自主研发的。新系统部署代码之后，就需要做缓存恢复的操作。一种恢复方式是每次用户查询的时候，根据用户信息自动
恢复对应的缓存数据。如果这种方式没有成功，则使用接口来进行全量恢复，解决缓存恢复可能出现的问题。这个操作在
系统中使用了好几个接口来做这个事情。
.c.缓存操作接口。
由于不能直接连接redis缓存数据库，因此对于缓存操作，比如说查询，修改，删除操作。都提供了对应的接口。一般情况下
不会去直接使用这个接口，只是在遇到一些特殊情况的时候，需要排查问题的时候，查看缓存数据对不对就需要使用这些
接口来进行排查。当然权限这一块自己一定要控制好，避免出现越权的情况，那就很尴尬。还比如app首页查询的数据，都是
从缓存当中取的，有定时任务去执行将数据库的数据加入到缓存中。如果执行失败，则需要考虑手动执行，这时候添加一个接口，
手动执行这个缓存添加操作，以备不时之需。
.d.根据条件修改某张表的数据。
一般的业务都有删除操作，可是在业务执行过程中，某些操作需要关联多张表进行操作。主表的数据如果删除之后，后续的逻辑
就执行不了。添加一个主表数据的恢复接口，根据主键恢复数据，防止业务执行过程出现问题。正常情况下也不会去使用这个接口，
可是在异常情况下，可能就会需要去手动去执行这个接口，恢复一些被删除的数据。
.e.通过接口触发、模拟一些核心业务逻辑的操作.
对于某些复杂的业务逻辑，需要走的流程比较多，并且操作很复杂。这时候可以考虑通过接口来触发执行某些复杂的，比较重要的
业务逻辑，这样也非常便于测试业务流程与业务逻辑是否正确。打个比方现在很多app比如淘宝，京东都有很多抽奖的功能，如何
去模拟抽奖，领奖的功能，就可以考虑使用接口来触发，去模拟这个过程。
.f.通过字典表开关控制，让程序执行新代码还是旧代码。
某些系统的设计，对于字典表数据是定时更新到缓存中，这时就可以考虑在字典表中配置一些开关数据。举个具体的示例，如果查询
语句有更新，新系统发版的时候，会关联第三方系统。需要第三方系统发版成功之后，才能起用新的查询；如果第三方系统发版失败，
回滚代码，这个查询也需要使用原有的查询，这时候就可以考虑使用开关来动态控制是否使用新查询。在使用MQ切换的时候，是否
使用新的MQ；或者是在新旧系统进行切换的时候，可以考虑使用新的数据源还是旧有的数据源。
原文地址：http://www.cnblogs.com/yilangcode/p/16908463.html
