一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第11天，点击查看活动详情。
最近对创作灵感的功能进行了迭代升级，主要有以下功能变化
- 所有热点都展示视频
- 联动必剪素材
- 增加主题分类
- 增加稿件feed流功能
因此需要对之前的功能进行一系列的迭代升级，我这里总结一些日常开发中可以借鉴的地方。
使用4s的方法进行分析。关于系统设计的方法，可参考：《系统设计面试指北》
Scenario 场景
本次多了非常多的外部依赖，针对不同的外部依赖，需要采用不同的做法。
- 对于更新频率要求较高的数据源
有些外部数据，如果每次都实时查的话，大概有几百的QPS，不光意义不大，同时也会给对方服务带来比较大的压力。
因此，可以考虑在我们服务里走一层缓存。缓存比较常见的有两种，一种是local cache，一种是redis缓存。
local cache直接存储在内存中，不需要引入额外的外部依赖，如果所有用户访问的数据都是同一份的话，可以考虑存储在local cache里。
具体的实现逻辑是：服务刚启动的时候，先加载一遍local cache，然后启动异步的定时任务，比如每10s一次，去更新缓存。
- 对于更新频率要求不高的数据源
有的数据，如果要求的是t+1更新，我们可以使用定时任务的方式。
有些优秀的分布式调度工具，比如celery，xxl-job，可以帮助我们去做定时任务的调度。每天执行一次任务即可，数据可存储在MySQL中。
Service 服务
在我们本次的设计中，同时做了微服务的拆分。
我们把提出了一个叫做聚合网关的概念，原来的服务，只会聚合各个微服务的数据进行展示，可以接触对原来数据库的依赖。
微服务拆分后，有常规的三块内容，接口、后台管理、任务。
同时，对于原服务的老接口，我们要么把它重定向到新服务上，要么在新服务上提供rpc接口，供原服务读取数据。
Storage 存储
本次的存储也比较常规，MySQL+Redis即可满足需求。MySQL是存储一些业务数据，而Redis存储一些关键的key，以及去做分布式锁。
Scale 扩展
因为这次引入了定期刷新缓存的机制，运营配置完后，无法立刻看到效果，引起了他们的不满。
因此除了定期刷新缓存之外，额外设计了一种版本号管理的方式。
即在admin后台的操作，会以当前时间戳为值，在redis中记录一下版本号，实例在运行过程中，也会内部维护一个版本号，如果当检查到当前版本号，比redis的版本号要小，则触发一次主动更新。
这样主动更新+轮询更新的方式，可以有效保证缓存为最新。
当然，还可以考虑用消息队列广播的形式，不过这个我没有试过，理论上是可行的。
