从项目立项之初，到现在也有三个月了，服务器架构经过几个推到重来的过程到现在基本确立Spring Cloud作为基础微服务的架构也有一番波折。仅以此文记录这一路的艰辛。
0x01 单机滚新服架构1.0
项目程序之前都是MMORPG出身，策划的需求很稳定且单一，一般就是充值活动、能力坑，偶尔来一两个玩法类活动。这类需求的特征很明显，逻辑复杂，但是并没有跨服需求，传统的单机数据库事务可以很好满足这类需求。在新项目立项之初，大家都带着做MMORPG单机滚新服版2.0的心情而来。
所以有人提出了下面这种架构。
优点：
- 公司老程序员学习成本几乎为0。
- 由于都是项目内部开发，所以线上排错会比较容易。
- 因为对这套架构的熟悉，所以前期的开发效率会很高。
缺点：
- 等到跨服需求开始铺量，开发效率会降低。
- 由于增加了数据中转服，我们一切跨服操作需要手动编写RPC调用，对于网络的超时重传处理增加了开发的复杂度。
- 数据中转服在老的项目是一个使用频率较低的组件，但是在新项目的需求下，却是一个高频的组件，如果只有一个数据中转服，整个架构会存在单点问题。
- 数据中转服基本上是”硬编码”在各个逻辑服内，如果数据中转服进行迁移，需要修改逻辑服内的配置或代码。
0x02 基于消息队列的架构2.0
为了解决单点问题、逻辑服和数据中转服的强耦合问题，我们尝试将MQ的Broker作为数据中转服，因为MQ Broker可以配置集群和副本数据，所以保证了数据中转服的高可用。并且Broker还可以兼具服务中心的作用，可以对其他服务的解耦。
由于业务需求增加了C++实现的战斗服，这个服务器也需要加入到我们的架构中，所以MQ的多语言客户端成为我们使用MQ的重要原因。
下文对各种服务器统一称为服务。
优点：
- MQ Broker可以作为简易版服务中心使用。
- 服务之间可以解耦。
- MQ Broker一般可以支持Consumer端的负载均衡。
- 如果MQ有异构语言的客户端，那这种架构就可以支持异构语言的RPC。
缺点
- 大多数的消息队列都是会将消息持久化到磁盘中，然而在游戏数据中转服的业务场景下，消息持久化这个功能反而会带来一些弊端。
- 消息队列中的Producer/Consumer异常下线，其他的Producer/Consumer是无法感知的，所以消息队列的Broker并不具备服务中心的所有功能。
- 部分MQ并不支持EOS语义，消息可被重复投递/消费。
- 消息队列是异步通信，消息可能会被积压很久才被Consumer拉取消费，RPC效率很低。
0x03 基于Spring Cloud的微服务架构3.0
为了解决消息队列带来的这些问题，在对比dubbo和Spring Cloud之后，我们选择了Spring Cloud作为新的服务器架构。
优点：
- 可以使用Spring提供的一些功能，使用Spring Boot简化一些配置。
- 完善的服务中心，具备服务发现、服务注册、服务下线等功能。
- 可以使用Ribbon做客户端的负载均衡。
- Hystrix可以作为熔断器来使用，可以对线上有问题的服务进行限流、降级。
- Feign客户端封装了RPC调用，勿需对RPC进行额外的编码。
- 可以使用Zipkin来做APM。
- 可以使用一些开源的测试工具，方便测试。
- 较多的运维监控，Spring Boot Actuator、Hystrix Dashboard、Hystrix Turbine。
缺点：
- 对异构语言的支持并不完善，虽然有sidecar，但是整套架构基于Restful的接口，所以对Http支持不够完善的语言仍然是没办法接入的。
- 应用必须运行在Spring Boot之中，非Web项目在接入到Spring Cloud架构的时候要考虑对Web的支持，相对于istio，Spring Cloud还是逊色了一点。
0x04 完整服务器架构(2017-11-07)
0x05 完整服务器架构(2018-01-29)
- 把注册中心替换为consul，支持异构语言的注册。
- 战斗服fgs接入微软的rest sdk，与room service之间的RPC采用http。
- 上将匹配队列拆分为多个服务。
- 增加组队服务。
- 增加好友服务。