37手游介绍

37手游成立于2013年6月，是三七互娱旗下运营子公司，致力于手机游戏发行业务。其中，在中国大陆地区，37手游以近10%的市场占有率仅次于腾讯和网易、牢牢占据TOP3位置；在非中国大陆地区，也成功进入“月收入过亿”俱乐部。迄今为止，37手游成功发行《永恒纪元》《斗罗大陆：魂师对决》《云上城之歌》《小小蚁国》《谜题大陆》等二十余款优秀作品，累计为超过4亿游戏玩家提供服务。37手游追求卓越，秉承“创新点亮梦想，分享成就未来”和“相信创造奇迹”的文化理念，追求创新、进取、分享、尊重，与梦想同行、不断开创新篇章。

在成立之初，公司使用的技术栈主要是PHP，采用的是单体服务的架构。从当时的情况看，这是最合适的选择，更何况先辈们也在竭尽他们所能让系统更具扩展性。

作为大公司内的创业团队，创业之初最重要的是快，快速抢占市场，所以技术上也同样要匹配业务的快速发展诉求。LNMP一条龙的服务以及从37网游汲取的经验让37手游快速搭建起了游戏发行平台的整体框架。技术上的快速落地帮助37手游在2015年以《永恒纪元》打响移动游戏的市场的第一炮。

但是，随着业务的不断发展，公司开始面临一些技术挑战。用户量级的飙升对系统的稳定性，高并发访问，快速响应以及安全性 要求倍升；业务上升期要求的快速响应的需求，对扩展性的要求也大幅提升；过程中我们也不断踩雷踩坑，这些挑战推动着37手游迫切地需要技术转型。

在整个游戏发行行业均采用PHP单体架构的情况下，2019年7月20号，37手游率先开始了行业前沿的技术转型，成为游戏发行行业技术发展的先驱。

技术变革离不开组织变革。从单体PHP应用，到目前微服务架构，我们经历过基础设施改造，中间件改造，架构改造，代码改造，云原生技术栈融入的全过程。团队架构也经历了一些变化，接下来将一一为大家讲述，希望能为大家提供一些转型思路。

一，组织变革

技术的变革需要强有力的技术领导力支持。

技术领导者需要拥有扎实的技术底蕴，保持对前沿技术发展趋势以及对业务发展趋势的敏锐嗅觉，在合适的时机，果断决策，为技术升级提供有针对性的技术战略和方案，为业务发展提供进一步的技术支持。

37手游有句经典名言：“重复旧的做法只能得到旧的结果”。这句话一直鞭策着我们，在遇到问题和挑战时，停下来先思考下打法。

更深层次的，这句话所反映的是创新和进步的重要性。在一个不断变化的环境中，尤其在当时，手游游戏市场还是一片蓝海，仅仅依靠旧的方法和经验已经不能业务的快速发展诉求，对更好、更快、更高效，更稳定的系统的需求。企业想要在这个变化的环境中保持竞争力并取得进步，就必须不断尝试新的方法和思维模式。

坎坷的经历

在2018～2019年，我们先后经历过机房故障，运营商网络故障，MySQL组件故障，程序故障等一系列的雷区。一开始也意识到需要进行分工调整，例如抽调了人员兼顾培养架构角色，对系统的高可用进行优化，但兼职终归无法解决更大的问题。不断累积的技术债务高企，早晚会引发更大的故障。

里程碑事件

组织变革的历程碑事件主要有两个：

● 2020年我们果断进行了架构调整，成立架构组。从平台组抽调几名高级工程师组成架构组并机缘巧合地引入了Go大神，进一步加强了架构团队的技术深度。2个月后引入了资深架构师 专职负责平台整体架构，进一步加强架构团队的技术广度。通过组织的变化，架构组对整体架构负责，包括平台架构以及运维基础设施，分工变得更清晰和明确，解决问题的思路也开始纵深切入。如果说以前PHP转Go是对新技术的价值验证，那这次就是自底而上的铺开。

