@salmon5 #15 ARMS 开箱即用，自己用开 ECS+SkyWalking ？这 CTO 相当外行

@stardustree #13 ，PaaS 云上基于 IaaS 自建 ，那肯定是开倒车，比如以阿里云为例 ACK 、SLS 、云监控等等，这些搞自建？那是相当外行。（你自己可怜的人力能有云厂商做的好？随便搞个 ELK ，能和 SLS 比？）
”SaaS 直接用专门的厂商"？屁大的需求和功能，来一次采购招投标？

@stardustree #13 ，PaaS 云上基于 IaaS ，那肯定是开倒车，比如以阿里云为例 ACK 、SLS 、云监控等等，这些搞自建？那是相当外行。
”SaaS 直接用专门的厂商"？屁大的需求和功能，来一次采购招投标？

你怎么知道没人用？
”例如只做虚拟机、云盘、负载均衡、虚拟网络、对象存储、云数据库这些“，这些还叫云吗？
云不止 IaaS ，还有 PaaS 、SaaS 。

另外已知的基于 RHEL8 的 KVM 、Vmware 的 ESXI 6.7 guest 机器默认还是 BIOS ，如果安装最新 Ubuntu ，强制最少 2 个分区（ bios_grub 分区和/跟分区）。

随着 BIOS+MBR 1 个分区的逐步淘汰，以后 BIOS/UEFI+GPT 至少 3 分区(bios_grub,/boot/efi,/)是主流，再以后 UEFI+GPT 至少 2 分区(/boot/efi,/)是主流。

“ From Ubuntu 20.04 LTS onwards, the Ubuntu Server Live Installer is the preferred installation media for Ubuntu Server installs, and the legacy installer based on debian-installer is deprecated. To ease this transition, media was published for the legacy installer as part of the 20.04 and 20.04.1 releases, but we are not providing legacy images for further point releases. There is no guarantee that these outdated legacy images will continue to work. ”

现在云厂商都是至少 3 个分区，bios_grub 分区、/boot/efi 和/根分区，这样既兼容 BIOS 又兼容 UEFI 。

https://cdimage.ubuntu.com/ubuntu-legacy-server/releases/20.04/release/
Ubuntu 从 20.04 开始废弃了基于“debian-installer”的安装方式：
BIOS：BIOS+GPT 方式，最少 2 个分区（ bios_grub 分区和/跟分区）
UEFI：UEFI+GPT 格式，最少 2 个分区（/boot/efi 和/根分区）
强制了 GPT 分区，只能最少 2 个分区，安装的时候无法修改成 MBR 分区。

@whileFalse 我想了下，还是直接创建新线程合理，核心线程都在用了，就别到队列等核心线程了，现在云计算扩容很快。核心线程不够用，就直接创建新线程。最终不够就横向+纵向扩容。
如果扔到队列，等核心线程，结果就是”服务慢、服务器空闲“。

@LiaoMatt #35 这个貌似 Java 的又合理了。

合理：核心线程---->不够了创建新线程--->队列（ Tomcat ）
不合理：核心线程---->队列满了--->创建新线程（ Java ）

@muyiluop 混合部署省钱，64C256G/128G 可以部署十几、几十个微服务，不是每一个服务都每一刻这么大并发，需要的时候就申请，很多服务 tps 个位数，初始线程不需要那么多。（但是你核心线程不够了，可以马上申请创建，而不是弄个队列，自废武功）

“先判断是否达到最大线程数在判断任务队列是否满了”，我推测 因为这个逻辑是 199 几年或者 200 几年弄的，那时候云计算或者硬件资源都相当有限，所有这个逻辑有点落后了。

@salmon5 #17 ，假如一台 CPU 64C 混部的机器，CPU 只用了 20C ，还有 44C ；
1 个 Java 核心线程是 10 ，放着 44C 不用，不够了居然放到了队列，这种线程池逻辑明显落后了。

tomcat 的线程池逻辑就是合理的：核心线程不够了，直接申请新创建线程。而不是先扔到队列。

这个逻辑有点落后了，10-20 年前的思维，现在已经不是物理机时代（资源需要几天才能扩容到位：采购新物理服务器、CPU 、内存）。

这个逻辑其实不合理。计算资源可以扩容解决。

1 ，云控制台先扩容系统盘（云厂商底层的 kvm 会在线扩容对应系统盘的块设备），一般最大不大于 2T 。
2 ，系统盘：
ext4：
growpart /dev/vda 1
resize2fs /dev/vda1

xfs：
growpart /dev/vda 1
xfs_growfs /dev/vda1
如果内核<3.6 ，就重启系统生效；如果内核>=3.6 就在线生效，无需重启。