基于 Nginx 的大型互联网集群架构与实战方案

简介: 基于 Nginx 的大型互联网集群架构与实战方案
  1. Nginx 负载均衡基础配置

首先,搭建一个基础的 Nginx 负载均衡器,用于将流量分发到多个后端服务器上。
步骤 1.1:安装 Nginx

在每台要作为负载均衡器的服务器上,安装 Nginx。可以使用包管理工具进行安装,例如在 Ubuntu 上执行以下命令:

sudo apt update
sudo apt install nginx

步骤 1.2:配置 Nginx 负载均衡

Nginx 的核心是配置文件 nginx.conf,我们可以在其中定义后端服务器池以及负载均衡策略。以下是一个简单的 Nginx 负载均衡配置:

定义一个名为 backend 的后端服务器池

upstream backend {
server backend1.example.com weight=5; # 设置权重
server backend2.example.com weight=3;
server backend3.example.com weight=2;

# 启用健康检查(需要 Nginx Plus 支持开箱配置,开源版本需要第三方模块)
# Nginx Plus 示例:
health_check interval=10s fails=3 passes=2;

}

配置 HTTP 服务器

server {
listen 80;
server_name loadbalancer.example.com;

location / {
proxy_pass http://backend;
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_set_header X-Forwarded-Proto $scheme;
}
}

配置详解:

upstream 指令:定义了后端服务器池(backend),并为各服务器分配了不同的权重,Nginx 根据权重将流量按照比例分发到后端服务器。

健康检查:此配置会定期检查后端服务器是否可用,确保当某个服务器宕机时,不会继续向其发送请求。

proxy_pass:将客户端请求代理到后端服务器池。

步骤 1.3:启动和测试 Nginx

确保配置无误后,启动或重启 Nginx 服务:

sudo nginx -t # 测试配置文件是否正确
sudo systemctl restart nginx # 重启 Nginx

测试:通过访问 http://loadbalancer.example.com,验证请求是否被均匀分发到后端服务器。

  1. 高可用性配置(Keepalived + Nginx)

单独使用 Nginx 进行负载均衡仍然会面临单点故障问题。如果前端的 Nginx 宕机,整个服务将不可用。因此,我们需要通过 Keepalived 实现高可用的 Nginx 集群。
步骤 2.1:安装 Keepalived

在每台 Nginx 服务器上安装 Keepalived。以 Ubuntu 为例:

sudo apt install keepalived

步骤 2.2:配置 Keepalived

Keepalived 通过虚拟 IP 地址(VIP)实现故障转移。当主服务器宕机时,VIP 自动切换到备用服务器,确保服务的高可用性。

在主 Nginx 服务器上,编辑 Keepalived 的配置文件 /etc/keepalived/keepalived.conf:

vrrp_instance VI_1 {
state MASTER # 主服务器
interface eth0 # 网络接口
virtual_router_id 51
priority 100 # 主服务器优先级较高
advert_int 1 # 广播间隔
authentication {
auth_type PASS
auth_pass 123456 # 密码
}
virtual_ipaddress {
192.168.0.100 # 虚拟IP地址
}
track_script {
chk_nginx # 监控 Nginx 状态的脚本
}
}

在备用 Nginx 服务器上,将 state 设置为 BACKUP,并将 priority 设置为较低的值,例如 90。
步骤 2.3:监控 Nginx 状态

Keepalived 可以通过监控 Nginx 的运行状态来决定是否切换 VIP。创建一个监控脚本 /etc/keepalived/check_nginx.sh:

!/bin/bash

if ! pidof nginx > /dev/null
then
systemctl stop keepalived # 如果 Nginx 停止,关闭 Keepalived 以触发 VIP 切换
fi

将此脚本添加为可执行:

sudo chmod +x /etc/keepalived/check_nginx.sh

在 Keepalived 的配置文件中添加监控脚本:

vrrp_script chk_nginx {
script "/etc/keepalived/check_nginx.sh"
interval 2
}

步骤 2.4:启动 Keepalived

完成配置后,启动或重启 Keepalived 服务:

sudo systemctl restart keepalived

测试:关闭主服务器的 Nginx,VIP 应该自动切换到备用服务器,确保服务不中断。

  1. Nginx 健康检查和动态扩展

Nginx 可以结合健康检查功能,确保只有状态正常的服务器参与负载均衡。另外,动态扩展是应对突发流量的关键。以下是相关配置和实战方案。
步骤 3.1:配置健康检查(开源版本)

Nginx 开源版本不自带健康检查模块,可以通过第三方模块(如 ngx_http_healthcheck_module)实现健康检查。假设已安装此模块,配置如下:

upstream backend {
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;

# 使用第三方模块实现健康检查
check interval=5000 rise=2 fall=5 timeout=2000;

}

步骤 3.2:动态扩展后端服务器

结合容器化技术(如 Docker 或 Kubernetes),可以根据流量自动扩展后端服务器。例如,在 Kubernetes 集群中可以使用 Horizontal Pod Autoscaler (HPA) 自动扩展应用服务的副本数。

以下是在 Kubernetes 中配置自动扩展的示例:

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: backend-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: backend
minReplicas: 3
maxReplicas: 10
targetCPUUtilizationPercentage: 70 # 当 CPU 利用率超过 70% 时扩容

通过这种方式,后端服务可以根据负载动态扩展,Nginx 通过配置服务发现机制可以自动识别新的后端服务器。

  1. Nginx SSL/TLS 配置

[box.884636.com)
[box.alt-seals.com)
[box.917380.com)
[box.an-diy.com)
[box.aiziyo.com)

