1 微服务系统监控

1.1 监控系统的意义

微服务系统监控对于一个企业来说非常重要，因为它能够提供以下几个方面的价值：

1、提高系统稳定性和可靠性：微服务架构中的每个服务都是独立的，因此出现故障的概率也会增加。监控系统可以实时地检测并报告各个服务的状态和性能数据，及时发现并解决问题，提高系统的稳定性和可靠性。

2、提高服务质量和用户体验：微服务系统监控可以帮助企业追踪和分析服务性能数据，如响应时间、请求成功率、错误率等，从而了解服务的运行情况，并及时采取措施来提高服务质量和用户体验。

3、提高运维效率和降低成本：微服务系统监控可以自动收集和分析各个服务的运行数据，帮助企业快速发现和解决问题，从而提高运维效率并降低成本。此外，监控数据还可以帮助企业优化资源分配和容量规划，减少资源浪费和成本开销。

4、帮助企业预测和规避风险：微服务系统监控可以帮助企业实时了解服务的运行情况，预测和规避可能出现的问题和风险，保障系统的稳定性和可靠性，从而避免损失和影响

总之，微服务系统监控可以帮助企业及时发现和解决问题，提高系统稳定性和可靠性，优化服务质量和用户体验，提高运维效率和降低成本，预测和规避风险，是企业微服务架构中不可或缺的一部分。

1.2 SBA监控方案

官网地址：https://docs.spring-boot-admin.com/

Spring Boot Admin：Spring Boot Admin是一个用于管理和监控Spring Boot应用程序的开源项目。它提供了一个用户友好的Web界面，可以方便地查看和管理运行中的Spring Boot应用程序。

Spring Boot Admin具有以下主要功能：

1、应用程序监控：Spring Boot Admin可以监控注册到其上的Spring Boot应用程序的运行状态、健康状况、内存使用情况、线程信息等。它通过与Spring Boot Actuator集成来获取这些信息，并以可视化的方式展示在管理界面上。

2、集中式配置管理：Spring Boot Admin允许您在管理界面上对注册的Spring Boot应用程序进行配置管理。您可以动态修改应用程序的配置属性，而无需重新启动应用程序。

3、日志管理：Spring Boot Admin提供了对应用程序日志的集中式管理和查看功能。您可以在管理界面上查看应用程序的日志输出，并根据需要进行搜索和过滤。

4、通知和告警：Spring Boot Admin支持通过电子邮件、Slack等方式发送通知和告警。您可以设置特定的规则和阈值，当应用程序达到或超过这些规则时，将会触发相应的通知。

5、安全性和权限控制：Spring Boot Admin提供了安全性和权限控制机制，可以限制对管理界面的访问，并为不同的用户或角色分配不同的权限。

Spring Boot Admin是一个基于客户端-服务器架构的应用程序管理和监控工具。它由两个主要组件组成：Admin Server（服务器）和Admin Client（客户端）。

1、Admin Server（服务器）： Admin Server是Spring Boot Admin的核心组件，负责提供Web界面和API接口，用于管理和监控注册到其上的Spring Boot应用程序。Admin Server通过HTTP或HTTPS与Admin Client进行通信，并收集应用程序的运行状态、健康状况、配置信息、日志等数据。它还提供了用户认证和权限控制机制，以确保安全访问。

2、Admin Client（客户端）： Admin Client是被管理的Spring Boot应用程序，它通过将Spring Boot Actuator与Admin Server集成来实现与Admin Server的通信。Admin Client在启动时会向Admin Server注册自己，并定期发送心跳信息和应用程序的运行状态、健康状况等数据给Admin Server。Admin Client还可以接收来自Admin Server的命令和配置更新，并根据需要执行相应的操作。

1.3 SBA实战

1.3.1 创建SBA服务端

具体步骤：

1、在cloud-parent下创建一个监控微服务(cloud-sba)，加入如下依赖：

<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-server</artifactId>
    <version>3.1.0</version>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

2、编写启动类

