架构的深刻思考 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服务，即在有图片上传时触发各类图片处理的算法。

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