自习周报coreos的黑魔法

2017-10-05 09:04:00 oilbeater 我的观点

CoreOS 在容器圈里是个技术水平相当高的公司,做操作系统有和公司同名的 CoreOS 这种以容器思维架构的发行版 Linux 系统;做分布式 KV 做出来了在 Golang 圈地位类似 ZK 在 Java 圈的顶级项目;做安全做出来了现在镜像扫描最主流的开源方案 Clair,做网络做出来了 Flannel 这样影响了很多容器网络插件发展的产品,甚至他们还启动了一个容器持久化的存储项目 Torus。列举了上述的项目对容器圈稍微有些了解的就应该知道这家公司多厉害了,假期趁着有时间,把他们的官方博客过了一遍。他们家文档写的很差,博客倒是写得很严谨,颇有学院派的风格。再过滤掉一些常规的安全更新,版本迭代和公司 PR 选了五篇我觉得比较有深度的博文分享给大家。


关注公众号后回复『 周报 6 』可以获得这五篇精选博文地址。


  1. 测试

    分布式系统之所以难,一方面因为编写起来还复杂,另一方面则是测试起来也困难。节点异常,网络分区,网络变慢,这些故障都是不太好模拟的。要命的是在处理逻辑的不同阶段发生这些故障引发的问题可能是不一样的,测试需要能够在每个阶段点都注入各种类型的失败,才能模拟真实的生产环境可能的故障。CoreOS 有两篇文章介绍了他们是针对 etcd 的测试方案,还有代码级别的如何注入故障,对于复杂系统的测试很有借鉴意义。


  2. 性能

    这一部分也是有两篇文章。其实都可以归到测试里,因为性能问题的解决也依赖良好的测试方法。第一篇是介绍 etcd,zk 和 consul 的性能对比,测试过程十分学院派,详细的介绍了前置条件,并且测试到了很多指标,包括对磁盘和网络的利用效率,cpu 和内存的消耗,以及吞吐量和延迟的稳定等,感觉就是一个性能测试的教程。

    第二篇则介绍了 CoreOS 是如何定位到 Kubernetes Scheduler 性能问题并进行优化的,同样是一篇十分学院派的文章一步步改进测试来定位瓶颈的所在,看到最后有种看侦探小说抓到凶手的感觉,里面提到的各种方法,也很适合针对其他复杂系统来定位问题所在


  3. 事务

    etcd 在 v2 的时候只提供了原子操作和锁这样的并发控制原语,在 v3 的时候上了套全新的 api 并提供了事务的功能并且抛弃了原来的原子操作和锁。事务的实现是用的 mvcc,这种实现的话就不禁要想 etcd 里面的并发事务的隔离模型是怎么样的。毕竟事务相对来说还好做用原来的 WAL 就可以做到,但是并发事务就很麻烦了,在最后提交的时候如果有冲突该怎么办。隔离级别太高性能会很差,隔离级别低又容易有不一致的意外情况,通常数据库里都是一个相对低的隔离级别再加上一些用户手动的锁来实现并发控制,可 etcd 又不用锁这个原语了。看了这篇博文才知道 etcd v3 里是直接把 mvcc 的版本机制给暴露出来了,这样在事务提交的冲突检测完全可以由用户来编程控制什么样的情况算冲突要回滚,什么时候可以忽略冲突直接提交,这样暴露 mvcc 原语的方式可以实现最大的灵活性。甚至博文最后还有个用这种原语实现 STM 的代码,可谓丧心病狂。


关注公众号后回复『 周报 6 』可以获得这五篇精选博文地址。


假期愉快!