我关注的一周技术动态2015.7.26

容器技术

1. Docker持续部署图文详解

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%2B3eh

要点: 本文演示了若是基于 docker 实现持续部署的过程. 主要最新的代码提交到 git, 自动会部署到线上, 这一切不是多数工程师一直向往的吗? 固然 demo 很简单, 真正用到线上还有不少工做, 好比自动化测试和分级发布等等, 无论怎么说, 文章提供了一种思路, 让咱们从docker 的视角看待问题, 我人为这也是 docker 最最核心的竞争力所在.

2. Google宣布成立CNCF基金会，Kubernetes 1.0正式发布

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

要点: kubernetes 终于发布了1.0版本了, 意味着 kubernetes 宣称能够支持生产环境了, 不过 kubernetes发展太快了, 邮件组中天天有数千封邮件讨论 kubernetes 的相关问题, 要想用的化, 仍是须要等功能逐渐稳定了以后吧.

3. 剖析Docker文件系统：Aufs与Devicemapper

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

要点: 这不是一篇新文章, 若是稍微了解 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 到高层镜像中, 也能够实现相似的功能, 摆脱这些文件系统对高版本内核的要求.

4. 深刻理解docker ulimit

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 这样的插件也很是有帮助.