网络游戏架构的前世今生——总结

上文：网络游戏架构的前世今生——数据架构https://blog.csdn.net/finishy/article/details/129334718

6. 总结

我们将这一大章介绍的网络、计算、数据三大块内容结合在一起，就成了网络游戏的服务器架构。如果我们再加上图像动画的渲染部分，这部分通常由客户端引擎代劳，那就是完整的游戏架构。

回首再看，作为一个游戏开发者，我试图站在一个旁观者的视角来讲述游戏技术的变迁，但其实有不少内容还是“站了队”，讲了许多自己的见解和判断。在知晓并尊重其他技术实现方式的同时，我有着明确的技术倾向或者说是选择，正是这种选择促使我去淌出一条微服务架构的路。

幸运的是，我不是唯一坚持这条路的人。介绍微服务的那一篇曾讲过，最早萌生这个想法是受到日本多款游戏大作架构的启发，后来在上海自己参与的游戏项目中，也有接触到微服务架构。他们在这条路上比我走的更早，也有着更成熟的案例，但公开出来的经验见解极少，更是没有成熟的程序框架。我只知道这条路一定走的通，但却不知道为何去走？如何去走？如何让一群普通的程序员，开发出完善的微服务游戏服务器，稳定又要高效？

老牌游戏大厂也有过尝试。巨人网络曾在 Github 上放过一个 Golang 的微服务框架 go-service，现在再去访问已经 404。网易放在 Github 上的 pomelo，上一次维护是在三年多以前，纯 js 的框架，只适合运用在一些用量不大、对性能要求不严格的游戏上。TopFreeGames 放在 Github 上的 pitaya，据说是参考了网易的 pomelo 而构建的一个 Golang 微服务框架，至今还在维护，但文档支持方面做的很差，案例也很少，所以不温不火。大厂一定有着稳定高效的后端框架，使用了很多年，微服务对他们还剩多大的吸引力呢？

开源项目也有过尝试。mqant 是让我印象最深刻的游戏微服务框架，可以说我现在实现的框架一部分借鉴了 mqant 的思想。这样的框架有热度，也有一定的案例做支撑，但是还不够完善。或者说是，对于底层开发者而言，使用门槛还是高了些。

 

（图片来源于 mqant 文档）

我想做一套微服务框架，降低使用者的门槛，它能像开发单体应用那样开发，同时又支持分布式的部署。它的架构应该是这样：

从第三章开始，我会详细阐述如何从零开始，一步步把整个框架搭建起来。最后，再分享几个成熟的游戏架构例子：

某国内传统游戏架构

 某日本著名微服务游戏架构

下一篇开始第二章《微服务的价值》，重点解决”为什么”的问题，也回答部分质疑“游戏服务器不能应用微服务”的经典问题。

第二章将按下述顺序进行展开
1. 微服务真的慢吗
2. 解耦
3. 剥离有状态
4. 敏捷开发
5. 运维管理
6. 完美热更
7. 总结