又拍云运维总监邵海杨详解 DevOps “八荣八耻”

《又拍云运维总监邵海杨详解 DevOps “八荣八耻”》要点：
本文介绍了又拍云运维总监邵海杨详解 DevOps “八荣八耻”，希望对您有用。如果有疑问，可以联系我们。

邵海杨老专家在Tech Minds No.5中根据自己10余年的研发、运维经验,总结并分享了DevOps的“八荣八耻”、Herku PaaS的12要素宣言.

又拍云运维总监 邵海杨

以下是分享全文：

今天我讲的是DevOps的八荣八耻,和后面Herku PaaS的12要素宣言相呼应,大家可以一起对照的来看,这其实是一个互相印证的过程.

DevOps这个思想提出来已经五六年了,一直都是呼声很高,落地很难,为什么呢?

这可能与各个公司的业务情况和技术发展路线有或多或少的关系：

• 比如说创业的最早技术合伙人是运维出身或者技术出身,但是水平不高,为了公司持续发展,引入新鲜血液时,就会存在技术的先进性跟解决遗留烂摊子的矛盾.
• 又或者业务本身偏向于用户,导致技术被边缘化,产品又没有好的架构,限制了快速发展等.

所以,DevOps的推进一定要自上而下,凭借挑战自我,颠覆传统的勇气才能去落实.

好的,下面我正式开始.

DevOps的八荣八耻

一、以可配置为荣,以硬编码为耻

△ 以可配置为荣,以硬编码为耻

做过开发的朋友都知道,程序跟变量分离会出现单独的配置文件,所以运维要像开发学习,学会把软件和配置分离.

举个例子,我们公司第一个版本自动化运维时,把所有的硬参数配置到upyun.cfg,如上图.它的好处在于,只要编写一个config函数,就可以把这种文本的运行方式,变成右边nginx所能运行的格式.

并且可以用同样一份配置去适用不同的后端软件,如用haproxy替换nginx,只要重新写一下config函数即可,运维和开发仍然可以使用同一份参数.

本地配置的文本格式有txt、ini、cfg,但是这些格式都没有没有硬性要求,如ini在php里用的多一点,cfg在mysql里用的多一些.

一般配置的文件里面会包括开关变量,调试参数、可变参数、权重,以及关联上下游的参数,这些都可以放在配置里面,通过程序生成程序的方式完成.

第二代就不再使用它了.我们现在使用Yaml来定义配置文件,通过它动态生成配置文件,这两者的思路是相同的,都是通过程序生成程序.

除此之外,现在也有一些更加流行的技术,比如通过etcd或者是consul来实现服务的自动发现、自动注册.

?二、以互备为荣,以单点为耻

△ 以互备为荣,以单点为耻

互容互备一直是优良架构的设计重点.

我们早期做架构设计,使用了LVS+Keeplived+VRRP做转换,这样可以方便负载均衡,动态升级,隔离故障.现在第二代,已经在部分大节点使用OSPF和Quagga做等价路由的负载均衡和冗余保障.

Nginx可以加Haproxy或LVS做负载均衡.MySQL可以做主从切换,或者是MMM的高可用成熟解决方案.

我们的消息队列之前用rabbitmq做,现在主要是redis和kafka集群化,其中kafka已经迁到了Mesos容器平台里.

服务的自动发现、注册,我们可以使用consul、etcd、doozer(Heroku公司产品),还有zookeeper.

主要区别是算法不一样,zookeeper用的是paxos算法,而consul用的是raft算法.目前看来consul比较流行,因为consul的自动发现和自动注册更加容易使用.

etcd主要是CoreOS在主推,CoreOS本身就是一个滚动发布的针对分布式部署的操作系统,大家可以去关注一下它.还有一个是hadoop和elk,大数据平台的可扩展性是标配,很容易互备.

上面是举了一些常见互备的软件组件的选型,那我们应该如何设计一个无单点的架构呢?主要掌握以下几点：

1. 无状态

无状态意味着没有竞争,很容易做负载均衡,负载均衡的方式有很多种,F5,LVS,Haproxy,总能找到一种适合你的方式.

2. 无共享

以前我们很喜欢用内存来保持临时信息,如进程间的交换,这种方式虽然效率很高,但是对程序的扩展性没什么好处,尤其是现在的互联网体量,光靠单机或者高性能机器是明显玩不转的.

所以我们现在就需要使用类似消息队列的组件,把数据共享出去,利用多台机器把负载给承担下来.

3. 松耦合/异步处理

以前我们用Gearman这样的任务框架.大家可以把任务丢进任务池里,生成多个消费者去取任务.当我的消费不够用时,可以平滑增加我的work资源,让他从更快的去拿任务.运维平台这边以python/celery的组合使用更多.

4. 分布式/集群协作

像Hadoop这样的天生大数据/数据仓库解决方案,由于先前设计比较成熟,一般都是通过很多台机器扩容来实现map/reduce的扩展计算能力.

三、以随时重启为荣,以不能迁移为耻

△ 以随时重启为荣,以不能迁移为耻

关于这个点,我们讲三个方面：

1. Pet到Cow观念的转变

以前我们说机器是pet,也就是宠物模式,然后花了几万块钱去买的服务器,当宝一般供奉.但事实上却并不是这样,任何电子设备、服务器只要一上线,便开始了一个衰老的过程.

你根本不知道在运行过程中会发生什么事,比如说质量差的电容会老化爆浆,电子元器件在机房的恶劣环境里会加速损坏,这些变化都是我们无法参与控制的,所以无论我们怎么努力,都无法保障机器有多么的牢靠.

谷歌指出的Cow模式就是指农场模式.就是要把机器发生故障当做常态,打个比方,比如说这头牛死了,那我就不要了,因为我有很多这样的牛,或者是再拉一头新的牛.这就是我们软件开发和运维需要做的转变,去适应这种变化.

2. OpenStack虚拟机的编排

虚拟化是个好东西,通过OpenStack我们很容易就可以做出一些存储或者迁移的操作,但是在实施的过程中,也是一波三折的.

我们从2014年开始在内部推动OpenStack,当然我们也踩过OpenStack网络的坑.

那时候我们用双千兆的卡做内网通讯,因为使用OpenStack实现虚拟化后,一切都变成了文件,在网络上传输的话,对网络的压力会非常大,结果就导致部分服务响应缓慢.

因为本身就是实验性质,所以在硬件上没有足够投入,内测时也没有推广,所以影响不大.

2015年我们再上的OpenStack,全部都用双万兆的网卡做bonding,交换机也是做了端口聚合和堆叠.目前来说,只有云存储没有上线,其它云处理,云网络的使用还是能够满足要求.

3. Docker的导入导出

Docker是更轻量级的资源隔离和复用技术,从2016年开始,又拍云同时也在尝试使用Mesos/Docker来实现云处理的业务迁移.

四、以整体交付为荣,以部分交付为耻

（编辑：ASP站长网）