一线工程师宝贵经验:架构的深入思考 From FunData

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

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

摘要

本文与上一篇完全不同,从另一个角度来阐述为什么FunData的系统需要优化,整理出怎么优化架构的一些思路吧,希望能为各位看官带来一些灵感和思考。

我们还是先从FunData的两张架构图开始吧。

图1ETL 架构图1.0

图2ETL总架构图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服务,即在有图片上传时触发各种图片处理的算法。

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180712A1TN0I00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券