构建高可用服务端

一. 什么是高可用性

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

停工的缘由通常有：

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. 模拟服务器宕机，能够直接断开服务器网络来模拟

3、应用

应用通常都是针对上面的机器问题致使的机器层面的灾难，由于业务层面的，通常是在代码开发阶段考虑的。

高可用能够分为两个关键点：

• 多节点
• 自动切换流量

多节点，也就是要部署多个节点，不管其余节点是挂起状态（主从），仍是工做昨天（多机多工）。
当有了多节点后，仍是不够的，由于当灾难来临的话，若是要人工去切换流量，必然要花费较长时间，因此须要有自动切换流量的机制。
自动切换流量的另外一个功能就是，当损坏的节点恢复后，流量又会自动得切回去。

4、HTTP的应用

经常使用的服务端架构，通常是这样：

• 客户端从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了。

• 一主多从（主从复制）
• 二主多从（主主复制）

5、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接口那边调用。

参考：
柔性可用——移动互联网时代的一秒响应秘诀
发这么多红包 微信IT架构为啥没崩溃？
高可用性
腾讯大讲堂：发10亿个红包，微信为啥没崩溃？
关于柔性可用的一些思考