Nginx配置之负载均衡、限流、缓存、黑名单和灰度发布

一、Nginx安装(基于CentOS 6.5)

1.yum命令安装

yum install nginx –y
(若不能安装,执行命令yum install epel-release)

2. 启动、停止和重启

service nginx start
service nginx stop
service nginx restart
浏览器中 输入服务器的 ip 地址,即可看到相应信息

3. 其他信息

rpm -ql nginx 来查看安装路径
yum remove nginx 来卸载 
nginx -s reload 配置热更新 

二、Nginx负载均衡配置(/etc/nginx/nginx.conf)

  1. 负载均衡配置

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

http {

       ……

    upstream real_server {

       server 192.168.103.100:2001 weight=1;  #轮询服务器和访问权重

       server 192.168.103.100:2002 weight=2;

    }

 

    server {

        listen  80;

 

        location / {

            proxy_pass http://real_server;

        }

    }

}

    2.失败重试配置

1

2

3

4

upstream real_server {

   server 192.168.103.100:2001 weight=1 max_fails=2 fail_timeout=60s;

   server 192.168.103.100:2002 weight=2 max_fails=2 fail_timeout=60s;

}

意思是在fail_timeout时间内失败了max_fails次请求后,则认为该上游服务器不可用,然后将该服务地址踢除掉。fail_timeout时间后会再次将该服务器加入存活列表,进行重试。

三、Nginx限流配置

  1. 配置参数

limit_req_zone指令设置参数 

1

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

1)limit_req_zone定义在http块中,$binary_remote_addr表示保存客户端IP地址的二进制形式。
2)Zone定义IP状态及URL访问频率的共享内存区域。zone=keyword标识区域的名字,以及冒号后面跟区域大小。16000个IP地址的状态信息约1MB,所以示例中区域可以存储160000个IP地址。
3)Rate定义最大请求速率。示例中速率不能超过每秒10个请求。

2.设置限流

1

2

3

4

location / {

        limit_req zone=mylimit burst=20 nodelay;

        proxy_pass http://real_server;

}

burst排队大小,nodelay不限制单个请求间的时间

3.不限流白名单

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

geo $limit {

default              1;

192.168.2.0/24  0;

}

 

map $limit $limit_key {

1 $binary_remote_addr;

"";

}

 

limit_req_zone $limit_key zone=mylimit:10m rate=1r/s;

 

location / {

        limit_req zone=mylimit burst=1 nodelay;

        proxy_pass http://real_server;

}

上述配置中,192.168.2.0/24网段的IP访问是不限流的,其他限流。

IP后面的数字含义:

24表示子网掩码:255.255.255.0

16表示子网掩码:255.255.0.0

8表示子网掩码:255.0.0.0

四、Nginx缓存配置

  1. 浏览器缓存

静态资源缓存用expire

1

2

3

location ~*  .(jpg|jpeg|png|gif|ico|css|js)$ {

   expires 2d;

}

Response Header中添加了Expires和Cache-Control


静态资源包括(一般缓存)

1)普通不变的图像,如logo,图标等
2)js、css静态文件
3)可下载的内容,媒体文件

协商缓存(add_header ETag/Last-Modified value)

1)HTML文件
2)经常替换的图片
3)经常修改的js、css文件
4)基本不变的API接口

不需要缓存

1)用户隐私等敏感数据

2)经常改变的api数据接口

2.代理层缓存

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

//缓存路径,inactive表示缓存的时间,到期之后将会把缓存清理

proxy_cache_path /data/cache/nginx/ levels=1:2 keys_zone=cache:512m inactive = 1d max_size=8g;

 

location / {

    location ~ \.(htm|html)?$ {

        proxy_cache cache;

        proxy_cache_key    $uri$is_args$args;     //以此变量值做HASH,作为KEY

        //HTTP响应首部可以看到X-Cache字段,内容可以有HIT,MISS,EXPIRES等等

        add_header X-Cache $upstream_cache_status;

        proxy_cache_valid 200 10m;

        proxy_cache_valid any 1m;

        proxy_pass  http://real_server;

        proxy_redirect     off;

    }

    location ~ .*\.(gif|jpg|jpeg|bmp|png|ico|txt|js|css)$ {

        root /data/webapps/edc;

        expires      3d;

        add_header Static Nginx-Proxy;

    }

}

        在本地磁盘创建一个文件目录,根据设置,将请求的资源以K-V形式缓存在此目录当中,KEY需要自己定义(这里用的是url的hash值),同时可以根据需要指定某内容的缓存时长,比如状态码为200缓存10分钟,状态码为301,302的缓存5分钟,其他所有内容缓存1分钟等等。
        可以通过purger的功能清理缓存。
        AB测试/个性化需求时应禁用掉浏览器缓存。

五、Nginx黑名单

1.一般配置

1

2

3

4

5

6

7

location / {

    deny  192.168.1.1;

    deny 192.168.1.0/24;

    allow 10.1.1.0/16;

    allow 2001:0db8::/32;

    deny  all;

}

