从临危授命到扭转乾坤，天天拍车运维架构演进及实践(4)

对象缓存,我们把Memcached替换成Redis.现在的缓存也不是什么数据都往Redis里面放,Redis里面只做数据对应关系的缓存.不像以前Memcached里面,不光存缓存,还有很多乱七八糟全都存.后来Memcached经常出现失败,原因就是因为缓存的非常大,超过1M.Memcached默认是1M这是1.4.21版本之前.

• 图片存储：NFS–àFastDFS–àTFS

图片存储对51汽车来说是最头疼的事情.最早是用NFS来搭建的,而且是两台.我去的时候NFS 6T空间用的不到500G,访问一些图片时非常非常慢,慢到什么程度呢?假如说你在一个图片库下要执行的话会卡住,大家知道某一个目录下面存在了上千万张图片时,怎么才能最快速度地把图片给列出来?这个是非常小的技巧,就是用LS命令在执行的时候把色彩参数给去掉,或者直接dir命令.

NFS用得非常头大,所以我们使用了FastDFS,因为它非常的轻量.可后来我们为什么又替换了FastDFS呢?因为扩容时必须以group单位进行扩容,如果单位超过16个单位怎么办?当你的FastDFS上的硬盘是独立的模式,如果一台戴尔的730XD可以插14块硬盘,当硬盘再多时你会发现挂载时你在Nginx做配置,这个零零你们猜是10进制还是16进制,这个信息FastDFS的作者从来没有说过,作者说这个地方只能是16进制的,M00到MFF,就踩了这么一个坑,后来发现它在扩容时真的不方便,因为我以前用过TFS,所以建议我们老大换TFS.

TFS可以做什么呢?动态进行了扩容,我们现在是5台TFS DS,当容量不够的时候只需要往里面增加机器就可以了,每增加一台机器,原来5台的机器数据就可以做负载,增加到新的机器上,这个扩容是非常容易的,比起FastDFS的扩容简单的多,FastDFS的扩容每次绝对是两个服务器.

• 数据库：MySQL–à?Percona

服务器我们用的是MySQL,后来我们全部统一替换成Percona.原因是它里面的功能做了增强,对于一些空闲的事物做了控制,库里面的数据可以拿出来,在下次数据启动时可以进行热加载.

• 数据库读写分离：代码实现–à?OneProxy

唯品会也用过,但他们做了修改.13.0使用的一种方式,但是大部分的公司肯定不会投入这么大的精力.很多人只能说两台放在那里做高可用,结果到只要你的数据库连接库超过800就开“死”.发现它已经发布的版本跟下一个版本的文字表述是有差异的,会让我们踩到坑.代码里面并没有写名,这个配置1.4的版本是这样的,在1.5的版本是那样的,但是并没有写名,原代码的注释里面写的,一路坑.后来没有办法我们又上了Oneproxy,自从用上了这个,我再也没有关心过数据库的问题,基本上数据库没出现过问题,使用这个根本不用在数据库服务器上查询,通过Onepoxy我们可以直接看到业务过来的时候哪些执行时间非常高,哪些执行时间非常长,现在都不需要上服务器.包括我们的研发,现在都很主动、自觉地等到Oneproxy.

• 引入RabbitMQ并且实现集群化

原来我们写入数据库时,当你访问量大时数据库写压会比较大,我们引用了RabbitMQ,RabbitMQ很多公司也要用.做集群必须要注意一点,就是连接.节点之间必须配置长连接,如果没有长连接的话你的应用里面经常会报错,这个我们原来是碰上了.做调试实现了超连接.当然是TCP的而不是HTTP.

• 引入业务内网DNS系统：PowerDNS

再下面是引入了业务内网DNS系统,我们之前用的东西是非常低效,我刚去时代码连接的数据库存全是用的IP,只要用一遍,应用就要修改、重启,很麻烦.我并没有用棒的东西,虽然现在有插件,但是还是需要修改的方式,我当时觉得这个东西肯定不是高效的.我使用了的话没有办法进国内网的DNS系统进行匹配.

现在如果有新的机器要开或者有运维的变化,会通过我们的运维访问工具直接上数据库里面去写数据就可以了,不是很忙的时候可以通过PowerDNS的数据包进行修改.我们会通过格式导出来,导出来的文件会下发到所有的机器上面,让面还部署了PowerDNS的解析器,每一台访问的是宾机的PowerDNS的解析器.不管我们PowerDNS的认证器挂不挂,我都可以保证在解析方面不会出现任何错误的.

