重点听了运维相关的和平台架构的,选择困难症开始出现,有一些要回头看视频补上,包括萧田国的那场。人太多了,前面基本上单手托笔记本另外一只手打字,没机会拍照。会场一如既往地热,还好换了短袖。。。
———————————-分割线————————————–
新浪微博大规模分布式系统的架构挑战
从监控、日志分析、问题现场查看、原因分析、解决问题、确认和预防讨论了新浪微博的架构演变过程。发现一个特点,就是基础架构做的好的大厂,在有牛人坐镇之外,更重要的是找到了让牛人发挥的合适的方式。其实后面这点可能更重要,因为牛人是会从问题和挑战中成长出来的,但是组织方式不合适的话只能在泥地里打滚,种不出好庄稼。新浪的方式是基础架构部门会直接去推动的事情,一定是他们能够掌控的,比如说架构的变化和升级。对于应用的影响,他们会放有架构人员进团队,做出的成绩算团队的,这样才能有效推动一致性落地。
- 监控
Dashboard:从graphite开始,不够有效,换成全局trace实现全链路追踪。
- 日志管理
三层日志:
- 业务日志: 统计与分步计时
- 性能日志
- 容器日志和系统日志
对日志分维度过滤:
- 时间级别
- 请求级别:带调用链路 在框架级别添加全局trace;
- 日志级别:warning和error
日志集中检索
Elk + JPool:elk存储日志,量大的时候elk成本太高,所以只记录请求的链路和日志进行日志定位。JPool自研的基于agent的日志查询。听的我兴趣盎然,后来还跑去听了JPool的session。
日志分析中的效率和成本平衡
- 现场勘察
Linux性能分析:
快照分析,内存状态异常状态。可用工具:gdb xmap mat jstack工具
调用工具:java的btrace Linux的xtrace
聚合分析工具:perf xstat
- 原因分析
问题常处在:
- 应用层次:死锁,内存溢出,依赖资源。
- 系统层次:jvm kernal tcp
- 硬件层次:没来得及问新浪有没有做OCP。。。
联合排查:多部门。(跨部门协调怎么快速开展是个管理问题)
开发,运维,dba,网络
- 实际案例
- 观察现场
- 复现:tcp copy模拟流量导入,问题重现。
- 分析:用perf发现close系统调用消耗大量cpu,用jstack发现大量线程卡在niodecloseintfd,通过strace发现close系统调用时间很长。通过对比压测发现旧版内核频繁调用close有性能问题。
- 解决:解决问题就是升级内核。
- 确认:开发环境->测试->线上
- 后续观察,没有引入新问题:灰度上线。功能无异常,性能无下降。
Ti p:当心解决方案的陷阱。
案例:
发现问题在本地缓存,加本地缓存时候顺手加个统计造成web server性能瓶颈。
- 预防
- 高可用的架构设计:
- 服务隔离
- 按部署隔离
- 分机房
- 核心服务独立部署
- 服务独立化部署
- 按调用隔离
- 异步队列
- 快速失败:前面失败了让后面尽快失败,服务也要降级。(这个和业务分析中做到场景的原子性和连续性也有关系)
- 可靠的系统实现
耦合方式:同步,异步,丢弃。丢弃机制在更高层次保障系统性能
异常处理的异常处理:不要让事情变得更糟。
- 压测演练
tcpcopy模拟线上流量。
touchstone来模拟后端资源异常,在tcp层次模拟丢包。
演练过预案好过更多的没有演练过的预案。
—————————————分割线——————————————–
美拍用户破亿的架构演进
这个过程演进介绍的很完整,基本上是问题驱动的进化,碰到的问题都很典型,解决方案感觉都讲究快速见效,很多时候直接加资源搞定。
- 技术选型
考虑团队的实际情况和技术栈,尽可能使用现有的云服务加快开发速度。
- 初级阶段,快速研发上线:3 mon,1 dev 1 week。
基于团队技能,成熟的LAMP,CDN和云存储。极简化设计:
redis计数器和队列。为了控制技术栈
搜索:sphinx。和mysql结合地比较好
图片、视频:云服务
存储:mysql
缓存:memcached
activity(好友动态)没有用推送,直接用user和好友列表的join(mysql都敢这么搞。。。)
后期的问题:
memcached的连接超时 – 调高连接数;缓存命中率降低 – 扩容到8节点
mysql出现满查询:
读瓶颈、读写分离、增加从苦
写入慢:SATA->SAS->SSD(亮了。。。不知道规模上的多快,成本增加速度又怎么样)
计数器延迟:
redis读超时 – 扩容使用多从
rdb dump期间影响用户请求:凌晨来做。使用独立的不对外服务的机器来做rdb 的dump
scale up
scale out(低成本)
- 产品快速迭代:3 mon
保持简单性,满足快速迭代的产品需求和业务系统需要。
技术选型尝试使用部分新技术比如mongoDB,使用更多同类云服务。
出现的新问题:
接口响应时间变长
memcached命中率降低:整体业务命中率降低、个别新业务命中率奇低
问题根源:缓存容量成为瓶颈、slab calcification problem(钙化)。方案:核心业务隔离性部署。
依赖影响引发的血案 – 线上多个业务同时出现问题,响应时间变长。
问题根源:mongodb升级忘记加索引,大量mongodb请求超时,apache进程数快速上升,memcached连接数上升,apache借口大量超时,进程数超高。方案:核心业务隔离性部署 – 拆掉隔离和耦合,避免依赖影响。nginx7层,apache4层,资源层。
sphinx昵称搜索延迟:到秒级甚至10s。单个searchd节点数据量超过4kw出现瓶颈。
业务端根据搜索请求分布(关键词和内容还是话题)。
解决方案:业务层加缓存对抗热情求,评估数据层及时性问题及其访问量。
多个服务出现mysql写入慢。
好友关系和喜欢:扩容到128张表
监控报警:添加细粒度监控项,运行性能瓶颈:使用更好的机器(给监控系统)。
云服务保障:CDN、云处理、云存储、云视频。
CDN:移动设备弱网络、遇到dns攻击(谁搞的?)
客户端智能适配接入网络,自动探测切换备选节点。
与运营商深度合作
多家厂商做灾备
云服务保障的处理 – 本地和云端。 ffmpeg, imagemagick,graphicsmagick。
尽可能使用本地计算资源做视频处理,云服务做轻处理:转码、压缩。
scale out (资源扩容)
云服务的可用性保证
- 社交化:3 mon
可扩展和可用性
新功能研发:LBS、私信、表情文等。
对抗大量级访问和稳定性保障。
技术体系部分引入java和C:核心处理和底层服务(重写一遍核心处理速度这么快?)
LBS:
基于mongodb,使用2dsphere索引,基于geo nearsphere
使用replica-set方式,不用auto-sharding,为了问题出现的时候可控。
通过容量规划规避一定风险:考虑mongodb可能出现的问题,mongodb独立部署,全内存存储(继续亮了)。
可用性保证:基于geohash实现缓存策略。使用google s2-geometry-lib,缓存热点区域数据,合并计算附近9个各自数据解决距离不精确的问题。
实现对mongodb弱依赖(怎么做剥离的?):出故障仅影响非热点区域和长尾数据,便于尝试新技术。
好友动态架构优化:现有方案添加字段成本高,对春节期间的峰值访问。
改成拉模式,缓存和数据库变成分布式部署
异步写入:前段永远可写。前后端分离。
数据库:索引和内容分离。索引仅存放需要索引的字段,保证高性能查找。形式是kv,内容是pb二进制数据。分库分表。
缓存:防单点、线性扩容。slave穿透到master防单点,不是直接跑去存储。master穿透到slave防单点,直接请求master场景,而不是跑去mysql存储(绕口令。。。)master也承担读取对应缓存热度。快速添加slave实现现行扩容。
可运维性:
监控报警:成功率、响应时间max、min、分布range
问题定位:
降级策略:极端异常情况核心路径可控;快速开关服务和导流
在线压测:
tcpcopy拷贝流量在线压测,观察接口和资源。(感觉tcpcopy已经是标配工具了)
春节保障:
服务器保障、预留备用服务器
评估和新服务支撑能力:在线压测
完善监控项和报警机制,加入业务维度监控
员工配上网卡(这个就不要说了吧。。。)
核心服务保证资源(也是服务隔离的一种啦)
不完全可控:弱依赖。
架构的scale out和可用性保证。
——————————————分割线———————————
搜狗商业广告流式计算实践:
本来想听一下大流量高并发下的流式计算,看看有没有什么可以借鉴的,结果讲师太厚道了,把整个平台的架构和用到的关键技术都讲了一个遍。一大堆新名词直接让我overflow了 – 只能先记下来回头有机会再看了,直觉上不是我的菜。。。
- 在线商业广告平台特点
volume (10T/day)/variety(格式)/velocity (实效性)/veracity(物料、真实性)/ value(发现有用的价值)
分别面对广告主和用户,中间连接处是存储系统。
- 过程:
采集:采集、聚合、过滤、传输
数据接入:缓冲以提供采集速度和处理速度不匹配的问题、持久化、负载均衡、单播和广播
计算:任务调度、执行、资源管理、中间结果缓存
查询:索引、读写分离、同步选举、冷热分离
- 特点
事务性、一致性:计费消息不重复不丢失。账户状态和广告状态
时序性:状态消息
高性能、高可靠、可扩展
- 采集系统选型:
目标:健壮性(网络闪断,机房、交换机割接、新版本上线)、功能(过滤、断点续传)、性能(应对突发流量)
选型:scribe、flume-NG(采集和agent的插件丰富度),最后决定自研
inotify扫描数据源,发送给发送组建,发送系统调用序列号生成服务,发送到接入系统,提供重传功能。
容错:LSN记录断点续传和故障恢复。
性能优化:同步发送+异步批量push。
可扩展:过滤机制配置化。发送组建插件化。
数据源格式统一。
- 序列号生成服务:
目标:支持多topic空间分割,全局递增。高可用,能自动fail over。可扩展,支持水平扩容缩容,支持topic增删。
系统设计:nginx做路由。zookeeper做序列号的本地存储、服务拓扑 topic->node – 保证服务的唯一性,集群状态。
服务集群按照服务拓扑提供服务。
高可用:主节点计算服务拓扑、主节点是小的时候leader重新选举。发现node失效,主节点重新计算服务拓扑,其他节点根据服务拓扑变化,完成failover。提供了一个拓扑同步节点来确认状态的一致性,这个集群这个时候才能够向外提供服务。
性能:网络接口:客户端提供批量接口。ZK采用序列号预分配机制,降低ZK读写压力。负载均衡在计算服务拓扑时候考虑topic权重防止过载。
- 数据接入系统选型:
Kafka:
高性能
高可用:显式分布式
容错性:replicas,ZK记录消费offset
问题:数据容错不支持exactly once,所有ISR(?)可能消息丢失。缺乏权限控制。
权限控制:读(iptables)、写(拦截) – 自研
运维管理工具:重放、修复工具、监控管理工具 – 自研
- 计算系统选型:
nimbus总控 + storm (为啥没用spark?)
关注:事务性、高性能、资源管理
事务性:trident topology/transactionaltridentkafkaspout/opaquetridentkafkaspout
资源管理:Cgroups
性能调优:worker数设置,spout设置、负载均衡,避免热点bolt
物料审核:ac状态机
流式计算:bloom filter,无漏判低误判
复杂位图UV统计:hyper log通过位图信息估计UV,位图大小决定同级精度
滑动窗口技术:DGIM划分窗口,对窗口技术进行估计。
- 存储系统
关系型内存数据库 – 自研 (是不是自研精力花的太多了?)
目标:支持sql,性能超过mysql。memory efficient、查询一致性、高可用高扩展。
负载均衡:多partition,一致性hash,同一partition主从同步,双机热备。
冷热数据分离:
cache+持久化
置换策略:lazy load
全局热数据定期计算。
可用工具箱:开源社区的candidate (再去看一下ppt,有几个名字漏掉了)
- 下一步
资源整合:storm on yarn/ kafka on yarn
可伸缩性:启发式预测、机器学习预测
权限控制:
服务分级:
———————————–分割线—————————————–
新浪微博JPool自动运维平台
这场是因为听了keynote被勾引过来的,听的时候条件很艰苦,要单手托键盘,另外一只手打字。。。讲的内容还是蛮丰富的,介绍了整个自动运维发展历程。
- 微博平台业务背景
百T的每日日志
3000多台机器,200多个集群
8亿用户
- 自动化运维发展状况
- 原始:变更脚本化
- 工具系统:运维标准化,工具WEB化(所以可视化走在平台化前面)
- 综合运维平台:运维精细化,工具平台化,数据API化
- 云计算&智能运维:运维服务化、智能化运维,DEVOPS,*aaS
- Sina Dispatch
Shell 调度:内置变量+自定义变量,可并发,实时回显。安全:MD5加密
任务调度:并发数控制,最大比例控制,超时控制
架构:配置数据库+agent+控制中心(主线程+admin线程+任务处理线程)
agent架构:有slave master的集群概念。shell处理发到队列,vfork启动shell。任务-任务队列-vfork-执行任务。shell执行不区别master slave,但是任务只能通过master来调度,是因为任务有状态概念,要保证一致性。
- Jpool平台
(听起来好像还是用物理机比较多,有上架过程,没找到机会问一下是不是用OCP)
Jpool根据host的生命周期进行设计
通用化集群管控平台:
用户权限
资源管理:DB化。
业界的实践:
基于演进的带层级的管理关系,设计复杂,实现简单,可用性强。代表是百度noah,jpool1;
基于tag,设计简单,实现复杂,灵活多变,可扩展性强。代表是小米,jpool2
设备:设备池对应
app:和应用池对应,最后是应用设备
配置管理:
基础配置、机房相关配置、业务相关配置。
基于puppet的实践。
文件:module-池子-资源文件。
变量:池子-pool-module。
节点:池子。
module。经常需要修改的部分可视化、db化:变量、module、节点和池子。
部署管理:可以做灰度发布。
任务管理:通用的脚本自动执行平台。任务状态监控。tag,部署路径,超时时间,步长&比例。
Ngnx变更管理
降级、封杀管理:封杀窗口(分钟级别以内)、原则是覆盖全(5K+)、通过正则匹配快速定位。需要业务代码框架层实现开关接口,通过动态修改JVM运行时变量值实现、前端监听端口支持check/ on/ off,集成JPool。
日志查询
- Docker
双实例CGROUPS隔离方案。2cpu 12 core,12g(低配),前端配置。
隔离方式:cpu分组、内存分组、UMA VS NUMA。
docker单机部署:用jenkins打镜像
docker集群部署:像发布代码一样发布镜像,部署成本分钟级,快速流量转移。
过程:设备录入及迁移-前段镜像发布-nginx变更。自己写了CM系统读入需要的内容,结合简易服务发现,像jpool资源池提出请求并dispatch
docker的好处之一是代码和配置统一了。负载迁移也比较方便 – 扩容和缩容都容易。
- JPool2 – Paas平台。和开发和测试的系统打通,变成真正的paas。
- docker进展:
前端机器53% docker化,1000+实例。feed的压力基本上都docker了。
节点迁移数2k+,单台机器<5分钟。
————————————-分割线———————————-
零零星星还听了一些其他的,要不就是人太多挤不进去,要不就是听了没什么直接相关就懒得记笔记了。
转载请注明:爱开源 » #QCon北京2015# 听课笔记 Day 2 Sessions