运维经验分享：服务器成本优化策略

业务分类平台化减少运营成本

运营资源（各区域+各IDC的服务器、带宽、专线、QOS）与产品线的现有架构和实际增量需求（包括未来架构变化，扩展、优化），都与容量管理、成本管理相关，最终驱动预算和预算模型实现，最终又通过运营成本体现。

大公司有多个事业部多个产品，而每一个产品都需要多种运营资源，都需要容量管理、成本和预算管理，让每个产品每个团队都具有好的规划能力是不现实的，而将产品中的模块分类抽取合并成平台，就可以统一规划和管理，将运营资源进行有效控制，服务分类平台化分享如下：

按通用应用分类平台化

谈到淘宝，大家应该对淘宝的CDN平台有很深刻的印象，2012年双十一最高流量达到2000G，是当下互联网公司最大规模的静态应用平台，分析淘宝网站不难发现，淘宝80%~90%的流量是由静态图片贡献的，这个案例可以关联所有的电商类网站、社区类网站、门户类网站等，通常平台主要有以下三个方向。

1、静态类平台，大图、小图、文本、JS、下载、视频等

2、动态类平台，逻辑、列队、消息、推荐、账号、关系、PHP、Java等

3、数据类平台，日志、计算、存储，数据库等

将对平台化应用做到极致

淘宝的CDN是一个例子，规模、架构、硬件、内容、速度、成本追求极致，这一个典型的应用平台成功案例，这种应用平台可以做到部门级、公司级平台，甚至做到业界最好的平台。

平台不是一蹴而就的，从小到大，由粗放到精细，而且不断吸收历史及新产品中的同类应用，不断壮大。传统运维新上线的业务如同需要准备很多原料，再对原料进行加工，而平台化之后，只需要拿组件进行组装即可，而且这些组件不用自己维护。

混布最大限度提高资源利用率

随着应用平台化、集约化，应用平台已经慢慢取代传统运维的对象，也就是产品线，而应用平台又由应用集群构成，所以集群已经成为了当下的运维基本单位，而随着各项业务的发展，各种集群规模以每年以数倍的速度高速膨胀，大的应用平台服务器已经达到了数万台服务器规模。

而这些平台的功能和角色各不相同，总体又分CPU密集型、I/O密集型、存储密集型三大类，如果平均下来，服务器整体资源利用率却不高，资源利用不均衡，平台和集群数量越大，浪费越多，因历史扩容和服务器硬件不一致等原因，会加重这种资源的闲置和浪费，这一类有规模有规律的资源闲置可以通过服务的混布来提高资源的使用率。

服务混布的前提

1、平台类业务，平台类业务具有规模属性，同时也具备了多区域和多IDC分布、数据分发、备份等必要的积累，可快速整合进行混布上线。

2、非突发、不同类型业务，突发类业务因热点事件可以将负载提高到平时的数倍，所以不适合做混布，相同类型业务因存在资源竞争，也不适合混布，同类业务资源使用率低可根据资源使用趋势决定是否混布。

3、硬件配置、网络分布接近，在多个产品的生命周期的各环节，服务器和服务器所在的IDC是分批次采购和上线，因为产品不是短时间成规模的，而硬件几乎每年都发生巨大变化，硬件接近可以让各区域的模块性能平衡，如果硬件存在大的差异，会出现"头重脚轻"的性能不均现象，为了混布可以进行硬件升级或置换。

服务混布的问题

1、集群交叉影响，混布的集群因用户规模不同、用户解析策略不同、资源使用率增涨趋势不同等，会存在必然的交叉影响，这种影响会发生在超载的状态下，所以容量管理做好的前题下可以有效规避。

2、硬件交叉影响，硬件故障具有必然性和不确定性，这里的硬件是指所有线上生产环境的硬件，网络硬件、服务器及机架硬件等，硬件故障可以导致混布的集群直接不可用，所以混布要依赖平台健康监测和自动恢复能力。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友