成立于2010年，仅凭*借贷的30万欧元起家，从芬兰30平走出来的游戏公司Supercell在短短4年时间里凭借《海岛奇兵》《部落冲突》《卡通农场》这三款游戏获得了17亿美元的收入，第五年受马云及阿里高管团队的登门取经，第六年被恐为人后的腾讯以86亿美元收购其84.3%的股权。

腾讯下了一步好棋，在过去的十年（2010-2019）里，Supercell的《部落冲突》和《皇室战争》在全球手游总收入排行榜上分别位列第一和第十（农药第七）。当然错失先机的阿里也并非一无所获，从Supercell高效的组织模式与技术架构，阿里改组了事业群编制，并提出出了“大中台，小前台”的架构，一直热门至今。

回头来看Supercell这家公司，从其各款游戏的画风来看，基本是由一套统一的3D模型加工而成。（下图从左至右：部落冲突、皇室战争、海岛奇兵）

当然这完全可以理解，毕竟画风就是游戏公司的招牌，换画风相当于放弃既有用户群体。另一方面也最大程度减小了美工团队的规模和工作量，我们可以看到目前250人的Supercell中每个游戏（共5款游戏）平均只有20人的团队运维，其中还包括3名服务器开发人员。

详细来说，Supercell将组织按产品线分割，而非传统的职能分割，管理以自底向上的方式，其创始人埃卡·潘纳宁在接受采访时就表示希望成为全球最“弱”的CEO，所有决定由游戏团队来做，毕竟研发者才是最接近玩家的，他们比任何人都更清楚玩家的需求。扁平化的管理也使得开发流程更加高效，敏捷的不仅是开发团队，还包括整个组织。

Supercell没有单独的运维团队，每个游戏团队有自己独立的AWS账号（Supercell的IT轻资产化，所有应用程序都搭建在AWS EC2上），每个团队各自应付数以亿计的活跃用户、高达400万次的峰值并发带来的应用压力，以及AWS EC2上成百到数千的实例和跨地域不同数量的数据库带来的运维压力。

解决了组织架构，为满足企业在不同时期所面临的外部并发，技术架构也必须是弹性扩展的，为此Supercell在成立第二年（2011年）就完成了应用的微服务化与数据库层的切片。甚至来说Supercell的微服务更轻量级，所有的游戏都复用一套网关代理、主页模块、匹配模块和战斗模块。整个组织使用一套高可用的组件库，一种开发语言，一个团队即One Repo，One Language，One Team。上过阿里中台课程的同学听着是不是很熟悉？

微服务化可以方便地对任何一个功能模块进行横向扩展，作为一款游戏来说，玩家的状态信息是实时变化的，因此战斗模块中的所有组件都需要更新用户状态，全局的Zookeeper服务可以保证各组件间的用户状态保持一致。用户的所有状态更新会通过事件的形式存放在持久数据湖中，关于事件驱动可查看小编之前的文章。以下是玩家等级提升的事件样例。

数据切片是将海量的用户数据分地域存储，每个地域的数据保持多个副本。类似于对数据的行进行拆分，但是不同地区数据的Schema是一致的。在数据量不断增大时，只需增加切片数量来应对。

2012年，Supercell采用了统一的事件收集器，用户产生的所有游戏内数据通过REST API传递到AWS上的事件接收器，再以CSV的形式存放到Amazon S3存储中。

随后的一年，一些团队发现S3中的数据质量堪忧，为提升数据的精度，在2013年，Supercell的技术架构上加入了服务端事件收集器作为数据质量校验的补充事件源，使用UDP通讯协议的目的是减少交互，最小化对游戏主服务器的影响。

事件管道的好处是架构简单并且比传统数据库更能体现细节，毕竟传统数据库只展示数据的最终状态，事件可以帮助查看达到这一状态的完整过程。其弊端就是无法提供实时访问，稍不注意就会磁盘写满导致数据溢出，并且Amazon S3是消费数据的唯一渠道。

2013年下半年，Supercell终于考虑添加流式管道（Streaming Pipeline）作为数据缓冲层，由于之前和AWS的良好合作，这次的流管产品多数团队也是投票给了Kinesis，相对于Kafka，它的运维更加简单，体验更好（天生与AWS管理界面集成），后续可以对接各种事件消费者，不论是实时查询面板，第三方集成，实时分析，还是通过事件集成入库S3。

这套架构的优势在于即便在系统故障时数据仍是安全的；访问数据更实时以及多通路的数据消费/订阅，这有点像之前小编介绍的Uber数据架构，只是streaming的产品换了。

熟悉Kafka的人都知道，在同一个消息分区（Partition）中，事件的时序是有保障的，但是为了运维方便加之对游戏软件对时序并不敏感，Supercell采取了随机分区的方式在不同数据切片上的负载均衡。
2013年同期在数仓设计上，Supercell使用Azkaban批量工作流任务调度器将CSV数据加载到AWS的Vertica数仓中，数据科学家通过开发接口对历史数据进行分析，形成一些数据服务，对内或对外输出。

这个架构在今后几年里遇到了新的瓶颈。首先Vertica集群的负载达到的峰值，第二在ETL的时候查询会变得缓慢，第三数仓的扩容花费巨大，第四存储与计算耦合紧密，第五再大的宽表数据库都会有列的极限。注意到这些问题之后，Supercell致力于：

• 限制Vertica的数据存储量；
• 将存储与计算资源切割；
• 将ETL流程与查询流程切割；
• 维护单一来源的置信数据；
• 利用云的便利性优化资源使用。

到2018年，公司决定将Amazon S3作为单一置信来源，以Parquet列表的形式存放数据，将Amazon EMR用作ETL转存目标，原来的Vertica只用来存放计算结果（例如账号、统计数据和KPI）而不是原始数据。

这样一来，Azkaban还是控制ETL流程，只是这次加载到Amazon EMR托管集群平台，然后以多张Parquet列表的形式存放到Amazon S3中，因为公司已经对数据行数做了切片，使用列表存储更能提升存储效率。

分布式的S3作为唯一置信源，消费使用与列表更加契合的Athena作为查询工具，数据科学家可以到源数仓EMR中查看实时数据并做分析，包装成实时数据产品，也可以通过界面工具到置信源S3或结果数仓Vertica中查看OLAP大数据并进行建模分析，生成数据产品。

在2018年完成改造之后，由于EMR的延展性，可以瞬间扩展出大量的数据集就很好地解决了列宽的问题，并且有效地将存储与计算分离（EMR复制计算，S3负责存储）。在ETL时可以通过计划任务扩建一个集群跑ETL，跑完之后释放资源。而且EMR的环境对于数据科学团队来说更加友好。

现在Supercell已被腾讯收购，相信Pony不只是为了代理它的海岛奇兵，腾讯云一定也在酝酿一个“中台计划”。