为什么很多项目并发上来最终推荐的都是堆机器？

2022年5月7日14:50:29

 在很多的技术群，探讨系统框架升级或者增加系统提升并发的时候，往往讨论之后，结果基本是推荐堆机器为主，优化系统，优化代码为辅，为什么呢？

 

通常问这个问题的人，通常对系统架构是没什么系统的理解，很多人都是只处于代码层面看待系统，但是随着业务繁荣，并发增长之后，就需要去提前预先设计系统的迭代，或者是自己想去了解高并发系统的设计，或者干脆就是老板派下来的任务

回答也通常是每个人都不一样，比如

 

1，单语言开发者，多语言开发者，系统架构师，每个层面的开发者对系统设计都是不一样的

单语言开发者，通常使用的组件较少，比如php 习惯使用rabbmitmq redis mysql  elasticsearch等体系，数据分析使用clickhouse等，java习惯RocketMQ，mysql ，spring cloud alibaba，redis，elasticsearch数据分析使用hadoop等

c#使用的又是一套东西，lua更是依赖nginx做高性能项目，c c++的话基本全部是自己造轮子做高性能，所以这种系统设计是比较片面的，而且每个开发者的技能树也是不一样的，很少非常全面，因为没必要全部都会

 

2，有些建议更换技术栈

说动不动就更换技术栈更是荒唐，什么语言性能比什么语言强多少，其实在链接数据库的处理数据的情况下，性能差别不是特别大，因为性能瓶颈在数据库，动不动就建议更换技术栈的多数是因为他只会这个一个技术栈而且算是比较熟练

换技术栈的成本很高，如果重写完，发现性能提升只有一点，又大大增加了团队的开发成本，如果老板比较信任你还行，如果信任度一般，这样的话你很可能完蛋

 

3，有些建议优化系统组件，优化代码和数据库查询

这样的建议是比较中肯的，但是通常时间成本，和对技术要求成本也是很高的，首先优化系统的人必须是对系统业务非常了解的人，开发技术也得非常好，需要做好数据库，代码规范，代码结构设计都预留很多东西，这样花了很多人力和时间

去优化系统是很好的，可以减少大量的技术债，但是对其他开发者也需要去跟上做系统优化的人的代码和业务水平，对代码和对系统的认证较高，整体人力，时间成本爆表，而且可能造成系统优化完之后，一段时间业务不稳定，因为修改的东西太多，需要时间来

稳定优化系统，通常这种做法是需要重构的时候才会花这样的代价

 

4，有的建议找技术顾问，技术总监或者架构师去处理

这个是比较靠谱的建议，什么样的水平处理什么样的问题，水平差距较大去处理架构层级的问题，很可能会背锅，特别是技术总监或者技术经理水平较差的情况下，他们不懂，你也不懂，互相忽悠，结果项目出大问题，其实花点钱找个技术顾问是很多

外企和国企的做法，这样成本也不高，还能增长全部技术人员的系统架构认知，还能指导代码层面的问题，一些难点痛点，高手简单指点一下就容易多，好处其实挺多，也不需要觉得丢脸，因为技术是需要一步一个脚印走下来的，学习别人的技术也是很好的

 

5，堆机器

只需要简单做个nginx反向代理，多个应用，就可以极大增加整体性能，有些公司为了，临时应对大流量，直接重新购买高性能的云服务器，直接从硬件源头解决并发问题，还不影响业务运行，也是最好的方案

其实很多公司都小看了人力成本和时间成本，对公司业务的影响，觉得人都招来了，当然是人来解决更好了，为什么要多花些钱来搞这些东西，其实不然业务才是公司的根本，技术，运营都是服务业务的发展的，很多东西因小失大，错过时间机遇

 

我个人的建议是，首先看你的团队结构是怎么样的，如果你们是多语言开发，那么最好需要一个懂多语言的人来协商问题，寻找适合各个团队的方案，不要唯一独行，比如我们只会用这个，应该是大家商议的结果，不然互相对接的时候满是问题和坑

很容易造成团队协作出问题，如果你们是单语言开发，其实就比较简单了，选择成本低，改造简单的方案，或者在底层处理好，绝大多数人只需要关注写逻辑代码即可，避免上手难度大，写出一些奇奇怪怪的bug

尊重团队习惯也是很重要的事情，代码风格尽量统一，不然一个人一个写法，最后代码乱七八糟的不好维护，当然有些故意写成屎山，只能自己维护的，这样的人也有，通常也就能忽悠一下小公司的领导