nginx集群

转自：https://blog.csdn.net/yinwenjie/article/details/46605451 在上一篇《标准Web系统的架构分层》文章中，我们概述了WEB系统架构中的分层架设体系，介绍了包括负载均衡层、业务层、业务通信层、数据存储层的作用和存在意义。从本片文章开始，我们将首先详细讲解负载均衡层的架构原理和选型场景。 1、不同的负载场景 我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”，那么不同的业务场景需要的负载均衡方式又是不一样的，架构师还要考虑架构方案的成本、可扩展性、运维难易度等问题。下面我们先介绍几种典型的不同业务场景，大家也可以先想一下如果是您，会怎么架设这些场景的负载均衡层。 需要注意的是，这个系统的文章，我们都将使用这几个典型的业务场景来讲解系统架构的设计递归设计。在后续几篇介绍负载层架构的文章中，我们也将通过这几个典型的业务场景讲解负载层的架构方案。 1.1、负载场景一 这是一个国家级物流园区的货运订单和物流管理系统。在物流园区内的货运代理商、合作司机（货运车辆）、园区管理员和客服人员都要使用这套系统。每日RUV在1万人次，日PV在10万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品是否能起到提高效率的作用”。可以看出整个系统基本上没有访问压力

　　上一篇博客我们大概介绍了一下nginx，nginx的架构，nginx编译安装和nginx命令的用法，回顾请参考 https://www.cnblogs.com/qiuhom-1874/p/12366808.html ；今天我们来配置简单的配置下nginx和一些简单指令说明。 　　nginx和httpd类似都是高度模块化的软件，不同的模块有着不同的功能，想要把nginx配置好，首先我们需要了解各个模块的用法以及模块选项的用法和说明。首先我们来了解下nginx用yum安装后，程序环境 [root@www ~]# rpm -ql nginx /etc/logrotate.d/nginx /etc/nginx/fastcgi.conf /etc/nginx/fastcgi.conf.default /etc/nginx/fastcgi_params /etc/nginx/fastcgi_params.default /etc/nginx/koi-utf /etc/nginx/koi-win /etc/nginx/mime.types /etc/nginx/mime.types.default /etc/nginx/nginx.conf /etc/nginx/nginx.conf.default /etc/nginx/scgi_params /etc/nginx/scgi_params

正向代理 正向代理(Forward Proxy)：代替客户端去访问服务器，代理的是客户端。 正向代理的作用 （1）访问本无法访问的服务器 比如说原本的链路 -> 网关1 -> 网关2 发生故障，或者zf、学校在网关上用防火墙屏蔽了一些网站，导致客户端不能访问服务器。 通过代理服务器可以访问服务器，v p n 的搭建即此原理。 （2）客户端访问授权 比如说内网的服务器上的内容是一些机密文件，只对内部的部分人员开放。 可以在内网设置代理，在代理的防火墙检查发起请求的客户端的地址，是某个部门、办公室的ip才放行，否则直接拦截掉。 （1）是在代理的防火墙中检测服务器地址，（2）是在代理的防火墙中检测发起请求的客户端地址。 （3）加速访问 可能网关1、网关2的带宽较小，网速慢，使用高带宽的代理服务器可以提高访问速度。 （4）cache作用 代理可以缓存服务器的数据，比如客户端A访问服务器的xx内容，后续某些客户端发起相同请求时，代理不再去访问服务器，直接从缓存中获取数据返回给客户端， 叫做cache命中，加快响应速度、减轻服务器负担。 （5）隐藏客户端 对服务器来说，客户端是代理，服务器的访问记录是代理，从而隐藏了原始客户端。 一般说的代理都是正向代理。 反向代理 反向代理（reverse proxy）：代理的是服务器。 正向代理是由客户端的公司|组织设置的、或者由第三方代理设置

