架构的深入思考 From FunData

内容来源： 之前作者写了一篇《FunData — 电竞大数据系统架构演进》的文章，传送门：http://t.cn/RdgKWGW 觉得没有深入写出一些深层次的东西。纠结了几个晚上决定重写一篇不一样的文章。本文由IT大咖说（微信id：itdakashuo）整理，经投稿者与嘉宾审阅授权发布。

阅读字数： 3497 | 9分钟阅读

图1 ETL 架构图1.0

图2 ETL总架构图2.0

架构1.0和2.0都属于 微服务架构 ，架构2.0在原有的基础上对数据传输的模型，数据存储与渲染的方式及服务治理等方面做了更多的改进。

数据传输模型

1.0架构我们选择的主语言是 Python ，系统模型是 Master-Slave ，通过 Python 自带的MQ库构建数据传输的模型。处理的逻辑即从STEAM公开接口拉取比赛数据，将比赛任务分配给各个Slave节点处理，处理记录元数据和处理的数据落地MySQL。

InMemory的队列模式，对我们系统维护上带来许多不方便。Slave节点的更新重启，因为没有注册服务保证任务执行完后节点的正常下线，重启时很随机，无法保证在节点内的任务正常执行完；Master的节点更新重启，需要所有Slave节点全部重启一次，建立新连接，当然这里可以用重连机制（ 这个之后会结合service mesh讨论 ）。

因此架构2.0使用MQ服务将上下游的系统解耦开，并采用消息总线的方式推送消息，从原来的 Master-Slave 的方式转成 Controller-Worker 的方式，这样的好处是一方面系统更新没有依赖，亦不需要重启整个系统；另一方面，更加细化的worker可以让我们的针对不同数据要求编写worker，使得数据处理变得更可控(可插拔的方式)，有针对性的做worker扩容，资源使用率更加精准。

数据落地方式

早期我们使用的是主备模式的MySQL，容量上限为2T，存储上很容易出现瓶颈，当时没有 分布式MySQL 和 读写分离模式 ，达到容量瓶颈后，只能新增一个主备MySQL，在ETL和API层多配置一个DB入口做数据存储和聚合处理，着实很麻烦，另外配置要维护的很准确；另外团队数据点的需求一直在变化，结构化的存储很不利于数据点的扩展。

2.0里我们果断选择NoSQL且分布式存储的方式，具体请参考 FunData电竞大数据系统里对数据存储的设计和思考 。

服务治理

1.0的系统属于快速迭代上线的产物，旁路系统的建设几乎为0，系统在线上常常是“裸奔”的状态。为了保证服务的稳定性，我们引入了很多旁路建设。

• K8S - 减少服务运维压力，增加系统的扩展性。

• 日志系统 - 系统处理异常可追踪

• 灰度系统与负载均衡 - 接口更新及请求流量可控

• Harbor + Registry - 镜像仓库统一管理，代码分版本

• CI/CD - 快速上线，统一部署与测试

• Serverless - 将耗资源的算法，分配到serverless服务，不独立维护系统，pay-as-you-go

……

我们在FunData的微服务架构上还在持续优化，通过更好的架构和计算模型处理更多的数据，处理更多的电竞游戏数据。

看了FunData的架构优化后，可能大家有疑问说我们在系统的架构设计上 为什么不能一步到位 呢？ 微服务架构是"万金油" 么？

个人认为系统设计是没有统一公式的，关键在于在系统迭代的过程中，通过合理的分层与组合得到符合业务发展的架构形态。在系统架构设计上有如下一些思路，供大家参考。

单点系统

项目早期或者demo阶段，单点服务设计的方式会更加适合。一方面快速验证想法，另一方面没有太多成本上的压力，不要考虑HA/AZ容灾之类，功能实现和业务逻辑的自证才是核心。

单点系统

对于小团队，单点服务使用一个repo维护代码已经足够，也只需要一台服务器跑起服务即可。

微服务

微服务架构的使用，可以从以下几点考虑

