我關注的一週技術動態2015.7.26

時間 2019-11-20

標籤關注一週 1周技術動態 2015.7.26 简体版

原文原文鏈接

容器技術

1. Docker持續部署圖文詳解php

http://mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=208550161&idx=1&sn=e1bdb3d219c110c79850f43c0fe1d297&key=c76941211a49ab5870652c78bff255aa29b56abb1fbd503a3584dea04af2275000a4e796fee253975115f33b11f203b1&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=8v85tN1QS3hxebVAhDtc6ukXMi3rJa9OXz2dz1W%2FcTgAoFG2PtOeCtCciSf9%2B3ehpython

要點: 本文演示了若是基於 docker 實現持續部署的過程. 主要最新的代碼提交到 git, 自動會部署到線上, 這一切不是多數工程師一直嚮往的嗎? 固然 demo 很簡單, 真正用到線上還有不少工做, 好比自動化測試和分級發佈等等, 無論怎麼說, 文章提供了一種思路, 讓咱們從docker 的視角看待問題, 我人爲這也是 docker 最最核心的競爭力所在.linux

2. Google宣佈成立CNCF基金會，Kubernetes 1.0正式發佈ios

http://dockone.io/article/518#rd?sukey=fc78a68049a14bb2cffbb7d4a2dbc0f2d82571c618cbc68358353b2e71c270c4941a93cd7eef75de40b89599d925b74fc++

要點: kubernetes 終於發佈了1.0版本了, 意味着 kubernetes 宣稱能夠支持生產環境了, 不過 kubernetes發展太快了, 郵件組中天天有數千封郵件討論 kubernetes 的相關問題, 要想用的化, 仍是須要等功能逐漸穩定了以後吧.git

3. 剖析Docker文件系統：Aufs與Devicemapperweb

http://www.infoq.com/cn/articles/analysis-of-docker-file-system-aufs-and-devicemapperchrome

要點: 這不是一篇新文章, 若是稍微瞭解 docker 的話, 相信你們對 docker 依賴的 cgroup 和 namespace 技術比較容易理解, 可是cgroup 和 namespace 技術在比較早的 linux 內核版本中其實已經支持的比較好了, 爲何 docker 還要依賴比較高(linux 3.8以上)的 linux 內核版本呢? 主要是由於 docker 的分層特性. 爲了減小存儲空間, docker 鏡像採用層次化結構, 高層次鏡像能夠共享低層鏡像的文件, 同時要支持容器之間隔離, 容器中進程的文件寫入不能被其餘容器看到. 爲了實現這個目標, docker 依賴於特殊文件系統的特性. 目前Docker支持Aufs，Devicemapper，Btrfs和Vfs四種文件系統, 這篇文章就是幫助咱們理解 docker 是如何依賴 aufs 和 devicemapper 的. 可是這些文件系統都依賴相對高版本的 linux 內核, 其實我以爲在必定的限制條件下, 經過 mount 系統調用, 把依賴的底層鏡像文件 mount 到高層鏡像中, 也能夠實現相似的功能, 擺脫這些文件系統對高版本內核的要求.docker

4. 深刻理解docker ulimitshell

http://weibo.com/p/1001603867707551442110

要點: 文章中遇到的問題主要是與系統的啓動順序有關, 相信你們對 ulimit 都不陌生了, 可是如何正確的讓 ulimt 生效而且理解其中的原理特別是針對 docker 中的鏡像? 這篇文件就是很是好的選擇.

服務化和資源管理技術

1. 服務發現：六問四專家

http://dockone.io/article/509#rd?sukey=fc78a68049a14bb2ec54365a6d6daeeca437e166a69146795e4d90ba4e6f478903992e78ee8445b80b88edf61080b189

要點: 服務發現系統是實現服務化的核心組件之一, 這篇文章介紹了4位雲計算專家回答關於服務發現的技術和選型的問題.

2. 春晚微信紅包，是怎麼扛住一百億次請求的？

http://mp.weixin.qq.com/s?__biz=MzAxNDU2MTU5MA==&mid=208037085&idx=1&sn=fb093eecec51c525f1cd3685645cef1a&scene=1&key=c76941211a49ab5817b68e29bbf4969884639ef6cfe7486665a07e2cfbadde27b5eae0e54d9ae6741692adabb0af824d&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=8v85tN1QS3hxebVAhDtc6ukXMi3rJa9OXz2dz1W%2FcTgAoFG2PtOeCtCciSf9%2B3eh