• 构建数据备份集群：LizardFS(MFS)

数据库的备份集群使用了分布式文件系统,MFS大家应该比较熟悉了,比较常见了.就是MooseFS.我们并没有使用官方的,而是使用了这个,MooseFS的衍生版,它能做什么呢?它实现了MooseFS的影子版,备份数据库的数据.这个指令可以在被动服务商上使用,通过其它集群的Moos,方便我做数据的任意节点的恢复.

• 引入Rundeck作为代码发布任务的平台

再下面发代码,我们使用了Rundeck,很多公司是可以自己做代码发布平台,就是通常所说的自动化运营平台.我们因为没有,所以使用这种Rundeck方式,这个可以建议大家使用一下,非常方便.

• 引入Kong作为API Gateway

最后是API网关,我们引入了开源的Kong作为API访问网关,这个主要是做手机APP用的,为什么使用它呢?原因是在于Kong的底层使用的就是Opneresty.这是我们2015年到2016年整个的改造,实现了发布代码的分秒级.数据库再也没有操过心,虚拟化也没有操心,我现在基本上不做原来以前一线的运维,现在主要做架构.

这个图是我们刚才说的DNS系统的.这是是MQ集群的结构,两个内存节点加一个磁盘节点.这个是TFS的集群,如何向我们的应用提供服务.

三、未来的展望

1、网络架构

今年我们准备即将要做的事情,第一个就是网络.网络这一快写准备把介入层设备华为的CE交换机并升级为2台,使用华为的网络设备虚拟化技术,Stack技术,把两台设备虚成一台设备.可以提供给冗余.

主要是为我们的技术网络做铺垫,我们现在已经准备部署了,但是网络端并没有使用Vxlan,因为这是非常重要的事情,使用Vxlan坑太多.

2、构建日志采集分析平台

第二个是构建日志采集分析平台,我们的分析平台跟网上人家讲的ELK完全是不一样的,我们不使用ELK,而是使用了V8,V8版本是可以做模板定制,收集日志是GRaylog,非常方便.

3、非核心业务Docker化

这是我们即将马上实施的Docker方案.

4、Web业务前段技术验证

第四个是技术认证,通过ECMP+HAproxy可以实现百万并发,如果你们去买过京东技术解秘,京东目前就是用了这样的方式.

5、运维其他方面

再接下来是其它的辅助.首先是运营平台的建设、资产管理、VPN.然后,实时性能的分析大家都了解过,我们准备使用开源.

第三就是Zabbix+OneProxy的分库分表设计,数据库的性能单采用的性能是撑不住的,需要做分表,这一块儿我们是非常熟悉的.而且新浪微博也使用Zabbix做数据库.

第四是GlusterFS深入研究和集群化.我们现在使用的换并没有做集群,我们做集群化实践考虑是跟这个有关,GlusterFS.

第五是OVS-DPDK,如果你们公司采用Docker的话这块东西是必然跑不掉的.我们为什么要去研究?主要是因为DPDK环境下可以实现单机网卡性能的最大化.

Q&A

Q1：我是一个做网站的,将来想做大型的网站,但我不是网管,你说的都是网管的事情,跟我们不相关.

A1：绝对不是网管做的,公司必须要有专门的运维团队.

(接上问)

Q2：绝对不是做网站的程序员管的事情吗?

A2：很多公司都是由写代码的人区别做的,当你的网站有一定规模时必须要有专门的运维团队.

Q3：我问一个比较low的问题,我对防火墙的理解不是特别深,我也是搞开发的.看到你们把防火墙拿掉了,会不会有安全性的问题?

A3：如果你的服务器能把大部分的关口给关闭了,你的服务器不得不开放公网时,你在启动时必须加上监听IP,要监听在内网IP上,不要监听在0.0.0.0上.你只要把不需要的服务给关闭掉,基本上可以解决80%的安全问题.

防火墙真的能防护你吗?防不住,传统的放火墙并不能帮你处理一些基层的处理,你要做策略是做不了的.传统的防火墙做不了这件事的,只有应用服务墙是专门做的.但凡设计到硬件有一个最大的问题,不易扩展.

（编辑：ASP站长网）