中小企业基于开源 Web 的架构演变,这个部分尽量加速略过。因为分享时间有限,我用了很多图来更直观的展示:单机、机群、文件、缓存、数据、异地灾备。
0 X6 c# x+ \/ f: P7 Q
单机时代在Web架构上非常简单,单机时代我们关注的是单机的性能优化,这是很多人忽略的问题。 n8 |& C9 l4 d. Z) a7 Y
0 Q2 ~. e: d- J2 I( b# F组建分离,我们的图片要使用独立的**域名。比如说我之前是做电商的,需要写很多cookie到用户浏览器,如果都在一个**下,由于Cookie作用域的关系,别人访问图片的时候浏览器也会发送cookie 到图片服务器,这完全没有必要,可以使用独立的**应用来避免Cookie提交。
8 L7 b. l% p. T" h8 G1 S7 d- y) b
) _+ ^/ X2 i) A8 R' k7 _* [5 ?. P2 L' ]
& K! j+ Z6 \) n+ }
, i8 v* y% k0 `6 k" N( D单机时代主要关注的是 Web 性能,咱们做运维的,尤其是想面试高级工程师,现在到公司面试问的全都是基础问题。原因很简单,会基础了,其他的不会没关系,只要基础扎实就可以很快掌握,但是基础知识不会,遇到问题就很难快速定位和解决。% `- }9 q0 ]% R- `! O
/ D& f* U/ x) r2 I8 C0 h* A( ^! p# i
" {8 L$ U2 F6 ?' O# m: X) dsession 的处理方案总结起来有三种:一是会话保持,一个IP进来的可以固定访问到集群中的某一台后端机器上。还有就是 session 复制,基本上不建议使用,曾经6个节点的 Tomcat 集群做 Session 复制就会出现各种问题。最后 session 共享是终极解决方案。
3 W* s& {; B! R7 c5 d很多人会被文档把思想固化住,要记住别人写的东西未必是正确的,我可以说我今天讲的也未必是正确的,一定要学会分析,然后沉淀成自己的东西。就像网上有一种文档,就是你照着做,一定不会成功。
阿里开源的 Dubbo 是一个成功的开源 SOA 框架,帮助了很多公司,不过现在我司的一些服务正在从 Dubbo 框架迁移到Spring Cloud。这里不讨论孰优孰劣,真的是看具体需求了。
架构再往下发展就涉及到分布式部署,看看腾讯的分享,它们在这方面会做的比较好。
存储层面:0.tmpFS,最早玩 Squid 的时候,直接是挂载一个 tmpfs 文件存储,性能特别的快,因为 tmpfs 是占用系统的共享内存。
, \; d0 L9 ?" E7 z @4 |
I! w2 l" l* E+ @- l1. 本地硬盘
2.DAS 存储
3.SAN 存储都是块存储类型。
, ~9 z7 ^# H0 F
在做Web架构的时候,除了块存储用的最多的就是文件存储。在集群架构中,文件存储可以使用例如 NFS 的共享存储,还可以使用文件的分发和同步。还可以进行多级的分发。
: l- p) j8 [1 t2 h
- g/ d R; A7 d' v$ }# J我司是在标准化的原则上,统一用分布式的文件系统 Glusterfs 来做,早期图片是用的MooseFS 。还有一个系统是用 FASTDFS,对于做小视频或听书类的服务,每个文件大概是5M-20M左右,用 FASTDFS 特别合适。
- Q# B9 _0 F& n" g4 I讲完集群和存储,就到了Web架构中的缓存,我编写了一个《Web 缓存知识体系》,因为我在学习缓存的时候发现所有人的文章都是一个点,想把整个面都串起来的文章找不到,所以就自己把缓存的体系串联起来。我们通常所的缓存,会包括读缓存Cache和写缓冲Buffer。这里只聊读缓存 Cache。
( w' a8 d( R- d2 ~4 k
DNS 缓存,浏览器的 DNS 缓存,比如说 firefox 默认缓存60秒,操作系统DNS 缓存,DNS 缓存服务器,应用程序 DNS 缓存。浏览器是分发在千家万户的缓存代理,用好会非常的方便,所以浏览器缓存协商的三种方式是运维必会的,基于最后修改时间、Etag和过期时间。
4 {. n8 ~8 h5 D
代理层的缓存,反向代理反存,包括Web缓存,包括 Opcache 缓存。我之前在项目做过一个实验,我们是 PHP5.5,我开了 Opcahe 之后,我们的用户态CPU使用率从70%下降了40%左右。
( ^6 M; r3 M4 [ p. ~+ Q- H
做电商的对页面静态化比较了解,一般我们会有一个CMS系统,从后端服务集群获取到产品详细页、列表页等这些需要静态化的服务,然后将获取到的HTML本地缓存进行对应的修改后,直接使用Nginx发布出去。
, h" J! G7 R. e% Z聊完缓存在Web架构中,比较重要的就是数据库了
4 b8 a; ~3 x* `1 p1 P7 G: S7 x1 k. @5 X9 |/ j
拿 MySQL 的主从复制做例,目前我们用的最多的是主主复制,单写,因为双写有很多双写的问题,所以用单写的方式来做。
+ K; b Z) w' X: |: C9 a目前使用最多的方案就是 MHA 了,之前使用 MySQL MMM 问题很多。
5 R V, R+ v/ B! {6 yMySQL Proxy 的方案之前试用过 MySQL Proxy 和 Atlas,这个要看具体的需求,我不直接推荐。
4 ]1 E [6 y: O# _/ {9 f1 N7 u
7 W G) s# _/ Z# k; GMySQL PXC是我推荐的一个方案,当然和 Atlas 解决的问题不同。
如果从 DAL 层的观点出发,MyCAT 目前应用案例相对比较多一些
0 P* O$ O4 w3 l# ]1 X& E0 L2 q但是真的要把 MyCAT 玩明白需要一个团队,中小企业成本有限,很多使用客户端分片不仅保险,而且成本低。当然运维成本就高了。
1 |+ u) a* g4 J! V' G' K# a% ~: e
1 s* d$ g0 `9 ~ J最后推荐一下 Tidb,底层是分布式 KV系统,在 Tidb 这层实现了 MySQL 协议,访问它几乎就像访问 MySQL 一样。
% H2 B1 K5 }. E1 }% C& ?# l
" Y8 _3 t, Y5 {& @$ s2 B: H
最后聊聊异地灾备:
0 @4 N0 L: {4 p* W4 V3 y* U W4 e
创业公司倒闭机房着火哪个机率大?很多人会回答是创业公司,但是!说一个真实的案例,天津塘沽事故的时候,我们的服务器在托管在天津塘沽机房,当时我们启动了临时紧急灾备,把数据全部往其它机房都做了备份。
8 W7 A; W7 o" R6 N6 k( s; [对于很多互联网公司来说,不管公司市值多少个亿,要是机房真的没了,整个公司就没了,一点都不夸张。所以我强烈建议,不要考虑几率,灾备必须做,可以实现低等级的灾备,但是有胜于无。
根据灾备国家标准六个等级七个要素,我们做了一个分层、分阶段的建设,先有后完善。
我们当时的原则是先有,后完善,非对称配置。徘徊在”冷备”和”双活”之间,例如在 Nginx 上根据 IP 地址做分流,分一些量到灾备机房,保证备用机房的服务是真正可用的,然后定期做这样的测试。基本上是用了最低的成本做好了运维最后的防线。所以不要说自己是中小企业没钱,没钱有没钱的做法,但是不能不做。
6 c/ J; A* t0 | i3 |0 N% z
4、自动化运维发展历程0 I# f: y9 ~! y* Q; C
自动化运维发展历程,做自动化运维可能需要需要经历标准化、工具化、Web化、平台化、服务化、智能化。所有不以解决运维痛点的自动化运维都是耍流氓,现在很多公司都在做自动化运维平台。我这里有一个痛点案例:
我们有一个oracle数据库要升级打补丁,涉及到停库,先停备库打补丁,未来再停主库打补丁。需求是查找所有业务系统中03:00-06:00的所有定时任务(我们很多操作数据库的定时任务是crontab管理的),确定哪些定时任务连接需要停机数据库。如果你有上千台服务器,自杀的心都有了。
" _: }. ]/ u( B* `6 G0 k4 Y+ Q& X虽然最后是解决了,但是告诉我们只有标准化、工具化是解决不了问题的,所以要往Web化发展,后来我们做了一个作业平台,把定时作业全部通过作业平台管理起来。想加一个定时任务,提交工单,工单把所有任务记录下来,然后可以做查询。
% @$ ?% U. _1 x& E0 u, `. {; r
5 |$ ]4 O' i, E$ _0 L7 k所以要分析自身情况,找准痛点,不要盲目的做。
+ F+ v+ H- T' i% ]! m基于开源的全链路自动化运维体系是按照一个项目上线的流程来整理的。从传统的角度来说:
' k, s1 z5 x/ g: k' ~自动化系统安装:从自动化安装开始入手,使用Cobbler可以在企业中构建的自动化装机平台和私有Yum仓库;
配置管理:系统安装完毕后,然后我们需要在系统上运行服务,进行管理和配置,SaltStack可以帮助我们进行远程执行和配置管理,当然云管理也是SaltStack的非常棒的功能;
自动化监控:系统安装完毕后,我们需要做的第一件事情就是监控,可以基于Zabbix构建自动化、分布式、多维度的监控体系;
持续交付:应用服务使用SaltStack部署并运行后,我们需要将应用代码部署到集群中,使用Jenkins可以完成持续交付相关的工作。
日志收集:代码上线后在业务运行中,会产生不同类型的日志,那么紧接着我们通过ELKStack(Elastic Stack)来构建一个日志收集、存储、和展示平台。
基础设施自动化:可以使用OpenStack、Kubernetes来进行基础设施的虚拟化和容器化。
! Q, g5 U2 `+ Y
9 T7 O4 x0 g: y! l2 {2 R( S
最后所有的数据库放在 CMDB。所以说这是一个全链路的自动化体系。
从几个层面介绍一下,一个是 OpenStack,我们两个版本,一个I版,一个M版,做的多区域。
像上图的架构是可以用 SaltStack 进行自动化的配置管理。
基于 Jenkins 的持续交付。做自动运维要做一个体系,要解决全链路的问题,而不是做某一个层面,要把整个方面全考虑到位。
上图是我们基于 ELK 做的日志数据分析平台,我们这个有大数据的部分,会把数据全部写在 Kafka 里面,然后从 Kafka读出来,一部分写在 ES 里面,一部分写在 Hadoop 里面。
- z- s$ V; D7 y, w' C9 W; ^
8 c, R! t/ n* C然后基于 Hadoop 做数据分析和处理。 ES 主要是用于搜索和运维。这里想强调一点,如果你的业务也用ES的话,你要把运维的 ES 和业务的 ES 分开。
我做了一套基于全开源的智能化扩容的实现。例如 Zabbix 触发扩容,调用 Salt-Cloud 创建 OpenStack 虚拟机,将信息写入到 etcd,然后调用 SaltStack 进行环境部署,调用 Jenkins 进行代码部署,调用自动化测试进行测试。
: `) u8 ^5 F+ W6 @
p. [$ r7 ^9 b7 Z' w r# b n
最后 SaltStack 管理 Haproxy 的配置文件,进行自动重载,完成扩容工作。当然这只是一个简图,有 CMDB 的话,可以直接替换掉 etcd。
& O, ?, f, v, i& w+ C
5、未来展望下一步怎么走?刚才讲的做运维是标准化、工具化、平台化、服务化、智能化,下一步是产品化,对于一些运维老司机,在运维行业深耕多年,找准机会就可以创业去了。
技术成就梦想,最后,希望所有运维人都能够持续学习,不断成长,事实证明,运维不仅仅可以背黑锅,还可以站在舞台的正中央。我为自己是一个运维人而自豪!(转自赵班长)1 d: `% }1 \. R0 J% d2 f+ ]