前言
最近看到了几个事情,一个是某保险系统,为了快速上线,全量上云,结果生产正式运行后每月账单高达几十万。相关业务总扛不住这个支出,又劳师动众,让下面的项目经理、开发、运维、架构师花了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 的概念一样 |
在线用户数 | 天 | 一天的活跃用户数中,用户同时在一定的时间段内在线的数量 |
并发用户数 | -- | 指在线用户数基础上,某一时刻同时指向服务器发送请求的用户数 |
具体的性能监控指标如何和业务指标进行转换就先略过了。
推荐几个公有云云产品
这些公有云产品是基本上都会用到的,历经检验,且比较实用的产品。
- 云服务器
- 关系型数据库
- 负载均衡
- 对象存储
- VPC(Virtual Private Cloud):专有网络
- CDN
- Redis
- 安全类的基本产品(如:安全组、ACL、漏扫、WAF、DDoS防护等)
计算
云服务器配置以中低配为主
云服务器一般用于承载应用,推荐以更多台数的中低配为主,避免资源的浪费。 建议一般配置不要超过:16C32G,主流配置为:
- 4C8G 甚至更低
- 8C16G
推荐使用容器服务
容器服务有诸多优势,推荐无状态应用使用容器服务。
- 资源粒度更细,细粒度到: 0.1C, 内存 MB。
- 自动扩缩容更方便
- 扩容后 pod 自动加入负载均衡
- ...
按需购买
在云上,不要按照业务峰值购买全量的资源,而是推荐:买满足日常需求的资源
弹性扩容
在云上,如果需要搞活动,再通过「容器」或「API + 镜像 +快照」批量购买、弹性扩容。
比如在某手机的秒杀活动中,会瞬间开启 200 台机器且持续 2H 来应对,IT 资源花费 600 元人民币:
- 搭建好环境,制作好镜像;
- 活动前通过 API 秒开 200 台服务器来应对活动;
- 活动结束后,通过 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 缓存。
- 可以让 DNS TTL生效快一点;
- DNS配置的是负载均衡 IP,而不是云服务器的IP。
- 如果还是有部分用户出问题,指导用户清理 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防护和主机安全防护」。有基本的防护,会比裸奔安全很多。
三人行, 必有我师; 知识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.