自習周報：CoreOS 的黑魔法

01-31

CoreOS 在容器圈裡是個技術水平相當高的公司，做操作系統有和公司同名的 CoreOS 這種以容器思維架構的發行版 Linux 系統；做分散式 KV 做出來了在 Golang 圈地位類似 ZK 在 Java 圈的頂級項目；做安全做出來了現在鏡像掃描最主流的開源方案 Clair，做網路做出來了 Flannel 這樣影響了很多容器網路插件發展的產品，甚至他們還啟動了一個容器持久化的存儲項目 Torus。列舉了上述的項目對容器圈稍微有些了解的就應該知道這家公司多厲害了，假期趁著有時間，把他們的官方博客過了一遍。他們家文檔寫的很差，博客倒是寫得很嚴謹，頗有學院派的風格。再過濾掉一些常規的安全更新，版本迭代和公司 PR 選了五篇我覺得比較有深度的博文分享給大家。

測試

Testing distributed systems in Go

New Functional Testing in etcd

分散式系統之所以難，一方面因為編寫起來還複雜，另一方面則是測試起來也困難。節點異常，網路分區，網路變慢，這些故障都是不太好模擬的。要命的是在處理邏輯的不同階段發生這些故障引發的問題可能是不一樣的，測試需要能夠在每個階段點都注入各種類型的失敗，才能模擬真實的生產環境可能的故障。CoreOS 有兩篇文章介紹了他們是針對 etcd 的測試方案，還有代碼級別的如何注入故障，對於複雜系統的測試很有借鑒意義。

2. 性能

Exploring Performance of etcd, Zookeeper and Consul Consistent Key-value Datastores

Improving Kubernetes Scheduler Performance

這一部分也是有兩篇文章。其實都可以歸到測試里，因為性能問題的解決也依賴良好的測試方法。第一篇是介紹 etcd，zk 和 consul 的性能對比，測試過程十分學院派，詳細的介紹了前置條件，並且測試到了很多指標，包括對磁碟和網路的利用效率，cpu 和內存的消耗，以及吞吐量和延遲的穩定等，感覺就是一個性能測試的教程。

第二篇則介紹了 CoreOS 是如何定位到 Kubernetes Scheduler 性能問題並進行優化的，同樣是一篇十分學院派的文章一步步改進測試來定位瓶頸的所在，看到最後有種看偵探小說抓到兇手的感覺，裡面提到的各種方法，也很適合針對其他複雜系統來定位問題所在

3. 事務

Serializability and Distributed Software Transactional Memory with etcd3

etcd 在 v2 的時候只提供了原子操作和鎖這樣的並發控制原語，在 v3 的時候上了套全新的 api 並提供了事務的功能並且拋棄了原來的原子操作和鎖。事務的實現是用的 mvcc，這種實現的話就不禁要想 etcd 裡面的並發事務的隔離模型是怎麼樣的。畢竟事務相對來說還好做用原來的 WAL 就可以做到，但是並發事務就很麻煩了，在最後提交的時候如果有衝突該怎麼辦。隔離級別太高性能會很差，隔離級別低又容易有不一致的意外情況，通常資料庫里都是一個相對低的隔離級別再加上一些用戶手動的鎖來實現並發控制，可 etcd 又不用鎖這個原語了。看了這篇博文才知道 etcd v3 里是直接把 mvcc 的版本機制給暴露出來了，這樣在事務提交的衝突檢測完全可以由用戶來編程式控制制什麼樣的情況算衝突要回滾，什麼時候可以忽略衝突直接提交，這樣暴露 mvcc 原語的方式可以實現最大的靈活性。甚至博文最後還有個用這種原語實現 STM 的代碼，可謂喪心病狂。

假期愉快！