用一个简单的方法构建高可用服务端

一. 什么是高可用性

服务端,顾名思义就是为用户提供服务的。 停工时间,就是不能向用户提供服务的时间。 高可用,就是系统具有高度可用性,尽量减少停工时间。

停工的原因一般有:

  1. 服务器故障。例如服务器宕机,服务器网络出现问题,机房或者机架出现问题等。
  2. 访问量急剧上升,导致服务器压力过大。导致访问量急剧上升的原因有:
    1. 时间和访问量都可以预见的,例如秒杀活动,售票系统。
    2. 时间和访问量都不可以预见的,例如特发性新闻(马航失联的事件)

停工的原因,可以理解为灾难,所以系统的高可用性就是容灾,即应对灾难的能力,系统有较好的容灾能力,也就是即使灾难出现,系统依然可以正常工作。

二. 怎么提升系统的高可用性

1. 机器层面的灾难

例如:

  • 机器宕机(其中一台服务器宕机了)
  • 机房故障(机房被水淹了)
  • 网络异常(电信的某条光纤被挖断了)

从范围了说,有可能是一台机器,也有可能是多台机器(机房或者某个区域,例如广东),甚至全部机器(那就没救了。。)。

思路就是在多台机器上部署服务,即使一台机器出现问题,其他机器依然可以提供服务。当然,比较可靠的是,多台机器最好在不同的机房,不同的地域,但是对应的成本也会上升。

1. 主从方式

主服务负责提供服务,从服务负责监测主服务器的心跳。当主服务出现问题,立刻转换为从服务器提供服务。例如Mysql的主从架构。

2.多机多工方式

在N台机器上面,运行N个服务,通过负载均衡,把请求分发到不同的机器。当其中一台机器出现问题。系统会自动的切换流量,也就是把请求都导流到其他正常的机器上。

2. 业务层面的灾难

例如:

  • 程序出bug了
  • 访问量急剧上升(预计QPS是1k,突然去到1w)

优化思路:

  1. 大系统小做。一个大系统,必然会有许多模块,把这些模块切分为多个小服务。例如用户系统,是一个独立的服务,消费系统,是一个独立的服务。每个服务都提供访问的API,给其他服务访问。缺点是服务与服务之间的通讯成本增加,开发成本也会增加,因为要开发API。但是好处是:
    1. 必要的时候,这些API可以提供给外部
    2. 符合高内聚低耦合的原则
    3. 当某个服务压力上升时,或者服务出现bug时,其他不依赖于问题服务的服务,依然可以正常工作。例如消费服务出现问题,但是聊天服务可以依然可以正常工作。
  2. 有损服务。让服务延迟执行,以保证核心需求得到很好的处理。例如微信抢红包,核心需求是立刻知道抢红包的结果,所以服务端先返回抢红包的结果,而用户对是否即时入账并不关心,所以,把入账这个过程,放在异步队列里面做。
  3. 柔性可用。在正常服务和停工之间增加一个状态:部分可用。当压力上来的时候,可以停止某些非必要服务,以保证必要服务可以正常运行。又例如遇到bug的时候,短时间内不能立刻修复,而且出bug的业务又是非必要业务,可以先停止bug的业务,当然,这些要事先跟产品方商量好。
  4. 快速拒绝(过载保护)。检查当前系统的负载请求,如果负载过高,立刻返回等待提示,例如:系统繁忙,请稍后再试。否则,用户会不断重试,让已经负载很高的系统雪上加霜。在客户端,要限制重试的频率,例如30s后才能重试,或者没有收到服务端的返回前,不能再次提交请求。也可以在Nginx层加入限制,同一IP1秒内不能发送多于N个请求,多于的就快速拒绝,防止被攻击。

3. 验证高可用

当我们采用了各种措施来提升系统的容灾能力后,怎么测试我们的措施是否有用呢?

  1. 模拟客户端低网速。这个可以通过Fiddler来模拟
  2. 模拟服务端丢包。可以使用netern和tc
  3. 使用ab进行压测。
  4. 模拟服务器宕机,可以直接断开服务器网络来模拟

三、应用

