Hi~各位读者朋友们，感谢您阅读本文，我是笠泱，本期简单分享下云服务器规格与带宽选型。

本期导语

在阅读本期正文内容前，有几个概念需要读者朋友大致了解：

PV：Page View，即页面浏览量，一般指一天内页面访问次数，每打开或刷新一次页面，就算作一个PV，PV值通常用来衡量网站的流量大小，反映网站的访问频次和访问深度。在评估网站的用户活跃度和流量变化趋势时，PV值是一个重要的参考指标。

UV：Unique Visitor，即独立访客数量，一般指一天内访问站点的用户数，UV值能够反映网站的受众数量和用户粘性，即网站的忠实用户数量和留存率。UV值是衡量网站用户粘性和受众规模的主要指标之一，也是评估网站营销效果和用户转化率的重要参考指标之一。

IP：Internet Protocol，即独立IP地址访问量，一般SEO优化服务所说的流量就是指每天访问网站的IP量，每天同一个IP只计算一次，IP值可以反映网站的受众范围和地域分布情况，以及用户访问的网络环境和设备类型等信息。IP值虽然不能准确地反映网站的独立访客数量，但在评估网站的地域分布和受众群体时，具有一定的参考价值。

PV、UV、IP的简化换算关系如下：

活跃用户数 = UV * 0.2

在线用户数 = 活跃用户数 * 0.2

并发用户数（≈ 每秒请求数）= 在线用户数 * 0.2

PV = （IP量/活跃用户数）* 5

业务访问规律：一天中80%的业务请求发生在一天的40%的时间内。即用户请求访问量主要集中在白天，晚上业务请求量少，这是业务访问的一个特点，即一天的40%时间即9.6小时。

云服务器配置模型

先来看一个云上服务器配置选型最经典的失败案例，某客户使用16核64的服务器部署一个tomcat，这里要注意的是，只是一个tomcat，导致一台高配服务器资源使用严重过剩。虽然云解决了IDC硬件资源的利用、管理等问题。但是还未解决大家对服务器配置选择、甚至云产品规格型号的使用问题。资源过剩一直是IT管理中最大的问题。通过统计我们发现，80%的企业服务器的性能使用率仅在20%左右，这便是经典的资源利用八二原则。

那究竟云服务器配置选型有什么窍门？

首先需要将业务指标转换成技术指标，才能做好机器资源规划，如何根据访问量计算出合适的资源需求？举例：一个500万PV的网站，大概需要用多少台服务器？如果单纯的用500万 / 24 / 60 / 60 = 57来计算得出每秒请求数这是不合理的，根据业务访问规律一天中80%的业务请求量发生在40%的时间内，所以合理的QPS = (500万 * 0.8) / (24 * 60 * 60 * 0.4) = 115.7 个，偶尔还有高峰，高峰可能是平时的2-3倍，115.7 * 3 = 347.1个，如果一台服务器每秒能处理347以上的请求就可以抗住500万的PV。

下图是一个简单根据PV量所需对应的服务器资源参照表，仅供参考：

在获得总资源需求后，那具体的CPU和内存资源配比又该如何选择？

我们先来看看CPU与内存资源配比为1:1 ，适用于个人网站、官网等小型网站部署。一般在低配机器中，如1核1G，2核2G，基本上在云上实践中，我们也很少看到过用4核4G、8核8G、16核16G的云服务器来运维部署。

然后是1:2的配比，可谓是黄金配比，可以获得最优计算资源性价比。不管是线下IDC的物理服务器，还是云服务器的配置，1:2都为黄金比例。比如，2核4G、4核8G、8核16G、16核32G等。1:2的配比适用绝大部分业务场景部署，尤其需要高计算资源消耗。不过在云上应用配置最多的实属当为8核16G，这也是云服务器黄金比例配置中的最佳实践。web应用类特别适用1:2的配比，对CPU、内存都需要最优的计算资源。对于前面说的那个失败案例，Tomcat部署适用用中低配：2核4G、4核8G，特别是4核8G是最优选择。因为tomcat是单进程多线程的模式，是个轻量级且并发请求数最多只能跑到一千左右。所以单台tomcat高配的服务器并不能跑满服务器的性能，造成很大资源浪费。如果想跑满中高配服务器性能，我们常规做法就是在一台服务器上部署多台tomcat。

