有个疑问一直想不太明白，java api 服务是提高单虚拟的 cpu 核心数和内存大小，调高最大线程数。还是干脆用 tomcat 的默认配置，部署多台机器，用 nginx 负载均衡。感觉这个没有绝对的哪个好，只是在单个机器配置和负载的个数上。

目前就是两台机器在负载，考虑服务冗余的话也会至少两台。

目前没有部署，无法查看瓶颈，现有系统在平稳运行且未达到瓶颈，现要部署一套峰值并发是当前系统的 2.5 倍，预估需要机器的配置，为了保险起见现有部分配置提升至当前的 1-4 倍，均值在 2.5 倍左右，主数据库性能已提升四倍，由于项目原因无法部署集群，考虑后期维护问题，综合 v 友建议，保留两台机器的个数 cpu 提升 2.5 倍，内存翻倍，部署两个实例。后期若出现性能问题，优先调整 tomcat 参数，尝试单进程多线程方式解决，若效果不明显，则单机部署两个实例，增加负载个数。

先调查好瓶颈在哪

正常来说直接集群部署，简单暴力。

单实例调优各方面都需要付出时间精力，效果也不一定显著，可能调优测试完发现提升很小，白瞎。

调优一般在实例数量较多的情况下可以考虑，因为实例越多效益提升越大。

如果就一两台实例，就算提升 50%又有何意义？多加一个实例的钱付不起吗😂

意义可大了。不是自己的钱不心疼

对的，如果瓶颈在单体数据库，加再多机器也白搭。

集群个屁, 累不累啊, 单机部署多爽, 并发不够加配置, 4 路 4CPU 服务器单颗 128 核总共 512 核 128T 内存, 还不够你高并发的, 你做的难道是微信消息服务?

单纯从操作系统的角度想，线程调度比进程调度代价低，而且内存的利用率也高一些

建议集群，不仅是提高并发，还能确保服务的可用

先做 profile 看看瓶颈在哪
盲猜在数据库

总算力不是一样？

建议是采用集群部署，用多进程的方式，既能够满足生产环境中高可用的需求，也可以满足并发；而且根据你的需求，要达到的效果是满足峰值并发的情况，对付峰值并发有效的手段就是在短时间内自动通过伸缩机制进行更多实例的部署；如果不是峰值而是持续的高并发，那时候再进行应用内优化也不晚。

从概念上说虚拟机本身也有可能发生故障，单纯提升线程数会让虚拟机本身成为系统的单点故障隐患。所以还是用集群吧

多进程优先（我是基于将来需要更大负载时候直接使用多机器负载均衡的场景角度给出的建议）

数据落库吗？数据库性能也是一方面。

我们一个 pod 给的内存都挺小的

128T 内存的机子真没见到过.是什么神仙配置?

我面试的时候有个哥们说他们公司 java 服务器就是 128T 内存，我估计一次 fullgc 能 stw 起码半小时吧……

128TB 怕不是大型机了吧，128G 一根的 ECC 内存，都要插 1024 根，这特么 4 路的 CPU 通道也不够啊。

有可能是服务器虚拟化

可以集群那就集群部署
还要考虑日后升级需要

无脑上 K8S 就好了，HPA 弹性扩展，一键部署，滚动更新，A/B test ，金丝雀部署，想怎么玩就怎么玩。

你们设置多少内存？

这不是一个问题吧，你单机性能再好，能不用 Nginx 这类负载均衡？除非是很小的的服务

兄弟你知道太多了 -_-＃

单点故障不及时处理容易雪崩，上集群吧