从0到千万级并发服务架构演化

背景介绍

回顾

ShareSDK,顾名思义,分享的SDK组件,公司基于互联网,早期主要以ShareSDK起家。今日思来,很幸运,能陪着ShareSDK一起成长。

从0到千万级并发服务架构演化

如图

经典的单体应用架构, 和很多初创企业一样,当时采用这种架构。用redis等缓存挡住并发,用MySQL来存储数据。

前端的报表分析直接操作MySQL即可。

我并不反对单体架构,反而我觉得很合适,由于初创企业业务形态并不稳定,单体架构其实很容易调整,杀鸡焉用牛刀。

公司是国内第一家做移动端分享SDK的企业,随着业务发展,由于几乎每个APP都会有分享功能的需求,业务发展飞快。

我记得当时一个“魔漫相机”App就占据了我们半壁带宽。

问题与挑战

分流

在业务请求的入口并未根据业务做轻重之分,导致数据交互类的接口以及日志数据上报的接口共享网关。

  • 业务高峰,请求拥堵,核心数据交互的接口失败导致用户体验极差

  • 服务降级无法实施,相对而言,日志上报接口并不属于核心业务流程

  • 无法做线路区分,只能统一使用BGP,带宽等成本高

统计分析

早期数据直接落地MySQL,通过MySQL做统计分析。

  • 数据插入并发数受限,性能堪忧

  • 存储集群未拆分,不能根据业务特点分而治之

  • 查询慢

业务支持受限

由于整个架构比较简单,对于复杂的业务以及大数据分析支持基本上谈不上

基于单体应用,我们基本上看不到未来,这除了单体应用本身的局限性之外,在架构上本身也跑不动。这样就造就了成本以及资源的重度浪费。

系统架构演化

从0到千万级并发服务架构演化

服务架构

  • 通过业务域名拆分以及智能DNS,实现不同地域国家省市&不同业务落入不同网关(不同机房),不同带宽线路

  • 业务拆分、微服务化,不同业务区别对待,资源上也是分而治之

  • 服务拆分: 公共服务 & 具体业务服务

梳理后的整个服务架构,从请求端到网关API再到具体的业务处理,流量上可以随意切割以及合并,很方便的做扩容以及缩容操作。

数据架构

数据分为基础数据以及统计分析数据。

将核心关键的基础数据,比如配置信息等提取出来,分库存储,将所有的统计分析数据以及可异步存储数据落地本地磁盘,再由flume实时拉走。这样带来的好处有很多:

  • 基础数据可以选用高性能存储,极大加速部分核心业务响应

  • 采用模hash、一致性hash、日期等算法分隔不同的数据,分实例存储,方便扩容

  • 引入搜索引擎,专职前端&客户端的查询请求

  • 亚博登录不上引入Flume、Kafka,采用落地日志 + Flume + Kafka实现数据流分发,即使Flume挂了,由于日志先落地,所以待Flume修复后,仍然可以保证数据无丢失无断层继续传输,而在Flume上面,我们采用了Kafka Channel,而不是普通的FileChannel、MemoryChannel等,使之即使在流量高峰,也不至于导致FlumeServer挂起

  • 不同数据分析需求(如APM、业务统计等等)接入FlumeServer 或者 Kafka 按需获取数据处理

心得体会

上述简单讲到了服务架构以及数据架构的演化,但是细致各个环节可以有很多道道。包括服务的自动化部署,DI/DC以及链路监控等并未细说提及。

对于个人,最深刻的理解有两点:

  • 分而治之

充分理解各个软件工具本身适合的领域,让专业的软件工具对付它们擅长的业务,而不是一招拍死

  • 充分理解业务

架构基于业务,好不好的架构要看什么样的业务,如果换成公司的IMSDK,显然这个架构完全不合适。

  • 追求架构简单

数据每一次流动,都可能伴随一定的异常。那么架构简单如何体现?

能用一两层服务解决的事情绝对不使用三层服务,方便数据追踪跟进以及业务排错。

其次,服务业务尽可能简单,ShareSDK的配置服务以及社交信息服务等都是各自独立,这在团队分工优化上也显得简单。

结语

诚然,整个服务架构可以轻松应对千万级并发。但是,我认为可以优化的空间还有很多。期望,整个ShareSDK服务架构能伴随公司继续成长壮大。

文/Mob开发者平台 技术经理 觉醒