• 团队变大，单个repo的代码变得臃肿，包含10几种的业务功能，比如商城的登录、用户体系、购物车、支付等等。这种一个panic就搞垮整个商城的设计已经无法满足业务发展。

• 资源使用率参差不齐，可以考虑把逻辑拆分出来，对更细化的系统做合理的扩展，也不容易遇到一个业务瓶颈拖垮整个网站的情况。

• 系统需要分层和抽象时，比如拆分部分逻辑后，再整个系统需要一个统一的接入层做请求的调度，再比如数据量增大时，需要有独立的数据代理层来处理数据的聚合和batch insert的操作。

微服务架构参考

设计微服务架构时，一般是分层的设计思路，主逻辑链路上一般可以分为接入层、逻辑层、存储层，各旁路系统则是服务于各个主链路层的各种服务。

例如：接入层引入负载均衡和灰度系统，实现流量控制，限速限流，高峰降级等；逻辑层接入注册服务和调度服务，帮助处理内部RPC的合理分配和高可用；存储层使用存储代理，负责读写分离，批量写入及数据聚合等工作。

像日志服务、监控服务和底层的应用管理平台、云平台作为任何形态的系统都必不可少的模块，服务于整个系统。

FunData监控

FunData日志分析

除了使用旁路系统为整个系统保驾护航，代码层面上也有不少工作，比如为提升内部系统通信的成功率和稳定性，我们需要增加重试的机制；对于内部使用的队列、对象存储和注册服务等封装了统一的SDK，提供连接池、定时更新服务列表及注册抢主等机制。

到目前为止，微服务架构已经被不断的实践，围绕微服务架构的技术栈也层出不穷，例如Spring Cloud系列的微服务框架（如下图），传统的ELK日志服务，Prometheus/Falcon监控系统，Etcd分布式存储，kubernetes容器服务等。

然而，微服务的架构不是万能的，随着系统的增多，对系统的管理成本会逐渐增加，服务之间的依赖关系也更加复杂。对于一个大型微服务系统(上百个节点的那种)，工程师需要花大量时间去理解里面的调用依赖。另外一点也是我的切身体会，在开发业务逻辑时，对于上述提到的重试机制、智能RPC调度及限速限流等功能，有时并不是我最关心的，业务逻辑才是核心，但是在微服务架构中不得不注入更多的保护代码，或者引用个庞大的通用SDK来完成这些功能。为此，2017年左右，业界提出了Service Mesh的概念。

借大佬的话“Service Mesh通常用于描述构成这些应用程序的微服务网络以及它们之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等”。

传送门

https://www.nginx.com/blog/what-is-a-service-mesh/

Service Mesh不是一个新的架构体系，而是作为微服务架构的一次升级，将服务发现、负载均衡、故障恢复等在架构设计中系统层面的优化抽象出来，作为一层基础设施，用于搭载各个业务逻辑。高大上的说法就是，让算法专注于算法，业务服务于业务。通过Service Mesh将系统Robust的各中优化与保护脱离于业务开发，可能未来就是系统工程师和业务开发工程师的区别了。

Serverless

最后的最后，Serverless的架构也是大家可以考虑和选择的。我们在内部也有Serverless系统的实践。

《Serverless的概念与系统架构设计》传送门： https://myslide.cn/slides/8295

在考虑serverless架构时，主要有以下几个考量

• 成本 - Serverless作为更碎片化的一种架构模式，这类服务一般只对使用多少核小时进行计费，不需要关心服务器部署

• 耗时计算或流量不稳定的计算 - Serverless系统一般搭载大量机器提供10万级以上的核数，如果业务上有一些算法消耗计算时间或者存在大量并发的突发情况，可以考虑将业务逻辑和算法接入Serverless做处理，减少运维压力。

• 事件触发的Pipeline - 举个栗子，我们会把图片、视频等静态资源上传到对象存储， 单张图片可能就有多种使用场景，例如需要裁剪、转格式或者增强之类，这时可以使用Serverless服务，即在有图片上传时触发各种图片处理的算法。

传送门关闭~~~搓炉石回城