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