题外话:

笔者就职于某上市游戏发行公司,主导整个发行业务线从双 IDC 到腾讯云的搬迁。在此过程中踩了不少坑,便以文章的形式记录下来。

如有错漏之处,敬请指正。

我先简单介绍下我自己:

我是业务开发出身,负责渠道登录/支付业务,熟悉前端,研究后台开发框架后,逐步往运维方向摸索。

业务除了登录/支付业务,也做过风控系统、聊天监控系统,主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。

本系列篇幅较长,共有 7 篇文章,本文是第 7 篇。文章列表:

某上市游戏公司从 IDC 上腾讯云的落地经验(1)——上云必要性与方案设计
某上市游戏公司从 IDC 上腾讯云的落地经验(2)——方案实施之接入层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(3)——方案实施之应用层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(4)——方案实施之缓存层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(5)——方案实施之数据层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(6)——方案实施之中间件上云
某上市游戏公司从 IDC 上腾讯云的落地经验(7)——总结与回顾

总结与回顾

前面的文章写了非常多,最终感觉还是有一篇总结性的文章好一些。

文章的整体脉络围绕为什么上云和如何上云两大模块,并详细展开方案实施整个模块。


阅读全文

题外话:

笔者就职于某上市游戏发行公司,主导整个发行业务线从双 IDC 到腾讯云的搬迁。在此过程中踩了不少坑,便以文章的形式记录下来。

如有错漏之处,敬请指正。

我先简单介绍下我自己:

我是业务开发出身,负责渠道登录/支付业务,熟悉前端,研究后台开发框架后,逐步往运维方向摸索。

业务除了登录/支付业务,也做过风控系统、聊天监控系统,主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。

本系列篇幅较长,共有 7 篇文章,本文是第 6 篇。文章列表:

某上市游戏公司从 IDC 上腾讯云的落地经验(1)——上云必要性与方案设计
某上市游戏公司从 IDC 上腾讯云的落地经验(2)——方案实施之接入层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(3)——方案实施之应用层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(4)——方案实施之缓存层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(5)——方案实施之数据层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(6)——方案实施之中间件上云
某上市游戏公司从 IDC 上腾讯云的落地经验(7)——总结与回顾

中间件上云

中间件这块,我们的 Kafka 没有搬迁,属于大数据业务,目前依然在 IDC 机房。

Elasticsearch 是其他同事跟进,应该也是有同步工具并做 DNS 切换,业务无损。

而 RabbitMQ 这块是我负责上云的。我对它真的是又爱又恨——

  • 爱:RabbitMQ 非常稳定,几乎不需要运维,跑了很久基本不出问题,PHP / Go 都非常友好,用起来比较方便;具备完善的 API 接口和管理界面,方便自己编写脚本实现某些操作的自动化
  • 恨:性能堪忧,腾讯云的 CVM 自建 32 核 64 G内存 HDD * 2 台实例 + 4 层负载均衡,队列开启持久化吞吐量大概在 3 万消息每秒(主备模式);镜像模式下,单队列没有水平扩展的能力,即使关闭持久化,依然存在硬件上的性能瓶颈。

众所周知,RabbitMQ 支持主备模式、镜像队列两种主流的用法。

image-主备模式与镜像模式对比

这两种模式的优缺点如下:

主备模式:架构简单,但节点故障时非常难受,需要手工切换灾备节点(队列元数据需要声明才行,不然会丢数据),一般业务会开启持久化,不做切换时取决于节点何时恢复,不具备高可用的能力。

镜像模式:队列双副本 + 关闭持久化,同样配置吞吐量在 6 万消息每秒,但不具备水平扩展的能力,理论上换 SSD 磁盘会更快,但确实没办法再快了,和 Kafka 没法比。


阅读全文

题外话:

笔者就职于某上市游戏发行公司,主导整个发行业务线从双 IDC 到腾讯云的搬迁。在此过程中踩了不少坑,便以文章的形式记录下来。

如有错漏之处,敬请指正。

我先简单介绍下我自己:

我是业务开发出身,负责渠道登录/支付业务,熟悉前端,研究后台开发框架后,逐步往运维方向摸索。

业务除了登录/支付业务,也做过风控系统、聊天监控系统,主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。

