谈运维架构

根据几年的工作经验，在脑子里简单总结出来一些运维架构上的想法，写了下来，不当之处，欢迎指正，详略也不太适当，欢迎补充。

互联网企业从初创起步，以产品为核心进行发展壮大，因此运维常常成为开发的附庸，开发人员兼职运维的情况并不少见，如果有专职的运维人员，最多的工作也只是IDC机房运维。并且，运维人员的工作非常繁杂，知识面要求非常广，工作压力特别大。对于各种运维故障，几乎都会得到开发人员的立即响应。纵观整个初创阶段，都是面向产品的运维。

等到企业发展壮大，企业特性比较稳定，企业文化比较成熟时，服务器数量也发展到了一定规模，原来的单一产品变成了产品线甚至多条产品线，由于企业已经有了稳定甚至庞大的用户群，这个时候，企业必须以服务为核心，才能保持竞争力。也就是说。大中型企业的运维，是面向服务的运维。跟所有的大中型结构一样，这种运维讲究分工，实际上是面向基础架构的运维，因为基础架构即服务（IAAS）。随着云计算的深入发展，事实证明，国外这几年风气云涌的几大思潮SAAS（Software-As-A-Service）、PAAS（Platform-As-A-Service）最终都并入了IAAS （Infrastructure-As-A-Service） 。

一，面向基础架构的运维

面向基础架构的运维要求有明确的分工，在开发人员之外，提供了许多专业职位，运维架构师，DBA，网络工程师，系统分析师，自动化工程师，系统工程师 等等。

二、面向产品的运维

这个时候，产品运维虽然划归运维，但更像是运营，它的工作内容很多时候跟实际的IT技术脱节，反而跟用户更接近，以用户的身份来报告产品缺陷，挖掘产品潜力，提出新的市场需求，很多大公司都有各种产品经理，这里不细谈。

面向基础架构的运维该怎么做？可能大家在不同阶段或多或少的都做了一些，下面是我一些具体的心得体会。

一、程序和数据库分离

这个想必是人之共识，也是网站迈向架构设计的第一步，但这的确是最基础的架构设计。

二、域名和程序分离

这个呢，说白了，就是程序能够独立于域名而存在。

这个问题在程序设计之初一般不会出现，主要是程序功能不断堆积过程中，不小心将域名纳入了业务逻辑而导致的。结果是web服务器必须放在最前端，影响负载均衡，缓存系统的设计。

三、动静分离

如果在可预期的未来，与程序相伴的还有数量可观且不断增长的静态文件，那么最好要设计动静分离，否则会严重影响程序的横向扩展。

动静分离应该彻底将程序和静态文件作为系统的两个独立模块来设计，避免NFS之类的挂载使用方式（静态文件只是在物理上独立，在逻辑上依然从属于程序下的某个文件夹）；

四、保证配置文件的独立性

配置文件通常依附于程序，但也要保证一定的独立性，并且高度集中；

五、保证程序的扩展性和可维护性

程序在设计之初不光要考虑性能，还就要考虑如何扩展，如何排障，甚至提供监控接口；

六、负载均衡和web服务器分离

负载均衡应该是独立的功能实现，跟业务逻辑没有任何牵扯。

顺便唠叨一句，微软的NLB是个极其差劲的负载均衡方案，而LVS/nginx/haproxy都是优秀的。

七、高可用系统

给关键点（前端、数据库）设置必要的冗余和高可用（磁盘阵列，冗余电源，drbd，heartbeat，keepalived，pacemaker等）；

八、缓存系统

缓存系统是提升网站的响应速度最直接的办法，不论是文件级的缓存还是数据库缓存。Nosql 是常规架构很好的补充，速度几乎都是内存级的，memcached、redis等；

九、独立的监控系统

作为业务的辅助功能，集中式的监控系统非常必要；

十、自动化系统

集中式的用户管理，主机名管理（DNS），配置管理，程序发布系统；

十一、架构分层

按照网络划分，一般有：外网，内网，管理网

按照功能划分，一般有：接入层，缓存层，业务层，中间层，数据层，存储层

十二、运维流程化和文档化

流程化指的是团队协作分工，文档化是指企业运维资产的积累和传承。成熟的流程和文档能够减轻排障的技术难度，均衡团队成员的能力差异，达到快速分析，排障直指要害。

本文出自 “专注Linux 运维” 博客，请务必保留此出处http://purplegrape.blog.51cto.com/1330104/1288813