重点听了运维相关的和平台架构的，选择困难症开始出现，有一些要回头看视频补上，包括萧田国的那场。人太多了，前面基本上单手托笔记本另外一只手打字，没机会拍照。会场一如既往地热，还好换了短袖。。。
———————————-分割线————————————–
新浪微博大规模分布式系统的架构挑战
从监控、日志分析、问题现场查看、原因分析、解决问题、确认和预防讨论了新浪微博的架构演变过程。发现一个特点，就是基础架构做的好的大厂，在有牛人坐镇之外，更重要的是找到了让牛人发挥的合适的方式。其实后面这点可能更重要，因为牛人是会从问题和挑战中成长出来的，但是组织方式不合适的话只能在泥地里打滚，种不出好庄稼。新浪的方式是基础架构部门会直接去推动的事情，一定是他们能够掌控的，比如说架构的变化和升级。对于应用的影响，他们会放有架构人员进团队，做出的成绩算团队的，这样才能有效推动一致性落地。
- 监控
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