本系列篇幅较长,共有 7 篇文章,本文是第 5 篇。文章列表:

某上市游戏公司从 IDC 上腾讯云的落地经验(1)——上云必要性与方案设计
某上市游戏公司从 IDC 上腾讯云的落地经验(2)——方案实施之接入层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(3)——方案实施之应用层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(4)——方案实施之缓存层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(5)——方案实施之数据层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(6)——方案实施之中间件上云
某上市游戏公司从 IDC 上腾讯云的落地经验(7)——总结与回顾

数据层上云

由于缓存层上云时在 /etc/hosts 文件踩过小坑,后面我们把生产环境上所有绑定 hosts 的业务都整理了一次。

数据层主要是 Redis、MySQL 这两个组件。


阅读全文

题外话:

笔者就职于某上市游戏发行公司,主导整个发行业务线从双 IDC 到腾讯云的搬迁。在此过程中踩了不少坑,便以文章的形式记录下来。

如有错漏之处,敬请指正。

我先简单介绍下我自己:

我是业务开发出身,负责渠道登录/支付业务,熟悉前端,研究后台开发框架后,逐步往运维方向摸索。

业务除了登录/支付业务,也做过风控系统、聊天监控系统,主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。

本系列篇幅较长,共有 7 篇文章,本文是第 4 篇。文章列表:

某上市游戏公司从 IDC 上腾讯云的落地经验(1)——上云必要性与方案设计
某上市游戏公司从 IDC 上腾讯云的落地经验(2)——方案实施之接入层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(3)——方案实施之应用层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(4)——方案实施之缓存层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(5)——方案实施之数据层上云
某上市游戏公司从 IDC 上腾讯云的落地经验(6)——方案实施之中间件上云
某上市游戏公司从 IDC 上腾讯云的落地经验(7)——总结与回顾

缓存层上云

缓存,业务主要使用 Redis 和 Memcached 两大组件。


阅读全文

一、背景

1. 业务上云带来性能收益

公司从去年全面推动业务上云,而以往 IDC 架构部署上,接入层采用典型的 4 层 LVS 多机房容灾架构,在业务高峰时期,扩容困难(受限于物理机资源和 LVS 内网网段的网络规划),且抵挡不住 HTTPS 卸载引发的高 CPU 占用。

而经过压力测试发现,使用腾讯云 7 层 CLB 负载均衡进行 HTTPS 卸载,性能得到极大提升。测试数据也表明,IDC 旧架构中,启用 HTTPS 会带来 90% 以上的性能损耗。

2. 架构调整引发多次故障

引入腾讯云 7 层 CLB 负载均衡产品,带了了巨大的性能提升,却也给业务带来了痛苦,主要核心问题是获取客户端的真实 IP 上。

当前现状是业务语言异构(PHP + Go),多数业务已经历服务化改造,但缺乏服务发现机制,服务与服务之间的调用依赖域名和 DNS 解析,大部分都是 HTTP 服务。

在架构调整后,QA 没能 100% 覆盖测试,导致漏测的服务经常拿到错误的客户端 IP 地址,造成的后果是损失大量的用户。这些用户会因为短信验证码发送限制、IP 登录频次过高而无法登录、充值,给公司带来巨大损失。

3. 未来的路应该怎么走?

更进一步讲,当前业务如何抵挡外界的 DDoS 攻击、请求机器人、SQL 注入等等,最简单的是接入高防 IP、WAF 应用防火墙,而请求经过多轮转发,同样也有获取客户端真实 IP 的问题。

再者,业务也在逐步容器化,享受 Kubernetes 弹性扩容的便利,怎么平滑迁移也是非常值得深思的。

假设 SRE 配置不当,应用层拿到的,很有可能是高防 IP 或者 WAF 的 IP,业务绝对无法忍受。

显然,确定一个业务无感知的方案并成功落地迫在眉睫。然而我翻遍了互联网,几乎没有文章能把这些看起来很简单的事情捋清楚说明白,更不用说最佳实践。大多数人都是抄抄配置,潦潦草草上线,方案并没有普适性。

这篇文章也是我在这段时间的研究中总结出来的宝贵经验,希望对读者能有些许帮助。文章篇幅较长,难免有错误之处,还请各位看官斧正,感激不尽:)

阅读全文