数据库独立部署

在使用 Nginx 承载全部静态资源以后，如果你的低配云主机还是扛不住流量，该怎么办呢？这个时候就需要引入第二台云主机了：专门用来跑数据库。

将后端代码和数据库部署在同一台机器上是“灾难架构”

出于节省成本的需要，把后端代码和数据库部署在同一台机器上确实是一个无奈的选择。但是，我们要清楚的是，这是一种错误的架构设计方案，它只适合超低流量的系统。

一旦系统承受的压力稍大，便会面临“债股双杀”的局面：

1. CPU 被耗尽导致 MySQL 响应变慢；
2. 应用代码需更长时间等待，虽不额外消耗 CPU 资源，却占用大量内存；
3. 系统内存被占用导致 InnoDB 缓存被系统回收，进一步降低了 MySQL 的运行速度；
4. 最终形成“内卷”和“踩踏”，系统性能急剧下降，服务可能完全崩溃。

MySQL 单独部署时性能非常出色

只要你将 MySQL 与后端代码的 CPU 进行隔离，数据库的极限性能就能达到够用的水平。根据笔者的实测结果，即使是一台1 核 2G 的 MySQL 服务器，也能够达到 200QPS（Query Per Second，每秒执行的 SQL 语句数） 的每秒执行 SQL 语句数，足以支撑一个每天一百万 PV 的小网站。

MySQL 单独部署架构图

应用服务器和 MySQL 数据库服务器分为两台机器部署时，系统架构图如图 1-3 所示。

运维哲学初探

在这个小小的例子中，我们已经在不经意间窥探到了过去数十年运维技术圈的基本哲学：从物理机到虚拟机，从虚拟主机到云主机，再从云主机到 Kubernetes，虽然推动运维架构演进的是越来越复杂的软件架构和越来越多的计算资源需求，但是运维的基本哲学是不变的：

运维的核心价值不在于资源的扩充，而在于资源的隔离。

我们将在后面关于云服务和服务器硬件发展的讨论中进一步探讨这一运维哲学。