文章目录

平常心博客

平常心的日常积累

【转载】Spring Cloud(九)高可用的分布式配置中心 Spring Cloud Config 集成 Eureka 服务

上一篇文章,讲了SpringCloudConfig 集成Git仓库,这一篇我们讲一下 SpringCloudConfig 配和 Eureka 注册中心一起使用

在分布式系统中,由于服务数量巨多,为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件spring cloud config ,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中。在spring cloud config 组件中,分两个角色,一是config server,二是config client,业界也有些知名的同类开源产品,比如百度的disconf。

相比较同类产品,SpringCloudConfig最大的优势是和Spring无缝集成,支持Spring里面Environment和PropertySource的接口,对于已有的Spring应用程序的迁移成本非常低,在配置获取的接口上是完全一致,结合SpringBoot可使你的项目有更加统一的标准(包括依赖版本和约束规范),避免了应为集成不同开软件源造成的依赖版本冲突。

准备工作

Eureka Service

Eureka 注册中心,就使用第三篇文章的源码

项目:spring-cloud-eureka-service 下载地址在文章末尾

Spring Cloud(八)高可用的分布式配置中心 Spring Cloud Config

http://www.ymq.io/2017/12/05/spring-cloud-ribbon-rest/#eureka-server

服务端配置

config Server Eureka

复制上一篇的项目 spring-cloud-config-server 修改项目名称为:spring-cloud-config-server-eureka-provider

【转载】Spring Cloud(八)高可用的分布式配置中心 Spring Cloud Config

在分布式系统中,由于服务数量巨多,为了方便服务配置文件统一管理,实时更新,所以需要分布式配置中心组件。在Spring Cloud中,有分布式配置中心组件spring cloud config ,它支持配置服务放在配置服务的内存中(即本地),也支持放在远程Git仓库中。在spring cloud config 组件中,分两个角色,一是config server,二是config client,业界也有些知名的同类开源产品,比如百度的disconf。

相比较同类产品,SpringCloudConfig最大的优势是和Spring无缝集成,支持Spring里面Environment和PropertySource的接口,对于已有的Spring应用程序的迁移成本非常低,在配置获取的接口上是完全一致,结合SpringBoot可使你的项目有更加统一的标准(包括依赖版本和约束规范),避免了应为集成不同开软件源造成的依赖版本冲突。

Spring Cloud Config 简介

SpringCloudConfig就是我们通常意义上的配置中心,把应用原本放在本地文件的配置抽取出来放在中心服务器,从而能够提供更好的管理、发布能力。SpringCloudConfig分服务端和客户端,服务端负责将git(svn)中存储的配置文件发布成REST接口,客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化,从而主动去获取新的配置,这需要每个客户端通过POST方法触发各自的/refresh。

SpringCloudBus通过一个轻量级消息代理连接分布式系统的节点。这可以用于广播状态更改(如配置更改)或其他管理指令。SpringCloudBus提供了通过POST方法访问的endpoint/bus/refresh,这个接口通常由git的钩子功能调用,用以通知各个SpringCloudConfig的客户端去服务端更新配置。

注意:这是工作的流程图,实际的部署中SpringCloudBus并不是一个独立存在的服务,这里单列出来是为了能清晰的显示出工作流程。

【转载】Spring Cloud(七)服务网关 Zuul Filter 使用

上一篇文章中,讲了Zuul 转发,动态路由,负载均衡,等等一些Zuul 的特性,这个一篇文章,讲Zuul Filter 使用,关于网关的作用,这里就不再次赘述了,重点是zuul的Filter ,我们可以实现安全控制,比如,只有请求参数中有token和密码的客户端才能访问服务端的资源。那么如何来实现Filter了?

Spring Cloud Zuul

准备工作

在开始测试服务之前,我们先拿之前两篇博客,构建的两个微服务代码为基础,进行下面的操作,主要使用下面几个工程:

建议先阅读以下文章

Spring Cloud(六)服务网关 zuul 快速入门-http://blog.v5cn.cn/articles/2017/12/17/1513483153523.html

简单使用

新建项目 spring-cloud-zuul-filter

添加依赖

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>

【转发】Spring Cloud(六)服务网关 zuul 快速入门

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中,除了具备服务路由、均衡负载功能之外,它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色,为微服务架构提供了前门保护的作用,同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面,使得服务集群主体能够具备更高的可复用性和可测试性。

路由在微服务体系结构的一个组成部分。例如,/可以映射到您的Web应用程序,/api/users映射到用户服务,并将/api/shop映射到商店服务。ZuulNetflix的基于JVM的路由器和服务器端负载均衡器。