@SpringBootApplication
@EnableAdminServer
public class AdminApplication {

    public static void main(String[] args) {
        SpringApplication.run(AdminApplication.class , args) ;
    }

}

3、创建配置文件

# application.yml文件内容
server:
  port: 20100
spring:
  application:
    name: spzx-cloud-sba
  cloud:
    nacos:
      discovery:
        server-addr: 192.168.136.142:8848

4、启动监控服务，通过http://localhost:20100访问监控服务后台管理系统

1.3.2 微服务集成SBA

具体步骤如下所示：

1、在spzx-cloud-parent模块中添加如下依赖

<dependency>
    <groupId>de.codecentric</groupId>
    <artifactId>spring-boot-admin-starter-client</artifactId>
    <version>3.1.0</version>
</dependency>

2、在指定的微服务配置文件中加入如下依赖

management:
  endpoints:
    web:
      exposure:
        include: "*"    # 开启所有需要监控的指标端点
  endpoint:
    health:
      show-details: always

3、重启微服务，通过sba服务端查看微服务相关信息

注意：如果显示服务offline，开启飞行模式，重启微服务再次查看

1.4 微服务集成logback

在resources目录下创建一个logback-spring.xml文件，内容如下所示：

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="60 seconds" debug="false">

    <!-- 日志存放路径 -->
    <property name="log.path" value="F://logs/spzx-cloud-order" />

    <!-- 日志输出格式 -->
    <property name="log.pattern" value="%d{HH:mm:ss.SSS} [%thread] %-5level %logger{20} - [%method,%line] - %msg%n" />

    <!-- 控制台输出 -->
    <appender name="console" class="ch.qos.logback.core.ConsoleAppender">
        <encoder>
            <pattern>%highlight${log.pattern}</pattern>
        </encoder>
    </appender>

    <!-- 系统日志输出 -->
    <appender name="file_info" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${log.path}/info.log</file>
        <!-- 循环政策：基于时间创建日志文件 -->
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <!-- 日志文件名格式 -->
            <fileNamePattern>${log.path}/info.%d{yyyy-MM-dd}.log</fileNamePattern>
            <!-- 日志最大的历史 30天 -->
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder>
            <pattern>${log.pattern}</pattern>
        </encoder>
    </appender>

    <!-- 系统模块日志级别控制  -->
    <logger name="com.atguigu" level="info" />

    <!-- Spring日志级别控制  -->
    <logger name="org.springframework" level="warn" />

    <root level="info">
        <appender-ref ref="console" />
        <appender-ref ref="file_info" />
    </root>

</configuration>

在application.yml配置文件中添加如下配置

management:
  endpoint:
    logfile:
      external-file: F://logs/spzx-cloud-order//info.log

此时就可以在SBA的监控界面查询到Spring Boot应用所产生的配置文件。

1.5 配置邮件告警

Spring Boot Admin 可以与多种告警系统集成，例如 PagerDuty、Slack、邮件等，以便在应用程序状态异常时通知管理员。在这里，我将为您介绍如何在 Spring Boot Admin 中集成邮件告警功能。

具体步骤如下所示： XZREOKNYIMQRPHSA

1、开通邮件服务器(以163邮箱为例说明)

按照提示操作，会得到一个授权码，后期发送邮件的时候需要使用，注意授权码只会显示一次：

2、在SBA服务端添加如下依赖

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-mail</artifactId>
</dependency>

3、在配置文件中添加如下配置

spring:
  mail:
    host: smtp.163.com
    port: 465
    username: hly_atguigu@163.com
    password: JKMBEQUUBDJUEAXX
    properties:
      mail:
        smtp:
          auth: true
          starttls:   # 使用 SSL 安全协议，须如下配置
            enable: true
            required: true
    protocol: smtps   # 465端口使用的通讯协议为smtps
  boot:
    admin:
      notify:
        mail:
          to: hly_atguigu@163.com
          from: hly_atguigu@163.com
          enabled: true
        filter:
          health-status: DOWN       # 邮件通知策略，当微服务下线的时候发送通知邮件
      monitor:
        default-timeout: 30000

