沈剑 流量从0到10亿,技术架构演进之路

1. 流量从0到10亿,技术架构演进之路 快狗打车CTO-沈剑
3. 关于-我 • 前百度 - 高级工程师 • 58同城 - 高级架构师,技术委员会主席,技术学院优秀讲师 • 58到家 - 高级技术总监,技术委员会主席 • 快狗打车(原58速运) - CTO • “架构师之路”作者,深夜写写技术文章 • 本质:技术人一枚
4. 互联网分层架构技术迭代 演进历程
5. 分层架构演进与优化 • 小流量站点架构 • 中等规模站点架构 • 大流量站点架构 • 更大流量? • XXOO!
6. 好的架构是进化来的 不是设计来的
7. 如何进化? 找到和解决主要矛盾!
8. (1)小流量
9. 需求是什么 • 需求 (1)有个能看的见的网站就踏实了 • 特点 (1)请求量低(< 10w) (2)数据量小(<10w) (3)代码量小 (4)1台机器
10. 请求量小于10w意味着什么?
11. 实践:如何做容量预估?
12. 架构抽象-ALL IN ONE • 架构图 • 架构特点 (1)单机系统(all in one) (2)程序耦合(all in one) (3)逻辑核心是CURD
13. 架构选型的弯路 • 选择:windows,iis,sql-server,C# • 缘何走了“微软技术体系”这条路?
14. 如果重来,我们会怎么选? 创业优秀实践:LAMP
15. 主要矛盾:CURD频繁出错
16. 如何解决CURD频繁出错?
17. 技术 • DAO (1) Data Access Object (2)像访问对象一样访问数据 • ORM (1) Object Relation Mapping (2)简化数据库查询过程
18. (2)中等规模
19. 需求是什么 • 需求 (1)网站能够正常访问 (2)如果访问速度能快点就最好了 • 特点 (1)压力导致经常宕机 (2)数据库成为瓶颈啦 (3)人多的时候访问会卡 (4)10+台机器
20. 架构抽象-分布式 • 架构图 • 架构特点 (1)分布式系统 (2)劢静分离 (3)读写分离(主从同步)
21. 劢静分离
22. 主从同步+读写分离
23. 主要矛盾: 站点耦合+读写延时
24. 如何解耦?如何缓解延时?
25. 业务-垂直拆分 • 业务垂直拆分
26. 架构-垂直拆分 • 架构图 • 架构特点 (1)站点垂直划分 (2)数据库垂直划分 (3)代码垂直划分 • 主要矛盾缓解 (1)站点耦合 => 解耦 (2)读写延时 => 解耦
27. (3)大流量
28. 需求是什么 • 需求 (1)垂直业务也不能挂 (2)业务爆发-快速实现 (3)业务依赖-子系统依赖关系复杂 • 特点 (1)站点数激增 (2)数据量激增 (4)100台机器
29. 架构抽象-高可用 • 架构图 • 架构特点 (1)进一步垂直拆分 (2)分层抽象 (3)服务化 (4)水平拆分
30. 矛盾点:高可用
31. 高可用的思路是 冗余+故障转移
32. 矛盾点:高性能,高并发
33. 如何做到“无限性能”?
34. 无限性能的思路是 加机器就能扩展
35. 矛盾点:臃肿,耦合
36. 为什么要服务化?
37. 互联网典型服务化架构 • 联网典型高可用架构 (1)端 (2)反向代理 (3)应用 (4)服务 (5)数据
38. 服务化解决什么问题 • 向上层屏蔽底层细节,调用方很爽 • 复用性 • 接耦合(系统、数据库) • 丏注性 • SQL质量得到保证 • 提供无限性能(有限服务)
39. (4)更大流量
40. 需求是什么 • 需求 (1)用户量、数据量、并发量暴增 (2)业务量暴增 (3)迭代,敏捷 • 特点 (1)自劢化 (2)平台化 (3)综合治理 (4)1000台机器
41. 复杂性矛盾: 架构变成蜘蛛网
42. 架构抽象-进一步解耦 • 架构图 • 架构特点 (1)配置中心 (2)消息总线
43. 配置中心
44. 消息总线
45. 多维分层
46. 迭代思路 通用痛点抽象一层
47. 微服务架构其他最佳实践
48. 统一的服务框架
49. 技术-开源的开发框架 • 如何降低站点开发成本? (1)web框架 (2)https://github.com/58code/Argo • 如何降低服务开发成本? (1)服务框架 (2) https://github.com/58code/Gaea
50. 统一的数据访问
51. 总结 • 容量预估 • 三大分离:劢静,读写,前台与后台 • 高可用,冗余+故障自劢转移 • 扩展性,高并发,加机器就能扩容 • 为什么要服务化 • 配置中心,逻辑解耦,物理不解耦 • 消息总线,逻辑解耦,物理解耦 • 多维分层,通用痛点抽象一层
54. 讨论:秒杀实践