软件项目发展的历程

最近再次读到阮一峰的文章，讨论的是软件工程的最大难题，链接如下：
https://www.ruanyifeng.com/blog/2021/05/scaling-problem.html
看到这个，有一些感触，工作，未满一年，项目关于虚拟现实技术，从最初入职的十多个人，加上测试，一共有三十几号人。从最开始的十多个人一起开晨会、周会，到后面分成3个小组，每个小组十余号人，周二到周四，每个小组各自召开晨会，周一再合在一起召开周会。我在想，这大概就是团队解耦。
人员的增加，项目的扩充，势必会导致团队的平均生产力降低。而软件在不断地向前扩充，用户并发数在不断地增加，项目组最开始的服务器集群，已经不能简单地满足需要了。最近，项目组正在开始由集群向微服务架构进行改造，这需要对后端代码大动干戈，究竟投入产出比是多少，不知道架构师是否考虑过此问题，后端代码重构后，对整个系统是否有影响？测试工程师是否需要重新对其进行系统测试？不得而知。
系统架构的重构，我想确实是有必要的，最近的一次性能测试过程中，发现了功能性问题，经过讨论，是需要对产生功能性问题的模块进行重构的，至于升级成微服务架构后，是否对性能有所提升，亟待验证。
微服务的理解：
1.微服务，其中的“微”就体现了该服务的精髓，微就是小的意思，将之前的业务（服务）拆分成微服务（小服务），微服务就像搭积木，每一块积木就是一个独立的小系统；
2.项目未采用微服务架构时，部署时基本上会影响所有，当项目采用微服务架构时，若某个服务存在问题，单独部署该服务，大概率不会影响到其他服务的正常使用；
3.如果需要提高某个服务的性能，可以增加服务器数量
4.当然了，微服务也其缺点：增加运维成本
微服务架构解释得比较好的链接地址：
https://blog.csdn.net/qq_14826197/article/details/87976385