在生产环境中,启用 HTTPS 是必不可少的。以下是启用 SSL/TLS 的配置:
步骤 4.1:生成或获取 SSL 证书

使用 Let's Encrypt 生成免费的 SSL 证书:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com

步骤 4.2:配置 Nginx 使用 SSL

server {
listen 443 ssl;
server_name yourdomain.com;

ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

location / {
    proxy_pass http://backend;
    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_set_header X-Forwarded-Proto $scheme;
}

}

自动将 HTTP 请求重定向到 HTTPS

server {
listen 80;
server_name yourdomain.com;
return 301 https://$host$request_uri;
}

总结

通过 Nginx 的负载均衡、Keepalived 实现高可用、动态扩展后端服务器以及健康检查,构建了一个高效、可扩展且高可用的互联网集群架构。

相关文章
|
23天前
|
弹性计算 人工智能 架构师
阿里云携手Altair共拓云上工业仿真新机遇
2024年9月12日,「2024 Altair 技术大会杭州站」成功召开,阿里云弹性计算产品运营与生态负责人何川,与Altair中国技术总监赵阳在会上联合发布了最新的“云上CAE一体机”。
阿里云携手Altair共拓云上工业仿真新机遇
|
16天前
|
存储 关系型数据库 分布式数据库
GraphRAG:基于PolarDB+通义千问+LangChain的知识图谱+大模型最佳实践
本文介绍了如何使用PolarDB、通义千问和LangChain搭建GraphRAG系统,结合知识图谱和向量检索提升问答质量。通过实例展示了单独使用向量检索和图检索的局限性,并通过图+向量联合搜索增强了问答准确性。PolarDB支持AGE图引擎和pgvector插件,实现图数据和向量数据的统一存储与检索,提升了RAG系统的性能和效果。
|
20天前
|
机器学习/深度学习 算法 大数据
【BetterBench博士】2024 “华为杯”第二十一届中国研究生数学建模竞赛 选题分析
2024“华为杯”数学建模竞赛,对ABCDEF每个题进行详细的分析,涵盖风电场功率优化、WLAN网络吞吐量、磁性元件损耗建模、地理环境问题、高速公路应急车道启用和X射线脉冲星建模等多领域问题,解析了问题类型、专业和技能的需要。
2576 22
【BetterBench博士】2024 “华为杯”第二十一届中国研究生数学建模竞赛 选题分析
|
18天前
|
人工智能 IDE 程序员
期盼已久!通义灵码 AI 程序员开启邀测,全流程开发仅用几分钟
在云栖大会上,阿里云云原生应用平台负责人丁宇宣布,「通义灵码」完成全面升级,并正式发布 AI 程序员。
|
3天前
|
JSON 自然语言处理 数据管理
阿里云百炼产品月刊【2024年9月】
阿里云百炼产品月刊【2024年9月】,涵盖本月产品和功能发布、活动,应用实践等内容,帮助您快速了解阿里云百炼产品的最新动态。
阿里云百炼产品月刊【2024年9月】
|
2天前
|
存储 人工智能 搜索推荐
数据治理,是时候打破刻板印象了
瓴羊智能数据建设与治理产品Datapin全面升级,可演进扩展的数据架构体系为企业数据治理预留发展空间,推出敏捷版用以解决企业数据量不大但需构建数据的场景问题,基于大模型打造的DataAgent更是为企业用好数据资产提供了便利。
163 2
|
20天前
|
机器学习/深度学习 算法 数据可视化
【BetterBench博士】2024年中国研究生数学建模竞赛 C题:数据驱动下磁性元件的磁芯损耗建模 问题分析、数学模型、python 代码
2024年中国研究生数学建模竞赛C题聚焦磁性元件磁芯损耗建模。题目背景介绍了电能变换技术的发展与应用,强调磁性元件在功率变换器中的重要性。磁芯损耗受多种因素影响,现有模型难以精确预测。题目要求通过数据分析建立高精度磁芯损耗模型。具体任务包括励磁波形分类、修正斯坦麦茨方程、分析影响因素、构建预测模型及优化设计条件。涉及数据预处理、特征提取、机器学习及优化算法等技术。适合电气、材料、计算机等多个专业学生参与。
1576 16
【BetterBench博士】2024年中国研究生数学建模竞赛 C题:数据驱动下磁性元件的磁芯损耗建模 问题分析、数学模型、python 代码
|
22天前
|
编解码 JSON 自然语言处理
通义千问重磅开源Qwen2.5,性能超越Llama
击败Meta,阿里Qwen2.5再登全球开源大模型王座
972 14
|
3天前
|
Linux 虚拟化 开发者
一键将CentOs的yum源更换为国内阿里yum源
一键将CentOs的yum源更换为国内阿里yum源
218 2
|
17天前
|
人工智能 开发框架 Java
重磅发布!AI 驱动的 Java 开发框架:Spring AI Alibaba
随着生成式 AI 的快速发展,基于 AI 开发框架构建 AI 应用的诉求迅速增长,涌现出了包括 LangChain、LlamaIndex 等开发框架,但大部分框架只提供了 Python 语言的实现。但这些开发框架对于国内习惯了 Spring 开发范式的 Java 开发者而言,并非十分友好和丝滑。因此,我们基于 Spring AI 发布并快速演进 Spring AI Alibaba,通过提供一种方便的 API 抽象,帮助 Java 开发者简化 AI 应用的开发。同时,提供了完整的开源配套,包括可观测、网关、消息队列、配置中心等。
734 9