现如今为什么大多数游戏服务端还是用C++来写？

其实现在游戏服务端基本上都是多语言组合开发的，C++已经不再是唯一选择，Java、 Python 、Golang、Erlang、C#以及各种脚本语言都会涉及。但是为什么现如今大多数游戏服务端还是用C++来写呢？我认为一个项目在做技术选型时把C++作为游戏服务端的主要开发语言主要基于以下原因：

十多年前，技术栈，包含编程语言的选择还不是很多。C++是当时看来少数，被证明稳定，可靠，高性能，具备丰富功能的高级语言。所以理所当然被选择作为开发主力。基于此，进程框架，诸如线程模型，定时器，容器等；IPC，比如socket，共享内存，并由共享内存进一步衍生出的数据恢复技术等都蓬勃发展。而且大厂之前都有封闭的思想，这和现在开源流行完全不同。生怕别人知道自己的技术优势，也非常不信任社区产品的质量。结果就是——造轮子，各种造。从数据库，到序列化工具，从xml解析器到负载均衡组件，凡是游戏开发碰到的，全部自己造，而且都拿C++造。

游戏存在高性能需求场景目前无可替代。别的不说，一个简单的帧同步，每秒30/60帧，多人数据同步。现在我们用C++也只能支持单机小几千，大概就是每秒十多万个包吧。所以没有很强的信心换成别的语言。因为成本已经是这样了，为何要在机器成本没法明显优化的情况下，再去增加技术风险和迁移成本？在一些卡牌类型游戏中，后端也存在大量的数值密集型计算。虽然在架构上可以分布式，可以扩展，但降低机器成本同样非常重要。特别是对在线规模很大的游戏而言尤其重要，因为即使能优化10%，背后的机器数量恐怕也不是一个可以忽略的数目。

但总体上，随着技术的发展，百花齐放应该是大趋势。选择合适的语言，在合适的场景，做合适的事情，这是大家逐渐认同的。而且很多尝试都在解耦，从库依赖变成服务间通信，这样更有助于不同语言共生。现在基本形成，高性能C/C++，灵活逻辑脚本化，运维工具Python，大数据用spark，日志流用elk，旁路检索或查询用jvm系的局面。对开发人员而言，语言的要求慢慢从一招鲜变成了一专多能。唯一不变的是，业务需求永远在变，解决问题的技术就是好的技术。

最后附一张游戏开发学习线路图，希望对大家的学习有帮助~