关于蘑菇街
中国***的女性时尚社交电商平台，成立于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 容器，批量生成效率高 – 启动速度快。
– 资源利用率提升明显。
