6. 总结
我们将这一大章介绍的网络、计算、数据三大块内容结合在一起，就成了网络游戏的服务器架构。如果我们再加上图像动画的渲染部分，这部分通常由客户端引擎代劳，那就是完整的游戏架构。
回首再看，作为一个游戏开发者，我试图站在一个旁观者的视角来讲述游戏技术的变迁，但其实有不少内容还是“站了队”，讲了许多自己的见解和判断。在知晓并尊重其他技术实现方式的同时，我有着明确的技术倾向或者说是选择，正是这种选择促使我去淌出一条微服务架构的路。
幸运的是，我不是唯一坚持这条路的人。介绍微服务的那一篇曾讲过，最早萌生这个想法是受到日本多款游戏大作架构的启发，后来在上海自己参与的游戏项目中，也有接触到微服务架构。他们在这条路上比我走的更早，也有着更成熟的案例，但公开出来的经验见解极少，更是没有成熟的程序框架。我只知道这条路一定走的通，但却不知道为何去走？如何去走？如何让一群普通的程序员，开发出完善的微服务游戏服务器，稳定又要高效？
老牌游戏大厂也有过尝试。巨人网络曾在 Github 上放过一个 Golang 的微服务框架 go-service，现在再去访问已经 404。网易放在 Github 上的 pomelo，上一次维护是在三年多以前，纯 js 的框架，只适合运用在一些用量不大、对性能要求不严格的游戏上。TopFreeGames 放在 Github 上的 pitaya，据说是参考了网易的 pomelo 而构建的一个 Golang 微服务框架，至今还在维护，但文档支持方面做的很差，案例也很少，所以不温不火。大厂一定有着稳定高效的后端框架，使用了很多年，微服务对他们还剩多大的吸引力呢？
开源项目也有过尝试。mqant 是让我印象最深刻的游戏微服务框架，可以说我现在实现的框架一部分借鉴了 mqant 的思想。这样的框架有热度，也有一定的案例做支撑，但是还不够完善。或者说是，对于底层开发者而言，使用门槛还是高了些。
（图片来源于 mqant 文档）
我想做一套微服务框架，降低使用者的门槛，它能像开发单体应用那样开发，同时又支持分布式的部署。它的架构应该是这样：
从第三章开始，我会详细阐述如何从零开始，一步步把整个框架搭建起来。最后，再分享几个成熟的游戏架构例子：
某国内传统游戏架构
某日本著名微服务游戏架构
下一篇开始第二章《微服务的价值》，重点解决”为什么”的问题，也回答部分质疑“游戏服务器不能应用微服务”的经典问题。
第二章将按下述顺序进行展开
1. 微服务真的慢吗
2. 解耦
3. 剥离有状态
4. 敏捷开发
5. 运维管理
6. 完美热更
7. 总结