2. Lua+Redis动态黑名单(OpenResty)

1)安装运行

1

2

3

4

5

6

7

8

yum install yum-utils

yum-config-manager --add-repo https://openresty.org/package/centos/openresty.repo

yum install openresty

yum install openresty-resty

查看

yum --disablerepo="*" --enablerepo="openresty" list available

运行

service openresty start

2) 配置(/usr/local/openresty/nginx/conf/nginx.conf)

1

2

3

4

5

6

7

8

9

10

lua_shared_dict ip_blacklist 1m;

 

server {

    listen  80;

 

    location / {

        access_by_lua_file lua/ip_blacklist.lua;

        proxy_pass http://real_server;

    }

}

lua脚本(ip_blacklist.lua)

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

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

local redis_host    = "192.168.1.132"

local redis_port    = 6379

local redis_pwd     = 123456

local redis_db = 2

 

-- connection timeout for redis in ms.

local redis_connection_timeout = 100

 

-- a set key for blacklist entries

local redis_key     = "ip_blacklist"

 

-- cache lookups for this many seconds

local cache_ttl     = 60

 

-- end configuration

 

local ip                = ngx.var.remote_addr

local ip_blacklist      = ngx.shared.ip_blacklist

local last_update_time  = ip_blacklist:get("last_update_time");

 

-- update ip_blacklist from Redis every cache_ttl seconds:

if last_update_time == nil or last_update_time < ( ngx.now() - cache_ttl ) then

 

  local redis = require "resty.redis";

  local red = redis:new();

 

  red:set_timeout(redis_connect_timeout);

 

  local ok, err = red:connect(redis_host, redis_port);

  if not ok then

    ngx.log(ngx.ERR, "Redis connection error while connect: " .. err);

  else

    local ok, err = red:auth(redis_pwd)

    if not ok then

      ngx.log(ngx.ERR, "Redis password error while auth: " .. err);

    else

        local new_ip_blacklist, err = red:smembers(redis_key);

        if err then

            ngx.log(ngx.ERR, "Redis read error while retrieving ip_blacklist: " .. err);

        else

        ngx.log(ngx.ERR, "Get data success:" .. new_ip_blacklist)

          -- replace the locally stored ip_blacklist with the updated values:

            ip_blacklist:flush_all();

          for index, banned_ip in ipairs(new_ip_blacklist) do

            ip_blacklist:set(banned_ip, true);

          end

          -- update time

          ip_blacklist:set("last_update_time", ngx.now());

      end

    end

  end

end

 

if ip_blacklist:get(ip) then

  ngx.log(ngx.ERR, "Banned IP detected and refused access: " .. ip);

  return ngx.exit(ngx.HTTP_FORBIDDEN);

end

六、Nginx灰度发布

  1. 根据Cookie实现灰度发布

根据Cookie查询version值,如果该version值为v1转发到host1,为v2转发到host2,都不匹配的情况下转发默认。

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

29

30

31

32

33

34

35

36

37

upstream host1 {

   server 192.168.2.46:2001 weight=1;  #轮询服务器和访问权重

   server 192.168.2.46:2002 weight=2;

}

 

upstream host2 {

   server 192.168.1.155:1111  max_fails=1 fail_timeout=60;

}

 

upstream default {

   server 192.168.1.153:1111  max_fails=1 fail_timeout=60;

}

 

map $COOKIE_version $group {

   ~*v1$ host1;

   ~*v2$ host2;

   default default;

}

 

lua_shared_dict ip_blacklist 1m;

 

server {

    listen  80;

 

    #set $group "default";

    #if ($http_cookie ~* "version=v1"){

    #    set $group host1;

    #}

    #if ($http_cookie ~* "version=v2"){

    #    set $group host2;

    #}

 

    location / {

        access_by_lua_file lua/ip_blacklist.lua;

        proxy_pass http://$group;

    }

}

2. 根据来路IP实现灰度发布

1

2

3

4

5

6

7

8

9

