软件系统构建与监控全解析

### 云应用部署、监控与日志管理全解析 #### 1. 云应用部署基础 在云环境中部署应用是一项关键任务，以 Google Cloud Shell 为例，可以从零开始搭建 App Engine 应用，同时借助 GCP Cloud Build 实现持续交付。这里有一个简单的 Python 代码示例，用于启动一个应用： ```python if __name__ == '__main__': app.run(host='127.0.0.1', port=8080, debug=True) ``` 此代码使用 Python 启动一个应用，在本地主机的 8080 端口运行，并开启调试模式。 #### 2. NFSOPS 实战案例 NFSOPS 是一种利用 NFS（网络文件系统）挂载点来管理计算机集群的操作技术，它并非新事物，早在 Unix 时代就已存在。例如，2000 年 Noah 就在加州理工学院的 Unix 系统上使用 NFS 挂载点来管理和维护软件。 在旧金山的一家虚拟现实初创公司担任兼职顾问时，面临的一个问题是如何快速构建一个作业框架，将工作分配到数千个 AWS Spot 实例上。最终有效的解决方案是使用 NFSOPS，它可以在亚秒级将 Python 代码部署到数千个计算机视觉 Spot 实例上。 NFSOPS 的工作流程如下： - 使用构建服务器（如 Jenkins）挂载多个 Amazon Elastic File System（EFS）挂载点（DEV、STAGE、PROD）。 - 当进行持续集成构建时，最后一步是将文件同步到相应的挂载点，示例命令如下： ```bash #Jenkins deploy build step rsync -az --delete * /dev-efs/code/ ``` - 当数千个 Spot 实例启动时，它们会预先配置为挂载 EFS（NFS 挂载点）并使用源代码。 这种部署模式简单高效，还能与 IAC、Amazon Machine Image（AMI）或 Ansible 很好地配合使用。以下是 NFSOPS 工作流程的 mermaid 流程图： ```mermaid graph LR A[Jenkins] --> B[挂载 EFS 挂载点] B --> C[持续集成构建] C --> D[rsync 同步文件] D --> E[Spot 实例挂载 EFS 并使用代码] ``` #### 3. 构建可靠系统的关键概念 在构建软件系统时，有一些关键概念需要注意。首先，“信任我”是一个糟糕的反模式，理智的 DevOps 专业人员不会完全信任人类，因为人类容易犯错，可能会在一时冲动下摧毁整个公司。 构建可靠系统的更好方法是逐步构建，并且在创建平台时，要定期预期可能出现的故障。如果有强势人物参与架构构建，这种故障预期的重要性会呈指数级增加。 自动化比层级制度更重要，这是解决初创公司混乱局面的关键。软件的部署、测试和构建都应该实现 100% 自动化。 #### 4. 集中式日志记录 在大规模分布式系统中，日志记录非常重要。异常信息应始终发送到集中式日志记录系统。在开发软件时，创建调试日志而不是简单的打印语句是个好主意，这样可以在生产环境出现问题时启用调试信息。 以 Ceph 为例，它的守护进程可以有多达 20 个调试级别，所有这些级别都在代码中处理，系统可以根据需要调整日志记录的数量，还能限制每个守护进程的日志记录量。 以下是集中式日志记录的优势列表： - 便于统一管理和分析日志。 - 可以在出现问题时快速定位和排查。 - 有助于监控系统的整体运行状态。 #### 5. 生产数据库日志问题案例 在一个大型 Web 应用中，数据库产生了大量日志，导致 PostgreSQL 的日志记录级别被设置到最低，无法进行问题调试。因为提高日志级别会导致应用因大量 I/O 操作而停止工作。 经过分析，发现每天早上五点左右数据库负载会飙升。通过获取 15 分钟的日志，发现是一个 `SELECT *` 查询导致的问题。进一步调查发现，数据库管理员使用的备份脚本中包含多个 `SELECT *` 语句，随着数据库规模的增大，负载变得难以忍受。 解决方案是停止使用该脚本，改为备份四个二级（副本）数据库之一。同时，提前考虑日志输出的分发是正确的做法，像 rsyslog 这样的工具可以解决这个问题。以下是该案例的处理流程表格： | 步骤 | 操作 | | --- | --- | | 1 | 发现数据库负载问题 | | 2 | 协商获取 15 分钟日志 | | 3 | 分析日志找到慢查询 | | 4 | 检查 crontab 发现备份脚本问题 | | 5 | 更改备份策略 | #### 6. 自建还是购买 关于自建还是购买软件服务，存在一个经济原则——比较优势。除非公司规模达到科技巨头级别，否则自建、维护和改进私有云很难同时节省成本和提升业务。 例如，2017 年亚马逊推出了跨多个可用区自动故障转移的多主数据库部署功能，这是非常难以自行实现的。在考虑外包时，一个关键问题是：“这是否是公司的核心竞争力？”如果公司的核心业务是销售汽车零部件，却自行运行邮件服务器，那可能会面临风险并造成损失。 #### 7. 容错设计 容错是一个重要但容易混淆的概念。设计容错系统时，可以从回答以下问题开始：当服务出现故障时，如何减少或消除人工干预？ 以一个复杂的构建系统为例，该系统涉及多个步骤和组件，其中创建存储库的机器比较复杂，包括数据库、RabbitMQ 服务、大量存储和 Nginx 服务等。为了应对服务可能出现的故障，将负载分散到五台相同的机器上。 节点创建二进制文件时会查询 API 以获取健康的存储库机器，API 会向列表中的下一个构建服务器的 `/health/` 端点发送 HTTP 请求进行健康检查。如果服务器健康，二进制文件将被发送到该服务器；否则，API 将选择列表中的下一个服务器。如果一个节点连续三次健康检查失败，将被移除出轮换。修复后，系统管理员只需重启存储库服务即可将其重新加入轮换。 以下是容错系统的 mermaid 流程图： ```mermaid gr ```