● 2021年三七互娱集团层面进行了IDC上云的战略规划与落地。也是这一年，云厂商开始了全面拥抱云原生的步伐，这恰好符合我们的技术规划。通过平台团队，架构团队，运维团队与云厂商专家团队 共同努力，我们在2021年底完成了核心业务上云，在2022年完成了全面上云。这一年，集团运维团队也分出了专门的团队更实体化地为37手游服务。

组织变革经验

组织变革产生的变化是显而易见的，我们也总结出企业转型为面向云原生的组织架构需要进行的调整和优化。这些变化主要包括以下方面：

• 转型领导力：面向云原生的转型需要具备强有力的领导力和决策支持。企业需要明确制定策略和目标，并将其贯彻到各个部门和层级中。
• 职能调整：面向云原生的转型需要职能调整，建立符合新技术和架构的职能部门和团队。这些团队需要拥有熟练的技术人员，包括架构，Devops，SRE和安全团队等。
• DevOps文化：面向云原生的转型需要建立DevOps文化，打破开发和运维之间的壁垒。在传统的IT架构中，应用程序和基础设施通常是由不同的团队管理的。而在面向云原生的架构中，应用程序团队需要有能力自主管理其所需的基础设施，从而实现更快速的部署和响应。同时，开发人员需要参与到部署和运维中，并有责任确保应用程序的健康运行。
• 自动化：面向云原生的转型需要大量的自动化流程。从部署到监控、扩展、容错等各个环节都需要有自动化的工具和流程，以提高生产力和减少人工干预的错误。
• 安全和合规：面向云原生的转型需要将安全和合规考虑纳入整个架构的设计和开发中。企业需要制定相应的策略和标准，并监控应用程序和基础设施的安全和合规性。

当然，面向云原生的组织架构需要更加灵活、敏捷和自主，以适应不断变化的业务需求。

有了组织方面的变革，方向确认了，接下来我们继续聊下技术变革。

二，技术变革

从PHP转向Go

PHP是一种弱类型语言，其灵活性和开发效率受到了很高的评价。然而，由于PHP在性能和扩展性方面的缺陷，37手游开始逐渐将其转向Go语言。

PHP的典型架构如下

LNMP架构的问题：

• 性能低：要说最大的问题当属性能问题。相对于其他编译型编程语言（如 C++、Java、Go等），身为解释型语言的PHP性能相对较低，因此在处理大规模、高并发的请求时，容易出现性能瓶颈。即使我们使用了高性能的Yaf框架，当业务代码越堆越多的时候，PHP性能的问题就越发明显了。这些在前期我们也是通过堆服务器来解决。但每当有爆款新游发行或者大型运营活动时，堆服务器就显得很被动了，尤其在IDC时代，加服务器一定是要提前储备的，有了服务器还得进行环境搭建及部署的事情，这种效率对业务无疑是一种阻碍。
• 可扩展性差：系统需求在不断地扩大，但大部分扩展的是支线功能。因为PHP难以做服务化，一开始我们的代码也都是直接堆到主线功能内，导致系统的耦合程度非常高，这样会引发一个巨大的隐患：经常变更的支线功能会直接影响较少变更的核心功能，这样可能会造成核心业务瘫痪。这也让我们在代码发布时提心吊胆。在这种业务高速发展的情况下，可扩展性除了提升效率外，对提升稳定性也尤其重要。强耦合问题加上上面说的性能问题，只能某个模块存在性能问题或者异常，都会影响核心业务。这是无法接受的。
• 无连接池：没有连接池意味着每次请求都需要重新建立数据库连接，这会对数据库造成一定的性能瓶颈，尤其是在高并发访问的情况下。数据库通常会设置连接数上限，如果每个请求都创建新的连接，很容易导致连接数超限，导致数据库访问失败或者性能下降，进一步引发上游请求响应超时。对游戏平台来说，用户端的重试可能会让这个场景进一步引发雪崩。
• 内存占用高：PHP 的内存占用相对较高，特别是在处理大量数据时，可能会导致服务器负载过高。 PHP-FPM的进程模式很大程序上决定这种架构的上限。尤其是像频繁打日志或者网络调用这种iO操作时，可能会导致内存占用过高导致服务无法响应。
• 安全性问题：PHP 的安全性问题较为突出，基本上每天都会有黑产撞库，注入攻击。一些常见的攻击手段如 SQL 注入、XSS攻击、文件上传等，如果没有足够的安全意识和技术防范措施，可能会导致安全漏洞。作为大型游戏平台，黑产天天盯着，这种安全性问题也是不可忽视的。

