知乎上有一个问题：“游戏公司为什么不用微服务”。我的观点是微服务不是一个技术问题，而是一个管理问题。
我大学的专业是软件工程，但说实话上完大学也没有吃透软件工程。一方面原因是学生没做过大型商业项目，对大项目里的问题没有体会。另一方面老师基本也是对着软件工程的教材备课，然后讲解给我们，他本人也未必做过大型项目，多数是读到博士然后直接去高校教书。
现在我已经工作了超过十年，参与开发了十几个项目，并作为负责人领导了七个大大小小的项目。然后体会是大项目确实开发效率低，原因有两个：
（1）代码复杂度
一般项目开始时只有几个人，甚至只有一个人。这时代码的复杂度并不高，每个人基本都能理解整个代码库。随时进度的推进会加入越来越多的开发者，这时一个人想理解整个代码库已是不可能。这个问题不能归咎于程序员的技术水平低和管理不善，根本原因是代码规模的增长必然使得代码和团队变的笨重。
（2）团队原因
随着团队成员的增加，交流成本开始指数式上升。如果整个团队有 n 个程序员，为了了解其他人的工作，你需要跟 n - 1 个人逐一交流（口头或者书面），那么整个团队的交流路径总数就是 n * (n - 1) / 2。这意味着，交流成本的增长速度是人员增长速度的平方，团队人数越多，协同的难度就越大。
大团队保持扁平化管理，也会越来越困难，必须拆分成较小的群体。这时，对等的交流会被自上而下的交流所取代。团队成员会感觉，自己从平等的利益相关者，转变为普通的工作人员，工作动机受到了影响，责任感和主人翁意识都会淡漠。
解决方法
（1）代码解耦
代码解耦可以分成两个方向，我称它纵横分治：
纵向分治：整个软件分成若干层，越底层处理的问题越接近计算机，越上层处理的问题越接近用户。上层只能访问下层，严禁下层访问上层。
横向分治：每一层内也分成若干模块，模块对外只提供必要的公开接口，严禁一个模块访问另一个模块的私有接口。这在C++/C#/Java这类语言中用private很容易做到，脚本语言的话只能靠代码规范文档来指导。
（2）团队解耦
要把大团队成员分成若干的小团队，每个小团队只做一个项目的子集，相当于把大项目拆成多个小项目。那这些小项目之间如何通信呢？如果是单进程软件项目，例如Photoshop这类软件，还是通过提供API接口的形式供外部调用。如果是互联网项目，每个小项目都是一个或多个独立的进程，那么最好的方式是通过网络以某个标准协议进行通讯，例如REST。这就是微服务！
所以我认为微服务是一个解决团队耦合的比较理想的方案，团队解耦了那么代码也就解耦了，甚至代码都是物理级别的解耦，每个小团队都在各自的GIT仓库里工作。
游戏公司是否用微服务跟团队规模有关，如果是一只不超过100人的团队，没必要把团队分太细，而一般游戏开发团队大多几十人，上百人的已经是超大团队了，但跟互联网动辄几千人的团队规模还是没法比的。另外互联网应用主要逻辑都在服务端，比较容易微服务化，但游戏研发团队有一大半都在客户端，很难用上微服务。
参考
(1) http://www.ruanyifeng.com/blog/2021/05/scaling-problem.html