背景介绍
回顾
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服务架构能伴随公司继续成长壮大。