要點: 文章介紹了春晚微信發紅包的後臺架構設計演化過程, 面臨春晚這樣的重大事件, 確保服務穩定高效的處理海量用戶的爆發請求, 須要高技術含量的架構來支持.

3. SAMI：來自三星的基於Docker和Mesos的容器解決方案

http://dockone.io/article/506#rd?sukey=fc78a68049a14bb21f2b8921ff7ae6050597f20823385f7d3195a08acdfd4c5eac7b23ecaf88865b0b33043173416e2e

要點: 這篇文章介紹了 SAMI 基於 mesos 和 docker 搭建的持續集成+持續部署的解決方案, 全部工做配置都存放在Git中, 把應用軟件打包成Docker鏡像，便於快速部署. 在配置管理方面, 大搜索也採用相似的機制, 全部配置文件都寫入 svn, 可是帶來的一個問題是不一樣的機房或者不一樣的環境, 對應的配置多是不同的, 因此咱們目前採用的是模板機制, 服務部署時, 按照當前環境和模板生成對應的配置文件. 可是這也就帶來了模塊和環境的維護成本, 因爲全靠人工維護, 也比較容易出錯(好比新增了一個物理機房), 尚未想到更好的解決方法, 不知道 SAMI 是怎麼解決這個問題的, 文章沒有提.

4. 微服務架構成功之路

http://www.infoq.com/cn/news/2015/07/success-of-microservices#rd

要點: 前兩期也分享過微服務相關的文章, 我以爲這篇文章寫的比較有深意, 是否微服務不關鍵, 關鍵是"這些小型、跨職能的微服務團隊看起來像是小型開源項目同樣。你們一塊兒工做，不怕與別人分享本身的觀點；每一個人都熱衷於構建高質量軟件，因爲團隊規模足夠小而且聚焦，所以能夠構建出模塊化軟件。他們是開發者、測試、運維，一切工做都有着相同的目標，而這正是DevOps與微服務的真諦之所在。"

服務調度技術

1. Uber容錯設計與多機房容災方案

http://weibo.com/p/1001643867507730568365

要點: 本文介紹了 uber 在容災方面的技術, 基本上也是單點故障容災, 單個交換機容災, 單個機房容災這樣來考慮的, 容災一方面要快速服務故障, 另外一方面要保證遇到災難時可以有效的降級, 防止過載進而產生雪崩效益, 也就是 fail fast 的策略.

DevOps 技術

1. 從DO分離走向DO合做

http://mp.weixin.qq.com/s?__biz=MzA4NjAzMjEyOA==&mid=207411309&idx=1&sn=f6bd2c4673578e6f36233a12136ae291&scene=1&key=c76941211a49ab587b58892192ba6e5fae8eb999381453382fda8f1dd87bb5806bf231eb397b8566ac69a0771b9fa1bb&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=kjAQbpqrv1k4JEUjLZ%2Bgsq8ZccHlxm%2BubjZn4ZwoLErY4m9JeX4u1OeaHs9uG3An

要點: 文章中列舉了不少致使研發和運維分裂的因素, 其實不少因素咱們或多或少的也遇到過. 術業有專攻, 要想實現1+1>2, 就要擁抱彼此，互相合做，由於衡量咱們標準只有一個，「用戶說好，那纔是真的好」，其餘的還真的都是在扯淡。

2. 騰訊遊戲運維服務建設之「版本服務」

http://mp.weixin.qq.com/s?__biz=MjM5MDM2MzU3OQ==&mid=207205820&idx=1&sn=ad541ea2cd292cd155ffab227d98d593&scene=1&key=c76941211a49ab585aee8a71ed7ee251a51d7b306512f03597bb9af743659717417c6c0049edf0a5b399cdb6d618deec&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=u0DR%2Fa6EsWkHwAtGB0LLszVOEACFomaqkQSZelRgiq5nc0BQWQuJRRJrduOcvbBs

要點: 本文介紹了騰訊遊戲部門在新版本發佈先後須要關注的內容, 運維人員不只在版本發佈後關注程序運行的狀態和效果, 在開發過程當中就會關注軟件的質量和缺陷了, 而且推進開發人員去改善.

3. 現代告警平臺的設計是模塊化的

http://segmentfault.com/a/1190000003012335

