基于Tornado后端系统架构

Back-end system architecture based on Tornado Framework

Transcript

1. 基于tornado后端系统架构 twitter: @bf4x github: @bufferx
2. About Tornado • written in Python • non-blocking • event driven, base on epoll on linux • tens of thousands of long connections • lightweight
3. what • web server ◦ support HTTP/WSGI/WebSocket/SPDY
4. what • asynchronous networking library ◦ DIY Protocol
5. Like • Nginx • Libevent • ...
6. Core && Key Point • IOLoop • IOStream • stack_context • gen
7. Feature • 单进程单线程 ◦ one ioloop per thread ◦ GIL的原因, 多线程不能有效利用多核 ◦ 切忌阻塞操作
8. Feature • Proactor(IOStream) ◦ Non-Blocking IO + IOLoop + Biz Callback
9. Feature • Coroutine ◦ yield + IOLoop + Callback
10. 应用场景 WEB SERVER • Long Polling/COMET服务 • WebSockets • 接口服务
11. 应用场景 Async Client • 存储服务(Mongo/Redis/Memcached/...) • 基于HTTP的异步下载(HTTPCLIENT) • AMQP • 移动消息推送服务(DIY || APNS) • ....
12. Best Practices - 聚合服务 • 单请求可指定批量写任务,统一的读任务 • 读任务需消重 • 根据读任务需要请求多个CACHE服务(A类) • 多个CACHE数据同步返回方可执行批量任务 • 批量任务需要先异步请求计算服务 • 对每个计算服务返回可异步写CACHE(B类)
13. 聚合服务 -- 特点 • 异步接口 ◦ 收到用户REQUEST后, 立即RESPONSE • 同步逻辑写出异步代码
14. 聚合服务 -- 指标 • 高吞吐 ◦ 亿级网络IO • 延迟不敏感 ◦ 依赖于各UPSTREAM SERVICE • 日常负载<0.5
15. Best Practices - Cache Proxy • 读 • 写 • 删除 • MQ
16. Cache Proxy -- 架构 • lvs(keepalived) + sentinel(>=3) + redis(multi)
17. Cache Proxy -- 读 • 按业务KEY设置 过期/有效 时间 • 3段论 过期/有效 策略, 可指定读类型
18. Cache Proxy -- 写 • 缓存时间一般比较大
19. Cache Proxy -- 删除 • 删除KEY
20. Cache Proxy -- MQ • 通过MQ通知数据有效/无效 • 每进程缓存全量KEY
21. Cache Proxy -- MQ • 使用RabbitMQ作为Broker • Exchange Type: direct • Bind_Queue Instead of fanout exchange
22. Cache Proxy -- 指标 • 高吞吐 ◦ 亿级REQUEST • 高可用 ◦ 50ms可用率P999 • 传输字节 ◦ KB-MB/Request • QPS ◦ Peak: 接近10K ◦ 可Scale Out
23. Best Practices -- Notify • 异步化第三方服务调用 • 解耦系统间依赖 • 保证任务最终到达
24. Notify - How • STATUS ◦ NEW,PENDING,SUSPENED,(FAILURE),FINAL • RETRY_POLICY ◦ 1,2,4,8,12,16 • ALARM ◦ 离线统计 ◦ 即时触发
25. Notify - 特点 • 标准化状态转换 • 配置状态机字典 • 使用Timer功能实现Retry Policy
26. Notify - 指标 • 高可靠 ◦ 线上运行良好 • 可扩展
27. Notify - 架构 • 分布式 • 使用Mysql事务机制实现分布式任务锁
28. Best Practices -- Push • 自定义二进制应用层协议 • 长连接 • 流量小 • 耗电少 ◦ 客户端保证
29. Push -- 指标 • 高并发 ◦ 单机支持几百K量级, 瓶颈在于系统内存大小 • 可扩展 ◦ 增添机器可自动Scale Out
30. Push -- 架构 • 路由服务 • Push Service向路由注册 • Terminal通过路由获取一个可用Push Service • Terminal与Push Service建立连接并使用私有 协议通信
31. Push -- 协议设计 • 消息头 ◦ 版本 + 命令ID + 消息体长度 • 消息体 ◦ payload为Scheme Free,对Push Service透明 • 支持命令 ◦ 注册 ◦ 心跳 ◦ 推送 ◦ ...
32. Push -- 快速开发 • 原型: 3天 • 完成: 1周
33. 整体架构 • RESTFUL API • Name Server
34. 整体架构 -- RESTFUL • GET • PUT • POST • DELETE
35. 整体架构 -- Name Server • HERE • 有状态服务 ◦ Consistent Hash... • 无状态服务 ◦ Consistent Hash, WRR
36. 整体架构 -- Name Server 整体架构 -- Name Server(Dubbo Config Server)
37. 服务治理 • SLA • 超时控制 ◦ 作为CLIENT侧时,超时设置为SLA约定延迟时间 • 过载保护 ◦ 不能无节制地同时与后端服务建立大量连接 ◦ 可使用滑动窗口, 使用连接池并设置连接阈值 ◦ 每连接增加生命周期, IDLE时及时释放连接 • 服务降级 ◦ 系统整体不可用时, 可支持次要用户服务降级为不可用 ◦ 保证优先级服务可用
38. SLA • 服务级别协议 • 用于规范服务提供者与使用者双方的约定, 如 响应时间/吞吐/并发/冗灾/数据完整性等, 对于 服务提供方, 是一种服务标准承诺
39. Push -- 开发 SLA -- 可用性(并发,QPS,RT关系)
40. SLA -- 冗灾 • 一般可根据具体业务要求定义 • 比如是否需要重试, 重试策略等
41. SLA -- SPOF • 无单点, 多机多实例, 跨IDC
42. SLA -- Fail Over • 故障服务自动摘除 • 无状态服务 ◦ 返回错误码 ◦ 自动路由至其它服务 • 有状态服务 ◦ 故障数据恢复 ◦ 数据一致性 ◦ ...
43. SLA -- Recover • 故障服务恢复时间
44. SLA -- Overload Protection • 针对并发建立过载阈值, 可丢弃过载请求
45. 体系建设 • 代码规范 ◦ PEP8 OR Google Style • 版本控制 • 日志规范 • 私有Pypi • virtualenv • supervisord • 一键发布 ◦ puppet ◦ fabric
46. 调优 • 充分利用多核
47. 调优 • python语言级 ◦ 列表包含/生成器表达式/协程/闭包等 ◦ 使用装饰器 ◦ 使用__slots__ ◦ 避免使用(.)运算符 ◦ ...
48. 调优 • C扩展 ◦ Python C Extension ◦ Swig
49. 调优 • pypy ◦ twice times
50. who use • facebook • 10gen • bitly • quora • zhihu • admaster • sae • kuxun • ...
51. 周边生态 • https://github. com/tornadoweb/tornado/wiki/Links
52. 我的开源 • twork • tornado • toredis • asyncmongo • stormed-amqp • ...
53. 人生苦短 我用Python
54. Thanks