基于阿里云的云服务器如何进行调优运维

云端最热门的互联网应用，当属电商、游戏、移动社交、金融等。

在技术层面上，无非是java、php、python等开发语言，oracle、mysql、sqlserver等关系型数据库，以及mongodb、redis、memcache等非关系型数据库。

架构层面，无非是集群、负载均衡、缓存、文件存储、分布式等架构。

即使业务千奇百怪，回到架构层还是一样的，只不过针对不同业务，在架构中的考量和偏移会有所不同。

1.云端电商架构应用

业务特点：优惠活动、商品图片（静态资源几乎占了业务请求流量的80%）

技术特点：高并发

技术解决：弹性伸缩（解决促销活动的时候，访问人数、并发数量增大）、CND缓存（解决商品图片、视频比较多，变化不大，但经常访问）

2.云端移动社交

业务特点：海量（用户、图片、视频）

技术特点：大量信息存储

技术解决：非关系型数据库存储、OSS对象存储分布式文件系统、CND缓存（全是为了解决图片、视频、文件等资源的存储和访问）

3.云端金融架构应用

业务特点：安全

独立公有云，单独部署金融云（主要解决的是安全，其他方面根据实际业务调整）

4.阿里云主要常用有5个云产品5.使用云服务五个技术优势6.PV请求计算模型如下

每秒处理请求数量=（80%*总PV量）/（24小时*60分*60秒*40%）

7.用户数、活跃用户数、在线用户数计算模型

用户数*业务因子（10%-30%）=活跃用户数

活跃用户数*业务因子（10%-30%）=在线用户数

在线用户数*业务因子（10%-30%）=并发数 约=每秒请求数

1台8核16G的云服务器基本一天能处理web应用上百万的请求，所以可以对应100万PV。因此可以参加如下表：

8.PV量和服务器配置、RDS配置性能对应表PV（万）服务器配置RDS（数据库服务器）配置

1万

1核/1G/1台

无

10万

2核/4G/1台

1核/1G

50万

4核/8G/1台

2核4G

100万

8核/16G/1台

4核/8G

500万

8核/16G/10台

8核/16G

1000万

8核/16G/20台

16核/64G

互联网企业的服务器CPU利用率平均在10--20%，磁盘空间的利用率在20%--30%。在云端，80%企业存在资源核存储闲置浪费的现象。

阿里云最常见的配置是1核1G、1核2G、2核4G、4核8G、4核16G、8核16G、8核32G、16核64G、16核128G等。不管多少核多少G，CPU核数与内存大小的比是1:1、1:2、1:4、1:8。他们的应用场景及适合部署的软件服务汇总如下：

CPU与内存资源配比1:1

适用于个人网站、官网等小型网站部署，一般低配机器中，如1核1G，2核2G。基于云端实践，很少看到基于4核4G、8核8G、16核16G的配比。

CPU与内存资源配比1:2

1:2的处理器与内存配比可获得最优计算资源性价比，不管是线下IDC的物理服务器，还是云端ECS服务器的配置，1:2均为黄金比例。比如1核2G、2核4G、4核8G、8核16G、16核32G，这些都是实践中的黄金比例配置。1:2的配适用于绝大部分业务场景部署，尤其是需要消耗高资源的计算。如端游、页游、手游。在电商类高并发、秒杀活动类应用中使用得也特别广泛。使用最多的是8核16G，8核16G这个偏向与中大型web服务器/应用类部署。Tomcat适合中低配2核4G或者4核8G。因为Tomcat是单进程多线程的模式，是个轻量级且并发求请求数最多只能跑到1000左右。所以单台高配置的Tomcat的服务器并不能跑满服务器性能，会造成很大资源浪费。如果想跑满，常规做法是一台服务器上部署多个Tomcat。

CPU与内存资源配比1:4

比如2核8G、4核16G、8核32G。这类配比的配置偏向与内存，特别适合数据库类的应用。1:4尤其适合型数据库。8核32G是保障数据库具有良好性能的经典配置。但数据库数据是需要持久化，也就是写在硬盘上面的。需要SSD云盘提供高存储低读写延时。所以数据库对服务器首先要求的是I/O,其次才是内存。高内存会有效提升数据库的缓存性能，很大程度上提升数据库的性能。数据库其实对CPU要求并不高，所以偏向内存的配置，适合数据库部署。

CPU与内存资源配比1:8