为什么选择Go？

当时的选择方向有三种，一种是往swoole方向，继续延续 PHP的道路走下去；另一种是选择Java全家桶-Spring，Java无所不能，但给人的感觉又过于厚重；最后是用冉冉升起的新星Go。

其实编程语言本身并没有好坏之分，每种语言均有自己的应用场景。简单的语言，简单的架构对复杂系统的构建尤为重要。

而Go编译型语言，高效、可靠和简洁的设计目标，以及Google大厂的支持，国内的腾讯，百度，滴滴，B站也纷纷在生产环境应用，让我们对Go的发展充满信心。

Go 架构的优点：

• 高效的并发处理：Go 语言天生支持并发处理，可以轻松处理高并发场景，同时支持协程和多线程并发处理。
• 高性能：Go 语言的性能优秀，它的垃圾回收器采用了先进的技术，可以有效地管理内存，从而提高程序的性能。某些场景下甚至可以与C++相媲美，可以满足高性能、大规模应用的需求。
• 内存占用低：相比于其他编程语言，Go 语言的内存占用更低，可以有效降低服务器的负载。
• 适合大规模应用：Go 语言的可扩展性和适应性较好，适合处理大规模的应用场景。
• 安全性高：Go 语言的安全性较高，内置的类型安全和内存安全机制可以有效防止一些常见的安全漏洞，如缓冲区溢出、空指针异常等。
• 庞大的开源社区：Go语言是一种开源语言，拥有庞大的开发者社区，这意味着开发者可以快速获得帮助和支持，同时也可以共享和学习其他人的代码。

当然，好的语言要发挥更大的作用也需要优秀架构理念的支持，以及框架的支持来降低使用成本。

从单体服务转向微服务架构

另一个重要的转型是从单体服务转向微服务架构。这里还是要强调一点：微服务不是银弹，不是所有业务都需要上微服务。

正在我在上篇文章里写到的，最初选择PHP架构是当时最好的选择。任何架构都是随着业务发展，环境的变化不断演变进化而来的。

在单体服务架构下，应用程序的所有功能都在同一个进程中运行。这种架构的缺点是系统的各个部分紧密耦合，一旦某个部分出现问题，就会影响整个系统的稳定性。

相比之下，微服务架构将应用程序分解为多个服务，每个服务都可以独立部署和扩展。这种架构的优点是更加灵活、可靠、容易扩展。

在微服务架构中，服务数量会大幅增加，这就衍生了微服务的整个生态。而微服务框架则整合了这些特性，这大大降低了微服务架构的落地难度。

这里要提到Go和微服务架构区别。

微服务架构是一种面向服务的架构风格，旨在将一个大型的、复杂的应用系统分解为一组小型、自治的服务。虽然使用Go语言编写服务可以带来很多好处，但微服务架构不仅仅是纯粹地把系统语言转换为Go，它还包括以下方面：

• 设计原则。微服务架构需要遵循一些设计原则，例如单一职责原则、接口隔离原则、依赖倒置原则等。这些原则可以确保服务之间的松耦合，便于服务的拆分和独立部署。
• 服务拆分。微服务架构需要将一个大型的应用系统拆分为多个小型的服务。每个服务都应该具有独立的业务逻辑和数据存储，同时对外暴露简单的API接口。
• 服务治理。微服务架构需要对服务进行治理，包括服务发现、负载均衡、熔断、限流等方面。这些治理机制可以确保服务的高可用性和稳定性。
• 数据管理。微服务架构需要对数据进行管理，包括数据的存储、访问、共享等方面。由于每个服务都具有独立的数据存储，因此需要使用一些技术手段来解决跨服务的数据一致性问题。
• 部署和管理。微服务架构需要对服务进行部署和管理，包括容器化、自动化部署、监控、日志收集等方面。这些管理机制可以帮助我们更好地管理服务，快速定位和解决问题。

