Velocity 2016 参会笔记

大规模系统平衡性能最佳实践和弹性工程

  • Fire TV 的遥控器导航用例很有意思。但是太复杂了,但是值得思考。改变遥控器的输入方式,好像可以更简单的解决问题。
  • 有能跑 JavaScript 的电视棒了,是个好消息。
  • 并没有开源。但是有个 starter 项目仓库。
  • 讲师的中英文交叉的很6。

Web 组件介绍

  • Web is always fragmented。
  • ES6 class extends HTMLElement + Shadow DOM 实现 Web Component 很有意思。
  • attributeChangeCallback 可以实现自定义属性改变时的行为。
  • Template tag 可以用于代替 JSX。
  • https://webcomponents.org 有 polyfill 支持
  • 明天会讲 Polymer at YouTube。

零点之战——阿里双11技术架构演进之路

  • 很虚,PPT 做的很烂,字太多,图里面的字很小,画的也很难看。一直强调我们业务很复杂、用户量很大、流量很大,数据库怎么做一致性都没提。
  • 保障服务集群在区域内可以独立完成。(只有买家的业务会在自己的区域内独立完成。)
  • 服务集群可以快速复制。
  • 流量链条压测工具。
  • 阿里云降低双十一机器成本。
  • 处理不了的流量主动拒绝服务。
  • 动态设置任务分配不均的实例的权重。
  • 不要再线上使用没有测试过的预案。

OceanBase:蚂蚁双十一背后的关系数据库

  • 4 年落地,双十一全部使用 OceanBase。
  • 满足强一致性。
  • 分布式投票,Paxos协议强同步。但机房至少一个 raplication 做 backup。
  • 模拟断电断网。
  • 数据迁移,灰度引流,留好后路,随时回滚。
  • 查了一下,目前还没有开源。
  • 完全兼容 MySQL,优化器向 Oracle 学习。
  • 支持单个实例 10w 连接数。
  • 查询过程打断点,执行过程中可以取消执行,防止大查询占用过度资源。

滴滴弹性在线存储平台

  • 听起来很不靠谱,没有亮点,不知道为什么会做这个东西。一上来就是 redis、hbase、mongodb 都满足不了我们的需求,所以我们要自研。另一个造轮子的理由是,我们无法修改上游的代码。而且存储引擎是基于 RocksDB 和 Redis 的。尤其是数据同步的方案,竟然用 PPTP 的时间戳作为参考,呵呵哒。
  • 核心在于实现了一个可以伸缩的 Slot/Region 的路由表。

58 到家微服务架构实践

  • 比较水,其他厅也没有有价值的主题了,随便听一下吧。

DT时代的业务实时监控之道

  • 和我们的业务比较像。
  • 计算任务可以在前端编排。
  • 存储用的 hbase,用法很想 OpenTSDB。
  • 通过接口支持自定义查询。
  • 支持自定义可视化。
  • 只支持 5 个维度,但是对于维度的值不限制数量,但是遇到维度爆炸的情况会截断展开的量。
  • 没有考虑维度爆炸造成的存储资源浪费的问题。
  • Hbase 热点的问题,通过把 维度 放在 timestamp 之前解决。
  • 整体来看,整个的产品完成度非常高,我们需要一段时间才能追赶上。
  • 思考:需要做排名的指标,用我之前提出的记录用户访问习惯的思路可能会稍微做一下修改。

主题发言 阿里应用运维体系演变

  • 脚本化 => 工具化 => DevOPS => 自动化
  • 工具化
    • 工具/运维团队 => 合并各工具团队 => 工具团队同时兼 OPS 工作。
    • 工具化遇到的问题:
      • 推进落地难,思想转变,时间保障。
      • 有工具,但是工具的质量不高,运维的幸福感并没有明显提升。
      • 标准化,和国外差距比较大,刚开始做不好,就要化很多年时间去填补。
  • DevOPS
    • 将运维团队交还给研发团队。之前将运维的组织架构统一到一起,现在拆开。
    • 借助 Docker。
  • 自动化
    • 有工具但是需要人点,需要巨大的碎片化时间投入。
    • 无人值守比较难做。以发布过程为例,没有一个判断发布成功的统一条件。
  • 智能化
    • 还没开始做。
    • 说要通过机器学习判断特征,这个比较扯,比如 1000 个应用,999 个被下线了,机器学习是不是就自动下线最后一个应用呢?要是最后一个应用不能被下线怎么办?

主题发言 测量服务的可运维性 (Measure the operability of your service)

  • 讲师的开场介绍好像是在被面试一样。
  • 讲师的表达不太好。