重启SBA服务，手动下线spzx-cloud-order进行测试。

2 Nginx

2.1 Nginx简介

Nginx是一款轻量级的Web服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx的网站有：百度、京东、新浪、网易、腾讯、淘宝等。

Nginx是由伊戈尔·赛索耶夫为俄罗斯访问量第二的Rambler.ru站点（俄文：Рамблер）开发的，第一个公开版本0.1.0发布于2004年10月4日。

官网：https://nginx.org/

2.2 下载和安装

2.2.1 方式1：window本地安装

2.2.1.1 下载

在Nginx的官网的下载页面中(http://nginx.org/en/download.html)，就展示了当前Nginx版本，并提供了下载的连接。 如下：

在本项目中，我们所学习的Nginx选择的是windows版本的稳定版本的1.24.0这个版本，我们可以直接从官网下载，当然在我们的课程资料中也已经提供了该版本的安装包。

2.2.1.2 安装

windows版本的nginx安装比较简单，只需要将其解压到一个不带中文的目录下即可。

2.2.1.3 目录结构

安装完Nginx后，我们可以切换到Nginx的安装目录，先来熟悉一下Nginx的目录结构，如下图：

重点目录和文件如下:

目录/文件	说明	备注
conf	配置文件的存放目录
conf/nginx.conf	Nginx的核心配置文件	conf下有很多nginx的配置文件，我们主要操作这个核心配置文件
html	存放静态资源(html, css, )	部署到Nginx的静态资源都可以放在html目录中
logs	存放nginx日志(访问日志、错误日志等)
nginx.exe	二进制文件，用于启动、停止Nginx服务

2.2.1.4 常用命令

Nginx中，我们的二进制可执行文件就是nginx.exe，虽然只有一个可执行文件，但是我们可以通过该指令配合不同的参数达到更加强大的功能。接下来，我们就演示一下Nginx常见指令, 在执行下面的指令时,都需要在nginx的安装目录下执行。

常用命令如下所示：

nginx -v     						# 查看nginx的版本
nginx -t							# 检测配置文件
nginx								# 启动nginx、nginx启动成功以后会有两个进程， 也可以通过直接双击exe文件进行启动

nginx启动成功以后，我们可以直接访问Nginx的80端口， http://localhost

nginx -s stop                   # 停止nginx服务
nginx -s reload				  # 重新加载nginx的配置文件

注意：windows系统nginx经常无法正常关闭，可以查找端口占用进程并杀死进程

netstat -ano | findstr 端口号
taskkill /f /pid 进程id

2.2.2 docker安装

2.2.2.1 创建nginx容器

#拉取镜像
docker pull nginx:latest

#运行nginx镜像:  
docker run -d -p 80:80 \
--name sc-nginx \
-v nginx-html:/usr/share/nginx/html \
-v nginx-conf:/etc/nginx/ \
-v nginx-logs:/var/log/nginx  nginx

2.2.2.2 目录结构

#  查看nginx的挂载卷目录
docker volume ls |grep nginx
# nginx配置文件目录
#local     nginx-conf
# nginx静态页面目录
#local     nginx-html
# nginx日志目录
#local     nginx-logs

2.5 Nginx应用

介绍了并安装了Nginx之后，本章节将要讲解的是Nginx的使用，我们主要从以下四个方面进行讲解。

2.5.1 配置文件结构

nginx的配置文件(conf/nginx.conf)整体上分为三部分: 全局块、events块、http块。这三块的分别配置什么样的信息呢，看下表：

nginx配置文件查看：

view /var/lib/docker/volumes/nginx-conf/_data/nginx.conf

区域	职责
全局块	配置和nginx运行相关的全局配置
events块	配置和网络连接相关的配置
http块	配置代理、缓存、日志记录、虚拟主机等配置

具体结构图如下:

注意：在全局块、events块以及http块中，我们经常配置的是http块。在http块中可以包含多个server块,每个server块可以配置多个location块。

2.5.2 部署静态资源

概念介绍

Nginx可以作为静态web服务器来部署静态资源。这里所说的静态资源是指在服务端真实存在，并且能够直接展示的一些文件，比如常见的html页面、css文件、js文件、图片、视频等资源。

相对于Tomcat，Nginx处理静态资源的能力更加高效，所以在生产环境下，一般都会将静态资源部署到Nginx中。

将静态资源部署到Nginx非常简单，只需要将文件复制到Nginx安装目录下的html目录中即可。

server {
    listen 80;				#监听端口	
    server_name localhost;	#服务器名称
    location / {			#匹配客户端请求url
        root html;			#指定静态资源根目录
        index index.html;	#指定默认首页
    }
}

在资料中，我们提供了一个静态的html文件，我们需要将这个文件部署到nginx中，然后通过nginx访问html静态资源。

案例演示

在资料中，我们提供了一个静态的html文件，我们需要将这个文件部署到nginx中，然后通过nginx访问html静态资源。

1、将静态资源复制到 nginx安装目录的html目录中

2、启动nginx

3、打开浏览器进行访问：输入http://localhost/hello.html。

4、配置首页，当输入http://localhost地址的时候，默认访问的首页，首页的配置如下所示：

如果我们需要将hello.html作为nginx的首页，可以修改location的index指令，配置为hello.html，如下：

配置完毕后，我们可以通过指令，来检查配置文件是否配置正确： nginx -t

配置文件修改了，我们需要重新加载一下，才可以生效：

# windows
nginx.exe -s reload
# docker
docker restart sc-nginx

5、访问：http://192.168.1.170

2.5.3 反向代理

概念介绍

正向代理

正向代理服务器是一个位于客户端和原始服务器(origin server)之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标(原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。

正向代理的典型用途是为在防火墙内的局域网客户端提供访问Internet的途径。

正向代理一般是在客户端设置代理服务器，通过代理服务器转发请求，最终访问到目标服务器。在使用代理服务器的时候需要在客户端进行代理服务器地址的相关配置。

反向代理

反向代理服务器位于用户与目标服务器之间，但是对于用户而言，反向代理服务器就相当于目标服务器，即用户直接访问反向代理服务器就可以获得目标服务器的资源，反向代理服务器负责将请求转发给目标服务器。用户不需要知道目标服务器的地址，也无须在用户端作任何设定，对于用户来说，访问反向代理服务器是完全无感知的。

那么在本小节，我们就是要使用nginx来作为反向代理服务器使用。 在nginx中，我们可以在nginx.conf中配置反向代理:

server {
    listen 82;
    server_name localhost;
    location / {
        proxy_pass http://localhost:8081; 	# 反向代理配置，将请求转发到指定服务[网关服务]
    }
}

上述配置的含义为: 当我们访问nginx的82端口时，根据反向代理配置，会将请求转发到 http://localhost:8081 对应的服务上。

案例演示

1、整体访问流程介绍

2、启动相关微服务(spzx-cloud-gateway、spzx-cloud-user)

3、在nginx中配置反向代理

找到nginx的配置文件nginx.conf，在http块中,再添加一个server块虚拟主机的配置,监听82端口,并配置反向代理proxy_pass:

server {
    listen 82;
    server_name localhost;
    location / {
        proxy_pass http://localhost:8081; 	# 反向代理配置，将请求转发到指定服务[网关服务]
    }
}

4、检查配置文件，并重新加载

nginx -t   				# 检查配置文件是否正确
nginx -s reload			# 重新加载配置文件

5、访问： localhost:82/api/user/findUserByUserId/1?authorization=admin

2.5.4 负载均衡

概念介绍

早期的网站流量和业务功能都比较简单，单台服务器就可以满足基本需求，但是随着互联网的发展，业务流量越来越大并且业务逻辑也越来越复杂，单台服务器的性能及单点故障问题就凸显出来了，因此需要多台服务器组成应用集群，进行性能的水平扩展以及避免单点故障出现。

**应用集群：**将同一应用部署到多台机器上，组成应用集群，接收负载均衡器分发的请求，进行业务处理并返回响应数据

**负载均衡器：**将用户请求根据对应的负载均衡算法分发到应用集群中的一台服务器进行处理

此处的负载均衡器，我们将会使用Nginx来实现，而Nginx的负载均衡是基于反向代理的，只不过此时所代理的服务器不是一台，而是多台。

案例演示

1、启动两个spzx-cloud-gateway服务，端口号分别是8081和8082，可以通过配置启动参数进行实现：-Dserver.port=8081

2、在nginx中配置负载均衡

打开nginx的配置文件nginx.conf并增加如下配置:

#upstream指令可以定义一组服务器
upstream targetserver{	
    server localhost:8081;
    server localhost:8082;
}

server {
    listen       83;
    server_name  localhost;
    location / {
        proxy_pass http://targetserver;
    }
}

3、检查配置文件，并重新加载

nginx -t   				# 检查配置文件是否正确
nginx -s reload			# 重新加载配置文件

4、测试时,我们直接访问nginx的8080端口(http://localhost:83/api/user/findUserByUserId/1?authorization=admin), 此时nginx会根据负载均衡策略,将请求转发到后面的两台服务器。

负载均衡算法

常见算法介绍

在nginx中提供了很多的负载均衡算法，常见的负载均衡算法如下所示：

名称	说明	特点
round robin	轮询方式	默认的负载均衡算法，按照请求的顺序依次分配给后端服务器。
random	随机	随机选择一个后端服务器来处理请求
url_hash	依据url分配方式	根据客户端请求url的hash值，来分发请求, 同一个url请求, 会发转发到同一个服务器上
ip_hash	依据ip分配方式	根据客户端请求的IP地址计算hash值， 根据hash值来分发请求, 同一个IP发起的请求, 会发转发到同一个服务器上
weight	权重方式	根据权重分发请求,权重大的分配到请求的概率大
least_conn	依据最少连接方式	哪个服务器当前处理的连接少, 请求优先转发到这台服务器

random算法

#upstream指令可以定义一组服务器
upstream targetserver {
	random;
    server localhost:8081;
    server localhost:8082;
}

url_hash算法

#upstream指令可以定义一组服务器
upstream targetserver {
	hash $request_uri;
    server localhost:8081;
    server localhost:8082;
}

ip_hash算法

#upstream指令可以定义一组服务器
upstream targetserver {
	ip_hash;
    server localhost:8081;
    server localhost:8082;
}

weight算法

#upstream指令可以定义一组服务器
upstream targetserver {
    server localhost:8081 weight=5;
    server localhost:8082 weight=1; 
}

least_conn算法

#upstream指令可以定义一组服务器
upstream targetserver {
	least_conn;
    server localhost:8081 ;
    server localhost:8082 ; 
}

2.5.5 完整配置参考

#安全问题，建议用nobody,不要用root.
#user  nobody;

#worker数和服务器的cpu数相等是最为适宜
worker_processes  2;

#work绑定cpu(4 work绑定4cpu)
worker_cpu_affinity 0001 0010 0100 1000

#work绑定cpu (4 work绑定8cpu中的4个) 。
worker_cpu_affinity 0000001 00000010 00000100 00001000  

#error_log path(存放路径) level(日志等级) path表示日志路径，level表示日志等级，
#具体如下：[ debug | info | notice | warn | error | crit ]
#从左至右，日志详细程度逐级递减，即debug最详细，crit最少，默认为crit。 

#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid;

events {
    #这个值是表示每个worker进程所能建立连接的最大值，所以，一个nginx能建立的最大连接数，应该是worker_connections * worker_processes。
    #当然，这里说的是最大连接数，对于HTTP请求本地资源来说，能够支持的最大并发数量是worker_connections * worker_processes，
    #如果是支持http1.1的浏览器每次访问要占两个连接，
    #所以普通的静态访问最大并发数是： worker_connections * worker_processes /2，
    #而如果是HTTP作为反向代理来说，最大并发数量应该是worker_connections * worker_processes/4。
    #因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。

    worker_connections  1024;  

    #这个值是表示nginx要支持哪种多路io复用。
    #一般的Linux选择epoll, 如果是(*BSD)系列的Linux使用kquene。
    #windows版本的nginx不支持多路IO复用，这个值不用配。
    use epoll;

    # 当一个worker抢占到一个链接时，是否尽可能的让其获得更多的连接,默认是off 。
    multi_accept on; //并发量大时缓解客户端等待时间。

    # 默认是on ,开启nginx的抢占锁机制。
    accept_mutex  on; //master指派worker抢占锁
} 

http {
    #当web服务器收到静态的资源文件请求时，依据请求文件的后缀名在服务器的MIME配置文件中找到对应的MIME Type，再根据MIME Type设置HTTP Response的Content-Type，然后浏览器根据Content-Type的值处理文件。 
    include       mime.types;  #/usr/local/nginx/conf/mime.types
    #如果 不能从mime.types找到映射的话，用以下作为默认值-二进制
    default_type  application/octet-stream;
    #日志位置
    access_log  logs/host.access.log  main;
    #一条典型的accesslog：
    #101.226.166.254 - - [21/Oct/2013:20:34:28 +0800] "GET /movie_cat.php?year=2013 HTTP/1.1" 200 5209 "http://www.baidu.com" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MDDR; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322; Tablet PC 2.0); 360Spider"

    #1）101.226.166.254:(用户IP)
    #2）[21/Oct/2013:20:34:28 +0800]：(访问时间) 
    #3）GET：http请求方式，有GET和POST两种
    #4）/movie_cat.php?year=2013：当前访问的网页是动态网页，movie_cat.php即请求的后台接口，year=2013为具体接口的参数
    #5）200：服务状态，200表示正常，常见的还有，301永久重定向、4XX表示请求出错、5XX服务器内部错误
    #6）5209：传送字节数为5209，单位为byte
    #7）"http://www.baidu.com"：refer:即当前页面的上一个网页
    #8）"Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; #.NET CLR 3.0.30729; Media Center PC 6.0; MDDR; .NET4.0C; .NET4.0E; .NET CLR 1.1.4322; Tablet PC 2.0); 360Spider"： agent字段：通常用来记录操作系统、浏览器版本、浏览器内核等信息

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
        '$status $body_bytes_sent "$http_referer" '
        '"$http_user_agent" "$http_x_forwarded_for"';

    #开启从磁盘直接到网络的文件传输，适用于有大文件上传下载的情况，提高IO效率。
    sendfile        on; //大文件传递优化，提高效率

        #一个请求完成之后还要保持连接多久, 默认为0，表示完成请求后直接关闭连接。
        #keepalive_timeout  0;
        keepalive_timeout  65; 

    #开启或者关闭gzip模块
    #gzip  on ; //文件压缩，再传输，提高效率

    #设置允许压缩的页面最小字节数，页面字节数从header头中的Content-Length中进行获取。
    #gzip_min_lenth 1k;//超过该大小开始压缩，否则不用压缩

    # gzip压缩比，1 压缩比最小处理速度最快，9 压缩比最大但处理最慢（传输快但比较消耗cpu）
    #gzip_comp_level 4;

    #匹配MIME类型进行压缩，（无论是否指定）"text/html"类型总是会被压缩的。
    #gzip_types types text/plain text/css application/json  application/x-javascript text/xml   

    #动静分离
    #服务器端静态资源缓存，最大缓存到内存中的文件，不活跃期限
    open_file_cache max=655350 inactive=20s;   

    #活跃期限内最少使用的次数，否则视为不活跃。
    open_file_cache_min_uses 2;

    #验证缓存是否活跃的时间间隔 
    open_file_cache_valid 30s;

    upstream myserver{
        # 1、轮询（默认）
        # 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
        # 2、指定权重
        # 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
        #3、IP绑定 ip_hash
        # 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
        #4、备机方式 backup
        # 正常情况不访问设定为backup的备机，只有当所有非备机全都宕机的情况下，服务才会进备机。当非备机启动后，自动切换到非备机
        # ip_hash;
        server 192.168.161.132:8080 weight=1;
        server 192.168.161.132:8081 weight=1 backup;
        #5、fair（第三方）公平，需要安装插件才能用
        #按后端服务器的响应时间来分配请求，响应时间短的优先分配。   
        #6、url_hash（第三方）
        #按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。
        # ip_hash;
        server 192.168.161.132:8080 weight=1;
        server 192.168.161.132:8081 weight=1;
        #fair
        #hash $request_uri
        #hash_method crc32
    }
    #保留代理之前的host 包含客户端真实的域名和端口号
    proxy_set_header    Host  $host; 
    #保留代理之前的真实客户端ip
    proxy_set_header    X-Real-IP  $remote_addr; 
    #这个Header和X-Real-IP类似，但它在多级代理时会包含真实客户端及中间每个代理服务器的IP
    proxy_set_header    X-Forwarded-For  $proxy_add_x_forwarded_for;
    #表示客户端真实的协议（http还是https）
    proxy_set_header X-Forwarded-Proto $scheme;
    server {
        #监听端口号
        listen       80;
        #服务名
        server_name  192.168.161.130;
        #字符集
        #charset utf-8;
        #location [=|~|~*|^~] /uri/ { … }   
        # = 精确匹配
        # ~ 正则匹配，区分大小写
        # ~* 正则匹配，不区分大小写
        # ^~  关闭正则匹配
        #匹配原则：
        # 1、所有匹配分两个阶段，第一个叫普通匹配，第二个叫正则匹配。
        # 2、普通匹配，首先通过“=”来匹配完全精确的location
        #   2.1、 如果没有精确匹配到， 那么按照最大前缀匹配的原则，来匹配location
        #   2.2、 如果匹配到的location有^~,则以此location为匹配最终结果，如果没有那么会把匹配的结果暂存，继续进行正则匹配。
        # 3、正则匹配，依次从上到下匹配前缀是~或~*的location, 一旦匹配成功一次，则立刻以此location为准，不再向下继续进行正则匹配。
        # 4、如果正则匹配都不成功，则继续使用之前暂存的普通匹配成功的location.
        #不是以波浪线开头的都是普通匹配。
        location ~  /(css|data|fonts|img|js){
            root /opt/static;
        }

        location / {   # 匹配任何查询，因为所有请求都以 / 开头。但是正则表达式规则和长的块规则将被优先和查询匹配。
            # nginx上传文件大小限制
            client_max_body_size 600M;
            client_body_buffer_size 600M;
            #定义服务器的默认网站根目录位置
            #相对路径，省略了./  
            root   html;
            #绝对路径 /user/local/nginx/html  
            root /user/local/nginx/html;
            #默认访问首页索引文件的名称
            index  index.html index.html;
            #反向代理路径
            proxy_pass http://myserver;
            #反向代理的超时时间
            proxy_connect_timeout 10;
            proxy_redirect default;
        }
        #普通匹配
        location  /images/ {    
            root images ;
        }
        # 反正则匹配
        location ^~ /images/jpg/ {  # 匹配任何以 /images/jpg/ 开头的任何查询并且停止搜索。任何正则表达式将不会被测试。 
            root images/jpg/ ;
        }
        #正则匹配
        location ~*.(gif|jpg|jpeg)$ {       
            #所有静态文件直接读取硬盘
            root pic ;
            #expires定义用户浏览器缓存的时间为3天，如果静态页面不常更新，可以设置更长，这样可以节省带宽和缓解服务器的压力
            expires 3d; #缓存3天
        }
        #error_page  404              /404.html;
        # redirect server error pages to the static page /50x.html
        #
        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   html;
        } 
    }
}