接下来是1:4的配比，比如2核8G、4核16G、8核32G。这类配比的配置偏向内存，特别适合部署数据库类的应用。为什么这么说？我们知道数据库对服务器性能的需求首先是IO，因为数据库是个存储类应用，涉及数据持久化，所以IO性能的要求是最高的。其次才是内存，因为高内存能有效提升数据库的缓存性能。特别是MongoDB基于内存映射，大内存配置能有效发挥出MongoDB的性能特点。最后，数据库其实对CPU的要求并不是那么高。所以偏向内存的配比配置，特别适用部署数据库类的应用。

最后是1:8的配比，比如2核16G、4核32G、8核64G，这类是高内存资源占比。尤其适用于数据库类中的内存型应用，比如redis、memcache的部署。

一个经典案例：单个 python、squid、redis 部署在一台8核16G的服务器中合理吗？python、squid、redis都是单进程，对多核利用不好，8核CPU这会造成性能很大的剩余。当然，如果想对多核的性能资源利用好的话，可以跟tomcat一样，在一台机器上部署多个python、squid、redis进程实例。

带宽配置估算模型

相比服务器配置，带宽配置的选择更让人抓耳挠腮。一个网站，究竟选择怎么样的带宽配置？先看一个在云上带宽配置选择的经典失败案例，某一线知名大牌明星做的一个母婴用品电商平台，公司开发开了二十台8核16G 20Mbps固定带宽（一个月约四五千）来跑Java应用，这是一个对带宽配置使用没有概念的极端例子。

那在云上怎么跟应用估算带宽配置？

配置估算的参考是依靠我们业务访问的规律，在带宽配置估算时，就可以用总请求量（80%*总PV量）除以这些总请求量所花的时间，得到每秒的请求总量，然后乘以单次请求的数据大小，便得到带宽配置。

带宽配置计算模型：

带宽配置（平时访问量） = （80%*总PV量）/(24*60*60*40%） * （单次请求大小）  换算成Mbps/s

带宽峰值 = 平时访问量带宽的2~3倍

举例：某网站一天的访问量100万pv总量，假设平均页面大小20KB（实际大小，大家根据自己业务的特点来估算）。所以100万PV带宽配置为(80%100万)/(24*60*60（一天的秒数）*40%) * 20KB/s = 23.1个请求/秒 20KB/s，最后折算成带宽即3.5Mbps。

以上计算只是一个平均值，考虑请求压力的峰值波动，加上2倍或者3倍峰值，带宽配置变成7Mbps、11Mbps，所以建议用10Mbps带宽配置。

此外关于云上带宽究竟选择按量付费模式还是固定带宽模式，这里有一个参考标准：80%情况下默认选择按量带宽，足以应对突发流量；20%情况选择固定宽带（如果每天的下行流量合计费用超过按量的平均费用，才使用固定宽带）

云上运维的发展阶段

1、人工阶段

搬服务器、网络部署、机器上架、重启机器、更换硬盘、更换内存、解决硬件故障、环境配置、安全、故障处理、发布上线。

2、脚本及工具阶段

脚本解决大量重复的工作，Python已成为云端通过脚本进行自动化运维的标准，Ansible无疑也已成为云端通过工具自动化运维的标准。

3、DevOps阶段

DevOps的出现是为了解决软件软件开发人员和IT运维技术人员之间的沟通协作问题，以使得构建、测试、发布软件能够更加快速、频繁和可靠，提升业务快速集成和交付。

4、平台化阶段

通过图形化界面快速运维，通过web界面简易操作即可完成对各类云资源的操作。

5、智能化阶段即AIOps

需要大量的运维事件数据支撑，对事件的历史数据进行场景分类和标注，不断用模式识别和数据来训练机器识别和分析，然后让机器自动准确判断。AIOps的核心在于AI算法在运维领域的运用，但目前市面上类似的成熟解决方案和产品少之又少，还处于发展中。

本期总结

本期内容分享了下云上服务器的规格与带宽选型参考模型，希望供遇到相关问题的读者朋友提供一定参考，以及在文末简单谈了下云上运维发展阶段。

最后，感谢您的阅读！系列文章会同步更新在微信公众号@云上的喵酱、阿里云开发者社区@云上的喵酱、CSDN@笠泱，您的点赞+关注+转发是我后续更新的动力！

参考资料

《降云十八掌——阿里云运维架构最佳实践》

https://developer.aliyun.com/article/716324

《云上运维架构》

https://developer.aliyun.com/article/1317687

《阿里云官网-ECS实例规格选型指导》

https://help.aliyun.com/zh/ecs/user-guide/best-practices-for-instance-type-selection