Swarm优化:从单实例管理 1000 nodes 到 30000 nodes

  • 选择 Swarm 而不是其他方案的原因是因为对 docker 本身的协议更熟悉,方便深度定制。
  • 提到阿里采用的大部分开源软件都是经过深度定制的。
  • 问题:是否支持 airplane 或 busybox 之类的镜像。
  • 遇到的性能问题:
    • 节点多,线程太多,Swarm 进程直接崩溃。
    • TCP 连接泄露。
  • 实例太多,需要引入更多管理系统。
  • (对 golang 语言相关的不感兴趣,跳过这部分细节了。)
  • Swarm 线程最大线程数默认被限制在 50k。
    • 官方的解释是网络 IO 会创建很多线程。
    • 真正的原因是使用 conn.File() 将连接设置为了 block 模式。
      问题:查了一下已经被阿里的人提交 PR 并 merge 了。我的问题是,setTCPUserTimeout() 是 keepalive 还是应用层的心跳?删掉之后会有什么影响?如果是中间使用了代理会怎么样呢?
      回答:删掉之后会造成没有应用层心跳机制,要两个小时才能检测到另一端死掉了。Swarm 的协议并没有提供可以穿透代理的端到端的心跳机制。阿里内部的跨级房 Swarm 通信中间没有网管或代理,所以不会遇到 TCP 的心跳不能穿透代理的问题。
      
  • CPU消耗特别大,有很多低效率的算法造成的问题。
  • 问题:查了一下已经被阿里的人提交 PR 并 merge 了。我的问题是,setTCPUserTimeout() 是 keepalive 还是应用层的心跳?删掉之后会有什么影响?如果是中间使用了代理会怎么样呢?
    回答:删掉之后会造成没有应用层心跳机制,要两个小时才能检测到另一端死掉了。Swarm 的协议并没有提供可以穿透代理的端到端的心跳机制。阿里内部的跨级房 Swarm 通信中间没有网管或代理,所以不会遇到 TCP 的心跳不能穿透代理的问题。
    
  • 问题:阿里内部的 docker 容器可以支持所有的镜像吗?比如 alpine。
    回答并不可以,只能使用我们自己维护的镜像(有点儿像我们的 cargo)。而且只有 readhat 系的,想用 ubuntu 是不可能的(还不如 cargo)。社区的应用基本上没法用。
    

OWL 分布式开源监控最佳实践

  • 完全是来广告的。和我们的量级和功能相比,太小了,没什么有价值的信息。

网易蜂巢基于 kubernetes 的公有云运维实践

  • 作者的背景很靠谱,有很多容器化、虚拟化方案的经验。
  • 计算/网络/存储虚拟化
  • 从虚拟机到容器
    • 以资源为核心 => 以应用为核心
    • 有状态的容器:保留内存和硬盘可写能力
    • 容器跨主机互联
    • 云盘
  • 一板斧:去状态、可扩展(都已经喊得烂了,不记了)
  • 二板斧:容器化、可编排
    • Kuber 系技术栈实现快速编排无状态的应用,相当于分布式的 docker-compose,
  • 三板斧:DevOPS、可迭代
    • 主要讲的多个环境自动选择配置选项。基本上靠 CI、CD、kuber 系的 compose 功能实现。
  • 私有云到公有云
    • 容器的安全
      不同租户之间不共享虚拟机。
      
    • 容器的启动速度
      第一次启动比较慢,后面会比较快。
      
    • 容器的规模
      扩展到了 15k 个 kuber 节点。
      
    • 容器的租户隔离
      不同租户之间不共享虚拟机。
      
  • 编排优化
    • 支持多用户
    • 调度性能用户,默认只支持单个串行队列
    • 提高集群扩展性,通过拆分 etcd 集群实现
  • 虚拟机启动优化:提前分配 IP
  • 提供内部镜像仓库,提升下载镜像的速度
  • 整个蜂巢全部采用没有修改过的开源软件(这一点非常赞!好多公司都做不到啊!)

阿里巴巴 Aliware 十年微服务架构演进历程中的挑战与实践

  • 上百个人维护一个核心工程
    • 源代码冲突严重
    • 协同成本极高
  • 问题:工程化的方案,为什么没有采用 google、facebook 整个公司的代码放在一个仓库里的做法?放在一个仓库里还可以共享很多已经实现的逻辑看起来效率更高。
  • 错误难以隔离
  • 讲师:能写 if 就不会去重构了(谁要敢这么说,以后估计都不会找到工作了)。
  • 数据库能力达到上限
    • 连接数捉襟见肘
    • 单机 IOPS 达到瓶颈
  • 数据库容量日趋饱和
  • 长期高负荷运转,接近崩溃边缘
  • 数据孤岛
    • 数据隔离
    • 不一致
    • 无法复用
  • 无法进行全局数据分析
  • 中间件 / 基础服务
    • RPC
    • 消息队列
    • 配置中心
    • 监控(一直在讲 Java 系相关的内容,没兴趣)
    • 调用链路分析
    • 容量规划
      • 制造流量 => 压测单机性能 => 设定运行水位 => 计算机器使用量 => 机器上下线
      • 每天自动运行压测 => 部署前进行压测。
      • 亮点:
        - 使用线上流量进行压测,和 tcpcopy / goreplay 类似。
        - 根据运行水位自动伸缩,方案的完成度比较高。
        
      • 思考:性能平台达到可以扩张的时候,可以提供在线压测平台。
    • 限流降级
文章目录
  1. 1. 大规模系统平衡性能最佳实践和弹性工程
  2. 2. Web 组件介绍
  3. 3. 零点之战——阿里双11技术架构演进之路
  4. 4. OceanBase:蚂蚁双十一背后的关系数据库
  5. 5. 滴滴弹性在线存储平台
  6. 6. 58 到家微服务架构实践
  7. 7. DT时代的业务实时监控之道
  8. 8. 主题发言 阿里应用运维体系演变
  9. 9. 主题发言 测量服务的可运维性 (Measure the operability of your service)
  10. 10. Swarm优化:从单实例管理 1000 nodes 到 30000 nodes
  11. 11. OWL 分布式开源监控最佳实践
  12. 12. 网易蜂巢基于 kubernetes 的公有云运维实践
  13. 13. 阿里巴巴 Aliware 十年微服务架构演进历程中的挑战与实践