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

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

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

摘要

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

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

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

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

推荐文章

  • Hulu大数据架构与应用经验
  • 点融网亿级业务量背后的大数据技术应用
  • 大数据平台架构技术选型与场景运用

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2018-07-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师之路

互联网分层架构,为啥要前后端分离?

通用业务服务化之后,系统的典型后端结构如上: web-server通过RPC接口,从通用业务服务获取数据 biz-service通过RPC接口,从多个基础数据s...

4028
来自专栏Golang语言社区

GitHub上优秀的Go开源项目

近一年来,学习和研究Go语言,断断续续的收集了一些比较优秀的开源项目,这些项目都非常不错,可以供我们学习和研究Go用,从中可以学到很多关于Go的使用、技巧以及相...

2244
来自专栏程序猿DD

互联网分层架构,为啥要前后端分离?

作者:58沈剑,来源:架构师之路 一,典型后端架构 ? 通用业务服务化之后,系统的典型后端结构如上: web-server通过RPC接口,从通用业务服务获取数据...

3028
来自专栏CSDN技术头条

浅析:如何构建稳定的系统

作者:Jesper L. Andersen 原文:How to build stable systems 译者:孙薇 准备工作 第一个决策是最简单却最为重要的...

2196
来自专栏杨建荣的学习笔记

任务调度的思考和总结

1905
来自专栏Java架构

阿里java架构师:微服务写的最全的一篇文章

今年有人提出了2018年微服务将疯狂至死,可见微服务的争论从未停止过。在这我将自己对微服务的理解整理了一下,希望对大家有所帮助。

2K3
来自专栏云计算D1net

公有云提供商挑选准则

当涉及到选择一个公有云供应商时,成本常常是第一个考虑的因素。但其他的因素,例如虚拟机迁移,存储和自动扩展等,也都应该考虑在内。 在企业转移到公有云或混合云时,不...

4067
来自专栏北京马哥教育

抛开 Android 不谈,谁是最受欢迎的 Linux 发行版

2024
来自专栏腾讯移动品质中心TMQ的专栏

FAT(Fast-AutoTest) —专业服务于微信H5/小程序UI自动化测试

随着项目的发展,许多项目中H5(特别是微信平台内)以及小程序占比逐渐增多,因此快速建设相关的自动化来提高项目的效率和质量成为了许多项目中的重中之重。

1.9K7
来自专栏软件测试经验与教训

自动化测试实施方案

1.1K6

扫码关注云+社区

领取腾讯云代金券