《阿里云运维架构秘籍》笔记
《阿里云运维架构秘籍》
主要讲述的是：基于阿里云的云服务器如何进行调优运维。
云端最热门的互联网应用，当属电商、游戏、移动社交、金融等。
在技术层面上，无非是java、php、python等开发语言，oracle、mysql、sqlserver等关系型数据库，以及mongodb、redis、memcache等非关系型数据库。
架构层面，无非是集群、负载均衡、缓存、文件存储、分布式等架构。
即使业务千奇百怪，回到架构层还是一样的，只不过针对不同业务，在架构中的考量和偏移会有所不同。
云端电商架构应用
业务特点：优惠活动、商品图片（静态资源几乎占了业务请求流量的80%）
技术特点：高并发
技术解决：弹性伸缩（解决促销活动的时候，访问人数、并发数量增大）、CND缓存（解决商品图片、视频比较多，变化不大，但经常访问）
云端移动社交
业务特点：海量（用户、图片、视频）
技术特点：大量信息存储
技术解决：非关系型数据库存储、OSS对象存储分布式文件系统、CND缓存（全是为了解决图片、视频、文件等资源的存储和访问）
云端金融架构应用
业务特点：安全
独立公有云，单独部署金融云（主要解决的是安全，其他方面根据实际业务调整）
阿里云主要常用有5个云产品
ECS(Elastc Compute Service)弹性云服务器
RDS(Relational Database Service)关系型数据库
SLB(Server Load Balance)负载均衡
OSS(Object Storage Service)对象存储服务
VPC(Virtual Private Cloud)专有网络
使用云服务五个技术优势
1 安装配置方面
2 调优方面（比如mysql调优）
3 备份方面
4 高可用（比如ECS和OSS都是三副本的数据冗余）
5 安全性方面（不用考虑攻击）
|
指标 |
计算周期 |
含义 |
|
PV |
天 |
Page View的简写，页面浏览量或点击量。一般指web类业务一天内页面的访问次数。每打开或刷新一个页面，就算一个PV。 |
|
UV |
天 |
UV是Unique Visitor简写，独立访客数。Web类业务一天内访问站点的用户数（以Cookie为依据）。如果更换了IP但不清除cookies，再访问相同网站，UV是不变的。如果不保存cookies访问/清除了cookies，计数会加1。00：00-24：00内相同客户端多次访问一个网站只计为1个访客。 |
|
IP |
天 |
Web类业务一天内有多少独立的ip浏览了页面，即统计不同的IP浏览用户数量。同一IP不管访问了几个页面，独立IP数均为1；不同的IP浏览页面，计数会加1。IP是基于用户广域网IP地址来区分不同的访问者的，所以，多个用户（多个局域网IP）在同一个路由器（同一个广域网IP）内上网，可能被记录为一个独立IP访问者。 |
|
用户数 |
|
一般指业务系统的注册用户数 |
|
活跃用户数 |
按天 |
指注册用户数中，一天中实际使用了业务系统的用户数量，跟UV差不多 |
|
在线用户数 |
按天 |
指一天的活跃用户数中，用户在一定的时间段内的在线数量 |
|
并发用户数 |
|
指在线用户数基础上，某一时刻同时向服务器发送请求的用户数 |
一个网吧里有5台电脑使用同一个IP，此时五个人同时打开同一个网站，并且每个人都刷新了2次。这种情况，网站的数据为：10个PV，5个UV，1个IP。
一天的80%业务请求主要发生在40%的时间内，这成为我们计算PV值对应请求的依据。
PV请求计算模型如下：
每秒处理请求数量=（80%*总PV量）/（24小时*60分*60秒*40%）
用户数、活跃用户数、在线用户数计算模型：
用户数*业务因子（10%-30%）=活跃用户数
活跃用户数*业务因子（10%-30%）=在线用户数
在线用户数*业务因子（10%-30%）=并发数 约=每秒请求数
1台8核16G的云服务器基本一天能处理web应用上百万的请求，所以可以对应100万PV。因此可以参加如下表：
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。
磁盘空间选择参考如下
如果没有文件存储，只有linux系统日常基础日志存储，系统磁盘就足够了。
如果是部署代码的应用（如Java编写后生成的jar包或者war包放到tomcat上面），一般tomcat要输出日志，程序本身也有日志输出。所以系统盘默认的40G容量空间不够，一般选用100G-300G磁盘空间是标配。如果还需要存储用户上传的文件，可根据具体情况在评估。数据库类的应用，磁盘空间一般需求较大，都是500G以上。要存储数据库的Binlog、数据文件、备份等。数据库需要对数据读写有要求，即对磁盘I/O要求，一般采用高效云盘或者SSD云盘。
通过实践发现，100G、300G、500G存储空间对企业服务器配置是标配，但80%企业服务器磁盘利用率仅在20%-30%。
带宽选择8/2原则
很多人选择固定带宽。比如1Mbps、2Mbps、5Mbps、10Mbps、20Mbps，事实上，大多数情况没有必要。80%应该选择按量带宽。20%选择固定带宽。如果每天按量下载的量合计费用超过带宽平均每天费用，则使用固定带宽。
DevOps发展的四个阶段
1 人工阶段
2 脚本阶段
3 平台化阶段
4 智能化阶段
云端共享文件存储的方法
1 Rsync文件共享部署
不是实时同步的，需要手动执行或者定时任务
Rsync只适合两台服务器之间同步
2 Rsync+Inotify文件共享
Inotify是监控工具，监控目录或文件的变化，然后调用Rsync进行数据同步。
Inotify实现工具工具有3款：Inotify本身、Sersycn、Lsyncd。实践中建议选择Sersycn。
3 NFC文件共享实践
Rsync、Rsync+Inotify、Sersycn更多应用于定时/实时单向同步，很少双向。如果是堕胎机器的数据共享。一般建议NFS（Network File System，网络文件系统）。开源的解决方案中，NFC是标准的文件共享解决方案。
4 NAS文件共享（阿里云）
5 OSS文件共享（分布式存储）
监控方案一：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协议提供数据，即可完成监控。
