8核16G是云服务器选购中的热门档位，价格适中，但用来跑微服务集群往往会遇到隐藏瓶颈。我们先来看一套典型部署拓扑：网关、认证服务、订单服务、商品服务四个应用各自独立容器，数据层使用MySQL 8和Redis 7。为了避免单点，每个无状态服务至少两个副本，这样总共会启动十个左右的容器。对于8核CPU和16GB内存的机器来说，这已经不是宽松环境，而是需要精细分配资源的场景。
测试采用Docker Compose编排，宿主机操作系统为Ubuntu 22.04，Docker版本为24.0，JVM统一使用Eclipse Temurin 17。压测工具选择wrk，配合Prometheus和cAdvisor采集容器级指标。压测场景分为只读接口和混合读写接口，每个场景持续60秒，预热10秒。
一、测试环境与集群部署细节
这台8核16G服务器上实际跑了十个容器，但CPU和内存限制并不均等。网关和两个订单服务实例是流量入口，给每个服务分配了512MB到768MB的堆内存，认证服务因为涉及JWT生成与校验，给到512MB，商品服务主要是缓存读取，给到384MB。MySQL容器限制为2核4G，Redis限制为1核2G，其余资源留给操作系统和Docker守护进程。这样的分配看似合理，但实际压测中还是出现内存紧张。
JVM参数没有直接采用默认值，而是针对容器环境做了基础限制。下面这段启动命令是网关服务的常规配置，G1垃圾回收器配合200毫秒的目标停顿，在8核环境下表现比较稳定：
java -Xms512m -Xmx512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar gateway.jar
数据库连接池是另一个容易忽略的点。订单服务默认的HikariCP最大连接数设置成了20，四个微服务加起来就是80条连接，加上压测工具和后台探活，MySQL的连接数峰值一度超过120。虽然MySQL本身能承受，但每个连接都会占用内存和线程资源，在16G总量下进一步压缩了应用可用内存。
压测脚本使用wrk直接打网关端口，模拟前端请求经过网关路由到订单服务的完整链路。只读接口返回100条订单列表，混合读写接口会向数据库插入一条订单再返回。两个接口的调用比例为8比2，更贴近真实业务。下面这条是只读接口的压测命令：
wrk -t12 -c400 -d60s --latency http://127.0.0.1:8080/order/list
二、压测结果：吞吐量、延迟与资源瓶颈
先看一组直观数据。在只读接口场景下，两个订单服务实例时，网关层测得QPS稳定在3200左右，P99延迟为180毫秒；把订单服务副本增加到六个后，QPS反而下降到1900，P99延迟飙到420毫秒。混合读写场景的差距更明显，两个实例时QPS为850，六个实例时只有490。这说明在8核CPU上，盲目增加实例数并不一定能提升吞吐量，反而会因为上下文切换和服务间通信开销拉低整体性能。
把结果整理成表格更清楚：
| 订单服务实例数 | 只读QPS | 只读P99延迟 | 混合读写QPS | 平均CPU占用 |
|---|---|---|---|---|
| 2 | 3200 | 180ms | 850 | 62% |
| 4 | 2600 | 260ms | 680 | 78% |
| 6 | 1900 | 420ms | 490 | 90% |
从资源监控来看，六实例时CPU平均占用达到90%，但四个核心处于频繁切换状态，系统态CPU时间占比从两实例时的12%上升到28%。这说明多实例的线程数量超出物理核数后，大量时间花在调度和锁竞争上，并没有真正处理业务请求。
内存方面，两个实例时宿主机总内存占用约为11GB，其中MySQL缓存和JVM堆占了主要部分。六个实例后总内存达到14.5GB，剩余可用内存不足1GB，Linux开始频繁回收页缓存，MySQL的Buffer Pool命中率从99.7%下降到91.3%。这个变化直接导致混合读写接口里的大量查询走磁盘，响应时间翻倍。
另一个隐藏瓶颈出现在数据库连接池。六个订单服务实例每个都保持20条连接，连接池空闲连接过多，但真正活跃的只有不到30条。MySQL的Threads_connected持续在100以上，但Threads_running只有个位数。连接数高并不会直接提升吞吐，反而增加了认证和网络开销。
三、调优策略与适用场景判断
针对这些问题，我们做了三轮调整。第一轮把订单服务实例数回退到四个，并把每个实例的HikariCP最大连接数从20降到8，同时给网关加了请求限流。调整后，只读接口QPS回升到2800，P99延迟降到220毫秒，混合读写QPS恢复到720。第二轮进一步把订单服务堆内存从768MB压缩到512MB，使用G1的InitiatingHeapOccupancyPercent参数提前触发并发标记，Full GC次数从每10分钟一次降到每小时一次，内存波动明显变小。
Java 17环境还对比了ZGC和G1。ZGC在8核下暂停时间确实更低，P99延迟能再降15毫秒左右，但吞吐量略有下降，CPU占用比G1高8%左右。对于延迟敏感型接口，ZGC值得尝试；如果业务以吞吐优先，G1仍然是更稳妥的选择。需要强调的是，16G总内存下，JVM堆不能设置得过大，否则留给操作系统文件缓存和MySQL的空间会被挤压，反而拖慢整体响应。
综合来看，8核16G云服务器跑包含四到五个微服务的小型集群是可行的，但只适合低到中等流量场景，例如日请求量在300万以下、峰值QPS不超过1500的内部系统或初创业务。如果业务中有大量CPU密集计算、频繁的全文搜索或高并发写库操作，这个配置很快就会触顶。建议把无状态服务控制在四个以内，每个服务堆内存不超过768MB，数据库和缓存尽量使用云厂商托管服务，把宿主机资源集中给应用层。
对于研发团队来说，这台机器作为持续集成、预发环境或性能基准测试机比直接扛生产流量更合适。如果一定要上生产，至少要做全链路压测并留出30%的资源余量，同时配置好自动伸缩，避免流量突增时出现雪崩。
