文章目录

平常心博客

平常心的日常积累

标签: nginx (11)

【转载】究竟啥才是互联网架构“高可用”

一、什么是高可用

高可用HAHigh Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。

假设系统一直能够提供服务,我们说系统的可用性是100%。

如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。

很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。

百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过www.baidu.com 能不能访问来判断“网络的连通性”,百度高可用的服务让人留下啦“网络通畅,百度就能访问”,“百度打不开,应该是网络连不上”的印象,这其实是对百度HA最高的褒奖。

二、如何保障系统的高可用

我们都知道,单点是系统高可用的大敌,单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。方法论上,高可用保证的原则是“集群化”,或者叫“冗余”:只有一个单点,挂了服务会受影响;如果有冗余备份,挂了还有其他backup能够顶上。

保证系统高可用,架构设计的核心准则是:冗余。

有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以,又往往是通过“自动故障转移”来实现系统的高可用。

接下来我们看下典型互联网架构中,如何通过冗余+自动故障转移来保证系统的高可用特性。

【转载】架构设计:负载均衡层设计方案(9)——负载均衡层总结下篇

(接上一篇《架构设计:负载均衡层设计方案(8)——负载均衡层总结上篇》)

3、负载均衡层技术汇总

3-4、Keepalived技术

Keepalived在我的博客文章《架构设计:负载均衡层设计方案(7)》(http://blog.v5cn.cn/articles/2017/12/09/1512805702084.html)、《架构设计:负载均衡层设计方案(6)》(http://blog.v5cn.cn/articles/2017/12/07/1512652439344.html)中都有介绍。大家可能注意到,在这些文章中从来没有单独介绍Keepalived。这是因为Keepalived是为了监控集群节点的工作状态,在因为某种原因不能正常提供服务的前提下,完成备机的切换。这里面有两个关键点:监控节点上提供的服务完成网络切换。keepalived本身是不提供业务服务的,只是监控提供的服务是否正常工作,那么既然都没有可以监控的服务,那么Keepalived有什么独立使用的必要呢?

下图是曾经在博文中展现过的Nginx + Keepalived的工作结构和LVS + Keepalived 的工作结构:

【转载】架构设计:负载均衡层设计方案(8)——负载均衡层总结上篇

1、概述

很明显通过前面的八篇文章的介绍,并不能覆盖负载均衡层的所有技术,但是可以作为一个引子,告诉各位读者一个学习和使用负载均衡技术的思路。虽然后面我们将转向“业务层”和“业务通信”层的介绍,但是对负载均衡层的介绍也不会停止。在后续的时间我们将穿插进行负载均衡层的新文章的发布,包括Nginx技术的再介绍、HaProxy、LVS新的使用场景等等。

这篇文章我们对前面的知识点进行总结,并有意进行一些扩展,以便于各位读者找到新的学习思路。

2、负载均衡层的核心思想

2-1、一致性哈希与Key的选取

8ec88f2db063404e9b19e1108a12097e-20150703172857890.png

《架构设计:负载均衡层设计方案(2)——Nginx安装》 文章中我们详细介绍了一致性哈希算法。并且强调了一致性Hash算法是现代系统架构中的最关键算法之一,在分布式计算系统、分布式存储系统、数据分析等众多领域中广泛应用。针对我的博文,在负载均衡层、业务通信层、数据存储层都会有它的身影。

【转载】架构设计:负载均衡层设计方案(7)——LVS + Keepalived + Nginx安装及配置

1、概述

上篇文章《架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层》(http://blog.v5cn.cn/articles/2017/12/07/1512652439344.html) 我们讲解了Nginx的故障切换,并且承诺各位读者会尽快讲解 LVS + Keepalived + Nginx的安装和配置。在中间由于工作的原因,我又插写了三篇关于zookeeper的原理使用的文章。今天这边文章我们回归主题,为各位读者讲解LVS + Keepalived + Nginx的安装及配置。

2、安装计划和准备工作

下图,我们表示了本篇文章要搭建的整个集成架构的抽象结构:

da1da653502241879e98890c7fe74220-20150822113121644.png

我们采用两个LVS节点(141和142),但是一个时间工作的只有一个LVS节点,另一个始终处于热备standby状态,由keepalived监控这两个节点的工作状态并完成切换。

【转载】架构设计:负载均衡层设计方案(6)——Nginx + Keepalived构建高可用的负载层

1、概述

前两遍文章中,我们一直在说后文要介绍Nginx + Keepalived的搭建方式。这篇文章开始,我们就来兑现前文的承诺,后续的两篇文章我们将介绍Nginx + Keepalived和 LVS + Keepalived搭建高可用的负载层系统。如果你还不了解Nginx和LVS的相关知识,请参见我之前的两篇文章《架构设计:负载均衡层设计方案(2)——Nginx安装》(http://blog.v5cn.cn/articles/2017/12/03/1512303962665.html)、《架构设计:负载均衡层设计方案(4)——LVS原理》(http://blog.v5cn.cn/articles/2017/12/05/1512479477762.html

2、准备工作

2.1、准备两台独立工作的Nginx系统

准备两台Nginx的主机,如果您不知道为什么需要准备两台,没关系,准备就行。保证两台Nginx主机能够被外网访问。在我这里,安装两台Nginx的虚拟机IP地址分别是:

  • Nginx VM1:192.168.61.129:80
  • Nginx VM2:192.168.61.130:80

访问相关的地址,确保两台Nginx都是可用的:

【转载】架构设计:负载均衡层设计方案(5)——LVS单节点安装

1、概述

上篇文章《架构设计:负载均衡层设计方案(4)——LVS原理》(http://blog.v5cn.cn/articles/2017/12/05/1512479477762.html),我们介绍了LVS的工作模式,和每一种模式的具体工作过程。这篇文章中,我们将介绍单一LVS节点的安装方式。比起上一篇文章,这一片要提到的安装和配置就是非常简单的了,只要您了解原理,实践就是从容的事情。

您可以在您的电脑上使用VMware虚拟机,按照下面介绍的过程一步一步实践。我们将采用两台虚拟机,一台作为LVS节点,另外一台安装了Nginx的服务器作为Real Server节点。

2、LVS-NAT 模式安装

2.1、准备工作——LVS Server:

LVS Server:LSV Server有两张网卡。

  • eth0:192.168.100.10:这张网卡对应一个封闭的内网,不能访问外网资源,外网也不能直接通过这个IP访问这台主机
  • eth1:192.168.220.100:这张网卡设置的IP可以访问外网,也可以被外网访问。eth1的网关:192.168.220.1。
以下是设置的eth0    ip信息,
[root@lvs1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
BOOTPROTO="static"
HWADDR="00:0C:29:3E:4A:4F"
ONBOOT="yes"
TYPE="Ethernet"
IPADDR="192.168.100.10"
NETMASK="255.255.255.0"
====================================
以下是设置的eth1  ip信息
[root@lvs1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE="eth1"
BOOTPROTO="static"
HWADDR="00:0C:29:3E:4A:59"
ONBOOT="yes"
TYPE="Ethernet"
IPADDR="192.168.220.100"
NETMASK="255.255.255.0"
GATEWAY="192.168.220.1"

【转载】架构设计:负载均衡层设计方案(4)——LVS原理

之前我们花了两篇文章的篇幅,详细讲解了Nginx的原理、安装和特性组件。请参看《负载均衡层设计方案(2)——Nginx安装》(http://blog.v5cn.cn/articles/2017/12/03/1512303962665.html)和《架构设计:负载均衡层设计方案(3)——Nginx进阶》(http://blog.v5cn.cn/articles/2017/12/04/1512391317930.html)两篇文章。虽然不包括Nginx的所有知识(也不可能全部包括),但是足够读者将Nginx应用到实际的生产中,并进行重要特性的优化,后面有时间我们还会重新回到Nginx的讲解上。从本篇文章开始,我们将开始介绍LVS技术,包括基本概念、简单使用和进阶使用。

1、LVS介绍

请自行Google或者百度。

2、网络协议基础知识

根据官方文档LVS支持三种负载工作方式:NAT方式、TUN方式和DR方式。为了说明这三种方式的工作原理,我们首先需要了解一下基础的IP/TCP报文(注意,IP报文和TCP报文是两种不同的报文格式),以及链路层对IP数据的封装方式。然后我们采用看图说话的方式,以图文结合的方式为您介绍这三种工作方式中对报文或重写或封装的过程。

为了说清楚我们将要讲解的基础知识,就要提到OSI7层网络模型。

【转载】架构设计:负载均衡层设计方案(3)——Nginx进阶

上篇文章《架构设计:负载均衡层设计方案(2)——Nginx安装》(http://blog.v5cn.cn/articles/2017/12/03/1512303962665.html),我们介绍了Nginx的核心设计思想、基本安装和使用。本来准备继续介绍Nginx的几个使用特性,但是奈何博文篇幅太长,只有将一篇文章拆成两篇。本文我们将承接上文,继续讲解Nginx的实用特性,包括gzip功能、rewirte功能和一个第三方的节点监测模块。本文我们还将提到Taobao团队对Nginx的深度改造Tengine。

1、Nginx继续进阶

1.1、gzip

nginx对返回给浏览器的http response body是可以进行压缩的。虽然需要消耗一点cpu和内存资源,但是想到100KB的数据量可以压缩到60KB甚至更小进行传输,是否有一定的吸引力?这里我的建议是,不要为了节约成本将业务服务和负载层服务放在一台物理服务器上,这样做既影响性能又增加了运维难度。http返回数据进行压缩的功能在很多场景下都实用:

  • 如果浏览器使用的是3G/4G网络,那么流量对于用户来说就是money。

  • 压缩可节约服务器机房的对外带宽,为更多用户服务。按照目前的市场价良好的机房带宽资源的一般在200RMB/Mbps,而服务器方案的压力往往也来自于机房带宽。

  • 主要注意的是,不是Nginx开启了gzip功能,HTTP响应的数据就一定会被压缩,除了满足Nginx设置的“需要压缩的http格式”以外,客户端(浏览器)也需要支持gzip(不然它怎么解压呢),一个好消息是,目前大多数浏览器和API都支持http压缩。

【转载】架构设计:负载均衡层设计方案(2)——Nginx安装

前一篇文章《架构设计:负载均衡层设计方案(1)——负载场景和解决方式》中我们描述了要搭设负载均衡层的业务场景和负载均衡层搭建和扩展思路。从这篇文章开始的后几篇文章,我们将详细介绍Nginx、LVS和Nginx+Keepalived、LVS+Keepalived和LVS+Nginx+Keepalived的安装细节,以及它们的性能优化方式。

Nginx和LVS都是可以独立工作的,Keepalived作为检测机制,不但可以和Nginx、LVS集成也可以和其他软件集成形成高可用方案(例如可以和MySQL数据库集成、可以和Jetty服务器集成、还可以和自己写的程序集成)。所以首先我们先来详细讲述Nginx和LVS的核心工作原理、安装过程和优化方式,再分别讲解他们和Keepalived的集成方式。这样的方式应该可以使您更快的掌握其中的核心,并能最快的融会贯通。

1、Nginx重要算法介绍

Nginx是什么,请自行百度。我们先介绍几个关键的算法,如果您还不了解这些算法在Nginx中所起的作用,请不要着急,本文后半部分将说明它们的作用。

【转载】架构设计:负载均衡层设计方案(1)——负载场景和解决方式

在上一篇《标准Web系统的架构分层》文章中,我们概述了WEB系统架构中的分层架设体系,介绍了包括负载均衡层、业务层、业务通信层、数据存储层的作用和存在意义。从本片文章开始,我们将首先详细讲解负载均衡层的架构原理和选型场景。

1、不同的负载场景

我们知道负载均衡层的作用是“将来源于外部的处理压力通过某种规律/手段分摊到内部各个处理节点上”,那么不同的业务场景需要的负载均衡方式又是不一样的,架构师还要考虑架构方案的成本、可扩展性、运维难易度等问题。下面我们先介绍几种典型的不同业务场景,大家也可以先想一下如果是您,会怎么架设这些场景的负载均衡层。

需要注意的是,这个系统的文章,我们都将使用这几个典型的业务场景来讲解系统架构的设计递归设计。在后续几篇介绍负载层架构的文章中,我们也将通过这几个典型的业务场景讲解负载层的架构方案。

1.1、负载场景一

这是一个国家级物流园区的货运订单和物流管理系统。在物流园区内的货运代理商、合作司机(货运车辆)、园区管理员和客服人员都要使用这套系统。每日RUV在1万人次,日PV在10万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品是否能起到提高效率的作用”。可以看出整个系统基本上没有访问压力,甲方对您设计的系统只有一个要求:能够保证系统以后的功能和性能扩展性。

【原创】nginx 301跳转到带www域名方法(不带www访问时重定向到带www域名) 有更新!

直接上代码:

server {
	listen       80;
	server_name  v5cn.cn;
	return       301 http://www.v5cn.cn$request_uri;
}

server {
	listen       80;
	server_name  www.v5cn.cn;
	
	location / {
		proxy_read_timeout 500s;
		proxy_connect_timeout 200s;
		proxy_pass http://blog;
	 }
}