关于nginx:公有云降本增效最佳实践

前言

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

上云前做好业务量的评估

上云前做好业务量的评估，为云上的资源布局做好资源估算。
能够通过：

• 压测
• 已有监控数据分析

等形式评估业务量。

罕用的业务量指标如下：

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

举荐几个私有云云产品

这些私有云产品是基本上都会用到的，历经测验，且比拟实用的产品。

1. 云服务器
2. 关系型数据库
3. 负载平衡
4. 对象存储
5. VPC（Virtual Private Cloud）：专有网络
6. CDN
7. Redis
8. 安全类的根本产品（如：平安组、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 网关进来。
如果是运维，举荐通过 VPN + 跳板机（中小企业）或专线 + 堡垒机（大企业）来实现运维治理。

如果须要出公网，倡议应用 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 反向代理走公网申请 对象存储，速度和效率会晋升得更高，价格特定状况下也会更划算。

  • 👉 典型应用场景：CDN 对象存储

数据库

数据库举荐云服务 且必须有高可用保障

数据库不举荐自建，举荐间接应用云提供商的相干数据库服务，且举荐必备高可用保障，如集群模式或多正本，以及数据备份。
数据库优先采纳云提供商的相干数据库服务，低成本高效率：如果在云上购买云服务器自建 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 防护和主机平安防护」。有根本的防护，会比裸奔平安很多。

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.