关于蘑菇街：
中国最大的女性时尚社交电商平台。成立于2011年,总部位于浙江杭州, 目前(2015.Q3)拥有1.3亿注册用户,双十一日UV超2000万。2015.11.21日宣布完成D轮融资,并实施"一街双城"战略,杭州+北京,杭 州偏电商方向,北京偏社交媒体方向。
蘑菇街业务架构-导购期（2011-2012）
运维早期情况
早期阶段(2011-2012年)
– 两位数机器、个位数网络设备
– 没有运维,开发即运维,靠牛逼的脚本和一些开源工具搞定
蘑菇街业务架构-转型期（2013）
运维的发展
中间阶段(2013年-2014年)
– 三位数服务器、两位数网络设备
– 2-3名专职运维同学(主机&网络&DB&缓存&......) – 问题响应式的工作方式
– 工具化的运维平台
机器资源管理(CMDB的雏形)
PHP发布系统
从指标维度监控系统(主机、QPS、RT、调用次数.... )
蘑菇街业务架构-社会化电商
我们应该怎么做
思路:
建立以应用服务为核心的管理标准体系
打造CMDB、流程申请、持续集成和监控为一体的自动化运维系统, 而不是孤立的单点系统
把运维能力服务化(API),使运维的能力无处不在
关于应用服务管理
案例介绍
让我们看一个从服务器管理—申请—代码发布—线上监控的案例
关于应用服务器-Hestia服务和资源管理
从业务的维度来管理主机-CMDB的核心概念
支持扩容、上下线、设备保障、权限等常规流程申请
自动化任务的配置和下发
关于应用服务管理-Mops流程申请系统
关于应用服务管理-发布系统
以trade_ordership_service为标示,进行代码发布
关于应用服务管理-监控系统Sentry
通用+自定义监控，运维+开发可以时刻关注自己的服务状态和质量
运维的现状
专业的运维团队 – 系统运维
– 应用运维 – DBA
– 运维开发
• 运维的能力向平台化和服务化发展(DevOps,依赖于能力而不是人) – CMDB服务化平台
– PHP+Java持续集成发布平台
– 统一的监控平台
– 全链路服务质量分析平台 – 稳定性平台
– 容量评估平台(待做)
• 工作方式的改变
– 从问题响应式,向整体解决方案提供方向发展
双11技术保障，运维做了什么？
双11关键技术分享—全链路系统
全链路背景
复杂的分布式系统,页面上的一次链接点击,在后端 可能会产生几十次的RPC调用,Web、服务化、缓存、 消息、DB.......都有可能涉及,如果出了问题,如何快 速定位到故障点要扩容,如何合理评估
关键概念,全局唯一的TraceId
全链路技术架构
全链路应用-快速发现问题点和瓶颈点
全链路应用-调用合理性分析
没有明显的瓶颈点,每一次调用RT也很正常,但是全链整体的RT却很高, 问题又出在哪里了呢?
全链路使用后的收益和后续
使用全链路后的收益
– 提升问题的定位效率 – 准确的评估容量
后续
– Mogu-Watch,与前端打通,实现用户全链路的分析 – 压测做到平时,与容量评估平台和资源分配打通
– 引入云资源弹性扩容,避免应对峰值的批量机器采购
压测之后，关键技术改造-ATS静态化方案
静态化方案背景和简介
– 主链路(首页-详情&活动-交易-支付),降低RT,提升容量
– 资源类的如图片、CSS、JS等的静态化方案都会采用CDN技术
– 对于页面内容类的数据,如商品名称、商品详情等都属于静态数据,而 商品的库存、优惠等则需要获取动态结果
– 对于活动页面、H5活动推广页面等,则可以完全静态化
ATS(Apache Traffic Server)静态化技术方案-Cheetah
ATS静态化案例-商品详情页
ATS静态化使用后的收益和后续
• 使用静态化后的收益
– 详情页(全站流量的30%+)静态化在双11期间的命中率达到95%,换言之,减少了后端服务接近30%的流量压力
– RT从原来200ms降低到50ms,用户体验大大提升
– 容量提升,减少了后端服务器的数量
• 后续
– 借助云资源搭建云上的ATS,更贴近用户 – ATS Cluster方案
– 支持HTTPS
– 回源流控和容灾控制
限流&降级开关推送和WEB应急扩容方案
• 限流&降级开关
– 限流,Web层,防止被流量打垮
– 降级,App层(服务化),保障核心应用
• Web应急扩容方案
– 选择Docker 容器,批量生成效率高 – 启动速度快
– 资源利用率提升明显
