资讯专栏INFORMATION COLUMN

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

starsfun / 4023人阅读

摘要:包括服务的自动化部署,以及链路监控等并未细说提及。结语诚然,整个服务架构可以轻松应对千万级并发。期望,整个服务架构能伴随公司继续成长壮大。

背景介绍 回顾

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


如图
经典的单体应用架构, 和很多初创企业一样,当时采用这种架构。用redis等缓存挡住并发,用MySQL来存储数据。
前端的报表分析直接操作MySQL即可。
我并不反对单体架构,反而我觉得很合适,由于初创企业业务形态并不稳定,单体架构其实很容易调整,杀鸡焉用牛刀。

公司是国内第一家做移动端分享SDK的企业,随着业务发展,由于几乎每个APP都会有分享功能的需求,业务发展飞快。
我记得当时一个“魔漫相机”App就占据了我们半壁带宽。

问题与挑战 分流

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

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

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

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

统计分析

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

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

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

查询慢

业务支持受限

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

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

系统架构演化

服务架构

通过业务域名拆分以及智能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服务架构能伴随公司继续成长壮大。

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/71162.html

相关文章

  • 万级消息设计-思考(一)

    摘要:特别是将消息看的很重的平台。场合用户到百万时,数据量到千万级后已经满足第一个条件后,平台再来几个推广活动。用户同时上线,参加活动会给用户发消息的时候平台对用户进行推送消息,进行促销时,参加活动,活动奖励等使用消息通知的。 说明 第一次写,也不知道写成什么样,喜欢的给个赞,不喜欢的给我留言。—— 蚂蚁爬树不怕高,有心学习不怕老。 场景 消息对于用户和平台来说,就是平台和用户之间的桥梁。...

    Dr_Noooo 评论0 收藏0
  • 万级消息设计-思考(一)

    摘要:特别是将消息看的很重的平台。场合用户到百万时,数据量到千万级后已经满足第一个条件后,平台再来几个推广活动。用户同时上线,参加活动会给用户发消息的时候平台对用户进行推送消息,进行促销时,参加活动,活动奖励等使用消息通知的。 说明 第一次写,也不知道写成什么样,喜欢的给个赞,不喜欢的给我留言。—— 蚂蚁爬树不怕高,有心学习不怕老。 场景 消息对于用户和平台来说,就是平台和用户之间的桥梁。...

    DirtyMind 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<