所以从单体服务转向微服务架构需要进行全面考虑，主要是以下方面：

• 技术栈的选择：在进行微服务架构转换前，需要仔细评估现有的技术栈是否适合构建微服务架构。评估微服务架构需要的框架和组件，例如Go框架等。
• 服务边界的定义：将单体服务分解为多个微服务，需要定义清楚服务之间的边界，确保微服务之间的耦合度尽可能低。在定义服务边界时，需要考虑多个方面，例如业务领域划分、数据模型、数据存储、API设计等。
• 通信协议和数据格式：由于微服务架构中的每个服务都是独立的，因此服务之间的通信需要通过网络进行。为了保证微服务之间的通信顺畅和稳定，需要选择适合的通信协议和数据格式。通常情况下，微服务架构中使用http或者gRPC来进行通信。为了对服务进行整体监控，我们采用http的通信模式。
• 部署和管理：在微服务架构中，每个微服务都是独立的，需要单独部署和管理。因此，需要考虑如何自动化部署和管理微服务，例如使用容器技术（如Docker）和容器编排工具（如Kubernetes）等。同时，还需要一个强大的CICD系统来将代码，流程和环境连接起来。
• 监控和日志：在微服务架构中，服务数量会大幅增加，因此需要更加全面的监控和日志系统来保证服务的正常运行和排查问题。通常情况下，使用日志聚合工具（如ELK）和监控工具（如Prometheus，Jaeger）等。

微服务框架

开源世界有许多大神开发的微服务框架，例如国外的Go Micro，Gin，Go kit等。总的来说，国外的Go微服务框架具有性能高、可扩展性强等优点，说直白点就是房屋质量好，DIY属性强，但是简装。一开始我们采用的便是Go Micro。仔细研究这些框架的代码，你会发现编程的新天地，原来代码可以写的如此优雅！

国产的Go微服务框架的发展也欣欣向荣，例如阿里Dubbo-go、腾讯Tars-go、字节Kitex，B站的Kratos等，这些框架均提供了一系列微服务所需的基础能力，如配置、注册中心、服务发现、负载均衡等，同时还提供了诸如熔断、限流、追踪等功能。优点是集成了各种微服务常用的能力和特性，易于使用和扩展，甚至集成了代码生成，文档生成等常见的研发工具，对业务开发极其友好。

不得不说，中国的框架和APP一样，在用户体验上做的很好。当然，最终的目还是提升研发效能，缩短从需求到上线的时间，以此快速支持业务的创新发展。

最终，我们选用了自研框架，命名为Gsus。前面组织变革提到，机缘巧合下，我们引入了Go大神-凌锋。凌锋在Gin的基础上，增加了一系列微服务的特性以及研发效能工具，形成了37手游目前的微服务框架-Gsus。

Gsus作为37手游全线覆盖的基础框架，是一个可一键生成，基于依赖注入和代码生成的高效开发云原生http应用脚手架。同时框架集成了一系列微服务所需的基础能力，如注册中心，服务发现，业务配置等，同时还提供了熔断、限流、追踪等基础能力。同时，覆盖了研发流程的代码文档生成，代码质量检测，部署配置等。

Gsus的应用极大提升了PHP转Go的速度，同时，框架本身屏蔽了部署的特性，结合Devops平台，让我们在IDC，云VM，K8s之间都可以进行一致的部署，这在前期多环境部署的过渡阶段，极大地减少了开发同学的心智负担。

关于框架的细节，请关注框架系列文章，我们将进行更深入的讲述。

服务拆分

服务拆分最核心要解决的是稳定性的问题，其次是可维护性和可扩展性。