要點: 面對衆多的開源收集和監控平臺, 好比 ELK, Nagios，Zabbix等等, 做者認爲不少開源平臺都在追求大而全, 實際上咱們更須要的是一對小二精的組件拼裝成一個個性化的解決方案. 文章中包含了做者演講的視頻. 我也比較贊同做者的觀點, 畢竟在 IAAS 層, 不一樣公司面臨的硬件和基礎環境差別比較大, 一套"大而全"的系統每每不能解決所有問題, 並且爲了使用這套"大而全"的系統還不得不一樣時運行多套小系統來知足差別化需求.

4. 運維的本質—可視化

https://mp.weixin.qq.com/s?__biz=MzA4NjAzMjEyOA==&mid=207471771&idx=1&sn=b5d8f23abe978741bb4eed21c83764ca&scene=1&key=0acd51d81cb052bc8ade672f7509f4d9e67d13540a2f70117683c3fcbec6fda017ace2135f040cbfbb78c24326297e79&ascene=0&uin=Mjk1ODMyNTYyMg%3D%3D&devicetype=iMac+MacBookPro9%2C2+OSX+OSX+10.10.3+build(14D136)&version=11020012&pass_ticket=l2e4Y2LaqzrQir65a4ET7YS1SPJ1yNhVPzcrjPULWd%2Bwequ0%2BjoCS%2BTrVeh3aeQV

要點: 沒有比「可視化」更好的一個詞能歸納運維的本質，而「可視化」又應該分紅兩部分：可視化的服務交付和可視化的服務度量! 咱們作架構的同窗每每對可視化不是很重視, 認爲這是錦上添花的東西, 有更好, 沒有也無所謂. 可是從上半年 beehive 開始建設 dashboard 的過程當中發現, 可視化是實現運維自動化的利器. 沒有可視化, 就沒法談及運維自動化, 一方面由於自動化運維策略的制定來源於可視化的數據分析, 另外一方面沒有可視化的自動化運維, 咱們也不敢使用, 由於看不到當前狀態, 誰知道是正常仍是異常呢.

工具集合

1. YouCompleteMe

http://blog.marchtea.com/archives/161#rd?sukey=fc78a68049a14bb2ba33c15948d34749e1eb616df07efe977573d59996ea9b63dc82be61d5771f948f5d8f01a917acd7

要點: ycm 應該是目前爲止 vim 裏最好用的自動補全插件了, 基於 llvm 經過實時編譯來實現 c++程序的語義解析. 遺憾的是, 目前在 gcc 3.4.5上沒法編譯 llvm, 並且 llvm 發佈的 prebuild 包裏也沒有 redhat 的版本, 須要自行編譯. 若是你們使用 gcc 4.8.2 能夠用一下試試.

2. 最佳日誌實踐

http://www.bitstech.net/2014/01/07/log-best-practice/#rd?sukey=fc78a68049a14bb2b83589ac2af50619681535af567aee4d789810d67c3957ffaa91805bca31f9ce78e5437b84f98f61

要點: 又是一篇關於日誌的文章, 每次線上追查問題, 都被大量無效的日誌折磨着, 因此每次看到寫關於日誌的文章, 都忍不住想轉一下. 如何輸出日誌, 輸出哪些內容, 都是很是有講究的, 這些日誌將成爲咱們往後追查問題的利器, 若是組織的很差, 就會給咱們定位問題帶來很大的阻礙. 除了日誌內容以外, 選一個功能靈活, 性能優異的日誌庫也是很是重要的, 我指望的日誌庫具有的功能有: 日誌文件按照時間和大小兩個維度進行切割; 全部日誌文件的 size 有一個 quota 能夠限制, 超出以後自動刪除最舊的文件; 日誌的配置能夠在運行時修改而不須要重啓服務; 不一樣級別的日誌輸出到同一個文件裏; 日誌的輸出具備異步的語義, 不會由於磁盤故障而阻塞服務(特別是對於無狀態的服務). 目前看來彷佛只有 log4cplus 知足個人需求.

3. 像 shell 的-x 參數同樣追蹤 python 的執行過程

http://pymotw.com/2/trace/

要點: python 雖然比 shell 強大的多, 可是調試起來不太方便, 尤爲是不少狀況下只有運行起來以後纔會發現錯誤. 使用 python 的 trace 模塊可讓 python 像 shell 的-x 參數同樣打印腳本執行過程, 方便調試

4. 15個對開發人員有用的Chrome擴展插件

http://info.9iphp.com/15-chrome-extensions-for-developers/

要點: 一些經常使用的 chrome 插件, 即便不作 web 開發, 像 JSONView 這樣的插件也很是有幫助.