应用一般都是针对上面的机器问题导致的机器层面的灾难,因为业务层面的,一般是在代码开发阶段考虑的。

高可用可以分为两个关键点:

  • 多节点
  • 自动切换流量

多节点,也就是要部署多个节点,无论其他节点是挂起状态(主从),还是工作昨天(多机多工)。 当有了多节点后,还是不够的,因为当灾难来临的话,如果要人工去切换流量,必然要花费较长时间,所以需要有自动切换流量的机制。 自动切换流量的另一个功能就是,当损坏的节点恢复后,流量又会自动得切回去。

四、HTTP的应用

常用的服务端架构,一般是这样:

Alt text

  • 客户端从DNS服务器获取服务器的IP
  • 客户端发起请求,请求先到Nginx层
  • Nginx层分发请求到服务层
  • 如果需要,服务层会请求上游的服务层,例如向用户系统获取用户数据。一般会已通过HTTP来实现。
  • 如果需要,服务层会访问缓存层,获取数据
  • 如果需要,服务层会访问数据库层,获取数据

1. 客户端层到Nginx层

会部署多个Nginx层,DNS服务器中部署多个IP,这样DNS服务器会把流量均匀地分到多个Nginx。 缺点是:

  • 不能自动切换流量。当其中一台Nginx不可用了,DNS服务器并不知道,所以不会自动切换流量

本机的hosts配置中,可以设置一个域名对应多个IP,设置方法: 192.168.137.130 www.test.com 192.168.137.133 www.test.com hosts的解析策略是,先访问第一个IP,如果失败,才会访问第二个IP 所以没有负载均衡的功能,但是有自动流量切换的功能。

2. Nginx到服务层

Nginx里面可以配置多个服务层。 Nginx有监听服务层是否可用的机制(upstream),所以可以实现自动切换流量

nginx配置

upstream gunicorn_pool
{
    #server 地址:端口号 weight表示权值,权值越大,被分配的几率越大;max_fails表示在fail_timeout中失败的最大次数,如果达到该次数,就不再导流量到该server
    server 192.168.137.130:9098 weight=4 max_fails=2 fail_timeout=30s;
    server 192.168.137.133:9098 weight=4 max_fails=2 fail_timeout=30s;
}

server {
    listen 80;
    server_name 127.0.0.1 www.test.com;
    access_log /data/logs/nginx_access.log;
    error_log /data/logs/nginx_error.log;
    location @gunicorn_proxy {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
        proxy_pass http://gunicorn_pool;
    }
}

配置一个upstream,gunicorn_pool。里面有两个服务层(130和137) 如果两个服务层都正常,Nginx会把流量根据weight值,导流到两个服务器。 同一个请求中,如果nginx导流到server1,发现返回的是错误响应(例如502),nginx会把请求再发送server2,相当于重试。这时会记录server1的fail次数+1 如果再fail_timeout时间内,server1的fail次数超过max_fails,在fail_timeout时间内,nginx就不会再把其他请求导流到server1了。

上面的机制,就可以实现自动的流量切换。当然也有负载均衡的功能,这个就是高并发的范畴了。

3. 服务层到上游服务器

  1. DNS服务器。使用DNS服务器把流量均分到上游服务层。缺点也是不能自动切换流量
  2. RPC-client。在服务器的机器中,部署一个RPC-client,一般的实现方案是启动一个Nginx,利用Nginx的upstream功能来分发流量,同时可以实现自动流量切换。服务层到上游服务层的请求,会先发到RPC-client,然后再到上游服务层,相当于加了一个HTTP代理。

4.服务层到缓存层

常用的缓存有redis和mongodb

1.redis

  • 主从架构
  • 哨兵架构
  • 集群架构

redis cluster

2.mongo

  • 主从架构
  • 副本集架构
  • 分片

mongo HA

5.服务层到数据库层

常用的数据库就是Mysql了。

  • 一主多从(主从复制)
  • 二主多从(主主复制)

五、TCP的应用

1. DNS方法

配置DNS服务器,一个域名,对应多个IP。 缺点是不能实现流量自动切换,例如S1挂了,DNS还是会返回S1的iP给客户端。客户端可能要重试几次,才会拿到其他Server的IP,才能实现连接。