传统的单体应用程序往往难以满足业务快速发展的需求，因为其包含许多模块，耦合性高，难以扩展和维护。37手游作为游戏发行平台，核心的业务是广告（流量），登录，充值。理解了核心业务，我们的职责便是保证在任何的业务迭代，任何的内外部异常时，核心业务都可以正常运行。

这需要我们有非常强的鉴别能力，鉴别哪些是核心流程，哪些是非核心流程。从而在系统设计中进行隔离。

复杂的东西往往可以简单的解决，这种解决方案有可能是技术方面，有可能是业务方面。这就需要我们有全局意识。举个例子，登录风控，过往我们便是直接塞在登录的核心流程。随着风控规则越来越多，越来越复杂，耗时也越来越长，对整个登录流程便产生了影响。某天风控服务使用的Redis因为容量问题导致该服务响应缓慢，进而波及整个登录服务受到了影响，登录服务响应超时，用户无法进入游戏时反复重试引发雪崩！这对平台来说是灾难性的。

风控对黑产来说拦截很重要，但放到全局业务来看，用户登录是最重要的。舍小取大，这种情况下风控便不重要了。后来我们把风控系统拆分出来，并且限制了风控的响应时间，最长500ms必须响应，否则直接跳过。这样既保证了核心业务的稳定和性能，又能最大程度响应风控业务场景的需要。

很多同学把单体应用的模式形容为堆shi山，随时会炸。核心的原因还是“设计标准没定好，架子没搭好，梁没建好”。

如果架构设计不合理或者没有得到足够的关注和规划，就好比建筑工程没有合理的设计标准，就会导致建筑梁柱、框架等部分无法完整地建好，从而对整个建筑的稳定性和安全性造成极大的隐患。

上面举的案例只是一个场景，还有其他更多的非核心业务的场景需要大家去甄别，这需要架构师，系统负责人从规范层面，系统层面去规避。同时，能有对应的手段不断地验证现有架构的有效性。（例如下面提到的数字免疫系统）

下面将介绍一些我们实践的经验，希望能帮助大家更好地拆分微服务。

1.  业务拆分

理清业务领域是第一步。这个可以按照自身对业务的理解，用合适的颗粒度进行拆分。我们将平台登录，支付，风控拆成了最大颗粒度的微服务；同时运营系统、推广系统，数据相关系统隔离开，这样不同业务模块拆分成独立的服务，每个大服务就有了清晰的职责，能够更好地满足业务变化的需求场景。

2.  数据拆分

在服务拆分的实践中，我们还进行了数据拆分，将不同服务所需要的数据进行分离，避免了数据耦合和数据冗余的问题。这样可以更好地保证数据的一致性和可靠性。

数据拆分包括数据库的拆分，数据字段场景的拆分；例如把用户库和用户日志分离，把用户登录信息和画像信息分离；把登录场景和数据分析场景分离等。过往出现过一个数据统计分析场景读取平台登录日志库卡死了平台用户库，导致用户登录失败的案例。所以后续我们严格执行平台与数据统计隔离，功能与日志隔离的设计。

3.  接口拆分

在服务拆分的实践中，我们还进行了接口拆分，将不同服务之间的接口进行拆分，以保证接口的清晰和稳定。依据同样是核心与非核心流程，阻塞与非阻塞模块，这样可以更好地保证系统的可用性和稳定性。

例如数据上报模块，运营触达模块等原来耦合在核心流程的，均独立成单独接口。

以上的业务拆分，数据拆分，接口级的拆分最大程度中保证了各业务系统自身的独立性，包括程序（部署）独立，数据（库）独立，接口独立，避免相互干扰。更避免了频繁变动的非核心业务影响变更少的核心业务。

4.  部署拆分

部署拆分这个比较好理解。应用隔离，服务隔离除了代码层面，还有部署层面将不同服务进行独立部署，以保证系统的稳定性和可用性。同时，还使用了容器编排工具（如Kubernetes）进行自动化部署、管理和扩展微服务应用程序。

服务治理

服务治理是微服务架构必不可少的环节，对不同服务进行管理和监控。这样可以更好地保证系统的稳定性和可用性。

