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

偏执的太偏执、 2022-09-24 14:21 187阅读 0赞

当前数据中心TCO成本构成中，服务器及机柜成本是最大成本，约占总成本的54%左右，排在第二位的是供电和制冷，约占21%左右，从中可以看到，服务器成本优化对整个运营成本控制是有关键作用。

当前服务器发展趋势是大规模（高密度、定制化）、更低功耗、更高性能，各大公司主要与OEM厂商合作，根据各家公司业务类型进行定制，定制过程对外坚持多品牌，去差异化，对内屏蔽品牌信息，套餐化。基于硬件的定制并结合服务器分类、分级、分层达到成本的优化有以下几点分享如下：

服务器分类

互联网公司都有多个产品线，例如腾讯、百度都有近百个产品线，每个产品线又分产品，每个产品又对应不同的硬件和网络，这些产品重要程度和规模各不相同，需要选择对应的类型的服务器硬件，如图11-1所示，以免造成资源闲置和浪费，通常会将服务器分类如下。

1、接入型服务器，主要用于WEB接入服务器，I/O密集型并且CPU处理少，这一类属于低成本服务器，要以为单电源模块和扩展插槽、无热插拔、无RAID等，可以根据CPU、内存、SSD、硬盘等再进行2~3种分类，也可以使用高密度服务器，例如一U两机、二U四机，密度提升50%，功耗减少15%，机架租用成本减少一半。

2、均衡型服务器，主要用于应用服务，可以理解为是通用服务器，与专用服务器区分开来，用于逻辑服务或中间层服务均可，可以根据CPU、内存、SSD、硬盘等再进行2~3种分类。

3、存储型服务器，主要用于线上、线下存储服务，大硬盘大存储空间，可以根据硬盘空间和类型再进行2~3种分类，这类服务器也是各家互联网大公司存储云的主力服务器。

[![wKioL1MNnY6jo4meAAEhkE-WZu4716.jpg][]][wKioL1MNnY6jo4meAAEhkE-WZu4716.jpg]

表11-1 模块分类及服务器分类

服务器分层

根据产品架构分层，每层使用不同类型的服务器，每一层服务使用一类服务器，可以让性能均衡，最大极度使用服务器资源，也有益于做容易管理，批量上架扩容，批量下架退役，优秀的运营规划师可以让每一层的应用最合理的使用服务器资源，进而避免资源闲置和浪费。

服务器分级

根据产品重要程度，收入大小，上线时间等，可以将对应的服务器进行分级，

1、优秀产品，例如收益高的产品和明星新产品，各层模块使用全新、高配服务器，保持低容量，并准备充足预算，每季度提前扩容。

2、稳定产品，2~3年稳定产品服务器保持高容量外，使用对应年限的服务器进行更新扩容，甚至根据容量下线合并服务器。

3、历史产品，4年以下产品，这类业务历经多年，也历经多个研发，又交叉被多个产品线使用，这类服务器最终将面临服务器老化退役，需要提前将这类业务模块进行合并或者平台化、甚至是剥离下线。

服务器分类、分级、分层定制适合非云化的公司和产品，优秀的运营规划师像管家一样，将线上服务和成本理料到一个平衡点，最佳使用资源又不浪费。

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

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

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

按通用应用分类平台化

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

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

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

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

将对平台化应用做到极致

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

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

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

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

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

服务混布的前提

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

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

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

服务混布的问题

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

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

来自:http://os.51cto.com/art/201402/430418.htm

[wKioL1MNnY6jo4meAAEhkE-WZu4716.jpg]: /images/20220719/ced29cbdb61349068fba8d3823258231.png