1、请简述 OSI 七层网络模型有哪些层及各自的含义？
物理层：底层数据传输，比如网线、网卡标准
数据链路层：定义数据的基本格式，如何传输，如何标识。比如网卡 MAC 地址
网络层：定义 IP 编码，定义路由功能，比如不同设备的数据转发
传输层：端到端传输数据的基本功能，比如 TCP、UDP
会话层：控制应用程序之间会话能力，比如不同软件数据分发给不停软件
表示层：数据格式标识，基本压缩加密功能。
应用层：各种应用软件，包括 Web 应用。
这个分 3 种
第一种方法:
AI助手
资讯
常用工具
网站模板growpart /dev/vda 1
resize2fs /dev/vda1
第二种方法:
partpeobe /dev/sda
resize2fs /dev/vda1
第三种方法:
fdisk /dev/sdb # n p 1 1 回车 回车 t 8e w
pvcreate /dev/sdb1
vgextend datavg /dev/sdb1
lvextend -r -L +100%free /dev/mapper/datavg-lv01
8005 关闭时使用
8009 为 AJP 端口，即容器使用，如 Apache 能通过 AJP 协议访问 Tomcat 的 8009 端口来实现功能
8080 一般应用使用
迭代查询（返回最优结果）、递归查询（本地找 DNS）用户要访问 www.baidu.com，会先找本机的 host 文件，再找本地设置的 DNS 服务器，如果也没有找到，就去网络中找根服务器，根服务器反馈结果，说只能提供一级域名服务器.cn，就去找一级域名服务器，一级域名服务器说只能提供二级域名服务器.com.cn, 就去找二级域名服务器，二级域服务器只能提供三级域名服务器.baidu.com.cn，就去找三级域名服务器，三级域名服务器正好有这个网站 www.baidu.com，然后发给请求的服务器，保存一份之后，再发给客户端。
在一个虚拟路由器中，只有作为 MASTER 的 VRRP (虚拟路由冗余协议) 路由器会一直发送 VRRP 通告信息，BACKUP 不会抢占 MASTER，除非它的优先级更高。当 MASTER 不可用时 (BACKUP 收不到通告信息) 多台 BACKUP 中优先级最高的这台会被抢占为 MASTER。这种抢占是非常快速的 (<1s)，以保证服务的连续性由于安全性考虑，VRRP 包使用了加密协议进行加密。BACKUP 不会发送通告信息，只会接收通告信息。
LVS：
抗负载能力强、工作在第 4 层仅作分发之用，没有流量的产生，这个特点也决定了它在负载均衡软件里的性能最强的；无流量，同时保证了均衡器 IO 的性能不会受到大流量的影响；
工作稳定，自身有完整的双机热备方案，如 LVS+Keepalived 和 LVS+Heartbeat；
应用范围比较广，可以对所有应用做负载均衡；
配置简单，因为没有可太多配置的东西，所以并不需要太多接触，大大减少了人为出错的几率；
LVS 的缺点：
软件本身不支持正则处理，不能做动静分离，这就凸显了 Nginx/HAProxy+Keepalived 的优势。
如果网站应用比较庞大，LVS/DR+Keepalived 就比较复杂了，特别是后面有 Windows Server 应用的机器，实施及配置还有维护过程就比较麻烦，相对而言，Nginx/HAProxy+Keepalived 就简单多了。
Nginx：
工作在第 7 层，应用层，可以针对 http 应用做一些分流的策略。比如针对域名、目录结构。它的正则比 HAProxy 更为强大和灵活；
Nginx 对网络的依赖非常小，理论上能 ping 通就就能进行负载功能
Nginx 安装和配置简单
可以承担高的负载压力且稳定，一般能支撑超过几万次的并发量；
Nginx 不仅仅是一款优秀的负载均衡器 / 反向代理软件，它同时也是功能强大的 Web 应用服务器。Nginx 在处理静态页面、特别是抗高并发方面相对 apache 有优势；
Nginx 作为 Web 反向代理加速缓存越来越成熟，速度比传统的 Squid 服务器更快
Nginx 的缺点：
Nginx 不支持 url 来检测。
Nginx 仅能支持 http、https 和 Email 协议
Nginx 的 Session 的保持，Cookie 的引导能力相对欠缺。
HAProxy：
HAProxy 是支持虚拟主机的，可以工作在 4、7 层 (支持多网段)；
能够补充 Nginx 的一些缺点比如 Session 的保持，Cookie 的引导等工作；
支持 url 检测后端的服务器；
它跟 LVS 一样，本身仅仅就只是一款负载均衡软件；单纯从效率上来讲 HAProxy 更会比 Nginx 有更出色的负载均衡速度，在并发处理上也是优于 Nginx 的；
HAProxy 可以对 Mysql 读进行负载均衡，对后端的 MySQL 节点进行检测和负载均衡，不过在后端的 MySQL slaves 数量超过 10 台时性能不如 LVS；
HAProxy 的算法较多，达到 8 种；
工作选择：
HAproxy 和 Nginx 由于可以做七层的转发，所以 URL 和目录的转发都可以做在很大并发量的时候我们就要选择 LVS，像中小型公司的话并发量没那么大选择 HAproxy 或者 Nginx 足已，由于 HAproxy 由是专业的代理服务器配置简单，所以中小型企业推荐使用 HAproxy。
docker 是一个 Client-Server 结构的系统，docker 守护进程运行在宿主机上，守护进程从客户端接受命令并管理运行在主机上的容器，容器是一个运行时环境，这就是我们说的集装箱。
一个完整的 docker 有以下几个部分组成：
docker client，客户端，为用户提供一系列可执行命令，用户用这些命令实现跟 docker daemon 交互；
docker daemon，守护进程，一般在宿主主机后台运行，等待接收来自客户端的请求消息；
docker image，镜像，镜像 run 之后就生成为 docker 容器；
docker container，容器，一个系统级别的服务，拥有自己的 ip 和系统目录结构；运行容器前需要本地存在对应的镜像，如果本地不存在该镜像则就去镜像仓库下载。
docker 使用客户端 - 服务器 (C/S) 架构模式，使用远程 api 来管理和创建 docker 容器。docker 容器通过 docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。
传统虚拟机是需要安装整个操作系统的，然后再在上面安装业务应用，启动应用，通常需要几分钟去启动应用，而 docker 是直接使用镜像来运行业务容器的，其容器启动属于秒级别；
Docker 需要的资源更少，Docker 在操作系统级别进行虚拟化，Docker 容器和内核交互，几乎没有性能损耗，而虚拟机运行着整个操作系统，占用物理机的资源就比较多；
Docker 更轻量，Docker 的架构可以共用一个内核与共享应用程序库，所占内存极小；同样的硬件环境，Docker 运行的镜像数远多于虚拟机数量，对系统的利用率非常高；
与虚拟机相比，Docker 隔离性更弱，Docker 属于进程之间的隔离，虚拟机可实现系统级别隔离；
Docker 的安全性也更弱，Docker 的租户 root 和宿主机 root 相同，一旦容器内的用户从普通用户权限提升为 root 权限，它就直接具备了宿主机的 root 权限，进而可进行无限制的操作。虚拟机租户 root 权限和宿主机的 root 虚拟机权限是分离的，并且虚拟机利用如 Intel 的 VT-d 和 VT-x 的 ring-1 硬件隔离技术，这种技术可以防止虚拟机突破和彼此交互，而容器至今还没有任何形式的硬件隔离；
Docker 的集中化管理工具还不算成熟，各种虚拟化技术都有成熟的管理工具，比如：VMware vCenter 提供完备的虚拟机管理能力；
Docker 对业务的高可用支持是通过快速重新部署实现的，虚拟化具备负载均衡，高可用、容错、迁移和数据保护等经过生产实践检验的成熟保障机制，Vmware 可承诺虚拟机 99.999% 高可用，保证业务连续性；
虚拟化创建是分钟级别的，Docker 容器创建是秒级别的，Docker 的快速迭代性，决定了无论是开发、测试、部署都可以节省大量时间；
虚拟机可以通过镜像实现环境交付的一致性，但镜像分发无法体系化，Docker 在 Dockerfile 中记录了容器构建过程，可在集群中实现快速分发和快速部署。from wljslmz
镜像：镜像是一种轻量级、可执行的独立软件包，它包含运行某个软件所需的所有内容，我们把应用程序和配置依赖打包好形成一个可交付的运行环境 (包括代码、运行时需要的库、环境变量和配置文件等)，这个打包好的运行环境就是 image 镜像文件。
容器：容器是基于镜像创建的，是镜像运行起来之后的一个实例，容器才是真正运行业务程序的地方。如果把镜像比作程序里面的类，那么容器就是对象。
镜像仓库：存放镜像的地方，研发工程师打包好镜像之后需要把镜像上传到镜像仓库中去，然后就可以运行有仓库权限的人拉取镜像来运行容器了。
一个完整的 Linux 操作系统包含 Linux 内核和 rootfs 根文件系统，即我们熟悉的 /dev、/proc/、/bin 等目录。我们平时看到的 centOS 除了 rootfs，还会选装很多软件，服务，图形桌面等，所以 centOS 镜像有好几个 G 也不足为奇。
而对于容器镜像而言，所有容器都是共享宿主机的 Linux 内核的，而对于 docker 镜像而言，docker 镜像只需要提供一个很小的 rootfs 即可，只需要包含最基本的命令，工具，程序库即可，所有 docker 镜像才会这么小。
一个新的镜像其实是从 base 镜像一层一层叠加生成的。每安装一个软件，dockerfile 中使用 RUM 命令，就会在现有镜像的基础上增加一层，这样一层一层的叠加最后构成整个镜像。所以我们 docker pull 拉取一个镜像的时候会看到 docker 是一层层拉去的。
分层机构最大的一个好处就是 ：共享资源。比如：有多个镜像都从相同的 base 镜像构建而来，那么 Docker Host 只需在磁盘上保存一份 base 镜像；同时内存中也只需加载一份 base 镜像，就可以为所有容器服务了。而且镜像的每一层都可以被共享。
我们知道，镜像是分层的，镜像的每一层都可以被共享，同时，镜像是只读的。当一个容器启动时，一个新的可写层被加载到镜像的顶部，这一层通常被称作 “容器层”，“容器层” 之下的都叫 “镜像层”。
所有对容器的改动 - 无论添加、删除、还是修改文件，都只会发生在容器层中，因为只有容器层是可写的，容器层下面的所有镜像层都是只读的。镜像层数量可能会很多，所有镜像层会联合在一起组成一个统一的文件系统。如果不同层中有一个相同路径的文件，比如 /a，上层的 /a 会覆盖下层的 /a，也就是说用户只能访问到上层中的文件 /a。在容器层中，用户看到的是一个叠加之后的文件系统。
添加文件：在容器中创建文件时，新文件被添加到容器层中。
读取文件：在容器中读取某个文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后打开并读入内存。
修改文件：在容器中修改已存在的文件时，Docker 会从上往下依次在各镜像层中查找此文件。一旦找到，立即将其复制到容器层，然后修改之。
删除文件：在容器中删除文件时，Docker 也是从上往下依次在镜像层中查找此文件。找到后，会在容器层中记录下此删除操作。
只有当需要修改时才复制一份数据，这种特性被称作 Copy-on-Write。可见，容器层保存的是镜像变化的部分，不会对镜像本身进行任何修改。
首先，创建一个目录用于存放应用程序以及构建过程中使用到的各个文件等；
然后，在这个目录下创建一个 Dockerfile 文件，一般建议 Dockerfile 的文件名就是 Dockerfile；
编写 Dockerfile 文件，编写指令，如，使用 FORM 指令指定基础镜像，COPY 指令复制文件，RUN 指令指定要运行的命令，ENV 设置环境变量，EXPOSE 指定容器要暴露的端口，WORKDIR 设置当前工作目录，CMD 容器启动时运行命令，等等指令构建镜像；
Dockerfile 编写完成就可以构建镜像了，使用 docker build -t 镜像名:tag . 命令来构建镜像，最后一个点是表示当前目录，docker 会默认寻找当前目录下的 Dockerfile 文件来构建镜像，如果不使用默认，可以使用 - f 参数来指定 dockerfile 文件，如：docker build -t 镜像名:tag -f /xx/xxx/Dockerfile ；
使用 docker build 命令构建之后，docker 就会将当前目录下所有的文件发送给 docker daemon，顺序执行 Dockerfile 文件里的指令，在这过程中会生成临时容器，在临时容器里面安装 RUN 指定的命令，安装成功后，docker 底层会使用类似于 docker commit 命令来将容器保存为镜像，然后删除临时容器，以此类推，一层层的构建镜像，运行临时容器安装软件，直到最后的镜像构建成功。
首先，Dockerfile 是一层一层的构建镜像，期间会产生一个或多个临时容器，构建过程中其实就是在临时容器里面安装应用，如果因为临时容器安装应用出现异常导致镜像构建失败，这时容器虽然被清理掉了，但是期间构建的中间镜像还在，那么我们可以根据异常时上一层已经构建好的临时镜像，将临时镜像运行为容器，然后在容器里面运行安装命令来定位具体的异常。
FROM 指定基础镜像（必须为第一个指令，因为需要指定使用哪个基础镜像来构建镜像）；
MAINTAINER 设置镜像作者相关信息，如作者名字，日期，邮件，联系方式等；
COPY 复制文件到镜像；
ADD 复制文件到镜像（ADD 与 COPY 的区别在于，ADD 会自动解压 tar、zip、tgz、xz 等归档文件，而 COPY 不会，同时 ADD 指令还可以接一个 url 下载文件地址，一般建议使用 COPY 复制文件即可，文件在宿主机上是什么样子复制到镜像里面就是什么样子这样比较好）；
ENV 设置环境变量；
EXPOSE 暴露容器进程的端口，仅仅是提示别人容器使用的哪个端口，没有过多作用；
VOLUME 数据卷持久化，挂载一个目录；
WORKDIR 设置工作目录，如果目录不在，则会自动创建目录；
RUN 在容器中运行命令，RUN 指令会创建新的镜像层，RUN 指令经常被用于安装软件包；
CMD 指定容器启动时默认运行哪些命令，如果有多个 CMD，则只有最后一个生效，另外，CMD 指令可以被 docker run 之后的参数替换；
ENTRYOINT 指定容器启动时运行哪些命令，如果有多个 ENTRYOINT，则只有最后一个生效，另外，如果 Dockerfile 中同时存在 CMD 和 ENTRYOINT，那么 CMD 或 docker run 之后的参数将被当做参数传递给 ENTRYOINT；
进入容器有两种方法：docker attach、docker exec。
K8s 是 kubernetes 的简称，其本质是一个开源的容器编排系统，主要用于管理容器化的应用，其目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes 提供了应用部署，规划，更新，维护的一种机制。
说简单点：k8s 就是一个编排容器的系统，一个可以管理容器应用全生命周期的工具，从创建应用，应用的部署，应用提供服务，扩容缩容应用，应用更新，都非常的方便，而且还可以做到故障自愈，所以，k8s 是一个非常强大的容器编排系统。
k8s 主要由 master 节点和 node 节点构成。master 节点负责管理集群，node 节点是容器应用真正运行的地方。
master 节点包含的组件有：kube-api-server、kube-controller-manager、kube-scheduler、etcd。
node 节点包含的组件有：kubelet、kube-proxy、container-runtime。
kube-api-server：以下简称 api-server，api-server 是 k8s 最重要的核心组件之一，它是 k8s 集群管理的统一访问入口，提供了 RESTful API 接口，实现了认证、授权和准入控制等安全功能；api-server 还是其他组件之间的数据交互和通信的枢纽，其他组件彼此之间并不会直接通信，其他组件对资源对象的增、删、改、查和监听操作都是交由 api-server 处理后，api-server 再提交给 etcd 数据库做持久化存储，只有 api-server 才能直接操作 etcd 数据库，其他组件都不能直接操作 etcd 数据库，其他组件都是通过 api-server 间接的读取，写入数据到 etcd。
kube-controller-manager：以下简称 controller-manager，controller-manager 是 k8s 中各种控制器的的管理者，是 k8s 集群内部的管理控制中心，也是 k8s 自动化功能的核心；controller-manager 内部包含 replication controller、node controller、deployment controller、endpoint controller 等各种资源对象的控制器，每种控制器都负责一种特定资源的控制流程，而 controller-manager 正是这些 controller 的核心管理者。
kube-scheduler：以下简称 scheduler，scheduler 负责集群资源调度，其作用是将待调度的 pod 通过一系列复杂的调度算法计算出最合适的 node 节点，然后将 pod 绑定到目标节点上。shceduler 会根据 pod 的信息（关注微信公众号：网络技术联盟站），全部节点信息列表，过滤掉不符合要求的节点，过滤出一批候选节点，然后给候选节点打分，选分最高的就是最佳节点，scheduler 就会把目标 pod 安置到该节点。
Etcd：etcd 是一个分布式的键值对存储数据库，主要是用于保存 k8s 集群状态数据，比如，pod，service 等资源对象的信息；etcd 可以是单个也可以有多个，多个就是 etcd 数据库集群，etcd 通常部署奇数个实例，在大规模集群中，etcd 有 5 个或 7 个节点就足够了；另外说明一点，etcd 本质上可以不与 master 节点部署在一起，只要 master 节点能通过网络连接 etcd 数据库即可。
kubelet：每个 node 节点上都有一个 kubelet 服务进程，kubelet 作为连接 master 和各 node 之间的桥梁，负责维护 pod 和容器的生命周期，当监听到 master 下发到本节点的任务时，比如创建、更新、终止 pod 等任务，kubelet 即通过控制 docker 来创建、更新、销毁容器；每个 kubelet 进程都会在 api-server 上注册本节点自身的信息，用于定期向 master 汇报本节点资源的使用情况。
kube-proxy：kube-proxy 运行在 node 节点上，在 Node 节点上实现 Pod 网络代理，维护网络规则和四层负载均衡工作，kube-proxy 会监听 api-server 中从而获取 service 和 endpoint 的变化情况，创建并维护路由规则以提供服务 IP 和负载均衡功能。简单理解此进程是 Service 的透明代理兼负载均衡器，其核心功能是将到某个 Service 的访问请求转发到后端的多个 Pod 实例上。
container-runtime：容器运行时环境，即运行容器所需要的一系列程序，目前 k8s 支持的容器运行时有很多，如 docker、rkt 或其他，比较受欢迎的是 docker，但是新版的 k8s 已经宣布弃用 docker。
kubelet 部署在每个 node 节点上的，它主要有 4 个功能：
节点管理。kubelet 启动时会向 api-server 进行注册，然后会定时的向 api-server 汇报本节点信息状态，资源使用状态等，这样 master 就能够知道 node 节点的资源剩余，节点是否失联等等相关的信息了。master 知道了整个集群所有节点的资源情况，这对于 pod 的调度和正常运行至关重要。
pod 管理。kubelet 负责维护 node 节点上 pod 的生命周期，当 kubelet 监听到 master 的下发到自己节点的任务时，比如要创建、更新、删除一个 pod，kubelet 就会通过 CRI（容器运行时接口）插件来调用不同的容器运行时来创建、更新、删除容器；常见的容器运行时有 docker、containerd、rkt 等等这些容器运行时，我们最熟悉的就是 docker 了，但在新版本的 k8s 已经弃用 docker 了，k8s1.24 版本中已经使用 containerd 作为容器运行时了。
容器健康检查。pod 中可以定义启动探针、存活探针、就绪探针等 3 种，我们最常用的就是存活探针、就绪探针，kubelet 会定期调用容器中的探针来检测容器是否存活，是否就绪，如果是存活探针，则会根据探测结果对检查失败的容器进行相应的重启策略；
Metrics Server 资源监控。在 node 节点上部署 Metrics Server 用于监控 node 节点、pod 的 CPU、内存、文件系统、网络使用等资源使用情况，而 kubelet 则通过 Metrics Server 获取所在节点及容器的上的数据。
kube-api-server 的端口是 8080 和 6443，前者是 http 的端口，后者是 https 的端口，以我本机使用 kubeadm 安装的 k8s 为例：
在命名空间的 kube-system 命名空间里，有一个名称为 kube-api-master 的 pod，这个 pod 就是运行着 kube-api-server 进程，它绑定了 master 主机的 ip 地址和 6443 端口，但是在 default 命名空间下，存在一个叫 kubernetes 的服务，该服务对外暴露端口为 443，目标端口 6443，这个服务的 ip 地址是 clusterip 地址池里面的第一个地址，同时这个服务的 yaml 定义里面并没有指定标签选择器，也就是说这个 kubernetes 服务所对应的 endpoint 是手动创建的，该 endpoint 也是名称叫做 kubernetes，该 endpoint 的 yaml 定义里面代理到 master 节点的 6443 端口，也就是 kube-api-server 的 IP 和端口。这样一来，其他 pod 访问 kube-api-server 的整个流程就是：pod 创建后嵌入了环境变量，pod 获取到了 kubernetes 这个服务的 ip 和 443 端口，请求到 kubernetes 这个服务其实就是转发到了 master 节点上的 6443 端口的 kube-api-server 这个 pod 里面。
amespace 是 kubernetes 系统中的一种非常重要的资源，namespace 的主要作用是用来实现多套环境的资源隔离，或者说是多租户的资源隔离。
k8s 通过将集群内部的资源分配到不同的 namespace 中，可以形成逻辑上的隔离，以方便不同的资源进行隔离使用和管理。不同的命名空间可以存在同名的资源，命名空间为资源提供了一个作用域。
可以通过 k8s 的授权机制，将不同的 namespace 交给不同的租户进行管理，这样就实现了多租户的资源隔离，还可以结合 k8s 的资源配额机制，限定不同的租户能占用的资源，例如 CPU 使用量、内存使用量等等来实现租户可用资源的管理。
Deployments：Deployment 为 Pod 和 ReplicaSet 提供声明式的更新能力。
ReplicaSet：ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。
StatefulSets：和 Deployment 类似，StatefulSet 管理基于相同容器规约的一组 Pod。但和 Deployment 不同的是，StatefulSet 为它们的每个 Pod 维护了一个有粘性的 ID。这些 Pod 是基于相同的规约来创建的，但是不能相互替换：无论怎么调度，每个 Pod 都有一个永久不变的 ID。
DaemonSet：DaemonSet 确保全部（或者某些）节点上运行一个 Pod 的副本。当有节点加入集群时，也会为他们新增一个 Pod。当有节点从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
Jobs：Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。当数量达到指定的成功个数阈值时，任务（即 Job）结束。删除 Job 的操作会清除所创建的全部 Pod。挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。
Automatic Clean-up for Finished Jobs：TTL-after-finished 控制器提供了一种 TTL 机制来限制已完成执行的资源对象的生命周期。TTL 控制器目前只处理 Job。
CronJob：一个 CronJob 对象就像 crontab (crontable) 文件中的一行。它用 Cron 格式进行编写，并周期性地在给定的调度时间执行 Job。
ReplicationController：ReplicationController 确保在任何时候都有特定数量的 Pod 副本处于运行状态。换句话说，ReplicationController 确保一个 Pod 或一组同类的 Pod 总是可用的。
轮询（默认）
加权轮询（轮询 + weight）
ip_hash
每一个请求的访问 IP，都会映射成一个 hash，再通过 hash 算法（hash 值 % node_count），分配到不同的后端服务器，访问 ip 相同的请求会固定访问同一个后端服务器，这样可以做到会话保持，解决 session 同步问题。
least_conn（最少连接）
使用最少连接的负载平衡，nginx 将尝试不会使繁忙的应用程序服务器超载请求过多，而是将新请求分发给不太繁忙的服务器。
upstream
rewrite
location
proxy_pass
top —> task (line)—> zombie.
把父进程杀掉，父进程死后，过继给 1 号进程 init，init 始终负责清理僵尸进程，它产生的所有僵尸进程跟着消失；如果你使用 kill ，一般都不能杀掉 defunct 进程.。用了 kill -15,kill -9 以后 之后反而会多出更多的僵尸进程。
pgrep -au neteagle
lsof -i :[port]
iptables -t nat -A PREROUTING -d 10.0.0.8 -p tcp --dport 80 -j REDIRECT --to-ports 8080
etstat-n|awk'/^tcp/{++b[$NF]}END{for(ainb)printa,b[a]}'
ls/var/log/-lR|grep"^-"|wc-l
第一步：开机自检，加载 BIOS
第二步：读取ＭＢＲ
第三步：Boot Loader grub 引导菜单
第四步：加载 kernel 内核
第五步：init 进程依据 inittab 文件夹来设定运行级别
第六步：init 进程执行 rc.sysinit
第七步：启动内核模块
第八步：执行不同运行级别的脚本程序
第九步：执行 /etc/rc.d/rc.lo
-：常规文件，即 file
d：目录文件
b：block device 即块设备文件，如硬盘；支持以 block 为单位进行随机访问
c：character device 即字符设备文件，如键盘支持以 character 为单位进行线性访问
l：symbolic link 即符号链接文件（关注微信公众号：网络技术联盟站），又称软链接文件
p：pipe 即命名管道文件
s：socket 即套接字文件，用于实现两个进程进行通信
功能：可以对磁盘进行动态管理。动态按需调整大小
概念：
PV 物理卷：物理卷在逻辑卷管理中处于最底层，它可以是实际物理硬盘上的分区，也可以是整个物理硬盘，也可以是 raid 设备。
VG 卷组：卷组建立在物理卷之上，一个卷组中至少要包括一个物理卷，在卷组建立之后可动态添加物理卷到卷组中。一个逻辑卷管理系统工程中可以只有一个卷组，也可以拥有多个卷组。
LV 逻辑卷：逻辑卷建立在卷组之上，卷组中的未分配空间可以用于建立新的逻辑卷，逻辑卷建立后可以动态地扩展和缩小空间。系统中的多个逻辑卷可以属于同一个卷组，也可以属于不同的多个卷组。
给 / 分区扩容步骤：
添加磁盘
使用 fdisk 命令对新增加的磁盘进行分区
分区完成后修改分区类型为 lvm
使用 pvcreate 创建物理卷
使用 vgextend 命令将新增加的分区加入到根目录分区中
使用 lvextend 命令进行扩容
使用 xfs_growfs 调整卷分区大小
以下操作全部在 vi/vim 命令行状态操作，不要在编辑状态操作：
在文本里 移动到想要复制的行按 yy 想复制到哪就移动到哪，然后按 P 就黏贴了
删除行 移动到改行 按 dd
删除全部 dG 这里注意 G 一定要大写
按行查找 :90 这样就是找到第 90 行
按字母查找 /path 这样就是找到 path 这个单词所在的位置，文本里可能存在多个，多次查找会显示在不同的位置。
我们可以把符号链接，也就是软连接 当做是 windows 系统里的 快捷方式。
硬链接 就好像是 又复制了一份.
ln 3.txt 4.txt 这是硬链接，相当于复制，不可以跨分区，但修改 3,4 会跟着变，若删除 3,4 不受任何影响。
ln -s 3.txt 4.txt 这是软连接，相当于快捷方式。修改 4,3 也会跟着变，若删除 3,4 就坏掉了。不可以用了。
一个位于客户端和原始服务器 (origin server) 之间的服务器，为了从原始服务器取得内容，客户端向代理发送一个请求并指定目标 (原始服务器)，然后代理向原始服务器转交请求并将获得的内容返回给客户端。
客户端才能使用正向代理。正向代理总结就一句话：代理端代理的是客户端。例如说：我们使用的 OpenVPN 等等。
反向代理（Reverse Proxy）方式，是指以代理服务器来接受 Internet 上的连接请求，然后将请求，发给内部网络上的服务器并将从服务器上得到的结果返回给 Internet 上请求连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。
反向代理总结就一句话：代理端代理的是服务端。
动态资源、静态资源分离，是让动态网站里的动态网页根据一定规则把不变的资源和经常变的资源区分开来，动静资源做好了拆分以后我们就可以根据静态资源的特点将其做缓存操作，这就是网站静态化处理的核心思路。
动态资源、静态资源分离简单的概括是：动态文件与静态文件的分离。
在我们的软件开发中，有些请求是需要后台处理的（如：.jsp,.do 等等），有些请求是不需要经过后台处理的（如：css、html、jpg、js 等等文件），这些不需要经过后台处理的文件称为静态文件，否则动态文件。
因此我们后台处理忽略静态文件。这会有人又说那我后台忽略静态文件不就完了吗？当然这是可以的，但是这样后台的请求次数就明显增多了。在我们对资源的响应速度有要求的时候，我们应该使用这种动静分离的策略去解决动、静分离将网站静态资源（HTML，JavaScript，CSS，img 等文件）与后台应用分开部署，提高用户访问静态代码的速度，降低对后台应用访问
这里我们将静态资源放到 Nginx 中，动态资源转发到 Tomcat 服务器中去。
当然，因为现在七牛、阿里云等 CDN 服务已经很成熟，主流的做法，是把静态资源缓存到 CDN 服务中，从而提升访问速度。
相比本地的 Nginx 来说，CDN 服务器由于在国内有更多的节点，可以实现用户的就近访问。并且，CDN 服务可以提供更大的带宽，不像我们自己的应用服务，提供的带宽是有限的。
网络带宽，这是一个很常见的瓶颈。
cpu、硬盘、内存配置过低，服务器负载不起来。
网站的开发代码不够完善，例如 mysql 语句没有进行优化，导致数据库的读写相当耗费时间。
数据库的瓶颈。当我们的数据库的数据变得越来越多的时候，那么对于数据库的读写压力肯定会变大。
AB 服务器不在同一个网段
首先把不同 IP 段的服务器划分给不同的 vlan
在通过通过三层交换机添加虚拟 IP 路由实在不同网段的 vlan 的连接
vi /etc/sysconfig/network-scripts/ifcfg-eth0
查看网卡状况 IP -a -s 网卡的名字
A 服务器设置相关网卡信息
子网掩码：255.255.255.0
IP=10.0.0.1
网关=10.0.0.254
重启网卡生效
查看路由信息
route -n
添加对应路由
route add -net 10.0.1.0/24 gw 10.0.0.11
B 服务器的设置相关信息
IP=10.0.1.10
网关10.0.1.254
重启网卡生效
route -n
添加对应的路由
route add -net 10.0.0.0/24 gw 10.0.1.11
C 服务器的两块网卡
网卡1
IP=10.0.0.11
网关=10.0.0.254
网卡2
IP=10.0.1.11
网关=10.0.1.254
重启网卡生效
route -n
vi /etc/sysctl.conf
net.ipv4.ip_forword = 1
首先先看看是不是网路接口故障水晶头或是网卡接口接触不良造成，其次检查交换机和路由等网络设备是有故障
是否关闭了防火墙和 selinux 机制
然后查看网卡和路由和网关是否配置正确
ifconfig 查看一下 docker0 网桥，ping 一下网桥看看是否通，有可能是网桥配置问题
weave 路由器端口 6783
安装 docker 容器的服务器没有关闭防火墙 (访问一下安装 docker 物理机的，是否能访问，如果不能访问就变不能访问 docker)
docker 在创建镜像的时候没有做端口映射 (出现这种情况能访问物理机不能访问 docker) 使用 dockers ps 查看镜像的端口映射情况
端口映射不正确
查看网络配置 ping 网桥看是否能 ping 通，有可能是网桥的原因
首先确定物理链路是否联通正常。
查看本机 IP，路由，DNS 的设置情况是否达标。
telnet 检查服务器的 WEB 有没有开启以及防火墙是否阻拦。
ping 一下网关，进行最基础的检查，通了，表示能够到达服务器。
测试到网关或路由器的通常情况，先测网关，然后再测路由器一级一级的测试。
测试 ping 公网 ip 的通常情况 (记住几个外部 IP)，
测试 DNS 的通畅。ping 出对应 IP。
通过以上检查后，还在网管的路由器上进行检查。
判断原因
首先我要以用户的身份登录我们的网站，判断问题出现在我们自身原因，还是用户那边的原因。
如果是用户问题有以下几个原因：
用户那边的带宽
用户的浏览器器版本低，安装插件太多
中毒和电脑里的垃圾文件过多
用户主机的主机的性能和操作系统
网络带宽
服务器的 cpu、硬盘、内存过低服务器负载不起来也就是说服务器自身的性能方面
网站代码不够完善。如 mysql 语句没有进行优化导致数据库读写耗时
服务器未开启图片压缩
网页下死连接过多插件使用及 js 文件调用频繁网站服务器的速度或是租用空间所在的服务器速度
解决思路
1、检测服务器速度的快慢
ping 命令查看连接到服务器的时间和丢包情况 (ping 测试网址的)
查看丢包率 (1000 个包没有丢一个是最理想的、一般一个速度好的机房丢包率不超过 1%)
ping 值要小同城电信 adsl ping 平均值绝对不能超过 20，一般都在 10，跨省的平均值 20-40 属于正常
ping 值要均匀最小值和最大值相差太大说明路由不稳定的表现
2、查看服务器自身性能
查看 cpu 的使用率 uptime
查看内存情况 free -m
查看 I/O 读写 iostat 磁盘 I/O 读写等看看是那个进程大量占用系统资源导致我的服务器变慢
3、看看访问最多的 URL 和 IP 有什么特征，如果是恶意 URL 和 IP 就把他屏蔽掉如果是善意的就限流有可能是 CDN 回源量大造成网站无法访问
4、查看同台服务器上其他网站的打开速度，可以通过查询工具查看和自己在同一台服务器上的网站个数和网址可以看他们打开快慢
5、电信和联通互访的问题
如果是空间打开时快时慢，有时打不开那就是空间不稳定找空间商解决或是换空间伤，如果是有的地方快有的地方慢应该是网络线路问题，比如电信用户访问放在联通服务器上的网站，联通用户访问放在电信服务器上的网站，解决办吧是：使用双线空间或是多线空间
6、从网站自身的原因
网站的程序设计结构是否合理是否由于幻灯片代码影响网站打开速度 (找程序设计相关人士解决)
网页的设计结构和代码错误 (请专业人士进行修改)
网页的内容如：大尺寸图片、大尺寸 flash、过多的引用其他网站内容，如果被引用内容的网站速度慢，也影响自身网站把。譬如友情连接可以把对方 的图片放到自己网站上
解决办法
优化图片，限制图片大小尺寸，降低图片质量，减少图片数量
限定图片的格式：jpg，png，gif
减少 http 的请求数 (当打开网页时浏览器会发出很多对象请求，每个对象的加载都会有所延时，如果网页上的对象很多就会花费大量的时间，去除不必要的对象，将临近的图片合成一张，合并 css 文件) f r o m ：w l j s l m z
我们一般通过 hexdump 命令 来查看二进制文件的内容。
hexdump -C XXX (文件名) -C 是参数 不同的参数有不同的意义
-C 是比较规范的 十六进制和 ASCII 码显示
-c 是单字节字符显示
-b 单字节八进制显示
-o 是双字节八进制显示
-d 是双字节十进制显示
-x 是双字节十六进制显示
等等等等
在生产环境下，不管是应用数据、还是数据库数据首先在部署的时候就会有主从架构、或者集群，这本身就是属于数据的热备份；其实考虑冷备份，用专门一台服务器做为备份服务器，比如可以用 rsync+inotify 配合计划任务来实现数据的冷备份，如果是发版的包备份，正常情况下有台发布服务器，每次发版都会保存好发版的包。
主机（host）：要监控的网络设备，可由 IP 或 DNS 名称指定；
主机组（hostgroup）：主机的逻辑容器，可以包含主机和模板，但同一个组织内的主机和模板不能互相链接；主机组通常在给用户或用户组指派监控权限时使用；
监控项（item）：一个特定监控指标的相关的数据；这些数据来自于被监控对象；item 是 zabbix 进行数据收集的核心，相对某个监控对象，每个 item 都由 "key" 标识；
触发器（trigger）：一个表达式，用于评估某监控对象的特定 item 内接收到的数据是否在合理范围内，也就是阈值；接收的数据量大于阈值时，触发器状态将从 "OK" 转变为 "Problem"，当数据再次恢复到合理范围，又转变为 "OK"；
事件（event）：触发一个值得关注的事情，比如触发器状态转变，新的 agent 或重新上线的 agent 的自动注册等；
动作（action）：指对于特定事件事先定义的处理方法，如发送通知，何时执行操作；
报警升级（escalation）：发送警报或者执行远程命令的自定义方案，如每隔 5 分钟发送一次警报，共发送 5 次等；
媒介（media）：发送通知的手段或者通道，如 Email、Jabber 或者 SMS 等；
通知（notification）：通过选定的媒介向用户发送的有关某事件的信息；远程命令（remote command）：预定义的命令，可在被监控主机处于某特定条件下时自动执行；
模板（template）：用于快速定义被监控主机的预设条目集合，通常包含了 item、trigger、graph、screen、application 以及 low-level
discovery rule；模板可以直接链接至某个主机；应用（application）：一组 item 的集合；
web 场景（webscennario）：用于检测 web 站点可用性的一个活多个 HTTP 请求；前端（frontend）：Zabbix 的 web 接口；
完全拟化技术：通过软件实现对操作系统的资源再分配，比较成熟，完全虚拟化代表技术：KVM、ESXI、Hyper-V。
半虚拟化技术：通过代码修改已有的系统，形成一种新的可虚拟化的系统，调用硬件资源去安装多个系统，整体速度上相对高一点，半虚拟化代表技术：Xen。
轻量级虚拟化：介于完全虚拟化、半虚拟化之间，轻量级虚拟化代表技术：Docker。
先告知运维经理和业务相关开发人员
在测试环境测试，并备份之前的配置文件
测试无误后修改生产环境配置
观察生产环境是否正常，是否有报警
完成配置文件更改