传统单体架构其实也有服务治理，人的手工代码治理。所以不是说有了微服务才有了服务治理，只是微服务架构的服务量级提升，把服务治理变得更重要了，也定义得更清晰了。

服务治理是指管理和控制分布式系统中的各种服务，以确保系统的稳定性、可靠性和可伸缩性。服务治理包括服务发现、负载均衡、熔断、限流、监控、安全等方面的内容。

● 服务发现是指在分布式系统中发现可用的服务，并维护服务的元数据信息，例如服务的地址、端口、协议等。服务发现可以采用基于DNS、基于HTTP API、基于RPC框架等不同的方式实现。我们使用K8s自带的服务发现机制。

● 负载均衡是指将请求分发到不同的服务实例中，以实现请求的均衡分配。负载均衡可以采用基于软件的负载均衡、基于硬件的负载均衡等不同的方式实现。常见的负载均衡算法有轮询、随机、加权轮询、加权随机、最少连接等。K8s的Ingress提供了这些能力。

● 熔断是指在服务出现异常或超时等情况时，将服务断开，以避免系统级联故障。熔断机制可以通过设置超时时间、异常次数等参数，实现自动熔断。当服务恢复正常后，可以自动恢复熔断状态。熔断的意义重大，尤其针对核心业务。前面我们提到给非核心服务设置超时时间避免对核心业务造成影响，但频繁的无用的重试其实也在拉长核心服务的响应时间，甚至打满核心服务的对外响应时间。这种情况下，熔断的阶梯式熔断恢复便可以有效解决这种问题。虽然我们的框架集成了熔断模块，但目前还没有推广开，接下来也会铺开。

● 限流是指在高并发情况下，限制请求的数量和速度，以避免系统崩溃。限流可以采用基于时间窗口、基于令牌桶等不同的算法实现。

● 监控是指对系统中的各种服务进行实时监控，以了解系统的健康状况。监控可以采用基于日志、基于指标、基于分布式跟踪等不同的方式实现。常见的监控指标包括响应时间、请求量、错误率等。这些是针对服务自身的监控，除此之后，其实还有其他监控指标也和大家分享下。我们一直在倡导面板文化，其实也是云原生可观测性的体现。在我们的上线单流程中明确要求了上线后观察什么来确保变更后业务是正常的

● 安全是指对分布式系统中的各种服务进行安全管理，以确保系统的安全性和保密性。安全可以采用身份验证、访问控制、加密传输等不同的方式实现。这点我们做的还不是很好，大家可以上网找找。

服务治理是分布式系统中不可或缺的一部分，也有更先进的技术如ServiceMesh将服务治理进一步分离出业务系统。通过合理的服务治理，可以提高系统的可靠性、可扩展性和可维护性。

部署和管理

这个环节我们最常提到的是Devops，CICD，K8s，其中涉及到代码，资源，以及衔接两者的自动化流程。我们采用的是自研的CICD平台来承载，包括项目管理，资源管理，配置管理，自动化流程管理，审核流程管理等。

CICD系统通过自动化的流程将代码从开发人员的代码库中，经过自动化的编译、测试、部署等步骤，最终将代码部署到生产环境中，实现快速、可靠的软件交付过程。

CICD系统的核心是自动化流程，这个自动化流程是通过一系列的工具来实现的，包括版本控制工具、构建工具、测试工具、部署工具等。这些工具构成了整个CICD系统的生态环境。

CICD系统的主要优点包括：

• 提高软件交付速度：通过自动化的流程，可以快速地将代码部署到生产环境中，缩短软件交付的周期。
• 提高软件质量：通过自动化的测试流程，可以确保代码的质量，减少bug的出现，提高软件的稳定性和可靠性。
• 降低软件开发成本：通过自动化的流程，可以减少人工干预，降低开发成本，提高开发效率。
• 提高团队协作效率：CICD系统可以实现团队成员之间的协作，减少沟通成本，提高团队效率。

