网络游戏架构的前世今生——微服务

上文：网络游戏架构的前世今生——热更

3.7 微服务

记得两年前，在知乎上看到一则回答，详细阐述了网络游戏不能应用微服务的原因。当时的我正好在 aws 研究微服务在游戏行业的应用，看到了不少日本游戏制作商应用微服务的案例，产生了想在知乎上回复的想法。但我知道网络上重拳出击没有任何意义，语言是苍白的，这些公司案例大部分都不能直接对外讲。而且最关键的一点是，我并不清楚内部的实现细节，在上海给数家游戏公司去讲游戏微服务时，我的内心是虚的，究竟怎么落地生产？工程上如何执行？那时候的我也不知道如何去实现游戏微服务。我只知道很多游戏公司用容易来测试、部署游戏后端，但容器并不是微服务——容器只是技术手段，微服务是理念架构。

是什么（what）、为什么（why）、怎么做（how），是我思考一个问题的基础逻辑，思考游戏微服务也是这个逻辑。在本章中我们重点解决是什么和为什么的问题，而怎么做是整个专栏的话题。

首先，微服务是什么？我所理解的微服务是，将单一应用程序划分成一组小的服务，服务满足低耦合、高内聚的特性。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。

关于微服务的定义还有很多阐述，例如有说“应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。”在我看来，这些表述是表象，或者说是扩展后的微服务定义。但实则，微服务是对单体应用程序的一种拆分方式，我们上文讲的网关服，也是从逻辑服中拆分的一种方式。这种拆分方式唯一需要满足的特点是——低耦合、高内聚。