前言
最近看到了几个事情，一个是某保险系统，为了快速上线，全量上云，结果生产正式运行后每月账单高达几十万。相关业务总扛不住这个支出，又劳师动众，让下面的项目经理、开发、运维、架构师花了3个月把业务全量从公有云迁移下来。相关人员被折磨的半死不活，而且大大拖慢了系统的迭代速度。
另一个是某个电商的案例，上云后刚开始费用账单也是很高，每月接近 20 万，经过「降本增效」优化后，费用大幅度降低，每月费用降到了 4 万左右，服务质量反而还有提升。
这 2 个故事告诉我们，云时代的滚滚浪潮扑面而来，我们也应该根据公有云的特性（如：弹性、灵活、多种计费方式等），在不降低服务质量的情况下，最大限度地优化成本。
以下是一些最佳实践。
最佳实践
整体
首选公有云服务而非自建
公有云除了提供 IaaS（计算、存储、网络等）外，也会提供 PaaS（微服务、中间件、数据库、大数据、开发套件等）和 SaaS 服务。
在公有云提供的服务（如 MySQL 数据库）可以满足需求的前提下，建议首选公有云上的 MySQL 数据库服务，而非自建。
理由简单说明如下：
对比项 | 成本 | 性能 | 伸缩性 | 维护方 | 可靠性 | 监控 | 易用性 |
|---|---|---|---|---|---|---|---|
自建 | 高 | 低 | 弱 | 我方 | 低 | 无 | 难 |
云上服务 | 中 | 高 | 高 | 云提供商 | 高 | 有 | 易用 |
•成本：
•自建，需要人员维护和优化的成本，需要自行考虑高可靠（可能需要购买多台服务器）和高性能（可能需要购买高性能存储），使得成本偏高。
•云上服务，通过规模效应、资源池化、参数调优等实现成本相对不高。
•性能：
•自建，不一定知道所有的参数优化项，也不一定同价位能买到专用的高性能硬件。
•云上服务，性能明码标价，按需选择适合自己的性能配置。
•伸缩性
•自建，伸缩较麻烦，要不手动，要不通过 历经检验的 DevOps 脚本，伸缩性弱。
•云上服务，很多PaaS类服务可以一键升配。
•维护方
•自建，我方自行兜底•云上服务，云提供商提供 SLA 兜底。•可靠性
•自建，不一定能实现该组件的集群模式或高可用模式的全部最佳实践。
•云上服务，会做好网络高可用（甚至是跨AZ的高可用）、存储多副本、计算跨物理服务器/机架/AZ甚至region、服务监控及自愈、备份等多种措施保障可靠性。
•监控：
•自建，要不没监控，要不监控需要从头（采集端）到尾（告警通知）实现一遍
•云上服务，监控具备，且和公有云监控无缝对接。
•易用性：
•自建：一般没有 Web 界面，需要通过线下或流程平台或 CLI 来申请和操作•云上服务：有易用的 web 界面，可以在 web 界面上完成大部分功能。
比如云数据库：
•运维架构：
•存储的数据规模及后期扩展，采用的高可用架构；
•异常切换
•硬件及基础环境部署
•选择什么配置的服务器，服务器型号及对应磁盘阵列；
•操作系统环境及内核设置；
•数据库安装及优化
•数据库版本安装部署及配置；
•数据库配置参数调优；
•SQL 语句优化；
•慢查询，对 SQL 语句及索引做优化
•数据库日常备份及恢复。
•备份；
•热备还是冷备？物理备份还是逻辑备份？
•备份策略、周期、频率
使用云数据库，这些步骤云数据库都帮你做了。其他 PaaS（中间件、大数据、微服务、DevOps等）也类似。
做好安全防护
公有云最大的风险就是数据泄露。所以一定要做好安全防护。这个安全防护是多方面的。详细见 安全 部分。
云的优势是「分布式」
如果对比单台服务器，可能云主机的性能差一些。「分布式」是云计算的最大优势。在实践中，不要只追求单台机器的性能，而是要通过分布式的设计思想来保障业务的高性能。最佳实践推荐，服务器标配 4C8G，低配也可以采用 2C4G 的配置。通过分布式充分压榨了单台服务器的资源，从而最大限度地保障了最终的低成本。所以，在云上，一般情况下应用服务器的选择条件是：更多的低配的云服务胜于更少的高配的云服务器。所以，在云上，对于数据库来说，如果数据量非常大，也推荐使用「分布式数据库」，而非在云上自建 Oracle。
云的优势是「弹性」
所以，在云上，不要按照业务峰值购买全量的资源，而是推荐：
•买满足日常需求的资源
•高峰时，再提前购买一些弹性的资源，弹性扩容。
另外，不仅仅是服务器资源，对于网络也适用，如果您的系统经常搞活动，网络负载差距很大，那么推荐：「大带宽按量付费」而不是「固定带宽固定计费」。
动静分离
静态：放 CDN 对象存储上，或者放 NGINX 服务器上也好，不要直接用应用服务器（如tomcat或nodejs）来处理静态资源。（浪费，术业有专攻） 动态：典型架构是 LB - NGINX - 应用服务器 - redis - 数据库。
上云前做好业务量的评估
上云前做好业务量的评估，为云上的资源规划做好资源预算。可以通过：
•压测
•已有监控数据分析
等方式评估业务量。
常用的业务量指标如下：
指标 | 计算周期 | 指标含义 |
|---|---|---|
PV | 天 | Page View。指 B/S 架构中的 Web 类业务一天内页面的访问次数，每打开或刷新一次页面，算一个 PV。 |
UV | 天 | UV 是 Unique Visitor 的简写。指 B/S 架构中 Web 类业务一天内访问站点的用户数（以 cookie 为依据） |
IP | 天 | B/S 架构中 Web 类业务一天内有多少个独立的 IP 浏览了页面，即统计不同的 IP 浏览用户数量。 |
用户数 | -- | 业务系统的注册用户数 |
活跃用户数 | 天 | 注册用户数中，一天中实际使用了业务系统的用户数量，跟 UV 的概念一样 |
在线用户数 | 天 | 一天的活跃用户数中，用户同时在一定的时间段内在线的数量 |
并发用户数 | -- | 指在线用户数基础上，某一时刻同时指向服务器发送请求的用户数 |
具体的性能监控指标如何和业务指标进行转换就先略过了。
推荐几个公有云云产品
这些公有云产品是基本上都会用到的，历经检验，且比较实用的产品。
1.云服务器
2.关系型数据库
3.负载均衡
4.对象存储
5.VPC（Virtual Private Cloud）：专有网络
6.CDN7.Redis8.安全类的基本产品（如：安全组、ACL、漏扫、WAF、DDoS防护等）
计算
云服务器配置以中低配为主
云服务器一般用于承载应用，推荐以更多台数的中低配为主，避免资源的浪费。建议一般配置不要超过：16C32G，主流配置为：
•4C8G 甚至更低
•8C16G
推荐使用容器服务
容器服务有诸多优势，推荐无状态应用使用容器服务。
•资源粒度更细，细粒度到: 0.1C, 内存 MB。
•自动扩缩容更方便
•扩容后 pod 自动加入负载均衡•...
按需购买
在云上，不要按照业务峰值购买全量的资源，而是推荐：买满足日常需求的资源
弹性扩容
在云上，如果需要搞活动，再通过「容器」或「API 镜像 快照」批量购买、弹性扩容。
比如在某手机的秒杀活动中，会瞬间开启 200 台机器且持续 2H 来应对，IT 资源花费 600 元人民币：
1.搭建好环境，制作好镜像；
2.活动前通过 API 秒开 200 台服务器来应对活动；
3.活动结束后，通过 API 瞬间释放资源
这在传统架构中，根本不可想象。比如传统架构，搞「双十一」，都要提前一个月准备 IT 资源。
另外上面的场景也可以利用 「弹性伸缩服务」或「容器 HPA」来动态调整。
使用 Ansible 等 DevOps 工具
既然云的优势是「分布式」，资源多，那么 Ansible 这种批量的 DevOps 工具是必不可少的，可以大幅度提升效率。具体应用，可以通过 Ansible，定制对应的 Playbook，自动化批量安装和运维。
通过镜像提升云端部署效率
先开通一台云服务器，并对这台云服务器做运维规范方面的系统调优、安全加固等措施。然后把这台云服务器做成一个基础镜像，批量开通 其他同样环境的服务器，可以大大提升部署效率。
网络
域名备案要先行
上云的最后一步，是要将域名的 IP 解析到 负载均衡 公网 IP 上。但需要提前在共有云上对域名进行备案，如果到最后域名解析到公有云上后才发现域名被拉黑，业务访问被拒绝，这将会变得非常麻烦。因此需要提前通过公有云进行域名备案，或者已经在其他供应商进行备案，那么需要将域名备案转接入公有云。
推荐必备 .CN 域名
近期国际形势愈演愈烈，中美摩擦进一步升级，形势紧张。要做最坏的打算：美国可能会断掉您的 .COM 域名的解析。另外国家最近有指引，不要使用外国管控的根域名作为基础设施的一级域名。.cn 是国家根域，.com.cn、net.cn、org.cn 等这些都是可以的。
严禁每台服务器都能访问公网
出于安全（受攻击面太大）和成本（公网IP都是钱）的考虑。而且没必要，如果是业务访问，入向通过负载均衡进来，出向通过 NAT 网关出去。如果是运维，推荐通过V** 跳板机（中小企业）或专线 堡垒机（大企业）来实现运维管理。
如果需要出公网，建议使用 NAT 网关而非在某台机器绑定公网IP
原因：可靠性更高，更安全。
利用低成本高负载的按量带宽
对于中小规模企业，如果您的系统经常搞活动，网络负载差距很大，那么推荐：「大带宽按量付费」而不是「固定带宽固定计费」，比如：「1Gbps峰值带宽按量计费」对比「100Mbps固定带宽」：
•费用可能更低
•带宽更大，活动期间可能会超过 100Mbps，那这时候固定带宽就会影响用户体验，而 1Gbps 峰值带宽是完全可以支撑的住的。
以某客户上云前后为例，在 IDC 机房，200Mbps 的独享电信带宽，一年的成本大概是 1Mbps/100元/月 x 12 个月 x 200 = 24万。而在云端，采用 1Gbps 峰值的 BGP 多线 SLB 带宽，在带宽质量上面提升了几个量级。另外，带宽费用采用按量付费，大大降低了维护成本。
推荐使用云上软负载均衡
推荐使用公有云提供的负载均衡，可以作为反向代理，防止客户端直连云服务器带来的安全和稳定性风险。
加入 负载均衡 可以保障架构灵活扩展性：加入 负载均衡 后，架构变得更加灵活。典型场景是将所有域名先绑定到 负载均衡 上，然后转到后端 Nginx，通过 Nginx 做虚拟主机等七层更灵活的控制。
高并发情况下，推荐使用 4 层负载均衡
采用 4层 负载均衡 保障性能：在实践中，面对高并发性能的场景时，发现 7 层的负载均衡，相比 4 层的负载均衡，在性能上面有很大差距。7 层负载均衡只能达到万级别并发，而 4 层的负载均衡能达到几十万级，甚至上百万级的并发量。所以在电商等网站应用中，对于 负载均衡，优先选择 TCP 层。四层 LB 能扛得住 10w-50w 的并发。
DNS 记录调整要注意
用户的 DNS TTL 我们是无法控制的，如果调整了某域名的DNS记录，可能某些用户已生效，某些用户没有生效。针对这种情况，需要在原有IP上做 302 重定向跳转，将依旧访问原IP 的客户引流到新IP上，这将大大提高用户的访问体验。
大型企业 - DNS 负载均衡实践
大规模应用。当后端有一两百台云服务器，而一台负载均衡 性能有限时，可以采用多个 负载均衡，前边通过DNS 负载均衡。典型如：淘宝、阿里云官网。
DNS有个最大的问题，就是 本地 DNS 缓存。
1.可以让 DNS TTL生效快一点；
2.DNS配置的是负载均衡 IP，而不是云服务器的IP。
3.如果还是有部分用户出问题，指导用户清理 DNS 缓存，或强制绑定本机 host 指向域名解析。
智能解析 -- 跨地域分布式架构中必不可少。根据 ClientIP，选择返回对应地域、运营商的IP。
运营商线路解析
如：DNS记录：
•默认线路：电信服务器IP
•网通：网通IP
•移动：移动IP
•教育网：教育网IP
•海外：海外IP
如果有 BGP 线路，那就更简单了：
•默认线路：负载均衡的公网IP
地域线路解析
如：用户请求访问域名，DNS 自动判断访问者IP 是「上海联通」还是「北京联通」，然后智能返回设置的对应的「上海联通」和「北京联通」的服务器 IP 地址完成域名解析。
海外：可以选择「海外、海外大洲、海外（国家/地区）」来细分解析。
如:
•海外 - 亚洲地区 - 新加坡线路：指向新加坡服务器的 IP
•海外 - 北美洲 - 美国线路：指向美国服务器的 IP
•海外 - 欧洲 - 德国线路：指向德国服务器的 IP
•默认线路：指向新加坡服务器的 IP
CDN 就是智能解析的最佳实践
存储
云上善用「对象存储服务」
云上建议尽量不要使用类 NAS 的共享文件存储服务，而应该使用对象存储服务来替代。在传统环境，NAS 的典型使用场景如下：
•负载均衡：使用 LB 多台 云服务器（如：Web 服务器）部署的业务。多台 云服务器 需要访问同一个存储空间，以便多台 云服务器 共享数据。
•替代方案：直接使用普通云数据盘，通过 DevOps 等工具实现批量部署及数据一致。
•代码共享：多台 云服务器 应用，部署的代码一致。将代码放在同一个存储空间，提供给多台 云服务器 同时访问。代码集中管理。
•替代方案：代码放在代码仓库中集中管理。
•日志共享：多台 云服务器 应用，需要将日志写入到同一个存储空间，以便做集中的日志数据处理和分析•替代方案：日志定期存储到对象存储中，可以根据策略、冷热数据的实际情况选择分别存储到「标准对象存储」、「低频对象存储」和「归档存储」中进一步压缩成本；或直接使用云上的「日志服务」。
•企业办公文件共享场景：企业有公共的文件需要共享给多组业务使用，需要集中的共享存储来存放数据。
•替代方案：使用对象存储来替代。
•容器服务的场景：部署的容器服务需要共享访问某个文件数据源，特别是在资源编排的容器服务。对应的容器可能会在不同的服务器中进行服务漂移，所以文件共享访问尤为重要。
•替代方案：这种场景确实需要用到云上文件系统服务。
•备份的场景：用户希望将数据备份到云上，可以通过挂载文件系统来存储数据备份。
•替代方案：备份到对象存储的「归档存储」中，进一步降低成本。
错误用法：NGINX 做公网转发到对象存储
在某个客户场景中，静态资源放到 对象存储 中，前端对静态资源的请求通过 Nginx 反向代理转发给 对象存储。但这种做法，在云端架构上是不推荐的，因为它会带来几个问题：
•访问静态资源的流量走 云服务器 的带宽流量，特别是中大型的 Web 应用中。流量走 云服务器 的带宽，很可能出现性能瓶颈。
•Nginx 是通过公网将请求反向代理转发给 对象存储 的，所以在网络传输上会影响速度性能。
•通过 Nginx 反向代理，不仅增加运维成本，还要维护 Nginx 配置文件等。
所以，添加 Nginx 做反向代理是多此一举。云端不推荐这么做。该客户这么用，主要原因是业务代码侧，静态资源的请求，都是通过目录划分。如果将静态资源单独放在二级域名，跨域等问题代码侧没很好地解决，从而产生这种不伦不类的架构。最终在业务代码侧进行了优化调整，对 对象存储 静态资源的使用规范如下：
•业务侧使用单独的二级域名来管理静态资源（如：<pic-cdn.ewhisper.cn>)，静态资源统一放在 对象存储 中；
•静态资源的二级域名直接将 CNAME 绑定在 对象存储 的 URL 地址上（访问量很少的情况下），这样就直接跳过「使用 Nginx 做反向代理」这个冗余的步骤了
•如果想要进一步提升 对象存储 中存放的静态资源的访问速度，可以无缝接入 CDN。CDN 的回源请求，会直接通过内网回源请求 对象存储 中的源数据。相比 Nginx 反向代理走公网请求 对象存储，速度和效率会提升得更高，价格特定情况下也会更划算。
数据库
数据库推荐云服务 且必须有高可用保障
数据库不推荐自建，推荐直接使用云提供商的相关数据库服务，且推荐必备高可用保障，如集群模式或多副本，以及数据备份。数据库优先采用云提供商的相关数据库服务 ，低成本高效率：如果在云上购买云服务器自建 MySQL 主从部署并维护的模式，使得后期的维护管理成本很大。即我们要监控及维护主从状态，并且在出现问题时需要及时处理，保障业务对数据库读写的连续性。在采用云提供商的相关数据库服务 后，这些问题都可以自动化解决。即对数据库主从的监控、备份、后期维护、故障切换等，都是全自动。
对于可靠性要求特别高的DB，可以选择跨AZ高可用的集群方案
对于可靠性要求特别高的DB，可以选择跨AZ高可用的集群方案。比如：Redis、MongoDB、MySQL都有类似的跨AZ高可用的集群方案提供。
按需选择合适的数据库
数据库多种多样，根据自己的实际需求进行选择，以下列出部分：
•关系型数据库
•MySQL
•SQL Server
•Postgresql
•MariaDB
•分布式数据库（如OceanBase或TDSQL等）
•非关系型：内存数据库
•Redis
•Memcache
•文档数据库：MongoDB
•列数据库
•HBase等
•时序数据库
•InfluxDB
•TSDB
CDN
典型使用场景：CDN 对象存储
•数据分发：适用于搭建下载行为较多的APP、音视频平台、网站等，用户可结合 CDN 对象存储 的能力，将静态内容（包括音视频、图片等文件）托管在对象存储中，并将热点文件提前下发至CDN边缘节点，降低下载访问延迟
•网站托管：适用于官方网站等偏静态的站点，将网站的静态资源快速托管存储在对象存储中，同时通过 CDN 对象存储 分发，通过CDN 配置的域名作为静态网站访客的访问地址入口，快速建好一个网站
安全
必须设置强密码
典型如：MongoDB、Redis、ES，默认无密码或弱密码，已经发生过多轮、大规模的数据泄露事件，所以针对这些服务，一定要设置强密码。至于云服务器、云账户、关系型数据库等，更是要保障强密码或者更强力的安全措施。
客户端访问必须 HTTPS
这个就不多说了。
•给域名申请证书，放在 Nginx 或 LB上 管理。
•业务侧，保留 HTTP 80 端口，做80 -> 443 的重定向。LB 上 80 和 443 端口监听都要开启。
一定要配置安全组和ACL
最基本的安全防护
不要 root 直连
不要 root 直连，用普通用户，登陆过去按需 sudo 切换到 root
建议暴露公网的 SSH 端口不要用 22
建议不要用默认的 22 端口，防止被扫描。另外还有建议用证书认证等方式，就不一一赘述了。
免费安全产品别忘领
如每开通一台云服务器，都会赠送一些免费额度的「DDoS防护和主机安全防护」。有基本的防护，会比裸奔安全很多。
