题外话：

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

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

我先简单介绍下我自己：

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

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

本系列篇幅较长，共有 7 篇文章，本文是第 1 篇。文章列表：

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

一、业务为什么要上云？

在我看来，上云最大的收益点是稳定二字。细分的话，我觉得有以下两方面：

1. 提升业务价值

没有业务，就没有公司。所以业务价值是极其重要的。

1.1 稳定大于一切

• 借助于云技术，很多需要好几个运维工程师共同维护的模块，上云后就不需要再操心太多
• 上云后周末基本没有处理过故障，告警次数也少了许多
• 不出故障，业务稳定，钱自然就有了。毕竟出一次事故，损失金钱，也损失人力，更损失人心

1.2 业务效率提升

• 使用云平台的验证码模块，极大提升刷号黑产成本，无需开发人员费尽心思对抗黑产
• 接入层使用 WAF 应用防火墙，拦截大部分恶意攻击流量，业务上的风控规则明显减少，维护成本极大提升

2. 工程师价值

2.1 运维工程师视角

• 业务扩容迅速，可以在后台直接购买实例 / 根据快照迅速生成新实例
• 硬件由云厂商保障，采购硬盘要一个月以上，挖矿的时候还买不到货呢……
• 规格多样（基础型、内存型、计算型……M核N内存），曾经少核多内存机器无法充分利用不再存在
• 基础设施完善，如四层/七层负载均衡，自带监控……
• 稳定的网络环境，无需自己维护网络线路
• 不惧怕DDoS网络攻击
• 应用防火墙
• 云原生、容器资源、弹性扩容……

2.2 开发工程师视角

• 使用云产品，提升开发效率
• 无需闭门造车，享用优质服务
• 环境统一，便于开发/测试……

二、业务该如何上云？

上云是一个庞大的工程，需要团队对整个公司的业务有个全盘的认知，并在某些方面有取有舍，权衡利弊，最终得到相对较好的方案并真正落地。

上云的步骤，主要分为四个步骤：上云准备、方案设计、方案实施、效果评估。

1. 上云准备

关键词提取：

• VPC 子网规划、成本控制、云产品兼容性
• 业务梳理、架构图、文档沉淀
• 监控系统、Elasticsearch + Filebeat + Kafaka、prometheus、pushgateway
• tcpdump、packetbeat

运维同学关心的更多是 VPC 子网规划、成本控制、云产品与当前的组件的兼容性等，而我更关注的是业务本身的平滑上云，实话说压力还是蛮大的。

在这个阶段我遇到最大的一个难题，就是早期运维团队先后离职，很多事情只能与其他业务开发沟通。而我作为业务开发的一员，本身对这块东西也挺感兴趣，和新运维团队协助配合，逐步摸清业务的来龙去脉。

成果上，我输出了各个核心业务的架构图梳理成文档沉淀，方便后续确定方案。我们也深刻意识到，一切变更的安全于否，首先需要保证监控的完整度，做到变更出现问题，及时回滚方案。

工欲善其事，必先利其器。通过 Elasticsearch + Filebeat + Kafaka 三剑客，运维开发团队打造了一套较为完善的监控系统。比如 nginx 出现 500 的状态码，及时告知给业务方。

除了 Elasticsearch 的日志告警，业务上我还将 Go 服务接入 prometheus 监控，通过 pushgateway 的上报，可以实时获取应用的 QPS，P95、P99 时延、内存占用、GC 时长等信息。

此外，我还创新性使用 Go 语言编写 PHP 扩展，无侵入业务进行链路追踪。监控系统这块，后续我觉得可以单独写一篇文章，深入探讨其演进之路。

我们还在整个上云的过程中使用了一些额外的工具，协助我们梳理业务——因为缺乏 CMDB 基础设施，有些机器压根不知道是做啥的……对于这种情况，我们只能开启 tcpdump 抓包，逐步分析它与其他业务之间的联系。

数据库这块，特别是 Redis 没有业务拆分，很难知道有谁过来访问。而 packetbeat 这个神器配合 Elasticsearch，可以清晰的知道 Redis、MySQL 具体执行的命令、来源 IP 地址。

2. 方案设计

经过大量的调研，梳理业务线，我们内部达成了从接入层到数据层逐步上云的方案。

“为什么？”

• 数据库多数业务直接读写，缺乏实例拆解和业务隔离，牵一发而动全身
• 运维团队入职不久，不太熟悉业务线。实施上，先简单后复杂，先切换接入层，最终到数据层
• 接入层切换失败不影响底层数据库，减少开发修补数据的痛苦

设计和验证是交替进行的。测试环境初步准备后，引入流量逐步验证，其中包含构造 curl 测试样例、QA 同学开发的自动化测试、tcpcopy 等方式。

测试中也发现，相比以前使用 LVS + nginx 直接做 https 证书卸载，使用腾讯云的 7 层 CLB 负载均衡，可以提升 90% 以上的性能。

好了，今天就先写到这里。整个方案的设计的大基调有了，后面的文章会细化每个模块是怎么上云的，上云期间遇到的一些坑也做一些总结。

感谢您的阅读：）