1. 概述 本文以淘宝作为例子，介绍从一百个到千万级并发情况下服务端的架构的演进过程，同时列举出每个演进阶段会遇到的相关技术，让大家对架构的演进有一个整体的认知，文章最后汇总了一些架构设计的原则。 特别说明：本文以淘宝为例仅仅是为了便于说明演进过程可能遇到的问题，并非是淘宝真正的技术演进路径 2. 基本概念 在介绍架构之前，为了避免部分读者对架构设计中的一些概念不了解，下面对几个最基础的概念进行介绍： 分布式 系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上 高可用 系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性 集群 一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Zookeeper中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性 负载均衡 请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的 正向代理和反向代理 系统内部要访问外部网络时

模拟tomcat集群 1、下载tomcat7，/usr/local下新建目录tomcat，将tomcat7剪切到/usr/local/tomcat wget http://mirror.bit.edu.cn/apache/tomcat/tomcat-7/v7.0.100/bin/apache-tomcat-7.0.100.tar.gz mkdir /usr/local/tomcat mv /root/apache-tomcat-7.0.100.tar.gz /usr/local/tomcat 2、解压，复制一份，分别重命名为tomcat1、tomcat2 cd /usr/local/tomcat tar -zxvf apache-tomcat-7.0.100.tar.gz rm apache-tomcat-7.0.100.tar.gz mv apache-tomcat-7.0.100 tomcat1 cp -r tomcat1 tomcat2 3、修改tomcat2使用的端口号，避免与tomcat1使用的端口号冲突 vim tomcat2/conf/server.xml 4、分别在2个tomcat的satrtup.sh中设置CATALINA_HOME vim tomcat1/bin/startup.sh 开头添加一行： export CATALINA_HOME=/usr/local

在此之前，发布过两个版本： 运维工程师打怪升级之路 V1.0 版本发布 运维工程师打怪升级必经之路 V1.0.1 很多读者伙伴们反应总结的很系统、很全面，无论是0基础初学者，还是有基础的入门者，或者是有经验的职场运维工程师们，都反馈此系列文章非常不错！ 为了更好的提升可阅读性、可查找性，特此，将列与公众号菜单的系统系列文章，统一整理于一篇文章，按原来的整体架构，分类整理，也就是说，今后的更新与迭代不再是多级的菜单目录，统一是一篇完整的文章，有利于读者阅读与查找。 命名：《运维工程师打怪升级之路》 版本：V1.0版本「2019年1月20日发布」 V1.0.1版本「2019年4月26日更新」 V2.0版本 「2019年5月13日发布」 内容概况： 内容由浅入深，从最基础的网络基础开始，逐渐深入系统的学习Linux系统运维知识。然后引入企业项目实战内容，从而让更多学习Linux系统运维的读者朋友们「无论前端、后端、测试还是运维，底层系统是必备技术点」，都能够快速入门、并且在一程度上掌握当下企业所需要的技术储备。再穿插企业面试题、面试经验等，同时也能帮助运维工程师们在求职的路上能更加顺畅，少踩坑。 后面会逐渐更新将其完善，希望能帮助到同为运维路上的技术人。 运维工程师打怪升级进阶之路基础篇 1、网络基础 网络组建之路由基础 网络基础NAT（Network Address

1. 简介 k8s 的 API Server 提供了 RESTful 风格的网关接口, 允许用户通过这个接口向 k8s 集群发起请求。如创建一个 Pod 或销毁一个 Pod 等操作 用户可以通过编程语言遵循 API Server 提供的网关接口规范和 API Server 进行通信, 也可以通过 k8s 自带的 kubectl 命令和 API Server 进行通信, 或者通过由 Dashboard 提供的 Web UI 和 API Server 进行通信 其中 kubectl 是官方提供的用于和 API Server 通信的 CLI 工具, 且是最为常用的交互式命令行工具 2. kubectl 2.1. 查看命令帮助 # 查看 kubectl 命令帮助 [root@master ~]# kubectl --help # 基础命令(适合初学者使用) Basic Commands (Beginner): create 创建资源, k8s 支持从 yaml 文件或者命令行参数直接创建资源 expose 暴露服务 run 运行 Pod set 设置对象属性 # 基础命令 Basic Commands (Intermediate): explain get 获取资源信息 edit 编辑资源 delete 删除资源 # 部署命令 Deploy Commands: rollout 更新管理

