共计 5595 个字符，预计需要花费 14 分钟才能阅读完成。
作者
陈智伟，腾讯 12 级后盾专家工程师，现负责欢畅游戏工作室公共后盾技术研发以及团队管理工作。在微服务分布式架构以及游戏后盾运维研发有丰盛的教训。
前言
欢畅游戏工作室后盾是散布式微服务架构，目前稳固承载着多款游戏，数千万 DAU 以及数百万级在线。原有云下架构脱胎于 QQGame 后盾，外围架构已有 10 多年的历史，其中应用了多套目标不同的自研开发框架，自研根底组件，并为适应繁冗的业务场景，衍生出不同的服务模型，最终积攒了数百个微服务，整体简化架构如下所示：
在这种大规模平台化的后盾零碎和简单多样的业务架构下，还要继续发明更大的业务价值，这给团队带来了较大的挑战和压力。简略列举几个问题：
- 机器资源利用率极低，集群内 CPU 峰值均匀利用率有余 20%；
- 服务治理能力有余，因为存在多套研发框架且服务治理形式不同，导致整体业务的保护以及根底服务治理能力的研发老本较高；
- 服务部署非常繁琐，自动化有余，耗时耗力，且容易出外网问题；
- 大量的古老业务服务不足保护，古老服务可视化能力有余，品质不易保障；
- 整体架构较为简单，新人上手老本较高，可维护性有余；
- 每年机房裁撤都要消耗较大人力老本；
在云原生时代，借着公司全面“拥抱云原生”的东风，咱们深度联合 K8s 以及 Istio 能力，逐模块拆分，粗疏梳理，经验过各类有状态、无状态服务的上云，协定革新，框架革新适配，服务模型云原生化，数据迁徙，欠缺云上周边服务组件，建设云上服务 DevOps 流程等等泛滥系统性工程革新。最终，在不停服、平滑兼容过渡的前提下，将整体架构的服务云化以及网格化。
在整体架构上云技术计划选型上，咱们衡量了各类计划的齐备性、可扩展性以及革新保护老本等因素，最终抉择 应用 Istio 服务网格 作为整体上云的技术计划。
接下来，我将依照原有架构演进的线路，简略介绍局部模块的上云计划。
研发框架以及架构降级，实现低成本无感平滑演进至服务网格
为了接入 Istio 以及服务可能平滑过渡，在根底框架和架构上做了较多适配性调整，最终能够实现：
- 存量业务代码无需调整，重编即可反对 gRPC 协定;
- 网格服务之间调用，应用 gRPC 通信；
- 云下服务调用网格服务，既能够应用公有协定也能够应用 gRPC 协定；
- 网格服务调用云下服务，应用 gRPC 协定；
- 旧业务可平滑灰度迁徙至网格内；
- 兼容 Client 侧的公有协定申请；
接下来，对其中局部内容做简要阐明。
原有架构引入 gRPC
思考到须要更全面利用 Istio 的服务治理能力，咱们在已有开发框架中引入了 gRPC 协定栈。同时为了兼容原有的公有协定的通信能力，应用 gRPC 包装公有协定，并在开发框架层以及架构层都做了兼容性解决。开发框架结构示意图如下所示：
应用 MeshGate 桥接网格以及云下服务
为了使得云上 Istio 中的服务，可能与云下服务互通，咱们研发了 MeshGate 服务桥接云上网格以及云下服务。
MeshGate 次要性能是实现服务在网格内外的双边代理注册，并实现 gRPC 与公有协定之间的互转适配，架构如下图所示：
架构演变
基于业务重编反对 gRPC 能力，以及网格内外服务兼容性的买通，咱们就能够实现新旧业务无感平滑的迁徙上云了。
当然在迁徙过程中，咱们也并非一味无脑的容器化上云，会对各类服务做针对性的云原生化解决以及服务质量加固，并进步服务的可观测性，最终晋升服务的可维护性以及资源利用率。
服务上云之后，其资源配置粒度变为 Pod 级别，并反对主动伸缩能力，因而无需为具体的服务预留过多资源，绝大部分服务都能够共用 Node 资源。进而能够大幅提高机器资源的利用率，整体的资源应用降幅可达 60-70% 左右。
除了机器资源的缩小益处之外，服务应用 helm 申明式一键部署模式，从而 K8s 能够较好地维持服务的可用性，同时架构也取得了 Istio 弱小的服务治理能力。最终极好地晋升了业务的 DevOps 效力。
整体架构的演变如下图所示：
但心细的同学可能会发现，服务上了网格之后，业务和 Client 侧的通信须要从自研接入集群 Lotus 转发至 MeshGate，并做屡次的协定转换以及转发，导致通信链路的性能开销以及时延加大。而对于游戏中时延敏感的业务场景，其中时延的损失，是难以承受的。因而咱们迫切需要一个 网格内的网关接入服务，接下来就介绍一下网关接入的革新计划。
网格内公有协定的接入服务
原有云下的自研接入集群 Lotus，是 基于公有协定的 TCP 长链接 的 Client 侧接入服务，具备服务注册，大规模用户链接治理，通信鉴权，加解密，转发等等能力。
除了前述服务迁徙至网格后，导致通信成果损耗之外，还存在一些其余问题：
- Lotus 集群的运维非常繁琐；因为为了避免用户游戏过程中呈现链接的断开导致的不好体验，Lotus 过程的进行，须要期待用户侧被动断开，而新链接则不会发送给待停的 Lotus 中，简而言之，Lotus 的进行须要排空已有长链接，这也导致 Lotus 的更新须要期待较长的工夫。咱们有统计过，每次全网跟新公布 Lotus 版本须要继续数天的工夫。而遇到问题、裁撤或者新增节点时，其变更须要人工调整全网配置策略，且须要执行十多项步骤，整体效率较低。
- Lotus 集群的资源利用率低；因为 Lotus 是最根底的服务，且部署不不便，因而为了应答业务流量的变动，就要预留出短缺的机器资源。但这也导致了 Lotus 的资源利用率较低，日常 CPU 峰值资源利用率仅 25% 左右；
为此，咱们基于 CNCF 旗下的开源我的项目 Envoy 的根底之上，反对公有协定的转发，并对接 Istio 管制面，使之适配咱们原有的业务模型，并实现公有通信鉴权，加解密，客户端链接治理等等能力，最终实现接入服上云的工作。整体技术框架如下图所示：
革新结束之后，云上接入集群在各方面都取得了较好的晋升。
外围业务场景下的 公有协定转发性能以及提早开销与云下环境靠近 ；
针对外围的业务场景，咱们做过相应的压力测试，Envoy 在反对公有协定之后，其接入转发的性能开销以及时延与云下直连属于同一个量级。其中测试时延，如下表所示：场景 均匀耗时 P95 耗时 云下直连 0.38ms 0.67ms K8s pod 间转发 0.52ms 0.90ms Istio + TCP 转发(公有协定) 0.62ms 1.26ms Istio + gRPC 转发 6.23ms 14.62ms - 人造反对 Istio 的服务治理能力，更贴近云原生 Istio 下的应用形式；
- 通过 Helm 部署以及定义 Controller 治理，实现一键服务上架以及滚动更新；整个降级是主动的，且过程中实现排空更新能力，并思考会负载能力，排空效率更优。
- 因为反对主动伸缩能力，接入服务无需预留过多的资源，因而能够大幅升高资源开销；全量云化后接入集群的 CPU 节俭 50%-60%，内存节俭了近 70% 左右。
架构演变
有了云上接入集群，整体架构演变如上图所示。接下来再以游戏业务中的 GameSvr 作为游戏强状态服务的代表，简略介绍其上云计划。
GameSvr 上云
欢畅工作室以往大都是单局房间类的游戏（注：目前曾经远不止这些了，也有 MMO，大世界，SLG 等等各种游戏品类）。云下 GameSvr 架构如下图所示：
但以上架构在云下存在一些问题：
- 运维繁琐；单台 GameSvr 高低架需十余步人工操作，每年不停服机器裁撤须要消耗数周的人力，且容易产生事变；
- 资源利用率低；同样因为扩缩不易，就需预留足够的资源，做冗余部署，导致高峰期 CPU 利用率仅 20% 左右；
- 整体的容灾能力弱，宕机后需人工染指解决；
- 对局调度不灵便，都是依附人工配置动态策略；
因而借助云原生的能力，咱们打造了一套易伸缩、易保护和高可用的单局类 GameSvr 架构。如下图所示：
在整个迁徙上云的过程中，咱们是 不停服，不变更前端，用户无感地平滑过渡至云上网格 GameSvr 集群。最终实现了：
- 资源利用率上取得大幅晋升；整体 CPU 以及内存的应用都缩小了近 2/3。
- 运维效率获大幅晋升；通过自定义 CRD 和 Controller 的治理，实现 Helm 一键部署整个集群，高低架非常便捷，仅一个业务项目组每个月因公布 GameSvr 都能够无效节俭人力近 10 人天；
- GameSvr 可依据以后集群的负载压力变动以及历史负载压力的工夫序列实现牢靠主动伸缩；
- 实现了灵便牢靠的单局调度能力；通过简略的配置，即可实现单局依据不同的属性，调度到不同的 Set 中。且在调度的过程中，也会思考负载和服务质量，最终实现整体调度的较优抉择。
架构演变
GameSvr 上云之后，整体架构变迁如上图所示，接下来再看 CGI 是如何上云的。
数量宏大的 CGI 上云
咱们曾大规模应用 Apache 下的 CGI 作为经营类流动开发的框架。但原有 CGI 业务的一些现状：
- 业务品种较多，现网部署约 350 种 CGI 服务，且流量微小；
- CGI 同步阻塞的过程模型，导致其单过程的吞吐量极低；大部分 CGI 业务的 QPS 仅个位数，且存在 Apache 的服务调度以及音讯散发的性能开销；
- CGI 之间的资源隔离性差；因为 CGI 是同机多过程部署，极易呈现因为某个业务 CGI 忽然资源开销暴增，影响其余业务 CGI 的状况；
面对数量宏大且性能低效的 CGI 的上云，则须要 研发老本以及资源开销都低的上云计划。一开始咱们尝试过将 Apache 以及 CGI 整体打包成一个镜像简略容器化上云，但发现资源开销和部署模型都非常不现实，因而须要更优雅的上云计划。
接着，咱们对 CGI 的流量散布进行剖析，发现 90% 的业务流量次要集中在 5% 的 CGI 中，如下图所示。
因而，咱们针对不同流量的 CGI，做了一些辨别革新上云。
针对 头部流量 CGI 进行协程异步化革新，剥离 Apache，使框架性能获数十倍晋升。
在框架层实现监听 http 申请以及异步化：
- 应用 http-parser 革新，使的框架本身就反对 http 监听以及解决；
- 基于 libco 革新，使框架底层反对协程，从而实现异步化；
在业务层，也须要针对性做各类适配性解决：
- 针对全局变量，进行私有化或者关联至协程对象治理；
- 后端网络、io、配置加载以及内存等资源做各类复用化优化，晋升效率；
最终业务侧做较小的调整，即可协程异步化革新完。但即便革新老本再低，已有的 CGI 数量还是太多了，全量异步化革新性价比非常低。
- 针对残余长尾流量 CGI，与 Apache 一并打包，应用脚本一次性搬迁上云。为了晋升可观测性，还对这种单容器内，超多过程的 metrics 采集 export 做了非凡解决。
最初在上云过程中，充分利用 Apache 的转发机制，实现灰度可回滚上云。
上云后，CGI 的整体资源利用率以及可维护性均获大幅晋升。全量云化之后 CPU 可节俭近 85% 的核数，内存可节俭 70% 左右。
架构演变
搬迁完 CGI 之后，整体架构如上图所示。接下来介绍一下自研存储 CubeDB 的革新计划。
自研存储业务迁徙
咱们云下有具备数十 T 的自研存储数据，自建数百张 MySQL 表，整体的保护老本较高，且上云艰难。因而咱们的解决方案是“业余的事交给业余的人做”，将存储迁徙托管至 TcaplusDB（腾讯 IEG 自研公共存储服务）。整体的迁徙步骤简要形容如下：
- 研发了适配代理服务，即上图所示的 Cube2TcaplusProxy，将 CubeDB 公有协定适配转换至 TcaplusDB，那么新业务的存储就能够间接应用 TcaplusDB 了；
- 在 CubeDB 的备机同步业务的热数据，在开启同步之后，TcaplusDB 就有业务的最新数据；
- 将冷数据导入至 TcaplusDB，如果 TcaplusDB 中有记录数据，阐明它是最新的，则不笼罩；
- 全量比对 MySQL 与 TcaplusDB 的数据，屡次校验全量通过后则切换 Proxy 的路由；
最终通过这种计划，咱们实现 DB 存储的无损平滑迁徙。
架构演变
咱们自研存储服务革新结束之后，绝大部分服务均能够上云了。同时咱们还做了很多云上周边能力的建设和利用，例如云上对立配置核心，grafana as code，promethues，日志核心，染色调用链等等能力。
最终架构演变为：
多集群的部署模式
在云下，咱们是一个全区全服的架构，所有的游戏业务都在一个集群之中。但因为咱们组织架构以及业务状态的起因，冀望上云之后，不同的业务团队工作在不同的业务 K8s 集群，而对于大家共用的服务，则放到公共集群下治理。因而在迁徙上云的过程中，则还须要做更多的适配迁徙工作。
在 Istio 层面，因为咱们的 Istio 服务托管给 TCM 团队（腾讯云服务网格 TCM），在 TCM 同学的大力支持下，联合咱们目前的组织架构以及业务状态，实现 Istio 多集群下管制面信息的互通，由此咱们在多集群之间的相互调用，老本就很低了。如下是 TCM 相干的后盾架构：
总结
最终，咱们在简单的游戏业务架构下，通过粗疏剖析和基于云原生技术的继续重构演进，深度联合 K8s 以及 Istio 的能力，最终实现游戏业务场景下架构安稳平滑的高质量上云以及网格化，领有多框架多语言的微服务框架，自动化，服务发现，弹性伸缩，服务管控，流量调度治理，平面度量监控等等能力，并积淀游戏各类业务场景上云教训。对于业务模块的可靠性、可观测性、可维护性大幅提高，整体研运效率晋升非常显著。
欢畅游戏工作室旗下领有欢畅斗地主，欢畅麻将，欢畅降级等数款国民棋牌类游戏，同时在研大世界，MMO，SLG 等多种品类游戏，现大量招聘研发、策动以及美术等各类岗位，欢送猛戳招聘链接，举荐或者投递简历。
对于咱们
更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~
福利：
①公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~
②公众号后盾回复【系列】，可取得《15 个系列 100+ 篇超实用云原生原创干货合集》，蕴含 Kubernetes 降本增效、K8s 性能优化实际、最佳实际等系列。
③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
