亿级体量的后台技术架构设计指南.docx

PAGE 2 亿级体量的后台技术架构设计指南  目 录 TOC \o 1-3 \h \z \u 1. 一款优秀的架构，就是要满足业务和用户的所有需求 3 2. 海量数据存储所带来的架构压力 4 3. 高并发与业务峰值对架构的影响 6 4. 移动网络下的亿级长链接管理 9 5. 经验总结 11  随着国内移动互联网的逐渐深化，人手一台智能设备成为标配，每人每天都在产生大量的数据。这些数据对于企业来说，如果后台架构能轻松承担，其对于业务来说就是价值；反之如果无法承担这种数据体量，那么对于业务而言就是风险。 因此在现阶段，构建一套强大的、健壮的、可扩展性强的、能够支撑亿级体量的后台架构，对于企业来说是其“必需品”。就在昨天 5 月 14 日，InfoQ 十分荣幸邀请到了极光推送后台技术负责人曾振波老师，以线上直播形式，以极光的真实实践为引，全面阐述了极光是如何在解决其 380 亿注册用户的信息存储问题、面对日均百亿级别推送需求的同时，来实现其后台架构的高性能运转。 一款优秀的架构，就是要满足业务和用户的所有需求 搭建企业级后台架构，就要搞明白架构在企业业务中能起到怎样的作用。以极光推送的后台架构为例，其任务就是要满足每一名开发者的请求能够得到及时有效的响应。 首先要找到用户在使用过程中可能存在体验问题的点，要从用户使用产品整个流程出发，以极光为例，其整个流程是：用户发起请求 -API 对用户权限进行验证 - 从多维度数据中筛选出目标用户 - 从分布式存储集群中查询用户信息数据 - 选择对应的推送通道 - 实现消息推送。 那么极光的后台架构作用就是在上述流程过程中，满足用户在使用推送过程中的实时性和触达率的要求。那这个架构的目标就很明确了，接下来就是要分解在架构设计过程中将会面临的棘手的多重挑战。 首先是用户需求，极光的用户就是一线开发者，那么开发者使用推送的诉求就是对消息的实时性和消息触达率的准确性，如开发消息推送时候能不能及时的推送到目标设备，这个推送任务触达率是多少等。 其次就是业务需求，这也是本次曾振波老师分享的重中之重。要明确构建符合企业业务需求的架构，要面临哪些技术层面的挑战？那这就是在做架构设计时，需要重点考虑的方向。以极光为例，其架构主要面临以下三重的业务挑战。 首先是海量数据体量对存储造成的压力，极光拥有几百亿的用户数据，在存储的同时还需要实时推送各个维度的数据，并且这些数据是在持续增加的。如何存储如此大体量的数据？如何在大量数据集中进行增删改查，对后台数据架构来说是很大的一个挑战。 其次是高并发和峰值效应对架构的影响愈发明显，每一款产品都有其特定的用户使用时长高发期，极光也不例外。中午 12 点和晚 8 点 - 晚 11 点，这两个时间段是开发者使用极光推送能力的高峰期。这种时间段往往会产生大量的请求，后台服务往往需要同时处理比往常多达二十倍甚至更多的数据请求，因此需要后台架构能够撑起并提供相对稳定的服务。 最后是移动网络下的亿级长连接管理，面对移动互联网应用，极光的 SDK 产品每天都被曝光在在移动网络的环境下。此类环境不比 PC 端，“不稳定”可以说是移动网络的一个典型特征，经常会涉及到无法访问、弱网以及网络抖动的各种问题，因此需要尽量保证 SDK 能够稳定的连接到极光的后台推送架构之上。 海量数据存储所带来的架构压力 业务挑战从开发者发起推送请求之时就已经开始了。首先后台架构要能够快速对消息系统内部的数据进行梳理并发送到对应的终端设备之上。上万名用户的需求很简单，百万、千万的需求在当下大环境中也不难实现，但是如果面对的是几百亿的数据体量呢？这就对极光推送后台架构提出了更高的需求。 这种体量的业务，往往会对后台架构提出更多要求，如存储资源、高性能、高可用、可扩展、运维成本等等。面对上面这些问题，极光提出了一系列解决方案。 存储介质的选择 极光采用了 MySQL、Redis、PIKA、CouchBase 以及定制化的一个自研存储，会根据 OPS 数据量和数据特性，结合存储系统本身的特性来选择所对应存储系统。 Redis 的性能很高，但是集群能力很弱，单线程处理很容易造成命令性堵塞； CouchBase 性能很高，集群能力优势明显，但缺点是对资源的消耗过大； PIKA 本身是用磁盘作为存储的，因此性能比较低，但相对的成本也较低； MySQL 主要用于存储几百亿的用户数据，主要负责基础数据的插入和更新。 数据库优化方式 为了提高数据的存储效率，我们还对索引还有 SQL 语句进行了优化，如尽量避免“字符字段”作为主键等。 数据分片存储方式 极光数据存储采用的是分片 + 多副本的存储架构，这种结构适用于 MySQL 或其它第三方存储系统。以自研存储为例，基于 ICE 框架构造