2.get-ip接口

由于TCP是长连接,所以获取IP的请求是很少的,所以可以自己写一个接口,客户端通过接口来获取TCP Server的IP地址。 这样接口里面就可以做到自动切换流量了。例如A机器已经挂了,就不会返回A机器的IP了。 TCP Server可以把自身的状态在Redis,然后接口那边就可以获取TCP Server的状态了 也可以TCP Server提供一个http接口,返回自身的状态,供get-ip接口那边调用。 在互联网公司面试中,架构的底层一定是面试官会问问的问题,针对面试官一般会提到的问题,我录制了一些分布式,微服务,性能优化等技术点底层原理的录像视频,加群619881427可以免费获取这些录像,里面还有些分布式,微服务,性能优化,春天设计时,MyBatis的等源码知识点的录像视频。这些视频都是 找一些资深架构师朋友一起录制出来的,这些视频帮助以下几类程序员:

1.对现在的薪资不满,想要跳槽,却对自己的技术没有信心,不知道如何面对面试官。

2.想从传统行业转行到互联网行业,但没有接触过互联网技术。

3.工作1 - 5年需要提升自己的核心竞争力,但学习没有系统化,不知道自己接下来要学什么才是正确的,踩坑后又不知道找谁,百度后依然不知所以然。

4.工作5 - 10年无法突破技术瓶颈(运用过很多技术,在公司一直写着业务代码,却依然不懂底层实现原理)

如果你现在正处于我上述所说的几个阶段可以加下我的群来学习。而且我也能够提供一些面试指导,职业规划等建议。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏java达人

web安全简易规范123

web安全,大公司往往有专门的安全开发流程去保证,有专门的安全团队去维护,而对于中小网络公司,本身体量小,开发同时兼带运维工作,时间精力有限,但是,同样需要做一...

690
来自专栏BestSDK

体现细节设计?先从APP密码输入框开始吧

密码输入框在网页设计和APP设计中随处可见,相信每一位产品经理都思考且设计过相关的模块。 ? (图左:电脑网页上的密码输入框 图右:手机APP上的密码...

3486
来自专栏QQ音乐技术团队的专栏

追根溯源解杂音之谜,臻于至善得完美音质

不久前,团队发现其Android平台App在播放MV视频《凤凰花开的路口》时,会带有如电流声一般的杂音,这影响了用户体验。

2605
来自专栏大魏分享(微信公众号:david-share)

一个虚拟化客户上云的需求分析&架构设计-大卫的Azure学习笔记大全

案例分析与架构设计 案例分析:大卫公司电子商务网站案例研究 大卫公司是北京的一家媒体和出版公司,拥有约2000名员工。它有一个成功的直接面向消费者的电子商务网站...

3578
来自专栏程序员互动联盟

【入门必备】常用的C语言编程工具

中国有句古话叫做“工欲善其事,必先利其器”,可见我们对工具的利用是从祖辈就传下来的,而且也告诉我们在开始做事之前先要把工具准备好。有了好的工具那么我们做起事来也...

3345
来自专栏斑斓

可伸缩系统的架构经验

最近,阅读了Will Larson的文章Introduction to Architecting System for Scale,感觉很有价值。作者分享了他在...

2635
来自专栏有趣的django

Flask构建微电影(一) 第一章、项目介绍第二章、环境搭建

1740
来自专栏架构说

分布式追踪系统---google的dapper

说明:在info分析看到多次提到全链路跟踪 基本提到google的dapper, 这里不再重复早轮子,转载 看原文链接 最近看了google的分布式追踪系统da...

47912
来自专栏TSW

5201314对程序员意味着什么?

作为年轻人的潮流聚集地,Qzone在每个特殊的日子总会迎来一波猛烈的流量冲击。比如刚过去的520,下图是今年5月20号的流量情况:

2057
来自专栏AlgorithmDog的专栏

前端和后端分工的三种模式

最近在捣腾前端的东西,学习了一下前端知识。因这方面的知识太浅薄了,这篇简陋的博客就当抛砖引玉。 在Web开发中,前端攻城狮和后端攻城狮是...

2018

扫码关注云+社区