我關注的一週技術動態 2015.8.1

容器技術

1. kubernetes資料合集

http://special.csdncms.csdn.net/Kubernetes/?from=timeline&isappinstalled=0

要點: kubernetes 中文資料合集, 比較全.

2. docker技術介紹

連接: http://pan.baidu.com/s/1jGgrxzC 密碼: jg4x

要點: 分享2篇介紹容器技術的 ppt, 一篇側重於介紹容器技術的基本原理, 包括 cgroup, namespace 以及 docker 依賴的後端文件系統. 另外一篇側重介紹使用 docker 部署 mongodb 服務的經驗. 有狀態的服務要想達到快速部署的目的, 必須考慮狀態的存儲和恢復問題, 尤爲是像數據庫這種涉及大量數據的服務, 每每恢復服務的瓶頸就在於數據的同步上. 本文介紹依託於 mongodb 自動的數據遷移能力來實現數據的遷移. 另外還必須及時監控數據卷的各類異常, 好比數據卷不可訪問, IO 速度變慢等問題, 本文介紹依賴於 DB 日誌監控實現這一點.

3. etcd 2.1發佈，可不宕機滾動升級

http://dockone.io/article/539#rd?sukey=fc78a68049a14bb2979f9a98b09780c256c59187018d4fdf5563b063fac0e6768e1ed4bafbd0b5480156cefc2c5639d0

要點: etcd 是一款定位和 zookeeper 相同的分佈式 key-value 存儲系統, 使用 raft 協議實現. ectd 2.1號稱是 ectd 最穩定的版本, 同時實現了不宕機升級的功能.

4. 虛擬化技術的昨天、今天和明天

http://dockone.io/article/541

要點: 本文分別討論Docker和OS虛擬化。而後解密做者深刻分析數據以後發現的虛擬化領域正在和沒有發生的事情。

服務化和資源管理技術

1. Docker背後的容器集羣管理——從Borg到Kubernetes（二）

http://www.infoq.com/cn/articles/docker-container-cluster-management-part-02

要點: 本文重點闡述了 borg 論文中對資源控制的解讀, 這也是 borg 論文的重點. 從文章中能夠看出, borg 在如何提升資源利用率上下足了功夫, 不愧是google研發了近10年的"祕密武器".

2. WDT：多TCP鏈路的數據傳輸開源庫

http://www.infoq.com/cn/news/2015/07/facebook-wdt

要點: facebook 開源的高效數據傳輸庫, 在 facebook 的網絡環境下能夠達到近600Mb/s 的超高速傳輸.

3. Kubernetes v1.0新特性全角度解析

http://dockone.io/article/546

要點: 這是在 csdn container 羣裏的一個分享, 做者重點從負載均衡, 監控和 HA 解決方案上分享了 kubernetes 1.0的變化以及設計思路的轉變.

服務調度技術

1. 使用異步 I/O 大大提升應用程序的性能

http://mp.weixin.qq.com/s?__biz=MzAwNjMxNjQzNA==&mid=208035935&idx=1&sn=017c60ae525c7696658e1623428b6b99&key=0acd51d81cb052bc9201f541ecff130d1d20c58c18f7e3a38944ecaad767ec5b02d9afa449255d35bb622b2e9a39d431&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=ErTapDTloYaYbXFd8m30cljMvomMo0Y%2Bp1QfvsTXlqdQ%2B3DDFn8JCr43f52wANva

要點: 本文介紹了 linux 的幾種 IO 模型, 而後詳細介紹了 aio 的使用方法和基本原理.

2. 七牛是如何搞定天天500億條日誌的

http://mp.weixin.qq.com/s?__biz=MjM5NzAwNDI4Mg==&mid=211136387&idx=1&sn=b861d00ae41f993ee15e3fe9f745053f&key=0acd51d81cb052bc95ecbcfa63187eef872303c726e5eca6f8a3cc578ad1709eb3a2c9790319c7e724c9810bf0fc74d2&ascene=0&uin=ODI4MjczOTAx&devicetype=iMac+MacBookAir6%2C2+OSX+OSX+10.10.2+build(14C109)&version=11020012&pass_ticket=WqZgPuSJFtstSTwv1DTtqOJsx7rRVj65YNUC7JgZoL5CrhjBIDaIc4qd3bDT%2FRc%2B#wechat_redirect

要點: 本文介紹了七牛的日誌收集, 傳輸和分析架構, 數據收集端是本身開發的 agent, 數據傳輸使用 kafka和 flume, 數據分析實時計算使用 spark streaming, 離線分析使用 mapreduce. 總共使用了8臺機器, 抗80w TPS.

DevOps 技術

1. 應該對什麼告警?

http://segmentfault.com/a/1190000003021919

要點: 告警是你們很是熟悉的東西了, 咱們線上配置了無數的告警, 天天能夠收到無數的告警郵件. 可是常常聽到 op 抱怨, 線上告警太多而沒法及時處理的問題, 那麼應該如何設置告警才能最大程度的幫助咱們及時發現並定位問題呢? 本文做者提出瞭如何有效的設置告警的三個原則: 系統是否在持續完成其設定的工做, 用戶體驗是否好以及問題或者瓶頸在哪裏, 而且針對這些原則給出了設置告警的案例

2. Google SRE：運維還能如此高逼格？

http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=206883730&idx=1&sn=0c4ee925827cd29c8c36f4abab563540&scene=1&key=0acd51d81cb052bc5da1caf1f987a5dbc3b08e18b06b65e77ffd25d9d3ee2f621436d98cb7b0211898bc4c1d05f1b490&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=FNecT73%2Fn06dlrO2YmcQXH2L3NnbgByTAtu3nbjZomwU8T%2FxZ6f13a4Ou84pcSDS