比如2核16G、4核32G、8核64G。这类是高内存资源占比。尤其适合内存型数据库应用，比如redis、memcache的部署。在实践中，如果用8核16G部署一台Redis，会造成性能过剩。redis是单进程单线程模式，对多核利用得不太好，所以适合向1:4或者1:8的高内存资源配比考虑。如果想要redis把多核性能利用好，可以考虑一台机器上多部署几个redis。

9.磁盘空间选择参考

如果没有文件存储，只有linux系统日常基础日志存储，系统磁盘就足够了。

如果是部署代码的应用（如Java编写后生成的jar包或者war包放到tomcat上面），一般tomcat要输出日志，程序本身也有日志输出。所以系统盘默认的40G容量空间不够，一般选用100G-300G磁盘空间是标配。如果还需要存储用户上传的文件，可根据具体情况在评估。数据库类的应用php云系统，磁盘空间一般需求较大，都是500G以上。要存储数据库的Binlog、数据文件、备份等。数据库需要对数据读写有要求，即对磁盘I/O要求，一般采用高效云盘或者SSD云盘。

通过实践发现，100G、300G、500G存储空间对企业服务器配置是标配，但80%企业服务器磁盘利用率仅在20%-30%。

10.带宽选择8/2原则

很多人选择固定带宽。比如1Mbps、2Mbps、5Mbps、10Mbps、20Mbps，事实上，大多数情况没有必要。80%应该选择按量带宽。20%选择固定带宽。如果每天按量下载的量合计费用超过带宽平均每天费用，则使用固定带宽。

11.DevOps发展的四个阶段12.云端共享文件存储的方法

不是实时同步的，需要手动执行或者定时任务

Rsync只适合两台服务器之间同步

Inotify是监控工具，监控目录或文件的变化，然后调用Rsync进行数据同步。

Inotify实现工具工具有3款：Inotify本身、Sersycn、Lsyncd。实践中建议选择Sersycn。

Rsync、Rsync+Inotify、Sersycn更多应用于定时/实时单向同步，很少双向。如果是堕胎机器的数据共享。一般建议NFS（Network File System，网络文件系统）。开源的解决方案中，NFC是标准的文件共享解决方案。

13.监控方案

监控方案一：Shell/Python

应用场景：通过Shell或者Python脚本完成监控。这个监控解决方案一般用于不懂运维的研发人员，他们一般没听说过监控系统，所以就用自己擅长的开发语言，来完成日常的监控需求。

功能特点：主要通过脚本编码做些系统基础监控指标（CPU/内存/网卡/磁盘）报警

缺点：缺乏中间件、应用层监控。缺乏监控数据存储、数据查看等监控集中管理平台。

监控方案二：Nagios

物理机体系下，用的比较多的监控软件是Nagios

应用场景：IT基础架构监控，主要应用在主机系统、交换机路由等网络设备的监控上。

功能特点：偏向主机系统、交换机路由器等网络设备监控。

缺点：图形化差、很多功能通过插件化来实现，对技术能力要求很高、偏向主机层监控，在Nginx、Tomcat等应用中间件方面监控少

监控方案三：Nagios+Cacti

Cacti可以单独部部署使用以监控网络流量、监控数据图形界面展现效果比较好。

应用场景：Nagios+Cacti是物理机阶段最佳监控解决方案。

功能特点：Cacti良好的数据展示，弥补了Nagios监控软件的不足。

缺点：对技术能力要求很高、偏向主机层监控，在Nginx、Tomcat等应用中间件方面监控少

监控方案四：Zabbix

应用场景：企业级IT监控。

功能特点：主机、网络、中间件、日志等性能监控成熟完善。详细报表图标绘制、支持自动发现网络设备和服务、支持分布式集中管理、完善的API，支持企业定制化开发。

缺点：Zabbix用的是mysql为主的关系型数据库，服务端数据库有局限性。

需要在监控的目标主机中安装Agent，存在安全隐患。

对容器监控支持的不太好。

监控方案五：阿里云监控、驻云监控

监控方案六：Prometheus+Alertmanager+Grafana

Prometheus主要监控容器

应用场景：监控系统、时序数据库。只要有标准的HTTP协议的Metric数据，就能监控到Prometheus。

功能特点：

基于时序数据库（NOsql数据库）的多维数据库模型，同样适用于物联网海里数据存储及监控。

灵活的数据模型，特别适用于对于动态灵活性高的容器监控。

不需要Agent，只要监控目标能安卓标准的HTTP协议提供数据，即可完成监控。

（编辑：广州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!