server {

  ……………

  set $group default;

  if ($remote_addr ~ "192.168.119.1") {

      set $group host1;

  }

  if ($remote_addr ~ "192.168.119.2") {

      set $group host2;

  }

3. 更细粒度灰度发布

可用lua脚本实现,参考开源项目:https://github.com/CNSRE/ABTestingGateway

<think>嗯,用户想了解如何设计一个手机应用架构,这个应用需要调用摄像头扫描条形码,然后把数据传到后端查询商品信息。首先,我得理清楚整个流程涉及的各个部分。可能需要分模块来考虑,比如前端、后端、数据传输这些方面。 首先,前端部分。手机应用需要调用摄像头,所以得考虑权限问题,比如AndroidiOS各自的摄像头权限申请。然后,扫描条形码通常会用第三方库,比如Zxing或者ZBar,或者直接用平台提供的API,比如iOS的AVFoundation。这部分可能需要封装成独立的模块,方便维护更新。 接下来,扫描到条形码后,需要把数据传给后端。这里涉及到网络请求,可能用RESTful API或者GraphQL。数据格式方面,通常用JSON,但也要考虑安全性效率,比如使用HTTPS加密。另外,如果网络好,可能需要离线处理或者重试机制。 后端方面,需要接收请求,验证条形码的有效性,然后查询数据库或者第三方服务获取商品信息。数据库设计要高效,可能需要缓存常用数据,减少查询间。同,要考虑高并发情况,比如用负载均衡或者微服务架构来分散压力。 安全性也是重点。数据传输过程中要加密,防止中间人攻击。用户隐私方面,条形码可能包含敏感信息,需要脱敏处理。另外,后端接口要有身份验证,比如OAuth或者JWT,防止未授权访问。 扩展性方面,未来可能增加其他功能,比如二维码扫描或者图像识别,所以架构要模块化,方便扩展。比如使用微服务,每个功能独立部署,互影响。 测试维护也能忽视。单元测试、集成测试确保各个模块正常工作。监控系统日志,及发现问题。持续集成持续部署(CI/CD)可以自动化流程,提高效率。 可能还需要考虑用户体验,比如扫描的实反馈,处理扫描失败的情况,友好的错误提示。性能优化,比如图片压缩减少传输数据量,后端响应间优化。 参考现有的架构模式,比如MVVM或者Clean Architecture,可以提升代码的可维护性。前后端分离,前端负责UI交互,后端处理业务逻辑数据存储。 最后,结合用户提供的引用,比如引用[1]提到云端处理的应用场景,可能涉及到是否需要在云端进行图像处理,但用户的需求是扫描条形码,可能需要复杂的图像处理,但需要考虑网络传输的影响。引用[2]提到的设备标识用户体系对应关系,可能用于用户登录后同步数据,但当前需求可能需要,过未来扩展可以考虑。引用[3]的逻辑隔离数据分类标签,可能在后端数据处理需要考虑数据的安全存储传输。引用[4]的数据分析功能,可能后续可以加入商品信息的统计分析,但当前主要是查询功能。 总结一下,架构需要分层次,模块化设计,考虑前后端的通信,安全性扩展性,同优化用户体验性能。</think>### 手机应用扫描条形码查询商品信息的架构设计方案 #### 一、分层架构设计 1. **客户端层(Mobile Client)** - **摄像头调用模块** 使用平台原生API(Android CameraX/iOS AVFoundation)或跨平台框架(如Flutter Camera插件)实现摄像头控制,需动态申请摄像头权限[^3]。 ```dart // Flutter示例:调用摄像头并绑定预览界面 CameraController( const CameraDescription( name: '0', lensDirection: CameraLensDirection.back, sensorOrientation: 90), ResolutionPreset.medium, ); ``` - **条码识别模块** 集成开源库(ZBar、ZXing)或平台原生API(ML Kit Barcode Scanning),需独立封装解码逻辑以支持多格式(EAN-13、QR Code等)。 2. **服务网关层(API Gateway)** - 使用Nginx/Kong实现负载均衡与请求路由 - 配置SSL/TLS加密传输,支持HTTPS协议[^3] - 请求频率限制(如每分钟100次/设备) 3. **业务逻辑层(Backend Service)** - **条码验证服务** 校验规则:$$ \text{valid}(code) = \begin{cases} \text{true}, & \text{符合GS1标准且校验位正确} \\ \text{false}, & \text{其他情况} \end{cases} $$ - **商品查询服务** 对接本地数据库(MySQL商品表)或第三方API(阿里云商品库),采用Redis缓存热点数据,缓存策略:$$ TTL=300s $$ 4. **数据存储层(Data Storage)** - 结构化数据:MySQL商品表(主键`barcode`,字段含名称/价格/厂商) - 非结构化数据:MinIO存储商品图片 - 日志数据:Elasticsearch存储请求日志 #### 二、关键流程实现 1. **扫描优化方案** - 动态分辨率适配:根据设备性能选择$$ 1920\times1080 \ \text{或} \ 1280\times720 $$ - 图像预处理流水线:灰度化→高斯滤波→自适应二值化 - 多帧分析策略:连续3帧解码一致视为有效结果 2. **数据传输协议** - 请求体设计: ```json { "barcode": "6901234567890", "geo": "121.47,31.23", "device_id": "a1b2c3d4" } ``` - 响应体设计: ```json { "status": 200, "data": { "name": "商品名称", "price": 19.99, "manufacturer": "生产厂商" } } ``` #### 三、容错与安全设计 1. **异常处理机制** - 网络重试策略:指数退避算法(最大重试3次) - 无效条码过滤:黑名单机制(Redis存储异常条码) 2. **安全防护** - 敏感数据脱敏:商品价格字段加密传输 - 接口鉴权:JWT令牌验证,签名算法:$$ HMAC-SHA256(secret, payload) $$ - 输入过滤:正则表达式验证条码格式:$$ ^\d{13}$ $$ #### 四、性能优化建议 1. 客户端启用WebP图片压缩(压缩率30%-50%) 2. 服务端采用gRPC协议提升传输效率 3. 数据库查询优化:为`barcode`字段建立B+树索引
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值