电商系统峰值架构研究.pptxVIP

电商系统峰值架构研究 洋码头内部资料 梁中华 2014.12 lzh@ 目标场景 类似双10，双11，黑五这类大促 请求量、网络流量，短时间可达平时10倍，甚至几十倍 秒杀，限时抢购 瞬时流量可达平时的几十、上百倍，一个不慎，可能瞬间把整个集群摧垮 各种没有节操的攻击 找你的薄弱环节，狠狠地压你 各种网站联盟、线上、线下引流 面临的问题 带宽可能不够：做好图片、页面、资源压缩，节省流量 数据库可能撑不住：IO、CPU、连接数过高 缓存服务器可能撑不住：CPU，连接数过高 Session服务器负载过高 应用服务器可能撑不住： CPU、连接数、线程数、执行时间过长 第三方接口可能会撑不住： 短信、个推等 个别页面或业务的瞬间压力过大可能会导致整个系统面临很大的风险 各种原因，可能会宕机 整体解决思路 提前进行容量规划和场景分析 场景分析很重要、分析出可能的热点和薄弱环节 功夫在戏外，平时工作要做足 核心思想： 分而治之，大系统小做、小系统大做 Partition(Scalable) Everything, Async Everywhere, Caching Everything, Remember Everything Will Fail(Cluster,Monitor) 两个重点方向： 既要“快” – 天下武功，唯快不破 又要“稳” – 稳定压倒一切 “快”—Caching Everything 将有效期较长的页面进行ＣＤＮ缓存或反向代理服务器缓存 有效期短的页面或数据缓存到本地内存或者分布式缓存服务器，如Redis 考虑缓存失效情况，避免缓存失效穿透，造成后端瞬间压力过大 将混合型页面进行动静分离，如单品页，介绍性内容静态化；价格、库存等动态异步加载 有些只是Request级别或线程级别的数据，可以缓存在HttpContext或ThreadStatic变量中，避免多次从远程获取 “快”—应用代码结构和流程 尽量避免使用Session 尽量避免大量的嵌套循环、无意识的linq join操作，大数据量的排序和筛选，选取高效的算法。 尽量避免大数据量的复杂字符串操作 尽量减少远程调用的次数，提供粗粒度接口 远程调用时尽量使用长连接，减少频繁创建连接带来的资源损耗 尽量避免需要大量序列化和反序列化的操作 尽量避免创建大快内存，减少GC压力 必要时进行异步处理和并行处理 “快”—　数据库 SQL优化: 重构索引、where字句优化 减少大事务、最小化一致性要求 数据库读写分离：Master-Slaver 数据库分库：按业务垂直拆分，分散压力，保护主流程 数据库分区：按时间进行分区 通过ＭＱ异步写库：削峰填谷 “快”—负载均衡 通过负载均衡进行快速扩展集群容量 实现弹性扩容，Scalable Everything! 通过硬件实现：F5, NetScaler 通过软件实现：LVS, HAProxy,Nginx RPC服务框架自动实现负载均衡，如dubbo 自实现各种负载均衡算法 稳－分而治之 按业务，按模块进行拆分，使每个模块又轻又快，小而美。 公共模块SOA化，集中监控和扩容 使CPU密集、IO密集、占用内存高等不同资源敏感的服务得以不同的方式进行扩容 热点分离，减少各模块之间互相影响，保护核心业务流程 可以针对性的进行监控、流量控制和扩容 做好超时控制，每个远程调用都设置合理的超时时间 参考架构—当当 参考架构--JD 稳－服务降级 服务降级(有损服务) CAP：降低强一致性，换取高性能 同步变异步：降低用户体验，换取高性能 去除周边功能，保证核心业务：类目，单品，订单支付 等服务的核心功能 动态页面临时性变成静态页面，如活动页，部分热点单品页 需要很强的灵活性和应变能力，考验程序架构和运维能力 稳－流量控制 系统设计一般都有一定的流量标准 当流量超过标准时需要对流量进行限制： Web应用访问墙挡住恶意攻击流量 Nginx根据用户IP进行限流 服务根据单位时间内访问次数进行限流 Db根据连接数进行限流 应用配合限流的特殊返回情况 眼观六路，耳听八方 Remember Everything will Fail Monitor ,monitor …and Monitor! 网络监控：连接数，网络流量，路由，丢包率，DNS 系统监控：cpu,mem,connections, 应用监控: qps, request executings, requests exec time, threads, GC，应用心跳 页面、接口监控: 页面，接口访问量、响应时间 DB监控：cpu，mem，io，问题sql 代码方法监控：方法耗时监控 功夫在平时 监控 缓存 异步 SOA模块化 隔离热点 限流、防黑 功能降级 弹性部署