从 IaaS 到 Serverless：我的智能日志监控平台架构演进之路

从 IaaS 到 Serverless：我的智能日志监控平台架构演进之路 {#from-iaas-to-serverless}

本文基于我构建的“智能日志监控与分析平台”，详细记录从单机部署到微服务架构、再到探索 Serverless 的全过程。所有设计均来自真实实践，涵盖 Nginx 负载均衡、Filebeat 采集、Kafka 集群、Logstash 处理、Elasticsearch 存储、Kibana 可视化、Prometheus+Grafana 监控、Celery 定时任务等组件，最终形成一套企业级可观测性解决方案。

引子：一切始于一个简单的日志需求 {#starting-with-a-simple-log-need}

最初，我只是想解决一个问题：如何快速定位线上 Web 应用的错误？

当时我们团队的后端服务部署在多台服务器上，日志分散、查询困难。每次出问题都要登录不同机器 grep 查看，效率极低。

于是，我决定构建一个集中式日志收集与分析平台。经过调研和实践，最终搭建了一个基于微服务架构的智能日志监控系统。

现在，这个平台已经具备：

• 支持多源日志采集（Web 后端、数据库、Nginx）
• 实时处理与存储（Kafka + Logstash + Elasticsearch）
• 可视化分析（Kibana）
• 全链路监控（Prometheus + Grafana）
• 自动告警（Celery + Redis + 钉钉）

而这一切，都建立在我对云计算分层模型的逐步理解之上。

---

第一阶段：IaaS 上的单机部署时代 {#iaas-single-machine-deployment}

架构概览

初期版本只在一台阿里云 ECS 上运行所有组件：

• Nginx 负载均衡
• Kafka 单节点
• Logstash
• Elasticsearch
• Kibana
• Prometheus + Grafana

技术痛点

1. 单点故障：任何组件崩溃，整个系统不可用
2. 资源争抢：多个服务共用 CPU/内存，性能瓶颈明显
3. 无法扩展：用户量增加时，只能升级硬件
4. 运维复杂：手动管理启动脚本、配置文件、依赖关系

关键认知

这是典型的 IaaS（Infrastructure as a Service） 使用方式：
云厂商提供虚拟机（ECS），我负责操作系统、中间件、应用部署、高可用等一切。

虽然实现了功能，但维护成本极高，系统稳定性差，不适合生产环境。

---

第二阶段：引入微服务架构，实现解耦与高可用 {#microservices-for-decoupling-and-high-availability}

为了解决单点问题，我将系统重构为 微服务架构，并逐步容器化。

微服务拆分

根据业务职责，拆分为以下独立服务：

服务	功能	技术栈
Nginx 负载均衡	用户请求入口，负载分发	Nginx + Keepalived + VIP
Filebeat 采集器	实时采集 Web 服务器日志	Filebeat（轻量级）
Kafka 集群	日志消息队列，缓冲与解耦	Kafka （Kraft模式）
Logstash	日志解析、清洗、过滤	Logstash
Elasticsearch	日志存储与索引	ES（集群部署）
Kibana	日志可视化查询	Kibana（前端）
Prometheus + Grafana	系统指标监控与展示	Prometheus（拉取）、Grafana（面板）
Celery + Redis	定时任务调度	Celery（任务队列）、Redis（任务存储）

容器化部署

每个服务打包为 Docker 镜像，通过 docker-compose.yml 或 Kubernetes 编排：

version: '3'
services:
  kafka:
    image: confluentinc/cp-kafka
    ports: ["9092:9092"]
    environment:
      - KAFKA_BROKER_ID=1
      - KAFKA_ZOOKEEPER_CONNECT=zookeeper:2181

注：目前仍在尝试 Docker 容器化，未来计划迁移到 K8s。

效果提升

• 高可用：Kafka 集群 + Elasticsearch 集群，任一节点宕机不影响整体

• 可扩展：可通过增加节点水平扩展

• 故障隔离：某个服务崩溃，不影响其他服务

• 独立部署：各服务可独立更新、回滚

  微服务架构 的核心价值：围绕业务能力组织服务，独立演进，降低耦合度。

第三阶段：轻量级 CI/CD 与类 PaaS 体验 {#lightweight-cicd-and-paas-like-experience}

为了让团队成员也能轻松参与开发，我构建了一套轻量级 CI/CD 流程。

CI/CD 流程设计

• 开发者在本地修改代码（如 Kibana Dashboard）

• git push 到 GitHub/Gitee

• 触发 webhook，自动执行以下操作：

  git pull origin main
  docker build -t my-kibana .
  docker stop kibana || true
  docker rm kibana || true
  docker run -d --name kibana --network host my-kibana

  类 PaaS 体验

• 团队成员只需专注写代码

• 不需要关心部署流程、网络配置、Docker 命令

• 我负责维护 CI/CD 脚本和基础设施

  这种模式虽然不是标准 PaaS（如 Heroku），但已具备 PaaS 的核心特征：开发者只管应用，平台屏蔽底层复杂性。

  第四阶段：探索 Serverless 处理边缘任务 {#serverless-for-edge-tasks}

随着系统稳定，我开始思考：哪些任务可以更高效地完成？

例如：当系统 CPU 使用率 > 80%，自动发送告警邮件或钉钉消息。

传统做法是在 Prometheus 中设置规则，触发 Alertmanager 发送通知。但这种方式:

• 需要额外部署 Alertmanager
• 配置复杂
• 若告警频繁，可能影响主系统

于是我尝试使用 Serverless（阿里云函数计算 FC） 来处理这类边缘任务。

Serverless 实践

编写告警函数：

import requests
def handler(event, context):
    # 查询 Prometheus 接口获取 CPU 使用率
    cpu_usage = get_cpu_usage_from_prometheus()
    if cpu_usage > 0.8:
        send_dingtalk("CPU 使用率过高！")

• 在阿里云 FC 创建函数，设置定时触发器（每分钟一次）

• 函数执行时自动分配资源，执行完立即释放

  优势

• 零闲置成本：没触发时不计费

• 免运维：无需管理服务器、扩缩容

• 快速响应：支持毫秒级触发

注意：Serverless 并非替代微服务，而是补充边缘场景。主干（日志处理）仍需长运行服务，边缘（告警、文件处理）适合函数。

对比总结：IaaS / PaaS / SaaS / Serverless 的责任边界 {#responsibility-boundaries}
通过这个项目，我对云计算分层有了切身体会：

层级	谁负责什么？	我的实践
IaaS	云厂商：硬件、虚拟化 我：OS、运行时、应用、数据	阿里云 ECS 部署 Kafka + Consumer
PaaS	云厂商：OS、运行时、中间件 我：应用、数据	自研 CI/CD + Docker，同学只需要写代码
SaaS	云厂商：一切 用户：仅使用软件	若将日志系统做成 Web 产品供中小型公司使用
Serverless (FaaS)	云厂商：服务器、扩缩容、高可用 我：仅函数代码	钉钉告警函数，按执行时间付费

演进的本质，是责任不断上移，开发者越来越聚焦于“业务逻辑”本身。

未来展望：自动化、多租户与产品化 {#future-roadmap}

目前系统仍有不少优化空间：

• 多租户支持：不同公司使用同一套系统，数据隔离
• 自助注册：类似 SaaS，用户注册即得专属日志空间
• 全链路自动化：从代码提交到服务上线，无人工干预
• 成本优化：核心服务用 ECS，边缘任务用 Serverless，混合部署

长远看，这个项目或许真能成为一款面向中小企业的 可观测性 SaaS 产品——而这一切，始于一台 2 核 4G 的云服务器。

结语：技术演进的本质是“让人更聚焦创造” {#conclusion}

回望这段旅程，我最大的收获不是学会了 Docker 或 Serverless，而是明白了：

好的技术架构，不是炫技，而是不断降低“创造价值”的门槛。

从手动部署到 CI/CD，从单体到微服务，从自建服务器到 Serverless——每一步，都是为了让我和我的团队，能更专注于“写出更好的日志分析逻辑”，而不是“服务器为什么又崩了”。

如果你也在做个人项目，不妨问自己：

• 我是否还在重复做低价值的运维？
• 能否用自动化解放双手？
• 能否通过架构拆分，让系统更灵活？

答案，或许就藏在你的下一次 git push 中。