公有云降本增效最佳实践

最近看到了几个事情，一个是某保险系统，为了快速上线，全量上云，结果生产正式运行后每月账单高达几十万。相关业务总扛不住这个支出，又劳师动众，让下面的项目经理、开发、运维、架构师花了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 – 数据库。

上云前做好业务量的评估，为云上的资源规划做好资源预算。
可以通过：

压测
已有监控数据分析

等方式评估业务量。

常用的业务量指标如下：

具体的性能监控指标如何和业务指标进行转换就先略过了。

这些公有云产品是基本上都会用到的，历经检验，且比较实用的产品。

云服务器一般用于承载应用，推荐以更多台数的中低配为主，避免资源的浪费。
建议一般配置不要超过：16C32G，主流配置为：

4C8G 甚至更低
8C16G

容器服务有诸多优势，推荐无状态应用使用容器服务。

资源粒度更细，细粒度到: 0.1C, 内存 MB。
自动扩缩容更方便
扩容后 pod 自动加入负载均衡
…

在云上，不要按照业务峰值购买全量的资源，而是推荐：买满足日常需求的资源

在云上，如果需要搞活动，再通过「容器」或「API + 镜像 +快照」批量购买、弹性扩容。

比如在某手机的秒杀活动中，会瞬间开启 200 台机器且持续 2H 来应对，IT 资源花费 600 元人民币：

这在传统架构中，根本不可想象。比如传统架构，搞「双十一」，都要提前一个月准备 IT 资源。

另外上面的场景也可以利用「弹性伸缩服务」或「容器 HPA」来动态调整。

既然云的优势是「分布式」，资源多，那么 Ansible 这种批量的 DevOps 工具是必不可少的，可以大幅度提升效率。
具体应用，可以通过 Ansible，定制对应的 Playbook，自动化批量安装和运维。

先开通一台云服务器，并对这台云服务器做运维规范方面的系统调优、安全加固等措施。然后把这台云服务器做成一个基础镜像，批量开通其他同样环境的服务器，可以大大提升部署效率。

上云的最后一步，是要将域名的 IP 解析到负载均衡公网 IP 上。但需要提前在共有云上对域名进行备案，如果到最后域名解析到公有云上后才发现域名被拉黑，业务访问被拒绝，这将会变得非常麻烦。因此需要提前通过公有云进行域名备案，或者已经在其他供应商进行备案，那么需要将域名备案转接入公有云。

近期国际形势愈演愈烈，中美摩擦进一步升级，形势紧张。要做最坏的打算：美国可能会断掉您的 .COM 域名的解析。
另外国家最近有指引，不要使用外国管控的根域名作为基础设施的一级域名。
.cn 是国家根域，.com.cn、net.cn、org.cn 等这些都是可以的。

出于安全（受攻击面太大）和成本（公网IP都是钱）的考虑。
而且没必要，如果是业务访问，入向通过负载均衡进来，出向通过 NAT 网关出去。
如果是运维，推荐通过VPN + 跳板机（中小企业）或专线 + 堡垒机（大企业）来实现运维管理。

原因：可靠性更高，更安全。

对于中小规模企业，如果您的系统经常搞活动，网络负载差距很大，那么推荐：「大带宽按量付费」而不是「固定带宽固定计费」，比如：「1Gbps峰值带宽按量计费」对比「100Mbps固定带宽」：

费用可能更低
带宽更大，活动期间可能会超过 100Mbps，那这时候固定带宽就会影响用户体验，而 1Gbps 峰值带宽是完全可以支撑的住的。

以某客户上云前后为例，在 IDC 机房，200Mbps 的独享电信带宽，一年的成本大概是 1Mbps/100元/月 x 12 个月 x 200 = 24万。而在云端，采用 1Gbps 峰值的 BGP 多线 SLB 带宽，在带宽质量上面提升了几个量级。另外，带宽费用采用按量付费，大大降低了维护成本。

推荐使用公有云提供的负载均衡，可以作为反向代理，防止客户端直连云服务器带来的安全和稳定性风险。

加入负载均衡可以保障架构灵活扩展性：加入负载均衡后，架构变得更加灵活。典型场景是将所有域名先绑定到负载均衡上，然后转到后端 Nginx，通过 Nginx 做虚拟主机等七层更灵活的控制。

采用 4层负载均衡保障性能：在实践中，面对高并发性能的场景时，发现 7 层的负载均衡，相比 4 层的负载均衡，在性能上面有很大差距。7 层负载均衡只能达到万级别并发，而 4 层的负载均衡能达到几十万级，甚至上百万级的并发量。所以在电商等网站应用中，对于负载均衡，优先选择 TCP 层。四层 LB 能扛得住 10w-50w 的并发。

用户的 DNS TTL 我们是无法控制的，如果调整了某域名的DNS记录，可能某些用户已生效，某些用户没有生效。
针对这种情况，需要在原有IP上做 302 重定向跳转，将依旧访问原IP 的客户引流到新IP上，这将大大提高用户的访问体验。

大规模应用。当后端有一两百台云服务器，而一台负载均衡性能有限时，可以采用多个负载均衡，前边通过DNS 负载均衡。典型如：淘宝、阿里云官网。

DNS有个最大的问题，就是本地 DNS 缓存。

智能解析 — 跨地域分布式架构中必不可少。根据 ClientIP，选择返回对应地域、运营商的IP。

如：DNS记录：

默认线路：电信服务器IP
网通：网通IP
移动：移动IP
教育网：教育网IP
海外：海外IP

如果有 BGP 线路，那就更简单了：

默认线路：负载均衡的公网IP

