背景介绍

回顾

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