要點:  這是一篇對原 google 工程師的訪談, 文章中描述了 google 的所謂 op 的工做職能. 看完後發現 google 是沒有服務的專職 op 的, 全部服務的開發, 測試, 部署都是 SWE 完成的(SWE 包括 rd 和 qa), 這得益於 google 強大的基礎架構. google 只有 SRE, 並且即便 SRE 也歷來不接觸物理機. 從文章中推斷 SRE都是很是有經驗的工程師組成的, 在性能優化和服務穩定性方面擁有很是豐富的經驗. 何時咱們也能達到這樣的水平呢?

3. 騰訊藍鯨核心功能圖文詳解

http://mp.weixin.qq.com/s?__biz=MzA4Nzg5Nzc5OA==&mid=206891916&idx=1&sn=76b09bc9622f3cc3ee692a54983ecac0

要點: 前面我也分享過騰訊藍鯨系統的介紹文章, 這篇文章是一個補充, 重點闡述藍鯨系統的故障自動恢復, 遊戲無人值守自動開區, 自動發佈變動, 運維使用大數據輔助運營等問題.

4. 可視化持續部署系統的設計與實現

https://mp.weixin.qq.com/s?__biz=MzA4NjAzMjEyOA==&mid=206038157&idx=1&sn=e01ad6904d60921b7005eccdb42192f2&key=0acd51d81cb052bc1937e95850e0a9f6987d7e914db9fbf7b0d0cfce0aafc8e988ec8b01931cc4b699dc8faae7d0bf6d&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=FNecT73%2Fn06dlrO2YmcQXH2L3NnbgByTAtu3nbjZomwU8T%2FxZ6f13a4Ou84pcSDS

要點: 持續部署系統咱們其實不陌生, 原來的 beehive+863系統就能夠看作是一個持續部署系統, 只不過咱們在可視化方面作的比較弱. 和文章中介紹的持續部署系統不一樣, 對於配置管理這塊, 咱們是和程序打包在一塊兒的, 每次配置變動都不方便, 我以爲863也應該把配置變動單獨管理起來, 提供一個環境和配置的一一映射表, 根據環境生成對應的配置, 固然須要提供平臺, 由 rd 來維護這個映射表.

5. 國內最大的遊戲大佬如何開展運維實踐？

http://mp.weixin.qq.com/s?__biz=MzAxNDU2MTU5MA==&mid=208213981&idx=1&sn=d7f5e0137fd4fa79ba9361b4027a57f7&scene=1&key=0acd51d81cb052bcfc6e6abb3635d492a4505f74028a7fedc38b4178ed014c84abac0b67e80b75396b83f410e99e2865&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=6X6XaP05Q6GT38M0DRLejECVKvZrTmXDwbALwDetuyC524aeRunbHf%2F1Bf6jMEpD

要點: 本文介紹了騰訊遊戲運維的"四化"演化過程, "四化"即"標準化", "自動化", "服務化", "產品化". 在演化過程當中, 按照職責的特色, 分紅了操做運維, 開發運維和規劃運維三個角色. 操做運維重點在操做原子化方面, 就是把不少有差別同時又有不少相同點的工做,拆分紅一個一個原子化工. 開發運維重點在於實現這些原子化工具的頁面化, 實現可視化運維. 規劃運維的職責在於去規劃個人這些操做場景有哪些？個人需求有哪些？把這些場景分裝起來，場景分裝以後其實就是把咱們的這些流程，把全部的運維操做流程，把每一步驟流程化，分裝以後，對於咱們後面的操做運維來講，就能夠固化的進行工具的操做。這和 beehive Job Engine 的思路是相似的, 咱們但願 beehive Job Engine 首先實現原子化的 job 級接口的封裝, 而後經過流程引擎把這些原子化的 job 級接口串聯起來知足業務的需求.

工具集合

1. Web Service 性能測試工具比較

https://testerhome.com/topics/3003

要點: 本文介紹了幾種常見的 web 服務性能測試工具, 你們能夠嘗試.

2. 28個Unix/Linux的命令行神器

http://mp.weixin.qq.com/s?__biz=MzAwNjMxNjQzNA==&mid=208098099&idx=1&sn=438db0addcf31604def97f084d8aafad&scene=1&key=0acd51d81cb052bc91d1cc313c7e525850dbd466e2bc7b701baf6917e31d409a445a9036156e0e5c83c7871347fa18a8&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.4+build(14E46)&version=11020113&pass_ticket=6X6XaP05Q6GT38M0DRLejECVKvZrTmXDwbALwDetuyC524aeRunbHf%2F1Bf6jMEpD

要點: 一些經常使用的命令, 沒什麼特別可介紹的, 若是以爲好用就用吧.

3. Linux mkdir、tar 和 kill 命令的 4 個有用小技巧

https://linux.cn/article-5863-1.html

要點: 這些應該是你們平時用的最多的命令了. 文章中介紹了平時的工做場景中, 須要兩步或者三步的操做轉化爲一步的小技巧來提高效率. 咱們可能從小就被教育要勤奮, 在 codereview 時我也見過不少同窗很是"勤奮"的重複編寫不少功能很是相似的代碼, 做爲工程師, 有時候咱們須要"懶"一點, 能一步完成就不用兩步(固然要保證邏輯清晰), 重複的邏輯儘可能抽象成函數或者類來統一實現.