云计算

  1. 你在工作中用过哪些主流云平台（如 AWS、阿里云、华为云等）？请举例说明你对其中某一平台核心服务（如计算、存储、网络）的使用和配置经验。

    常用云平台如阿里云、AWS，腾讯云，华为云。以阿里云为例，核心服务经验如下：计算服务：配置ECS实例时，根据业务负载选择规格(如2核4G用于小型服务)，开启按量付费降低非峰值成本，通过弹性伸缩根据CPU利用率(超过70%扩容，低于30%缩容)自动调整实例数量；存储服务：将静态资源存至OSS，开启CDN加速，降低用户访问延迟，同时配置OSS生命周期规则，节省成本；网络服务：创建VPC划分公网、内网子网，通过安全组仅开放必要端口(如80/443用于http/https)，使用负载均衡SLB，将请求分发至多个ECS，避免单点故障。

  2. 当云服务器（如阿里云 ECS、AWS EC2）出现 CPU 利用率突然飙升至 90% 以上的情况时，你的排查思路和解决步骤是什么？

    先通过云平台控制台(如阿里云ECS监控、AWS CloudWatch)查看CPU高占用的具体进程，确认是业务进程(如JAVA程序)还是异常进程；若为业务进程：查看进程对应日志(如引用日志，数据库慢查询日志)，判断是否因代码漏洞（如死循环）、请求量突增导致；若请求量突增，想通过SLB限流或临时扩容缓解，在优化代码或配置缓存（如redis）；若为异常进程通过top/ps命令定位进程PID，用kill -9终止进程，同时检查服务器是否存在未授权访问（如ssh密钥是否泄露），并升级系统补丁；最后记录故障原因和解决方案，优化监控告警，cpu利用率超过80%触发短信告警，避免类似问题重负发生。

  3. 在云环境中，不同类型的云存储服务（如对象存储 OSS/S3、块存储 EBS、文件存储 NAS）适用场景有何区别？请举例说明你如何根据业务需求选择合适的存储服务。

    三类存储服务的区别及场景选择如下；1.对象存储（OSS/S3）：特性是无容量上限、支持http/https访问、成本低，适合存储非结构化数据，如业务静态资源、日志文件、备份数据。2.块存储（EBS）：特性是性能高、支持随机读写，需挂在到云服务器使用，适合作为操作系统盘、数据库存储盘。3.文件存储NAS：特性是支持多台云服务器共享访问，兼容POSIX协议，适合需要跨实例共享文件的场景，如多台web服务器共享静态资源、大数据分析场景下的共享数据存储。

  4. 为了保障云资源的安全性，你会采取哪些关键配置措施？比如在访问控制、网络防护、数据备份等方面。

    1.访问控制：使用云平台 IAM（身份与访问管理）服务，为不同角色（如开发、运维）分配最小权限（如运维仅能查看 ECS 配置，无删除权限），禁用 root 账号直接登录，强制使用 SSH 密钥（而非密码）登录云服务器；
    2.网络防护：在 VPC 内划分安全子网（如 Web 层、数据库层），数据库层仅允许 Web 层子网访问；通过 “安全组” 和 “网络 ACL” 双重防护，仅开放必要端口（如禁止公网直接访问数据库 3306 端口）；
    3.数据备份：对核心数据（如数据库、业务文件）配置 “定时自动备份”，备份文件跨区域存储（如阿里云跨 Region 备份），定期（如每月）验证备份文件的恢复可用性；
    其他：开启云平台 “安全中心” 实时监测漏洞（如系统漏洞、应用漏洞），定期进行安全扫描和渗透测试，及时修复高危漏洞。

  5. 你是否使用过自动化工具（如 Terraform、Ansible、Jenkins）管理云资源或部署服务？请说明某一工具的使用场景和它为运维工作带来的优势。

  6. 当云环境中的某一业务服务（如 Web 服务）出现部分用户访问超时，但其他用户访问正常的情况，你会从哪些维度排查问题？

    排查维度如下：
    1.网络维度：查看云平台 “负载均衡 SLB” 监控，确认是否存在部分节点健康检查失败（如某台 ECS 实例未响应），导致请求分发到故障节点；同时检查用户 IP 所属区域，判断是否因 “CDN 节点故障” 或 “跨区域网络链路不稳定” 导致超时；
    2.资源维度：查看故障节点的资源监控（CPU、内存、磁盘 IO），确认是否因单节点资源耗尽（如内存泄漏导致 OOM）无法处理请求；检查数据库是否存在锁表或慢查询，导致依赖数据库的业务接口超时；
    3.配置维度：检查服务配置（如 Nginx 的连接数限制、Tomcat 的线程池配置），是否因单节点最大连接数达到上限，导致新请求无法建立；查看云平台 “安全组” 或 “ACL” 是否误配置，拦截了部分用户 IP 的访问；
    4.业务维度：查看业务日志，确认是否因用户请求参数异常（如特殊字符导致代码报错）或部分功能模块（如第三方接口调用）故障，仅影响特定用户的访问；同时确认是否为版本发布问题（如部分节点未更新到最新版本，存在兼容性问题）。

