网站技术架构发展--[2. 也谈高可用]

    想写一个互联网技术栈的系列，先用高可用开始吧，都不可用了，其他技术更加无从谈起，说说我对高可用的理解吧。

    究竟什么是高可用，百度是这样说的说法有点复杂了，简单说就是：系统尽可能不要因为软件、硬件和运维部署的原因让系统用户无法访问。无论如何、一直可以用。

   无论如何、一直可以用是一个很高的要求，目前很难有公司做到所有产品线一直可以用。我一个朋友在苏宁易购，去年我10.2去他们家玩，他中午匆匆回来碰了个面说系统无法下单，晚上他再回来时候才说，降级了很多服务后，下单业务可以走通了。黄金周的两天(39小时)，交易平台无法使用忽略掉经济影响，从面子上挺跌份的；

    先从硬件讲起：

    通常在选择服务器上会进行拓扑图规划，其目的是针对不同的服务器职能(职责选择不同类型的服务器)：

    1.计算型：部署Web应用、逻辑服务、分布式计算服务。

    2.内存型：部署Redis，Memcached等缓存或内存数据库，数据库因为大量用到缓存机制，采购数据库服务时候也要考虑内存。

    3.存储型：部署文件系统等需要大量存储的系统。

   硬件层面高可用

   1.在企业里，分布式部署不太多的情况下，一般通过昂贵的硬件实现高可用，在单机上尽可能关注磁盘等持久性存储设备。

   2.互联网公司，更多的通过配置较低的服务器+冗余+软件手段实现高可用，毕竟对于再好的设备，硬件出现问题也不是低概率时间。

   3.纯硬件层面，要更多关注磁盘阵列的可用性，毕竟数据稳定大于一切。下图是几个RAID方案的对比。

再谈软件:

互联网行业的系统一般被划为：

展示层：使用web或者app

反向代理层：使用LVS或nginx

接口层：提供对外服务

服务层：完成业务，方便服务拆分

数据层：

整体的架构图通常如下：

软件上的高可用：

软件高可用有一个前提是：应用无状态。

反向代理层：

可以通过keepalive部署nginx的影子服务，实现高可用，通过心跳包检测状态，实现故障自动转移。

接口层的高可用：

接口层部署多台服务器，每台服务器部署相同服务，服务最好无状态。

nginx通过nginx.conf配置，实现方向代理，在多台都可用时候，将请求轮询(当然这里还有其他方式，轮询是最常用的一种方式)发送到一台服务器，如果其中一台服务器宕机，nginx会自动剔除该服务器，讲请求发送给尚【存活】的服务器。

服务层高可用：

服务层高可用，是用服务框架，将相同的服务部署在多台服务器上，每个服务注册到注册中心。api层在调用时，根据注册中心提供的服务地址，实现RPC调用。

服务层高可用：

这块有一点乱，说明如下：

1.是用服务框架，通常是dubbo或者netty

2.服务在启动时候注册服务到zookeeper上。

3.服务消费者启动时向注册中心订阅服务。

4.服务消费者通过服务提供者的jdk进行类似的本地调用。

5.服务框架将服务采用指定协议进行序列化，并根据注册中心提供的服务地址发送序列化后的数据。

6.服务提供者接受到请求后，服务框架对序列化的结果进行反序列化。

7.service执行并返回执行结果。

8.那台服务若不可用，注册中心会自动发送新的服务地址给消费者。

缓存层高可用

缓存层(使用Redis)高可用，可以通过Redis的哨兵机制，实现集群，哨兵机制可以在节点出现问题时候，通知客户端切换到备用服务上。同时可以多使用Redis的读写分离。

具体模型图如下：

数据层高可用

所有的数据库都可以实现主从同步，一台对应用提供服务，另一台冗余以保证高可用，常见的实践是keepalived存活探测，相同virtual IP提供服务，双读双写的情况专门列专题讲。

一通乱说，架构变为如下图：

这只是最基本的高可用架构，还没涉及搜索、分布式文件存储、消息队列等内容。

总结下：

所谓的高可用，无论软件还是硬件，都是通过冗余+故障自动转移来实现的,硬件故障是常态、50台物理机的机房，每1-2月出现一次所问题不奇怪，所谓的高可用就是用更多的硬件以及出现问题后的自动恢复来保证的。

（1）【反向代理层】的高可用，是通过nginx或lvs的冗余实现的，常见实践是keepalived + nginx。
      （2）【接口层】是通过服务层的冗余实现的，常见实践是nginx与服务之间的存活性探测与自动故障转移。
      （3）【服务层】的高可用，是通过服务层的冗余实现的，常见实践是通过dobbo和netty加上注册中心来实现的。
      （4）【缓存层】的高可用，是通过缓存数据的冗余实现的，可以通过哨兵机制来实现。
      （5）【数据层】的高可用，是通过写库的冗余实现的，常见实践是keepalived + virtual IP自动故障转移

今天就说这么多吧，更多内容可以关注本人微信公众号。