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

背景介绍

回顾

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