Kubernets 中的Node, Pod，Replication Controller, Service 等都可以看作一种资源对象，这些资源几乎都可以通过使用Kubernetes提供的kubectl 工具执行增删改查，并将其保存在etcd中持久化储存。通过跟踪对比etcd库中保存的“资源预设状态”与当前环境中的实际资源状态进行对比，对差异资源状态进行纠错，来实现自动控制集群状态的功能。下面将分别介绍这个组件角色。 管理角色 Kubernetes中有两种管理角色，Master和Node. Master Master是Kubernetes集群的控制节点，所有对于Kubernetes的命令操作都需要在控制节点执行。Master一般运行如下进程： kube-apiserver： Kubernetes API Server, 提供了HTTP Rest接口的关键服务进程，是所有资源增，删，改，查的入口，也是集群控制的入口进程，kubectl是直接与 API Server交互的，默认监听 6443端口。 kube-controller-manager: 每个资源一般都对应有一个控制器，而controller manager就是负责管理这些控制器的,它是自动化的循环控制器，是Kubernetes的核心控制守护进程。默认监听10252端口。 kube-scheduler ：

博文大纲： 一、Ingress简介 1）Ingress组成 2）Ingress工作原理 3） Ingress可以解决什么问题？ 二、配置Ingress-nginx 1）搭建registry私有仓库 2）创建用于测试的Pod 2）创建tomcat服务及其service 3）确保以上资源对象成功创建 4）创建Ingress-controller资源对象 5）创建Ingress资源对象 6）为Ingress-controller资源对象创建一个service资源对象 7）创建基于虚拟主机的Ingress规则 三、配置HTTPS 一、Ingress简介 在Kubernetes中，服务和Pod的IP地址仅在集群内部网络内部使用，对于集群的应用是不可见的。 为了使外部的应用能够访问集群内的服务，在Kubernetes目前提供了以下几种方案： 1）NodePort 2）LoadBalancer 3）Ingress 1）Ingress组成 Ingress 是反向代理规则，用来规定 HTTP/S 请求应该被转发到哪个 Service 上，比如根据请求中不同的 Host 和 url 路径让请求落到不同的 Service 上； Ingress Controller 就是一个反向代理程序，它负责解析 Ingress 的反向代理规则，如果 Ingress 有增删改的变动，所有的 Ingress

转自：https://www.cnblogs.com/wcwnina/p/8728391.html Nginx的产生 没有听过Nginx？那么一定听过它的“同行”Apache吧！Nginx同Apache一样都是一种WEB服务器。基于REST架构风格，以统一资源描述符(Uniform Resources Identifier)URI或者统一资源定位符(Uniform Resources Locator)URL作为沟通依据，通过HTTP协议提供各种网络服务。 然而，这些服务器在设计之初受到当时环境的局限，例如当时的用户规模，网络带宽，产品特点等局限并且各自的定位和发展都不尽相同。这也使得各个WEB服务器有着各自鲜明的特点。 Apache的发展时期很长，而且是毫无争议的世界第一大服务器。它有着很多有点：稳定、开源、跨平台等等。但是由于它出现的时间太长了。它兴起的年代，互联网产业远比不上现在。所以它被设计为一个重量级的。不支持高并发的服务器。在Apache上运行数以万计的并发访问，会导致服务器消耗大量内存。操作系统对其进行进程或线程间的切换也消耗了大量的CPU资源，导致HTTP请求的平均响应速度降低。 这些都决定了Apache不可能成为高性能WEB服务器，轻量级高并发服务器Nginx就应运而生了。 俄罗斯的工程师Igor Sysoev，他在为Rambler Media工作期间