最新消息:

#QCon北京2015# 听课笔记 Day 2 Sessions

QCon admin 3009浏览 0评论

重点听了运维相关的和平台架构的,选择困难症开始出现,有一些要回头看视频补上,包括萧田国的那场。人太多了,前面基本上单手托笔记本另外一只手打字,没机会拍照。会场一如既往地热,还好换了短袖。。。

———————————-分割线————————————–

新浪微博大规模分布式系统的架构挑战

从监控、日志分析、问题现场查看、原因分析、解决问题、确认和预防讨论了新浪微博的架构演变过程。发现一个特点,就是基础架构做的好的大厂,在有牛人坐镇之外,更重要的是找到了让牛人发挥的合适的方式。其实后面这点可能更重要,因为牛人是会从问题和挑战中成长出来的,但是组织方式不合适的话只能在泥地里打滚,种不出好庄稼。新浪的方式是基础架构部门会直接去推动的事情,一定是他们能够掌控的,比如说架构的变化和升级。对于应用的影响,他们会放有架构人员进团队,做出的成绩算团队的,这样才能有效推动一致性落地。

  • 监控

Dashboard:从graphite开始,不够有效,换成全局trace实现全链路追踪。

  • 日志管理

三层日志:

  1. 业务日志: 统计与分步计时
  2. 性能日志
  3. 容器日志和系统日志

 

对日志分维度过滤:

  1. 时间级别
  2. 请求级别:带调用链路 在框架级别添加全局trace;
  3. 日志级别: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,网络

 

 

  • 实际案例
  1. 观察现场
  2. 复现:tcp copy模拟流量导入,问题重现。
  3. 分析:用perf发现close系统调用消耗大量cpu,用jstack发现大量线程卡在niodecloseintfd,通过strace发现close系统调用时间很长。通过对比压测发现旧版内核频繁调用close有性能问题。
  4. 解决:解决问题就是升级内核。
  5. 确认:开发环境->测试->线上
  6. 后续观察,没有引入新问题:灰度上线。功能无异常,性能无下降。

 

Ti p:当心解决方案的陷阱。

案例:

发现问题在本地缓存,加本地缓存时候顺手加个统计造成web server性能瓶颈。

 

  • 预防
  • 高可用的架构设计:

 

  • 服务隔离
  1. 按部署隔离
  2. 分机房
  3. 核心服务独立部署
  4. 服务独立化部署
  5. 按调用隔离
  6. 异步队列
  7. 快速失败:前面失败了让后面尽快失败,服务也要降级。(这个和业务分析中做到场景的原子性和连续性也有关系)

 

  • 可靠的系统实现

耦合方式:同步,异步,丢弃。丢弃机制在更高层次保障系统性能

异常处理的异常处理:不要让事情变得更糟。

 

  • 压测演练

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亿用户

 

  • 自动化运维发展状况
  1. 原始:变更脚本化
  2. 工具系统:运维标准化,工具WEB化(所以可视化走在平台化前面)
  3. 综合运维平台:运维精细化,工具平台化,数据API化
  4. 云计算&智能运维:运维服务化、智能化运维,DEVOPS,*aaS
  • Sina Dispatch

Shell 调度:内置变量+自定义变量,可并发,实时回显。安全:MD5加密

任务调度:并发数控制,最大比例控制,超时控制

 

架构:配置数据库+agent+控制中心(主线程+admin线程+任务处理线程)

agent架构:有slave master的集群概念。shell处理发到队列,vfork启动shell。任务-任务队列-vfork-执行任务。shell执行不区别master slave,但是任务只能通过master来调度,是因为任务有状态概念,要保证一致性。

  • Jpool平台

(听起来好像还是用物理机比较多,有上架过程,没找到机会问一下是不是用OCP)

Jpool根据host的生命周期进行设计

JPools1

通用化集群管控平台:

JPools2

用户权限

资源管理:DB化。

业界的实践:

基于演进的带层级的管理关系,设计复杂,实现简单,可用性强。代表是百度noah,jpool1;

基于tag,设计简单,实现复杂,灵活多变,可扩展性强。代表是小米,jpool2

设备:设备池对应

app:和应用池对应,最后是应用设备

JPools3

配置管理:

基础配置、机房相关配置、业务相关配置。

基于puppet的实践。

文件:module-池子-资源文件。

变量:池子-pool-module。

节点:池子。

module。经常需要修改的部分可视化、db化:变量、module、节点和池子。

部署管理:可以做灰度发布。

任务管理:通用的脚本自动执行平台。任务状态监控。tag,部署路径,超时时间,步长&比例。

JPools4

Ngnx变更管理

JPools5

降级、封杀管理:封杀窗口(分钟级别以内)、原则是覆盖全(5K+)、通过正则匹配快速定位。需要业务代码框架层实现开关接口,通过动态修改JVM运行时变量值实现、前端监听端口支持check/ on/ off,集成JPool

日志查询

  • Docker

双实例CGROUPS隔离方案。2cpu 12 core,12g(低配),前端配置。

隔离方式:cpu分组、内存分组、UMA VS NUMA。

docker单机部署:用jenkins打镜像

JPools6

docker集群部署:像发布代码一样发布镜像,部署成本分钟级,快速流量转移。

过程:设备录入及迁移-前段镜像发布-nginx变更。自己写了CM系统读入需要的内容,结合简易服务发现,像jpool资源池提出请求并dispatch

docker的好处之一是代码和配置统一了。负载迁移也比较方便 – 扩容和缩容都容易。

  • JPool2 – Paas平台。和开发和测试的系统打通,变成真正的paas

JPools7

  • docker进展:

前端机器53% docker化,1000+实例。feed的压力基本上都docker了。

节点迁移数2k+,单台机器<5分钟。

————————————-分割线———————————-

零零星星还听了一些其他的,要不就是人太多挤不进去,要不就是听了没什么直接相关就懒得记笔记了。

转载请注明:爱开源 » #QCon北京2015# 听课笔记 Day 2 Sessions

您必须 登录 才能发表评论!