我关注的一周技术动态 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 时我也见过不少同窗很是"勤奋"的重复编写不少功能很是相似的代码, 做为工程师, 有时候咱们须要"懒"一点, 能一步完成就不用两步(固然要保证逻辑清晰), 重复的逻辑尽可能抽象成函数或者类来统一实现.