爱奇艺 邢常亮 - 与狼共舞 - 爱奇艺移动业务后台系统架构设计与优化实践

邶萍雅

2017/12/18 发布于 技术 分类

ArchSummit全球架构师峰会是InfoQ中国团队推出的面向高端技术管理者、架构师的技术大会,参会者中超过50%拥有8年以上的工作经验。 ArchSummit秉承“实践第一、案例为主”的原则,展示新技术在行业应用中的最新实践,技术在企业转型中的加速作用,帮助企业技术管理者、CTO、架构师做好技术选型、技术团队组建与管理,并确立技术对于产品和业务的关键作用。

文字内容
1. 与狼共舞 - 爱奇艺移动业务后台系统 架构设计与优化实践 邢常亮 爱奇艺 技术总监
5. 邢常亮 爱奇艺技术总监 负责爱奇艺移动业务后台系统的架构设计与研发管理,具有丰富的互联网高并发 系统的架构设计经验。 14年加入爱奇艺,主导完成多次移动业务后台系统的技术架构升级与改造,使得 系统经受住了多次业务洪峰的洗礼和考验,支撑爱奇艺移动业务实现从千万级用 户到亿级用户的跨越。 在加入爱奇艺之前,曾在IBM工作多年,从事基础中间件方面的研发及技术架构 的工作。个人对于高并发、云计算、大数据等方向都有较大的兴趣和热爱。
6. •  后台架构演进的必经之路 •  应对流量洪峰的三板斧 •  后台架构设计的发展思考
7. 01 PART ONE 后台架构演进的必经之路
8. 一个互联网产品的生命周期 孵化期 成长期 成熟期 衰退期 快速试错,基础产品功 能完善;系统架构尽可 能简单,功能快速上线 奇点 Gap 用户规模爆炸式增长,业 务需求大量涌入;原有架 构在性能、扩展性、容错 性等方面的局限性开始暴 露,持续的架构升级改造 成为常态 用户规模逐渐趋于稳定, 业务开始向多元化方向拓 展;架构设计的重点开始 从满足单一业务需求转变 为系统化的平台建设 技术成熟度 业务成熟度 产品新功能已经很少,主 要以维护工作为主 时间
9. 爱奇艺移动APP的发展历程 100W 2010 奇艺影视AppV3. 0图文模式全新 上线 用户2突0破15200万 1000W 2013 大力发展VIP业务 成为首个日活跃 用户过亿的视 频2A0p1p5 1.5Պ+ 月活跃用户数6亿+ 日视频播发量10亿+ 日页面访问量100亿+ 2017 OS/Android App上线 用户突破100w 日活跃用户突破1000万 占全站流量50% 500W 1Պ 视频与社交的交织 爱奇艺APP成为一个门户
10. 爱奇艺移动后台的架构升级 2017+ 2016 2014 化整为零 - 按业务进行垂直拆分 2015 华丽转身 -  技术平台从PHP转JAVA “微”服务化 -  基础服务抽离内部共享 平台之路 -  业务系统平台化
11. 面临的挑战 APP版本快速迭代,版本碎 片化问题严重,导致后台接 口背负的历史包袱越来越重 业务需求大量涌入,研发疲于 应付,没有精力进行架构设计 与代码重构,质量急剧下降 客户端APP版本占比
12. 2014 - 化整为零 两个原则: •  按照业务模块自上而下垂直拆分 •  引入接口版本概念进行持续迭代 客户端APP 改造成果: •  系统从1个拆分成了首页、播放、频道页、会 员、搜索等6个功能独立的子模块 •  代码工程从1个拆分为6个 •  接口个数从3个拆分为30+个 •  代码中“超级类”消失不见 •  Redis缓存从1个大集群拆分为5个小集群 业务模块A 接口V1.0 业务模块B 接口V1.0 业务模块A 接口V2.0 业务模块B 接口V2.0 案例数据: •  首页接口2.0升级改造后,接口参数从60多 个精简到20+个,返回数据包大小较少了 50%,接口响应时间缩短了一半
13. 2015 - 华丽转身 基础框架重新积累 挑战 开发人员技能转型 新功能重复开发
14. 2016 - “微”服务化 微服务 != RPC != Spring boot != 容器 && 有成本 采取的策略: •  有节制的进行基础服务的抽取 •  有节制的引入新的技术与框架 成本 收益 微服务
15. 2017+ - 平台之路 代码抽取成通用的SDK,提 高复用度,如:缓存组件、 熔断组件、HTTP组件等 代码基 础组件 通用社交基础服务,包括:评论、点 赞、Feed流、圈子、榜单、表情等 APP配 置中心 平台化 社交服 务平台 移动APP的通用管理能力,包括:灰度、 升级、热修复、开关控制、版本管理等 页面模 板平台 页面样式模板化,云控动态更新 50%功能上线无需APP发版
16. 02 PART TWO 应对流量洪峰的三板斧 .
17. 一部热剧引发的“血案”
18. 一个后台系统的“马斯洛模型” 好用 “自我实现” 服务平台化 多IDC部署, 多ISP部署 服务集群化 区域容灾 弹性扩容 能用 “归属”,“尊重” 集群化 服务自动降级 服务异步化 防刷 成 熔断 限流 架构容灾 多IDC 监控 本 可用 “生理”,”安全” 功能正常 单IDC 单点 基本可用
19. 快 - 缓存 “计算机科学只存在两个难题:缓存失效和命名。” —— Phil KarIton 使用到的缓存技术: •  视频CDN:码流文件 •  静态CDN:图片,资源文件 •  缓存中间件:热数据,中间计算结果,特定场景的持久化数据 •  接口本地缓存:热数据,响应时间敏感,实时性要求不高 •  APP本地缓存:伪静态资源,减少接口访问压力,降低接口依赖
20. 缓存组件 – qycache ֵአkeyັᧃ CBᖨਂ! (3) 命中但逻辑过期 命中? (1) 未命中(已物理过期) (2) 命中且未逻辑过期 ਖ਼ᖨਂӾጱහ ഝ‫؀‬ս‫ض‬ᬬࢧ! ਖ਼ᖨਂӾහ ഝፗളᬬࢧ! ᧗࿢क़᮱හഝრ឴‫ݐ‬ හഝ! ਖ਼හഝٟ‫ف‬CB҅ଚᦡ ᗝᇔቘ/᭦ᬋᬦ๗෸ᳵ! ୑ྍ‫ڬ‬ෛCB Ӿጱᖨਂහഝ! ᬬࢧහഝ! ӱ‫ۓ‬դᎱ! qycache! ᖨਂᕟկ! Couchbase! क़᮱හഝრ! (ള‫ݗ‬౲DB)! value数据结构:{ expired_t: long data_obj: string } // 逻辑过期时间 // 缓存的数据对象
21. 快 - 异步化 •  使用的技术 •  队列:MQ,Kafka 案例:频道页接口异步化改造后,响应时间缩短40% •  子线程并行处理,避免串行等待 •  收益 •  缩短接口处理时间,提高系统吞吐率 •  非阻塞式调用,减少资源占用 •  教训 •  过渡的异步化会降低系统的可维护性 接口响应时间(单位:毫秒) 改造前 改造后
22. 稳 - 服务降级 移动后台 业务系统 公司内部 业务系统 公司外部 业务系统 在复杂交错的网络调用链路中,一个局部的故障 会产生“连锁反应”,可能导致整体系统的雪崩。 服务降级策略 •  熔断 •  安全数据 •  限流 使用到的技术 •  Hystrix熔断器 •  Meerkat(自研组件) •  Nginx+lua
23. 熔断组件 - Meerkat 熔断 •  故障隔离 •  自动恢复 •  配置动态加载 监控 •  接口调用监控 •  熔断历史记录 •  自定义扩展 Meerkat ӱ metric! ‫ۓ‬ 阻断请求 դ metric! 隔离故障 Ꮁ! metric! 监控上报 क़᮱ള‫ݗ‬๐‫ۓ‬A! क़᮱ള‫ݗ‬๐‫ۓ‬B! क़᮱ള‫ݗ‬๐‫ۓ‬C!
24. 稳 - 多机房HA •  区域性灾备 •  多机房双活 运营商A 运营商B 运营商A 运营商C IDC机房 运营商B 运营商C 地域1 地域2 地域3
25. 准 – 监控 “缺少监控的线上系统就像是闭眼飞行” 关注的元素 •  系统层面:CPU,内存,网络 •  应用层面:QPS,时间,成功率 •  业务层面:逻辑正确性 使用的技术 •  Python •  Zabbix + Grafana + 时序DB •  邮件、短信、IM
26. 03 PART THREE 后台架构设计的发展思考
27. 如何设计一个好的后台架构? 面向对象, 分层,模 块化,SOA, 微服务, 容器,云计算, Devops,人工智能, VR,深度学习,BI, 大数据,虚拟现实,人 机交互,区块链 C++,Java,Go, Spring,Tomcat, Jetty, Apache, HDFS, Storm,Hadoop, ES, Thrift,Nginx,MQ, Docker,Swarm, Kubernetes,Kafka
28. 影响技术架构的关键因素 业务架构 技术架构 产品架构 组织架构
29. 架构设计的“三条军规” 充分考虑业务的差异性 要 不要 拿着锤子找钉子 . 选择最合适的技术栈 要 不要 盲目追求技术的先进性 能够实际落地解决问题 要 不要 让架构仅停留在纸面上
30. 好架构需要持续不断的打磨 0.99 = 365 0.03 1.01 365 = 37.8
31. 检验架构好坏的最终标准 – 业务成功
32. 总结 & 问答 •  后台架构演进的必经之路 •  应对流量洪峰的三板斧 •  后台架构设计的发展思考