某上市游戏公司从 IDC 上腾讯云的落地经验（3）——方案实施之应用层上云

题外话：

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

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

我先简单介绍下我自己：
我是业务开发出身，负责渠道登录/支付业务，熟悉前端，研究后台开发框架后，逐步往运维方向摸索。
业务除了登录/支付业务，也做过风控系统、聊天监控系统，主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。

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

应用层上云

对于应用层上云，我们大部分业务都是平移上去，也对小部分业务做了改造。

a. 先说平移——

我和运维团队通过对以往 IDC 环境的梳理，最终统一了 CentOS 6 / 7 两大基础镜像，大部分业务依然使用 6，容器业务使用 7。

细化到具体的业务，IDC 存在 PHP 5.1、5.2、5.4、5.6、7.0、7.2、7.4，而每个 PHP 版本的扩展又不一样，根据二八定理，统计发现，大部分业务集中在 PHP 5 /7 两个版本（为保证信息安全，具体小版本就不透露了），于是我们在平移的时候也顺便做了统一。

统一带来的好处，就是维护成本上极大降低了！对于运维的同学来说，只需要维护 2 个 PHP 包，扩展都是一致的，扩容的时候也很方便。开发也爽了，搭建测试环境只需要准备 2 个 PHP 版本。以前每个人对多个 PHP 都很头痛，宁可公用 1 台开发机，也懒得自己去折腾环境。

b. 再说改造——

背景：

存在 Thrift、go-micro、phprpc 等多套 RPC 框架，运维成本极高。如监控的接入非常不方便（所有业务都需要适配），发生故障时 grpc 类业务由于框架问题，运维无法协助切换流量等
go-micro 服务治理能力弱，选点策略缺乏可用区切流方式，而重试机制、熔断限流等几乎空白，只能自行实现
PHP 和 go-micro 结合并不是很好，中间还需要一层 grpc 到 HTTP 协议的转换层，而 PHP 业务将存在非常长的一段时间
大部分业务配置（依赖的服务）写死在代码里，无法享受 K8s 容器的服务发现能力

对策：

我们从一开始保留 go-micro 框架，包括可用区、熔断限流等服务治理都完成后，最后还是决定把它去掉了。

不得不说，go-micro 本身是一个挺优秀的框架，大部分代码都是以 interface{} 存在，定制化非常强。模块与模块之间松耦合，非常值得学习。

只是业务上必须保留 PHP，维护太多的协议对于不是很大的开发团队来说，无疑也是一种压力。

HTTP + JSON 大部分情况下表现非常好，但是 JSON 本身的序列化、反序列化也是比较消耗性能的——这也是我文章开头说的，一切都是权衡利弊。没有最好，只有适合。

总结下，应用层上云难度适中。但是在业务改造的过程中不甚理想，由于业务繁杂，迭代速度快，事情太多了，有些东西就无法做到尽善尽美，一切都需要时间去积淀。

就拿监控而言，我开发了初版后也有其他同事一起开发，慢慢地从一个小房子变成一座大别墅，内心真的是慢慢的成就感。

整个应用层花费的时间周期非常长，这点确实超乎我的预期。

今天就写到这，下次再聊缓存层上云。感谢您的阅读：）