上家公司解散后，我入职了新公司，负责研发效率和DevOps。我常常参与从前端、后端、美术、策划、质量保证、产品管理等所有流程的重新组织，制定标准，实现自动化，提高工业水平。每个公司的具体情况和所需人员各不相同，这让我有时间复盘过去项目的技术债务。这篇内容是我在思考“C#是否能做游戏全栈”的新见解。

首先，我无意引起语言之争，也不是在推广“Web方案、Java”的概念，标题中的词语并不是为了炫耀或贬低任何技术。对我来说，技术方案和语言只是工具，所以我不自称是C#或Go的专家。随着云原生、容器技术的发展，整个后端工业化和生态的进步，我开始重新思考“C#现在能否做游戏全栈开发”。

技术选型从来不是个人喜好或语言优劣的问题，而是对项目负责时需要综合考量的复杂决策。

云原生是什么？简单理解，它指的是在云环境下的软件开发、部署和管理的方法，包括容器化、微服务、服务网格等技术。我会在后续内容中详细解释其优势。

本文的目标是探讨Unity前端是否能使用C#构建一套“分布式游戏系统API服务器”。讨论将聚焦于游戏系统的API接口，如登录、签到、养成、抽卡等，暂不涉及游戏玩法同步部分。

在之前的项目中，我们采用了一种类似于明日方舟的二游结构，弱联网，游戏玩法和战斗可以在服务器验证后再结束。为了应对首日用户量的激增，我们设计了最高10万QPS和300万注册规模的目标。项目主要架构包括SpringCloud + 微服务 + Serverless + 无状态架构 + .NET Core战斗验算，托管在阿里云的Serverless K8s服务上。虽然Java作为业务接口开发的工具，但在分布式架构方面，我们更多依赖K8s本身，较少使用SpringCloud相关技术栈。

无状态架构带来的好处是，每个请求处理节点的结果相同，所有业务节点可以进行弹性扩展，故障节点可以快速恢复。Serverless架构也极大降低了运维成本，提高了整体服务的高可用性。

这种架构适合于明日方舟、1999这类弱联网游戏，或者像LOL、王者荣耀、雀魂这类大厅和游戏玩法、战斗分离清晰的游戏。在微服务架构下，可以进一步细分场景、战斗、房间逻辑等节点。

对于已有成型方案的项目，无需再做过多调整。

对于为什么在之前的项目中不使用C# / .NET Core，以及全栈开发的需要和全栈开发者的要求，我进行了复盘。在项目中，我将人员分为专业后端工程师和CURD员，后者负责基本接口编写。在资源有限的情况下，我们通过Unity客户端承担一部分全栈工作，即负责UI系统的接口编写，如卡牌数据、抽卡、结算等，但不负责过于复杂的模块，如账号系统、登录注册、游戏玩法等，这些复杂模块交由专业后端处理。

全栈开发者的需求是80%前端技术和20%后端技术的组合，以提高整体效率。引入GraphQL或APIJson等技术框架，减少接口数量，配合DevOps流程来保证接口稳定性。

为什么开始考虑C#？一方面，对于Unity前端的开发者来说，C#是一个重要选择，因为它可以减少语言切换的障碍。另一方面，基于C#构建分布式架构变得更容易，这要感谢云原生的发展。在之前项目中，我们最初使用SpringCloud，后来发现基于K8s本身构建分布式架构更为合适。云原生为后端生态系统带来了共享优势，降低了对单一语言的依赖。

如何保证接口稳定性？在微服务架构中，确保全栈开发者编写的接口服务稳定即可。在Serverless架构下，每个接口稳定是关键。测试覆盖率需要达到90%以上，每次修复错误时提交单元测试，进行代码审查、数据库结构审查、定期的CI测试和压测等。

综上所述，C#做游戏全栈开发似乎可行。基本架构可以采用k8s + Dapr + .NET Core + DevOps + APIJson / GraphQL（也可以选择任何语言）。

对于架构的理解，微服务不仅是一种设计方法，更是一种包含协作、沟通、团队管理和标准规范的架构。其核心特征包括围绕业务能力构建、分散治理、产品化思维、数据去中心化、容错性设计、演进式设计和基础设施自动化等。在新的项目技术栈上，我将采用C#作为业务接口编程语言，并推动全栈执行。后续会分享更多详细信息。

最后，我拥抱大云原生时代。

标签 c能否做游戏全栈