如：用户请求访问域名，DNS 自动判断访问者IP 是「上海联通」还是「北京联通」，然后智能返回设置的对应的「上海联通」和「北京联通」的服务器 IP 地址完成域名解析。

海外：可以选择「海外、海外大洲、海外（国家/地区）」来细分解析。

海外 – 亚洲地区 – 新加坡线路：指向新加坡服务器的 IP
海外 – 北美洲 – 美国线路：指向美国服务器的 IP
海外 – 欧洲 – 德国线路：指向德国服务器的 IP
默认线路：指向新加坡服务器的 IP

云上建议尽量不要使用类 NAS 的共享文件存储服务，而应该使用对象存储服务来替代。
在传统环境，NAS 的典型使用场景如下：

负载均衡：使用 LB + 多台云服务器（如：Web 服务器）部署的业务。多台云服务器需要访问同一个存储空间，以便多台云服务器共享数据。
- 替代方案：直接使用普通云数据盘，通过 DevOps 等工具实现批量部署及数据一致。
代码共享：多台云服务器应用，部署的代码一致。将代码放在同一个存储空间，提供给多台云服务器同时访问。代码集中管理。
- 替代方案：代码放在代码仓库中集中管理。
日志共享：多台云服务器应用，需要将日志写入到同一个存储空间，以便做集中的日志数据处理和分析
- 替代方案：日志定期存储到对象存储中，可以根据策略、冷热数据的实际情况选择分别存储到「标准对象存储」、「低频对象存储」和「归档存储」中进一步压缩成本；或直接使用云上的「日志服务」。
企业办公文件共享场景：企业有公共的文件需要共享给多组业务使用，需要集中的共享存储来存放数据。
- 替代方案：使用对象存储来替代。
容器服务的场景：部署的容器服务需要共享访问某个文件数据源，特别是在资源编排的容器服务。对应的容器可能会在不同的服务器中进行服务漂移，所以文件共享访问尤为重要。
- 替代方案：这种场景确实需要用到云上文件系统服务。
备份的场景：用户希望将数据备份到云上，可以通过挂载文件系统来存储数据备份。
- 替代方案：备份到对象存储的「归档存储」中，进一步降低成本。

在某个客户场景中，静态资源放到对象存储中，前端对静态资源的请求通过 Nginx 反向代理转发给对象存储。但这种做法，在云端架构上是不推荐的，因为它会带来几个问题：

访问静态资源的流量走云服务器的带宽流量，特别是中大型的 Web 应用中。流量走云服务器的带宽，很可能出现性能瓶颈。
Nginx 是通过公网将请求反向代理转发给对象存储的，所以在网络传输上会影响速度性能。
通过 Nginx 反向代理，不仅增加运维成本，还要维护 Nginx 配置文件等。

所以，添加 Nginx 做反向代理是多此一举。云端不推荐这么做。该客户这么用，主要原因是业务代码侧，静态资源的请求，都是通过目录划分。如果将静态资源单独放在二级域名，跨域等问题代码侧没很好地解决，从而产生这种不伦不类的架构。最终在业务代码侧进行了优化调整，对对象存储静态资源的使用规范如下：

业务侧使用单独的二级域名来管理静态资源（如：<pic-cdn.ewhisper.cn>)，静态资源统一放在对象存储中；
静态资源的二级域名直接将 CNAME 绑定在对象存储的 URL 地址上（访问量很少的情况下），这样就直接跳过「使用 Nginx 做反向代理」这个冗余的步骤了
如果想要进一步提升对象存储中存放的静态资源的访问速度，可以无缝接入 CDN。 CDN 的回源请求，会直接通过内网回源请求对象存储中的源数据。相比 Nginx 反向代理走公网请求对象存储，速度和效率会提升得更高，价格特定情况下也会更划算。
- 👉 典型使用场景：CDN 对象存储

数据库不推荐自建，推荐直接使用云提供商的相关数据库服务，且推荐必备高可用保障，如集群模式或多副本，以及数据备份。
数据库优先采用云提供商的相关数据库服务，低成本高效率：如果在云上购买云服务器自建 MySQL 主从部署并维护的模式，使得后期的维护管理成本很大。即我们要监控及维护主从状态，并且在出现问题时需要及时处理，保障业务对数据库读写的连续性。在采用云提供商的相关数据库服务后，这些问题都可以自动化解决。即对数据库主从的监控、备份、后期维护、故障切换等，都是全自动。

对于可靠性要求特别高的DB，可以选择跨AZ高可用的集群方案。比如：Redis、MongoDB、MySQL都有类似的跨AZ高可用的集群方案提供。

数据库多种多样，根据自己的实际需求进行选择，以下列出部分：

关系型数据库
- MySQL
- SQL Server
- Postgresql
- MariaDB
- 分布式数据库（如OceanBase或TDSQL等）
非关系型：内存数据库
- Redis
- Memcache
文档数据库：MongoDB
列数据库
- HBase等
时序数据库
- InfluxDB
- TSDB

数据分发：适用于搭建下载行为较多的APP、音视频平台、网站等，用户可结合 CDN + 对象存储的能力，将静态内容（包括音视频、图片等文件）托管在对象存储中，并将热点文件提前下发至CDN边缘节点，降低下载访问延迟
网站托管：适用于官方网站等偏静态的站点，将网站的静态资源快速托管存储在对象存储中，同时通过 CDN + 对象存储分发，通过CDN 配置的域名作为静态网站访客的访问地址入口，快速建好一个网站

典型如：MongoDB、Redis、ES，默认无密码或弱密码，已经发生过多轮、大规模的数据泄露事件，所以针对这些服务，一定要设置强密码。
至于云服务器、云账户、关系型数据库等，更是要保障强密码或者更强力的安全措施。

这个就不多说了。