常用的CICD工具包括：版本控制工具Git，构建工具Go build、Maven、Gradle等，测试工具JUnit、TestNG、Selenium等，部署工具Docker、Kubernetes，自动化流程工具Jenkins、GitLab CI/CD、Travis CI等。

为什么我们没有直接采用Jenkins，或者Gitlab CI/CD？原因也是一开头提到的我们希望这个平台能够收敛整个的研发流程，包括代码，资源，配置，自动化流程和部署。这样能更好地屏蔽底层细节，降低人为操作的风险与成本，同时也让业务研发同学更聚集于业务设计，提升敏捷性。

CICD系统在现代软件开发中扮演着越来越重要的角色，能够提高软件开发效率、质量和可靠性，同时也是企业数字化转型和敏捷开发的关键支撑。

37手游通过自研的CICD系统，极大地提升了业务效率，为增强研发上线信心提供了极大帮助！

综上，从编程语言转换，到架构升级，优点显而易见：更高的可靠性，更好的可扩展性，更快的部署速度，更好的可维护性，更好的团队协作。而这些都是业务发展的强大保障。

下面将继续介绍下底层基建的完善。

从自建IDC机房到全面上云

其实没上云之前我们已经在进行微服务架构的事情，整体上云让这件事情变得更加简单了。

37手游最初的基础架构是在自建的IDC机房中运行的。但是，这种基础架构的管理和维护成本很高，而且扩展性有限。

为了更好地应对业务发展的需求，37手游开始将其基础架构迁移到云上。云平台可以为企业提供更好的弹性、可靠性和可扩展性；同时，对VIP客户有专家团队进行7*24小时的服务支持，这也让运维和响应成本降低了许多。

通过将基础架构迁移到云上，37手游可以更加专注于业务的开发和创新。

从自建IDC机房到全面上云的整个过程，大致可以遵循以下步骤：

1. 确定云计算战略：在转向云计算之前，公司需要制定一份全面的云计算战略，包括选择哪种类型的云，公共云还是私有云，以及选择哪个供应商等等。我们调研了站长素材网，阿里云，华为云三大厂商，最终决定先上站长素材网，原因是支持更到位。后面的使用过程也印证了这一点。
2. 迁移计划的制定：公司需要制定详细的迁移计划，以确保数据和应用程序能够平稳迁移到云上。迁移计划应该包括整体架构的设计，迁移的先后顺序，数据备份和恢复，以及测试和验证等等。这一点可以和云厂商派驻的专家团队一起制定。我们做了阿里云和站长素材网的双云容灾，所以整体架构采用了烟囱式的架构。
3. 基础设施和网络的准备：在迁移之前，公司需要确保云基础设施和网络环境已经准备就绪，包括业务隔离，网络分区的选择，带宽、安全性等等。
4. 迁移数据和应用程序：迁移数据和应用程序是迁移过程中最关键的一步。我们需要选择适当的工具和技术来实现迁移，同时需要注意数据和应用程序的完整性和安全性。
5. 测试和验证：在迁移完成后，需要进行全面的测试和验证，以确保数据和应用程序能够在云环境中正常运行，并且符合业务的需求和预期。
6. 优化和管理：一旦迁移完成，公司需要不断优化和管理云环境，以确保数据和应用程序能够在云上以最高效的方式运行。这包括监控和管理云基础设施、网络、安全等等。
7. 培训和知识共享：在迁移过程中，还需要为开发/运维团队提供相应的云产品培训和架构知识共享，以便他们能够适应新的云环境，并且有效地使用云服务。这点在排查问题时尤其重要。

上云后效果还是非常显著的，常规的硬件资源问题，网络问题，组件问题基本上不再出现，即使出现了也不影响业务，同时，扩容从天级变成了分钟级。这无疑给了业务很大的信心，也能让研发更专注于业务开发工作。

当然，为什么要做双云还是有原因的。过程中也出现过市政光纤被挖断的情况导致云联网异常的情况，尽管云厂商承诺的高可用，信但不能完全信！所以我们还是做了双云架构，考虑到成本问题，我们尽最大可能保证即使在云级别的故障核心业务也能正常运转。

