蘑菇街运维体系及双十一关键技术分享

关于蘑菇街

中国***的女性时尚社交电商平台，成立于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 容器，批量生成效率高 – 启动速度快。

– 资源利用率提升明显。