Nginx的作用

  1. Nginx 是一款高性能的HTTP 服务器、反向代理服务器，同时也是负载均衡器、缓存服务器等，核心作用是解决 “高效处理网络请求” 和 “架构层的流量调度与资源优化” 问题，具体可以从以下几个方面理解：

  2. 作为 Web 服务器，处理静态资源Nginx 能直接接收客户端的 HTTP 请求，高效分发静态资源（如 HTML、CSS、JS、图片、视频等）。它的底层采用 “异步非阻塞” 模型，能以极少的内存占用支持数万并发连接，比传统的 Apache 更适合高并发场景（比如静态资源密集的门户网站、电商首页）。

  3. 作为反向代理，实现流量转发这是 Nginx 最常用的功能之一。在实际架构中，后端通常有多个应用服务器（如 Tomcat、Node.js、Python 服务），Nginx 作为 “中间层” 接收客户端请求，再根据配置转发到对应的后端服务。这样做的好处是：隐藏后端服务器真实 IP，提高安全性；统一入口域名，方便管理（比如所有请求都通过api.example.com进入，再由 Nginx 转发到不同微服务）。

  4. 作为负载均衡器，提升架构可用性当后端有多个相同功能的服务器（如多台 Tomcat 集群），Nginx 可以通过负载均衡策略（轮询、权重、IP 哈希等）将请求 “均匀” 分配到不同服务器，避免单台服务器过载。例如：电商秒杀时，通过 Nginx 将流量分散到 10 台后端服务器，既能扛住高并发，又能在某台服务器故障时自动将请求转发到其他正常节点，实现 “故障转移”。

  5. 实现动静分离，优化资源处理效率Nginx 擅长处理静态资源（IO 密集型操作），而后端应用服务器（如 Java 服务）更适合处理动态逻辑（CPU 密集型）。通过 Nginx 配置，可以将静态资源请求（如/static/*）直接由 Nginx 处理，动态请求（如/api/*）转发给后端，减少后端服务器的无效负载，提升整体响应速度。

  6. 提供缓存与 SSL 终端能力
    缓存：Nginx 可以缓存静态资源或后端 API 的响应结果（如频繁访问的商品详情页），再次请求时直接返回缓存内容，减少对后端的重复请求。

  7. SSL 终端：客户端的 HTTPS 请求（加密流量）由 Nginx 负责解密，再以 HTTP 方式转发给后端，后端无需处理复杂的 SSL/TLS 加密解密，简化配置并降低性能损耗。

Nginx 相关追问

你提到 Nginx 能做反向代理，那如果我要配置一个简单的反向代理 —— 让客户端访问http://example.com/api时，转发到后端两台 Tomcat 服务器（192.168.1.100:8080和192.168.1.101:8080），核心的 Nginx 配置块应该怎么写？需要注意哪些参数？

  1. 配置简单反向代理到两台 Tomcat 服务器的核心配置
    核心配置需要通过 upstream 定义后端服务器集群，再通过 location 块匹配请求并转发，示例如下：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    # 定义后端Tomcat服务器集群（名称可自定义，如tomcat_cluster）
    upstream tomcat_cluster {
        server 192.168.1.100:8080;  # 第一台Tomcat
        server 192.168.1.101:8080;  # 第二台Tomcat
    }

    server {
        listen 80;
        server_name example.com;

        # 匹配客户端访问的/api路径，转发到tomcat_cluster
        location /api {
            proxy_pass http://tomcat_cluster;  # 转发到上游集群
            # 关键参数：传递客户端真实IP和主机头（避免后端获取到的是Nginx的IP）
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
    注意事项：
    proxy_pass 后需跟 http:// + 上游集群名（不能直接写 IP，否则无法触发负载均衡）；
    必须配置 proxy_set_header 传递客户端信息，否则后端服务（如 Tomcat 日志）会错误记录 Nginx 的 IP；
    若后端服务有路径前缀（如 Tomcat 实际接口是 /api/v1），需调整 location 和 proxy_pass（例如 proxy_pass http://tomcat_cluster/v1）。

你说 Nginx 支持轮询、权重、IP 哈希等负载均衡策略，那你能分别说说这三种策略的适用场景吗？比如什么业务下适合用 IP 哈希，什么场景下更推荐调整权重？如果后端某台服务器临时故障，怎么配置能让 Nginx 自动跳过这台故障机，避免请求失败？

负载均衡策略适用场景及故障处理,三种策略的适用场景：

  • 轮询（默认）：适合后端服务器硬件配置、性能完全一致的场景（如集群中所有服务器都是 8 核 16G），请求会按顺序依次分发，简单均衡。
  • 权重（weight）：适合服务器性能有差异的场景（如一台 8 核 16G、一台 4 核 8G），可通过 weight 分配请求比例（例如 server 192.168.1.100:8080 weight=2; server 192.168.1.101:8080 weight=1; 表示 2:1 分发），让高性能服务器承担更多流量。
  • IP 哈希（ip_hash）：适合需要 “会话保持” 的业务（如用户登录状态、购物车数据存在服务器本地），通过客户端 IP 哈希值固定分发到某台服务器，避免用户操作被分配到不同服务器导致状态丢失。
  • 故障自动跳过配置：在 upstream 中添加 max_fails 和 fail_timeout 参数，示例：
    1
    2
    3
    4
    5
    6
    upstream tomcat_cluster {
        server 192.168.1.100:8080 max_fails=2 fail_timeout=30s;  # 2次失败后，30秒内视为故障机
        server 192.168.1.101:8080 max_fails=2 fail_timeout=30s;
    }
    max_fails=2：Nginx 连续 2 次请求后端失败（如连接超时、5xx 错误），标记为故障机；
    fail_timeout=30s：30 秒内不再向故障机转发请求，超时后自动重试，恢复正常则重新加入集群。

你提到了动静分离，那实际配置时，怎么让 Nginx 区分 “静态请求” 和 “动态请求”？比如我想让/static/路径下的所有文件（CSS、JS、图片）由 Nginx 直接处理，/dynamic/路径下的请求转发给后端 Node.js 服务，核心配置逻辑是什么？另外，为了优化静态资源访问，你会给 Nginx 加哪些缓存相关的配置（比如缓存时长、缓存失效策略）？

  • 动静分离配置及静态资源缓存优化
    动静分离核心配置：
    通过 location 按路径匹配静态 / 动态请求，分别处理：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    server {
        listen 80;
        server_name example.com;
        root /var/www/html;  # 静态资源根目录

        # 静态请求：匹配/static/路径下的所有文件（CSS、JS、图片等）
        location /static/ {
            # 直接读取本地文件，无需转发
            expires 7d;  # 缓存7天（针对静态资源）
            add_header Cache-Control "public, max-age=604800";  # 配合expires设置缓存策略
        }

        # 动态请求：匹配/dynamic/路径，转发到Node.js服务
        location /dynamic/ {
            proxy_pass http://127.0.0.1:3000;  # Node.js服务地址
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
    静态资源缓存优化配置：
    按文件类型设置不同缓存时长（图片缓存久，JS/CSS 适中）：

    location ~* \.(jpg|jpeg|png|gif|ico)$ {  # 图片类型
        expires 30d;  # 缓存30天
    }
    location ~* \.(css|js)$ {  # 样式和脚本
        expires 7d;  # 缓存7天
    }
    缓存失效策略：通过 add_header Cache-Control “public, max-age=604800, must-revalidate” 确保缓存过期后重新验证；静态资源更新时，通过文件名加哈希（如 style.v2.css）强制客户端更新缓存。

你说 Nginx 用 “异步非阻塞” 模型实现高并发，那你能简单解释下这个模型的原理吗？它和 Apache 的 “多进程 / 多线程” 模型相比，为什么在高并发场景下内存占用更低、响应更快？如果 Nginx 出现 “too many open files” 错误，可能是什么原因导致的，怎么解决？

  1. 异步非阻塞模型原理及 “too many open files” 问题, 异步非阻塞模型原理：
    Nginx 基于 “IO 多路复用”（如 Linux 的 epoll）实现：
  • 一个 worker 进程可以同时处理成千上万的连接，无需为每个连接创建新进程 / 线程；当连接发起 IO 请求（如读取文件、转发请求到后端）时，进程不会 “阻塞等待”，而是继续处理其他连接，直到 IO 操作完成后通过 “事件通知” 回调处理结果。
  • 与 Apache 多进程 / 多线程模型的对比：Apache 每处理一个连接会创建一个进程 / 线程，高并发时进程 / 线程数量暴增，导致内存占用飙升（每个进程 / 线程约几 MB），且进程切换开销大，性能下降快；
  • Nginx 的 worker 进程数量固定（通常等于 CPU 核心数），通过事件驱动复用连接，内存占用极低（单 worker 进程仅几 MB），高并发下更稳定。
  1. “too many open files” 错误原因及解决：
  • 原因：Linux 系统对进程打开的文件描述符（包括网络连接、文件）有默认限制（如默认单进程 1024），Nginx 高并发时连接数超过限制会触发该错误。
  • 解决：临时调整系统限制：ulimit -n 65535（当前会话生效）；永久调整：在 /etc/security/limits.conf 中添加 * hard nofile 65535 和 * soft nofile 65535，重启生效；Nginx 配置中增加 worker_rlimit_nofile 65535;（限制 worker 进程的最大文件描述符），并调大 worker_connections（如 worker_connections 10000;）。

实际运维中，如果客户端访问 Nginx 时出现 502 Bad Gateway 错误，你会从哪些维度排查问题？比如结合 Nginx 日志和后端服务状态，具体会看哪些日志文件、执行哪些命令？如果是 504 Gateway Timeout 呢，排查思路有什么不同？

  1. 502 和 504 错误的排查思路
  • 502 Bad Gateway（后端拒绝连接）排查：查看 Nginx 错误日志（默认 /var/log/nginx/error.log），关键信息如 connect() failed (111: Connection refused) while connecting to upstream，说明后端服务未启动或端口未监听；
  • 检查后端服务状态：执行 ps -ef | grep tomcat（以 Tomcat 为例）确认服务是否运行；执行 netstat -tlnp | grep 8080 确认后端端口是否正常监听（若显示 LISTEN 则正常）；
  • 检查网络连通性：在 Nginx 服务器上执行 telnet 192.168.1.100 8080，若无法连接，可能是后端防火墙拦截（需开放 8080 端口）或 IP / 端口错误。
  1. 504 Gateway Timeout（后端响应超时）排查：
  • 查看 Nginx 错误日志，关键信息如 upstream timed out (110: Connection timed out) while reading response header from upstream，说明后端处理时间超过 Nginx 的超时配置；
  • 检查 Nginx 超时参数：查看 proxy_connect_timeout（连接后端超时，默认 60s）、proxy_read_timeout（等待后端响应超时，默认 60s），若业务处理耗时较长（如大数据查询），需调大：
    1
    2
    3
    4
    5
    6
    nginx
    location /api {
        proxy_pass http://tomcat_cluster;
        proxy_connect_timeout 30s;
        proxy_read_timeout 120s;  # 延长到120秒
    }
  • 排查后端性能：查看后端服务日志（如 Tomcat 的 catalina.out），是否有慢查询、死锁等导致处理超时，需优化后端代码或数据库。

你提到 Nginx 能做 SSL 终端，那配置 HTTPS 时，需要在 Nginx 里放哪些文件（比如证书相关）？核心配置项（比如ssl_certificate、ssl_protocols）分别对应什么作用？另外，为了提升 HTTPS 性能，你会开启哪些优化配置（比如 SSL 会话缓存、HTTP/2）？

  1. SSL 配置及 HTTPS 性能优化
  • SSL 配置所需文件及核心配置项：
    所需文件：证书文件（通常是 .crt 或 .pem，包含公钥和证书链）；私钥文件（.key，需妥善保管，不可泄露）。
    核心配置项：
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    server {
        listen 443 ssl http2;  # 开启HTTPS和HTTP/2
        server_name example.com;

        ssl_certificate /etc/nginx/ssl/example.crt;  # 证书路径
        ssl_certificate_key /etc/nginx/ssl/example.key;  # 私钥路径

        ssl_protocols TLSv1.2 TLSv1.3;  # 仅支持安全的TLS版本（禁用SSLv3、TLSv1.0/1.1）
        ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;  # 选择高效加密套件
    }
    HTTPS 性能优化配置：
    开启 SSL 会话缓存：复用 SSL 握手信息，减少重复握手开销：
    nginx
    ssl_session_cache shared:SSL:10m;  # 共享缓存，大小10MB
    ssl_session_timeout 1d;  # 会话缓存有效期1天
    启用 HTTP/2：通过 listen 443 ssl http2; 开启，支持多路复用，减少连接建立次数；
    启用 OCSP Stapling：避免客户端验证证书时向 CA 服务器查询，加速 SSL 握手：
    nginx
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/ssl/ca-bundle.crt;  # CA根证书路径