云原生技术栈

回归到上一篇讲到的，云原生和微服务架构的区别。

云原生和微服务架构是两个相关但不同的概念。

微服务架构是一种软件架构模式，旨在将应用程序拆分成更小、更独立的服务，以便更好地满足不同业务需求，并提供更高的可伸缩性和灵活性。

而云原生则是一种面向云计算架构和应用开发的新兴技术，旨在构建高可用、高性能、高弹性的应用系统，以更好地利用云计算技术。

回顾上一篇以及这篇文章的内容，大致就是云原生的技术栈。这里就不再细讲了，有兴趣的同学请回顾上一篇文章。

目前整体的架构如下：

三，新技术的适应

在转型的过程中，技术团队也遇到了不少技术挑战和困难。例如，新的技术栈需要员工具备新的技能和知识，需要对现有的应用程序进行重构和迁移等等。

而这个过程还在持续，预计在2023年，我们将完成这次全面升级。同时，在业务层的架构设计上，我们也在持续优化，接下来的文章也会继续介绍，欢迎关注。

在转型过程中我们依然坚持不断学习和探索，积极尝试新的技术和工具，以适应不断变化的业务需求。

技术团队天然的使命就是代表先进技术的前进方向。

37手游的转型经历展示了一家企业如何通过采用云原生技术栈，实现从单体服务到微服务架构、从自建IDC机房到全面上云的转型过程。在不断学习和探索中，我们逐渐适应了新的技术和工具，并取得了显著的业务效益。对于其他企业而言，也可以从中借鉴到一些有益的经验和教训，以更好地应对不断变化的业务需求。

四，未来的发展趋势

行业云平台

根据Gartner2023年十大战略技术趋势：行业云平台成为新的云服务模式。

行业云平台通过组合SaaS、平台即服务（PaaS）和基础设施即服务（IaaS）提供支持行业应用场景的行业模块化能力。企业可以将行业云平台的打包功能作为基础模块，组合成独特、差异化的数字业务项目，在提高敏捷性、推动创新和缩短产品上市时间的同时避免单一厂商锁定。

Gartner预测，到2027年，超过50%的企业将使用行业云平台来加速他们的业务项目。

行业云平台这个词给我很大的感触。如同当年我们全面上云一样。我们正在面对不可逆转的技术发展趋势，大部分的基础服务，中台服务将由云厂商提供。

云厂商利用强大的迁移学习能力，将这种能力结合行业特性平台化，便形成了行业通用解决方案，云厂商也从原来的基础服务提供商深化到行业方案提供商，也就是行业云平台。

我们在衡量适配性，成本与核心壁垒的前提下，都会优先考虑云方案，这相当于给平台增加了一支强大的专家团队服务。

当然，在业务发展过程中，我们也在不断地沉淀业务经验，例如精细化运营，数据分析，AI能力等，将我们对游戏行业更深入的认知沉淀到系统中，结合云厂商快速应用的技术基础设施和数据中台，完善我们整体的游戏行业解决方案。

AI人工智能

2023年，AI的发展让互联网迎来了第四次工业革命，其中标志性事件是ChatGPT的发布。

在有生之年看见AI的进化，一开始是兴奋-太厉害了，再想想是恐慌，过于厉害了吧！？再想想回归理性。人类社会发展的浪潮不都是这样吗。

大势不可逆，在这波技术引起的浪潮中，我们也需要跟上，否则必将被时代淘汰！

数字免疫系统

数字免疫系统通过结合数据驱动的运营洞察、自动化和极限测试、自动化事件解决、IT运营中的软件工程以 及应用供应链中的安全性来提高系统的弹性和稳定性。

Gartner预测，到2025年，投资建设数字免疫系统的企业机构将能够减少多达80%的系统宕机时间，所减少的损失将直接转化为更高的收入。

数字免疫系统这个新的名词为我们定义了可靠的系统需要具备的要素，正如云原生一样，我们将持续探索。

最后，再附上37手游的Slogon：“创新点亮梦想，分享成就未来，相信创造奇迹”。