Netflix使用Zuul进行以下操作:

  • 认证
  • 洞察
  • 压力测试
  • 金丝雀测试
  • 动态路由
  • 服务迁移
  • 负载脱落
  • 安全
  • 静态响应处理
  • 主动/主动流量管理

Zuul的规则引擎允许基本上写任何JVM语言编写规则和过滤器,内置Java和Groovy。

什么是服务网关

服务网关 = 路由转发 + 过滤器

1、路由转发:接收一切外界请求,转发到后端的微服务上去;

2、过滤器:在服务网关中可以完成一系列的横切功能,例如权限校验、限流以及监控等,这些都可以通过过滤器完成(其实路由转发也是通过过滤器实现的)。

【转载】Spring Cloud(五)断路器监控(Hystrix Dashboard)

在上两篇文章中讲了,服务提供者 Eureka + 服务消费者 Feign,服务提供者 Eureka + 服务消费者(rest + Ribbon),本篇文章结合,上两篇文章中代码进行修改加入 断路器监控(Hystrix Dashboard)

在微服务架构中,根据业务来拆分成一个个的服务,服务与服务之间可以相互调用(RPC),在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用,单个服务通常会集群部署。由于网络原因或者自身的原因,服务并不能保证100%可用,如果单个服务出现问题,调用这个服务就会出现线程阻塞,此时若有大量的请求涌入,Servlet容器的线程资源会被消耗完毕,导致服务瘫痪。服务与服务之间的依赖性,故障会传播,会对整个微服务系统造成灾难性的严重后果,这就是服务故障的“雪崩”效应。

针对上述问题,在Spring Cloud Hystrix中实现了线程隔离、断路器等一系列的服务保护功能。它也是基于Netflix的开源框架 Hystrix实现的,该框架目标在于通过控制那些访问远程系统、服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。Hystrix具备了服务降级、服务熔断、线程隔离、请求缓存、请求合并以及服务监控等强大功能。

什么是断路器

断路器模式源于Martin Fowler的Circuit Breaker一文。“断路器”本身是一种开关装置,用于在电路上保护线路过载,当线路中有电器发生短路时,“断路器”能够及时的切断故障电路,防止发生过载、发热、甚至起火等严重后果。

在分布式架构中,断路器模式的作用也是类似的,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),向调用方返回一个错误响应,而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放,避免了故障在分布式系统中的蔓延。

【转载】Spring Cloud(四)服务提供者 Eureka + 服务消费者 Feign

上一篇文章,讲述了如何通过RestTemplate+Ribbon去消费服务,这篇文章主要讲述如何通过Feign去消费服务。

一、Feign简介

Feign是一个声明式的伪Http客户端,它使得写Http客户端变得更简单。使用Feign,只需要创建一个接口并注解。它具有可插拔的注解特性,可使用Feign 注解和JAX-RS注解。Feign支持可插拔的编码器和解码器。Feign默认集成了Ribbon,并和Eureka结合,默认实现了负载均衡的效果。

Feign 具有如下特性:

  • 可插拔的注解支持,包括Feign注解和JAX-RS注解
  • 支持可插拔的HTTP编码器和解码器
  • 支持Hystrix和它的Fallback
  • 支持Ribbon的负载均衡
  • 支持HTTP请求和响应的压缩 Feign是一个声明式的Web Service客户端,它的目的就是让Web Service调用更加简单。它整合了Ribbon和Hystrix,从而不再需要显式地使用这两个组件。Feign还提供了HTTP请求的模板,通过编写简单的接口和注解,就可以定义好HTTP请求的参数、格式、地址等信息。接下来,Feign会完全代理HTTP的请求,我们只需要像调用方法一样调用它就可以完成服务请求。

简而言之:Feign能干Ribbon和Hystrix的事情,但是要用Ribbon和Hystrix自带的注解必须要引入相应的jar包才可以。

Eureka Server

提供服务注册和发现服务

添加依赖

在项目 spring-cloud-eureka-service pom.xml中引入需要的依赖内容:

<dependency>
	<groupId>org.springframework.cloud</groupId>
	<artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>

【转载】Spring Cloud(三)服务提供者 Eureka + 服务消费者(rest + Ribbon)

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。

Ribbon是什么?

Ribbon是Netflix发布的开源项目,主要功能是提供客户端的软件负载均衡算法,将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时,重试等。简单的说,就是在配置文件中列出Load Balancer(简称LB)后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随即连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。

