在项目的发展前期，依照MVP理论（最小化可行产品），我们迅速推出FunData的第一版系统（架构图如图1）。系统主要有两个模块：Master与Slave。
Master模块功能如下：
定时调用Steam接口获取比赛ID与基础信息
通过In-Memory的消息队列分发比赛分析任务到Slave节点
记录比赛分析进度，并探测各Slave节点状态
Slave模块功能如下:
监听队列消息并获取任务(任务主要为录像分析，录像分析参考github项目clarity
分析数据入库
系统上线初期运行相对稳定，各维度的数据都可快速拉取。然而随着数据量的增多，数据与系统的可维护性问题却日益突出。
新增数据字段需要重新构建DB索引，数据表行数过亿构建时间太长且造成长时间锁表。
系统耦合度高，不易于维护，Master节点的更新重启后，Slave无重连机制需要全部重启；同时In-Memory消息队列有丢消息的风险。
系统可扩展性低，Slave节点扩容时需要频繁的制作虚拟机镜像，配置无统一管理，维护成本高。
DB为主从模式且存储空间有限，导致数据API层需要定制逻辑来分库读取数据做聚合分析。
节点粒度大，Slave可能承载的多个分析任务，故障时影响面大。
在开始2.0架构设计与改造前，尝试使用冷存储方法，通过迁移数据的方式来减轻系统压力（架构设计如图2）。由于数据表数据量太大，并发多个数据迁移任务需要大量时间，清理数据的过程同样会触发重新构建索引，方案的上线并没有根本性地解决问题。在V2.0版本里面，从维护性、扩展性和稳定性三个方面来考虑新数据系统架构应该具备的基本特性：
数据处理任务粒度细化，且支持高并发处理（全球一天DOTA2比赛的场次在120万场，录像分析相对耗时，串行处理会导致任务堆积严重）
数据分布式存储
系统解耦，各节点可优雅重启与更新
后来也是运用到了分布式的架构
在系统的解耦上
1.0架构中使用In-Memory的消息队列做数据传递，由于内存中队列数据没有持久化存储并与Master模块强耦合，Master节点更新或者异常Panic后会导致数据丢失，且恢复时间冗长。因此，在2.0架构中采用了第三方的消息队列作为消息总线，保障系统“上下游”节点解耦，可多次迭代更新，历史消息变得可追踪，基于云平台消息堆积也变得可视化。
1.0系统的数据API层为实现快速上线，在架构上未做太多的设计与优化，采用域名的方式实现负载均衡，并使用开源的DreamFactory搭建的ORM层，利用其RESTful的接口做数据访问。该架构在开发和使用过程中遇到许多问题：
API层部署在国内阿里云上，数据访问需要跨洋
ORM层提供的API获取表的全字段数据，数据粒度大
无缓存，应对大流量场景(如17年震中杯与ESL)经常出现服务不可用
多DB的数据聚合放在了API层，性能不足
服务更新维护成本高，每次更新需要从域名中先剔除机器
后来对于数据的高可用性：接入分布式存储系统后，对外数据API层也根据扩展的数据维度进行拆分，由多个数据API对外提供服务，例如比赛数据和联赛赛程等数据访问量大，应该与英雄、个人及道具数据分开，防止比赛/赛事接口异常影响所有数据不可访问。
文中部分截图，内容摘自原文的专业属于总结，如有不适，请联系15227013954