LB方案分类

目前主流的LB方案可分成两类:一种是集中式LB, 即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件,如F5, 也可以是软件,如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方;另一种是进程内LB,将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选择出一个合适的服务器。Ribbon就属于后者,它只是一个类库,集成于消费方进程,消费方通过它来获取到服务提供方的地址。

Ribbon的主要组件与工作流程

微服务架构的核心思想是,一个应用是由多个小的、相互独立的、微服务组成,这些服务运行在自己的进程中,开发和发布都没有依赖。 不同服务通过一些轻量级交互机制来通信,例如 RPC、HTTP 等,服务可独立扩展伸缩,每个服务定义了明确的边界,不同的服务甚至可以采用不同的编程语言来实现,由独立的团队来维护。 简单的来说,一个系统的不同模块转变成不同的服务!而且服务可以使用不同的技术加以实现!

Ribbon的核心组件

均为接口类型,有以下几个:

ServerList

  • 用于获取地址列表。它既可以是静态的(提供一组固定的地址),也可以是动态的(从注册中心中定期查询地址列表)。

ServerListFilter

  • 仅当使用动态ServerList时使用,用于在原始的服务列表中使用一定策略过虑掉一部分地址。

IRule

  • 选择一个最终的服务地址作为LB结果。选择策略有轮询、根据响应时间加权、断路器(当Hystrix可用时)等。

Ribbon在工作时首选会通过ServerList来获取所有可用的服务列表,然后通过ServerListFilter过虑掉一部分地址,最后在剩下的地址中通过IRule选择出一台服务器作为最终结果。

【转载】Spring Cloud(二)Consul 服务治理实现 有更新!

Spring Cloud Consul 项目是针对Consul的服务治理实现。Consul是一个分布式高可用的系统,具有分布式、高可用、高扩展性。

Consul 简介

Consul 是 HashiCorp 公司推出的开源工具,用于实现分布式系统的服务发现与配置。与其他分布式服务注册与发现的方案,Consul的方案更“一站式” ,内置了服务注册与发现框 架、具有以下性质:

  • 分布一致性协议实现、
  • 健康检查、
  • Key/Value存储、
  • 多数据中心方案,

不再需要依赖其他工具(比如ZooKeeper等)。

使用起来也较 为简单。Consul使用Go语言编写,因此具有天然可移植性(支持Linux、windows和Mac OS X);安装包仅包含一个可执行文件,方便部署,与Docker等轻量级容器可无缝配合 。 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对. 一致性协议采用 Raft 算法,用来保证服务的高可用. 使用 GOSSIP 协议管理成员和广播消息, 并且支持 ACL 访问控制.

Consul 的使用场景

  • docker 实例的注册与配置共享
  • coreos 实例的注册与配置共享
  • vitess 集群
  • SaaS 应用的配置共享
  • 与 confd 服务集成,动态生成 nginx 和 haproxy 配置文件

【转载】SpringCloud(一) 服务的注册与发现(Eureka) 有更新!

SpringCloud 服务的注册与发现(Eureka)

Spring Cloud是一个基于Spring Boot实现的云应用开发工具,它为基于JVM的云应用开发中涉及的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud简介

Spring Cloud包含了多个子项目(针对分布式系统中涉及的多个不同开源产品),比如:Spring Cloud Config、Spring Cloud Netflix、Spring Cloud0 CloudFoundry、Spring Cloud AWS、Spring Cloud Security、Spring Cloud Commons、Spring Cloud Zookeeper、Spring Cloud CLI等项目。

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

一、什么是高可用

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

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

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

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

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

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

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

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

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

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

【转载】小白科普:Netty有什么用? 有更新!

随着移动互联网的爆发性增长,小明公司的电子商务系统访问量越来越大,由于现有系统是个单体的巨型应用,已经无法满足海量的并发请求,拆分势在必行。
2008f6555f22445e8beadef49b1ada52-640.png

在微服务的大潮之中, 架构师小明把系统拆分成了多个服务,根据需要部署在多个机器上,这些服务非常灵活,可以随着访问量弹性扩展。

ed55535bba804f47ab4aaaf826f54a77-641.png

【转载】架构设计:负载均衡层设计方案(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万左右。甲方总经理使用这套系统的原有是抱着“试一下移动互联网对物流产品是否能起到提高效率的作用”。可以看出整个系统基本上没有访问压力,甲方对您设计的系统只有一个要求:能够保证系统以后的功能和性能扩展性。