－、高可用策略
1- 一个性能差的高可用其实上是假的高可用，高可用一定有性能的下限
2- 高可用首先是要保证重要业务的高可用，需要对业务进行取舍，关注于最重要的方面

3- 根据业务的优先级进行区分，高优先级的业务走不同的通道，保持高的服务质量，即QoS是高可用的重要组成部分

4- 高可用的一个最廉价同时也是最简单的方案就是扩容

5- 可服务节点的水平扩展和流量分流是保证高可用的常见手段

6- 对于异常的事件，或者说峰拥，需要进行自我保护，通过排队的机制来确保业务能够能够继续。否则的话事情只会是更糟


二、相关技术
高可用包含了如上所示的这些方面，每一个方面都不能够独立地解决高可用的问题，而需要统筹考虑。简单地说，相关的技术有：

1- 性能评估和测量

2- 业务的重要度区分

3- 不同重要的业务不同的通道，业务上进行分离

4- 服务的水平扩展

5- 流量的均衡分配

6- 性能的动态监控

7- 软件的自我保护

8- 协商式的请求分流

转载请标明出处：

https://www.fangzhipeng.com/springcloud/2017/06/07/sc07-config.html

本文出自方志朋的博客

个人博客纯净版：https://www.fangzhipeng.com/springcloud/2017/06/07/sc07-config.html
最新Finchley版本请访问：

https://www.fangzhipeng.com/springcloud/2018/08/07/sc-f7-config.html

或者

http://blog.csdn.net/forezp/article/details/81041045
上一篇文章讲述了一个服务如何从配置中心读取文件，配置中心如何从远程git读取配置文件，当服务实例很多时，都从配置中心读取文件，这时可以考虑将配置中心做成一个微服务，将其集群化，从而达到高可用，架构图如下：

一、准备工作
继续使用上一篇文章的工程，创建一个eureka-server工程，用作服务注册中心。
在其pom.xml文件引入Eureka的起步依赖spring-cloud-starter-eureka-server，代码如下:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
	<modelVersion>4.0.0</modelVersion>

	<groupId>com.forezp</groupId>
	<artifactId>eureka-server</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<packaging>jar</packaging>

	<name>eureka-server</name>
	<description>Demo project for Spring Boot</description>

	<parent>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-parent</artifactId>
		<version>1.5.2.RELEASE</version>
		<relativePath/> <!-- lookup parent from repository -->
	</parent>

	<properties>
		<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
		<project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
		<java.version>1.8</java.version>
	</properties>

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

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>
	</dependencies>

	<dependencyManagement>
		<dependencies>
			<dependency>
				<groupId>org.springframework.cloud</groupId>
				<artifactId>spring-cloud-dependencies</artifactId>
				<version>Dalston.RC1</version>
				<type>pom</type>
				<scope>import</scope>
			</dependency>
		</dependencies>
	</dependencyManagement>

	<build>
		<plugins>
			<plugin>
				<groupId>org.springframework.boot</groupId>
				<artifactId>spring-boot-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>

	<repositories>
		<repository>
			<id>spring-milestones</id>
			<name>Spring Milestones</name>
			<url>https://repo.spring.io/milestone</url>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
		</repository>
	</repositories>


</project>


在配置文件application.yml上，指定服务端口为8889，加上作为服务注册中心的基本配置，代码如下：
server:
  port: 8889

eureka:
  instance:
    hostname: localhost
  client:
    registerWithEureka: false
    fetchRegistry: false
    serviceUrl:
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

入口类：
@EnableEurekaServer
@SpringBootApplication
public class EurekaServerApplication {

	public static void main(String[] args) {
		SpringApplication.run(EurekaServerApplication.class, args);
	}
}


二、改造config-server
在其pom.xml文件加上EurekaClient的起步依赖spring-cloud-starter-eureka，代码如下:
<dependencies>
		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-config-server</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>

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


配置文件application.yml，指定服务注册地址为http://localhost:8889/eureka/，其他配置同上一篇文章，完整的配置如下：
spring.application.name=config-server
server.port=8888

spring.cloud.config.server.git.uri=https://github.com/forezp/SpringcloudConfig/
spring.cloud.config.server.git.searchPaths=respo
spring.cloud.config.label=master
spring.cloud.config.server.git.username= your username
spring.cloud.config.server.git.password= your password
eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/

最后需要在程序的启动类Application加上@EnableEureka的注解。
三、改造config-client
将其注册微到服务注册中心，作为Eureka客户端，需要pom文件加上起步依赖spring-cloud-starter-eureka，代码如下：
<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-config</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-web</artifactId>
		</dependency>

		<dependency>
			<groupId>org.springframework.cloud</groupId>
			<artifactId>spring-cloud-starter-eureka</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
			<scope>test</scope>
		</dependency>

配置文件bootstrap.properties，注意是bootstrap。加上服务注册地址为http://localhost:8889/eureka/
spring.application.name=config-client
spring.cloud.config.label=master
spring.cloud.config.profile=dev
#spring.cloud.config.uri= http://localhost:8888/

eureka.client.serviceUrl.defaultZone=http://localhost:8889/eureka/
spring.cloud.config.discovery.enabled=true
spring.cloud.config.discovery.serviceId=config-server
server.port=8881



spring.cloud.config.discovery.enabled 是从配置中心读取文件。
spring.cloud.config.discovery.serviceId 配置中心的servieId，即服务名。
这时发现，在读取配置文件不再写ip地址，而是服务名，这时如果配置服务部署多份，通过负载均衡，从而高可用。
依次启动eureka-servr,config-server,config-client

访问网址：http://localhost:8889/

访问http://localhost:8881/hi，浏览器显示：

foo version 3

本文源码下载：
https://github.com/forezp/SpringCloudLearning/tree/master/chapter7
四、参考资料
spring_cloud_config
更多阅读
史上最简单的 SpringCloud 教程汇总
SpringBoot教程汇总
Java面试题系列汇总

    

        

        扫码关注公众号有惊喜
    
    

        （转载本站文章请注明作者和出处 方志朋的博客）
    

高可用集群
 

这篇先来认识高可用集群的一些基本概念。

1、什么是高可用集群

       高可用集群（High Availability Cluster，简称HA Cluster），是指以减少服务中断时间为目的的服务器集群技术。它通过保护用户的业务程序对外不间断提供的服务，把因软件、硬件、人为造成的故障对业务的影响降低到最小程度。


       简单说就是：保证服务不间断地运行，比如，在淘宝网什么时候都可以上去买东西，微信随时可以打开发消息聊天。

2、高可用集群的衡量标准

       要保证集群服务100%时间永远完全可用，几乎可以说是一件不可能完成的任务。比如，淘宝在这几年双十一刚开始的时候，一下子进来买东西的人很多，访问量大，都出现一些问题，如下单后却支付不了。所以说只能保证服务尽可能的可用，当然有些场景相信还是可能做到100%可用的。


       通常用平均无故障时间(MTTF)来度量系统的可靠性,用平均故障维修时间（MTTR）来度量系统的可维护性。于是可用性被定义为：HA=MTTF/(MTTF+MTTR)*100%。


      具体HA衡量标准:



描述


通俗叫法


可用性级别


年度停机时间


基本可用性


2个9


99%


87.6小时


较高可用性


3个9


99.9%


8.8小时


具有故障自动恢复能力的可用性


4个9


99.99%


53分钟


极高可用性


5个9


99.999%


5分钟


 
3、高可用集群实现原理

      高可用集群主要实现自动侦测(Auto-Detect)故障、自动切换/故障转移(FailOver)和自动恢复(FailBack)。
      简单来说就是，用高可用集群软件实现故障检查和故障转移（故障/备份主机切换）的自动化，当然像负载均衡、DNS分发也可提供高可性。

3-1、自动侦测(Auto-Detect)/ 故障检查

     自动侦测阶段由主机上的软件通过冗余侦测线，经由复杂的监听程序，逻辑判断，来相互侦测对方运行的情况。
     常用的方法是：集群各节点间通过心跳信息判断节点是否出现故障。

3-1-1、问题是：当有节点（一个或多个）和另外节点互相接收不到对方心跳信息时，如何决定哪一部分节点是正常运行的，而哪一部分是出现故障需要隔离的呢（避免集群脑裂）？

      这时候通过法定票数（quorum）决定，即当有节点故障时，节点间投票决定哪个节点是有问题的，票数大于半数为合法。


票数：
       每个节点可以设置票数，即决定节点在集群内是否合法（正常）的权限值，这个是可以有多有少的，例如有些节点的性能较好或有其他优势，可以设置较多的票数。
法定票数（quorum）：

       当一个节点能和另一个节点保持心跳信息，该节点就获取得了另一个节点的票数，该节点获得的所有票数就是法定票数。

3-1-2、比较特殊的是只有两个节点的集群，或两边票数相等

       这时候可以借助另外的参考节点，如ping网关（可以是一个节点），可以和测试点ping通，但不可以和对方通，说明对方节点有问题，或本节点有问题；还有就是通过仲裁设备，如仲裁磁盘，每个节点都间隔一定时间不停往磁盘写数据，若监测到对方不再写入的时候，可能对方节点出故障。
      但最好还是使得组成集群的节点数量为单数台（2n+1），当集群分区脑裂时，节点数量小于一半（>n+1）的分区自动停止对外提供服务。


3-1-3、Pasox算法和Zookeeper


      关于“投票”，有必要知道著名的Pasox算法和Zookeeper：
Paxos算法：


      Paxos算法解决的是保证集群中每个节点执行相同的操作序列，可以保证分布式群集中的数据一致性。
      例如，通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被 批准（所以永远只会有一个写操作得到批准）；而其他的写操作竞争失败只好再发起一轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排序。

      编号严格递增，当一个节点接受了一个编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己数据不一致了，自动停止对外服务并重启同步过程。
      任何一个节点挂掉都不会影响整个集群的数据一致性（总2n+1台，除非挂掉大于n台）。


Zookeeper：


      Zookeeper是 Hadoop 大数据生态的一个独立组件，是 Google 的 Chubby一个开源的实现，可以说是Paxos算法（类似）的实现。
      Zookeeper主要提供分布式协调服务，分布式应用程序可以基于它实现服务注册（高可用），同步服务，配置维护和命名服务等。
      Zookeeper真正提供的是类似我们普通电脑上的文件系统目录的功能，不过可以原子的进行增/删/改/查操作；具体要实现什么分布式协调服务，需要自己写程序来操作Zookeeper上的“目录”。

      Zookeeper为什么可以作为分布式系统提供协调服务？


      最主要的是Zookeeper本身运行的是一个由多个Zookeeper节点组成的稳定的高可用集群。

       Zookeeper集群的高可用性和各节点“目录”数据的一致性正是基于 类似 Paxos算法实现的投票机制来保证的。

      所以 Zookeeper集群节点数量最好也是单数（2n+1），当集群脑裂分区时，分区节点数量不超过一半的（<n+1），会自动停止对外服务。
       比如：


      5台ZK节点组成ZK集群，当分成2台和3台的两个分区时，2台的分区会自动停止对外服务，3台的分区会继续提供服务。

      另外，如果用6台节点组成ZK集群，当分成3台和3台的两个分区时，这两个分区都自动停止对外服务，所以，容错率和5台节点组成的集群的是一样的，更应该用单数（2n+1）节点数量组成集群。




3-2、自动切换/故障转移（FailOver）

      自动切换阶段某一主机如果确认对方故障，则正常主机除继续进行原来的任务，还将依据各种容错备援模式接管预先设定的备援作业程序，并进行后续的程序及服务。
      通俗地说，即当A无法为客户服务时，系统能够自动地切换，使B能够及时地顶上继续为客户提供服务，且客户感觉不到这个为他提供服务的对象已经更换。
      通过上面判断节点故障后，将高可用集群资源（如VIP、httpd等，下面详见）从该不具备法定票数的集群节点转移到故障转移域（Failover Domain，可以接收故障资源转移的节点）。

3-2-1、高可用集群资源（HA Resource）和集群资源类型

集群资源是集群中使用的规则、服务和设备等，如VIP、httpd服务、STONITH设备等。类型如下：
        1、Primitive：主资源，在某一时刻只能运行在某个节点上，如VIP。
        2、group：组，资源容器，使得多个资源同时停/启等，一般只包含primitive资源。
        3、clone：克隆，可以在多个节点运行的资源，例如stonith设备管理进程、集群文件系统的分布式锁（dlm）作为资源，应运行在所有节点上。
        4、master/slave：特殊的clone资源，运行在两个节点上，一主一从，如：分布式复制块设备drbd（2.6.33之后整合进内核了）。

3-2-2、转移到哪个节点

根据资源的倾向（资源粘性、位置约束的分数比较）进行转移；
资源的倾向（资源定位的依据）：

 A、资源粘性：资源对节点倾向程度，资源是否倾向于当前节点。score，正值倾向于当前节点（还要和位置约束结合）。
 B、资源约束（Constraint）：资源和资源之间的关系

a、排列约束 （colocation）：资源间的依赖/互斥性，定义资源是否运行在同一节点上。score，正值表示要运行在同一节点上，负值则不可。
b、位置约束（location）：每个节点都有一个score值，正值则倾向于本节点，负值倾向于其他节点，所有节点score比较，倾向于最大值的节点。
c、顺序约束（order）：定义资源执行动作的次序，例如vip应先配置，httpd服务后配置。特殊的score值，-inf 负无穷，inf 正无穷。


       也就是说资源粘性定义资源对资源当前所在节点的倾向性，而位置约束定义资源对集群中所有节点的倾向性。如webip的资源粘性为100，位置约束对node1为200，当webip在node2上时，node1上线资源会转移到node1，因为当前节点node2粘性100小于对node1的位置约束200；如webip的资源粘性为200，位置约束对node1为100，当webip在node2上时，node1上线资源不会转移到node1，继续留在node2上，因为当前节点node2粘性200大于对node1的位置约束100。


3-3、自动恢复/故障回转(FailBack)

      自动恢复阶段在正常主机代替故障主机工作后，故障主机可离线进行修复工作。在故障主机修复后，透过冗余通讯线与原正常主机连线，自动切换回修复完成的主机上。

3-3-1、当排除故障后，是否要故障回转？

      根据资源粘性和资源约束的设置，一般备用设备单纯只用于备份，性能低于主设备，所以当主设备恢复时应转回，但故障回转需要资源转移，会影响到正在使用的客户，过程代价较高，所以是否需要回转根据实际判断。

3-4、其他关注点
3-4-1、如果节点不再成为集群节点成员时（不合法），如何处理运行于当前节点的资源？

      如果集群没有对其进行Fecning/Stonith隔离前，可以进行相关配置（without_quorum_policy），有如下配置选项：



1、stop：直接停止服务；
2、ignore：忽略，以前运行什么服务现在还运行什么（双节点集群需要配置该选项）；
3、Freeze：冻结，保持事先建立的连接，但不再接收新的请求；
4、suicide：kill掉服务。


3-4-2、集群脑裂（Split-Brain）和资源隔离（Fencing）

       脑裂是因为集群分裂导致的，集群中有节点因为处理器忙或者其他原因暂时停止响应时，与其他节点间的心跳出现故障，但这些节点还处于active状态，其他节点可能误认为该节点"已死"，从而争夺共享资源（如共享存储）的访问权，分裂为两部分独立节点。


       脑裂后果：这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。
       脑裂解决：上面3-1-1、3-1-2的方法也能一定程度上解决脑裂的问题，但完全解决还需要资源隔离（Fencing）。
       资源隔离（Fencing）：
              当不能确定某个节点的状态时，通过fencing把对方干掉，确保共享资源被完全释放，前提是必须要有可靠的fence设备。

   节点级别：
            STONITH（shoot the other node in the head，爆头。硬件方式），直接控制故障节点的电源，绝对彻底。
    资源级别：

            例如：FC SAN switch（软件方式）可以实现在存储资源级别拒绝某节点的访问


4、高可用集群工作模型
4-1、Active/Passive：主备模型

       一个活动主节点，另一个不活动作为备用节点，当主节点故障，转移到备节点，这时备节点就成为了主节点。备节点完全冗余，造成一定浪费。如下图，mysql、DRBD主从节点间还要进行同步：


4-2、Active/Active：双主模型

       两个节点都是活动的，两个节点运行两个不同的服务，也互为备用节点。也可以提供同一个服务，比如ipvs，前端基于DNS轮询。这种模型可以使用比较均衡的主机配置，不会造成浪费。

4-3、N+1

      N个活动主节点N个服务，一个备用节点。这需要额外的备用节点必须能够代替任何主节点，当任何主节点故障时，备节点能够负责它的角色对外提供相应的服务。如下图，最后一个备用节点可以作为前两台主节点的DRBD和第三台主节点的MYSQL提供备用功能：


4-4、N+M

      N个活动主节点，M个备用节点。像上面的N+1模型，一个备用节点可能无法提供足够的备用冗余能力，备用节点的数量M是成本和可靠性要求之间的折衷。
      也有一种说法：N-M: N个节点M个服务， N>M， 活动节点为N， 备用节点为N-M。

4-5、N-to-1

      这和N+1一样，也是N个活动主节点，一个备用节点；不同是的备用节点成为主节点只是暂时的，当原来故障的节点修复后，必须回转才能正常工作。

4-6、N-to-N

      N个主节点N个备用节点。这是A/A双主和N + M模型的组合，N节点都有服务，如果一个坏了，剩下的每个节点都可以作为替代提供服务。如下图，当共享存储是可用的，每一个节点都可能会被用于故障切换。起搏器甚至可以运行服务的多个副本，以分散工作量。


5、高可用集群架构层次
    
5-1、节点主机层 

       这一层主要是正在运行在物理主机上的服务，高可用集群相关的软件运行在各主机上，集群资源也是在各主机上。

5-2、Messaging and Membership Layer

       信息传递层，传递集群信息的一种机制，通过监听UDP 694号端口，可通过单播、组播、广播的方式，实时快速传递信息，传递的内容为高可用集群的集群事务，例如：心跳信息，资源事务信息等等，只负责传递信息，不负责信息的计算和比较。


       成员关系（Membership）层，这层最重要的作用是主节点（DC）通过Cluster Consensus Menbership Service（CCM或者CCS）这种服务由Messaging层提供的信息，来产生一个完整的成员关系。这层主要实现承上启下的作用，承上，将下层产生的信息生产成员关系图传递给上层以通知各个节点的工作状态；启下，将上层对于隔离某一设备予以具体实施。

5-3、CRM（Cluster Resource Manager）

      集群资源管理器层，它主要是用来提供那些不具有高可用的服务提供高可用性的。它需要借助Messaging Layer来实现工作，因此工作在Messaging Layer上层。
      资源管理器的主要工作是收集messaging Layer传递的节点信息，并负责信息的计算和比较，并做出相应的动作，如服务的启动、停止和资源转移、资源的定义和资源分配。
      在每一个节点上都包含一个CRM，且每个CRM都维护这一个CIB（Cluster Information Base，集群信息库），只有在主节点上的CIB是可以修改的，其他节点上的CIB都是从主节点那里复制而来的。
       CRM会推选出一个用于计算和比较的节点，叫DC（Designated coordinator）指定协调节点，计算由PE（Policy Engine）策略引擎实现，计算出结果后的动作控制由TE（Transition Engine）事务引擎实现。
       在每个节点上都有一个LRM（local resource manager）本地资源管理器，是CRM的一个子功能，接收TE传递过来的事务，在节点上采取相应动作，如运行RA脚本等。

5-4、RA（Resource Rgent）

      资源代理层，简单的说就是能够集群资源进行管理的脚本，如启动start，停止stop、重启restart和查询状态信息status等操作的脚本。LRM本地资源管理器负责运行。
      资源代理分为：



1、Legacy heartbeat（heatbeat v1版本的资源管理）；
2、LSB（Linux Standard Base），主要是/etc/init.d/*目录下的脚,start/stop/restart/status；
3、OCF（Open Cluster Famework），比LSB更专业，更加通用,除了上面的四种操作，还包含monitor、validate-all等集群操作，OCF 的规范在http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD。
4、STONITH：实现节点隔离


6、高可用集群软件
6-1、Messaging Layer 集群信息层软件

1、heartbeat (v1, v2)
2、heartbeat v3

可以拆分为：heartbeat, pacemaker, cluster-glue

3、corosync

从OpenAIS分离的项目。

4、cman 
5、keepalived

一般用于两个节点的集群


6、ultramokey

6-2、CRM集群资源管理器软件

1、Haresource

heartbeat v1 v2包含，使用文本配置接口haresources

2、crm 

heartbeat v2包含，可以使用crmsh或者heartbeat-gui来进行配置

3、pacemaker 

heartbeat v3分离出来的项目，配置接口：CLI：crm、pcs和GUI：hawk(WEB-GUI)、LCMC、pacemaker-mgmt、pcs

4、rgmanager 

Cman包含，使用rgmanager(resource group manager)实现管理, 具有Failover Domain故障转移域这一特性，也可以使用RHCS（Redhat Cluster Suite）套件来进行管理：Conga的全生命周期接口，Conga（luci/ricci）先安装后，可用其安装高可用软件，再进行配置。


6-3、常用组合

heartbeat v2+haresource(或crm) (说明：一般常用于CentOS 5.X)
heartbeat v3+pacemaker (说明：一般常用于CentOS 6.X)
corosync+pacemaker (说明：现在最常用的组合)
cman + rgmanager (说明：红帽集群套件中的组件，还包括gfs2,clvm)
keepalived+lvs (说明：常用于lvs的高可用)


7、共享存储

       高可用集群多节点都需要访问数据，如果各节点访问同一个数据文件都是在同一个存储空间内的，就是说数据共享的就一份，而这个存储空间就共享存储。


       如Web或Mysql高可用集群，他们的数据一般需要放在共享存储中，主节点能访问，从节点也能访问。当然这也不是必须的，如可以通过rsync、DRBD来同步分别存储在主、从节点上的块数据，而且相对共享存储实现成本更低，具体使用什么需要根据实际场景来选择。下面我们就简单说一下共享存储的类型：

7-1、DAS（Direct attached storage，直接附加存储）

       存储设备直接连接到主机总线上的，距离有限，而且还要重新挂载，之间有数据传输有延时；


       这是设备块级别驱动上实现的共享，持有锁是在节点主机本地上的，无法通知其他节点，所以如果多节点活动模型的集群同时写入数据，会发生严重的数据崩溃错误问题，主备双节点模型的集群在分裂的时候了会出现问题；


       常用的存储设备：RAID 阵列、SCSI 阵列。

7-2、NAS（network attached storage，网络附加存储）

       文件级别交互的共享，各存储设备通过文件系统向集群各节点提供共享存储服务，是用C/S框架协议来实现通信的应用层服务。


       常用的文件系统：NFS、FTP、CIFS等，如使用NFS实现的共享存储，各节点是通过NFS协议来向共享存储请求文件的。

7-3、SAN（storage area network、存储区域网络)

        块级别的，将通信传输网络模拟成SCSI（Small Computer System Interface）总线来使用，节点主机（initiator）和SAN主机（target）都需要SCSI驱动，并借助网络隧道来传输SAN报文，所以接入到SAN主机的存储设备不一定需要是SCSI类型的。


        常用的SAN：FC光网络（交换机的光接口超贵，代价太高）、IPSAN（iscsi、存取快，块级别，廉价）。




经过写这篇文章，对高可用集群有了一个基本的认识，下面将会动手进行应用配置……

 
【参考资料】
1、《大型网站技术架构：核心原理与案例分析》

2、《从Paxos到Zookeeper ：分布式一致性原理与实践》

3、《大话存储Ⅱ—存储系统架构与底层原理极限剖析》

4、Pacemaker：http://clusterlabs.org/wiki/Pacemaker
5、High-availability cluster：https://en.wikipedia.org/wiki/High-availability_cluster#Node_configurations|
6、Linux 高可用（HA）集群基本概念详解：http://www.linuxidc.com/Linux/2013-08/88522.htm
7、高可用集群基本概念与heartbeat文本配置接口：http://www.178linux.com/10982
8、高可用集群原理：http://boxinknown.blog.51cto.com/10435935/1673396
9、理解 OpenStack 高可用(HA) （4）: Pacemaker 和 OpenStack Resource Agent （RA）：http://www.cnblogs.com/sammyliu/p/5025362.html

本文来自阿里沐剑老师的分享。

 

写在前面

大家好，我今天分享的题目是《高可用实践：从淘宝到上云的差异》，取这个标题是因为会涉及到两个方面内容，一方面以淘宝为例子，传统的 IDC 的时候，我们稳定性是怎么做的，另外在云计算背景下，有很多创业公司是基于阿里云这样的公有云基础设施做研发，在公有云的环境下怎么做好我们系统的高可用。

我的花名叫沐剑，2011 年加入淘宝做评价系统，2012-2015 年在店铺平台，负责店铺的前台浏览系统和后台的 RPC 服务，以及一些性能优化、双 11 保障的事情。到了 2015 年开始到了 TAE 团队，开始负责云端架构及整体高可用方案，TAE 的升级版 EWS 现在也在聚石塔上面帮大量 ISV 和创业公司解决运维部署、自动化监控和性能分析等等问题。

去年我是作为阿里商家事业部双 11 作战项目研发的 PM。2017 年我开始接手商家营销团队。在阿里五六年的经验，其实就做了几件事，比如连续五年参加了双十一的核心备战，然后像去 IOE、异地多活，全链路压测、安全混合云、容器服务等项目参与设计和实施。

首先我会从淘宝店铺角度分享，以前在店铺是怎么样做双 11 保障的，后面是一些公有云相关的内容。

 

淘宝店铺稳定性体系建设

这是一个淘宝的店铺系统，这套系统是一个非常典型的高并发的浏览系统，在前几年的双 11 峰值有 20 万次的 Web 页面请求，平均一个页面对应了 20 次的 RPC 调用，这个时候对于整个系统的集合来说每秒的 QPS 是 400 万次，这中间就会涉及到缓存、数据库以及其它二方的 RPC 调用，对于这样的系统来说，在性能、稳定性和体验间要做一个平衡，既不能纯用太多的机器死扛这个访问量，又要保障用户的体验。



 

基础链路设计

从请求链路来说，首先 DNS 把 CDN 的 VIP 解析出来，分布在全球不同的区域，CDN 回源到接入层分别经过 4 层和 7 层的负载均衡，近几年会发现 CDN 这个行业早已不仅仅局限做 CSS/JS 等静态资源的缓存，也承担了一些动态加速和收敛的特性，所以我们是通过 CDN 做域名收敛，收敛后会把这个流量发到统一接入层，然后到应用集群，后面再经过应用存储、Cache 这些服务。

当我们在做稳定性的时候，会考虑性能和稳定性之间是什么关系，很多人认为这两者是冲突的，比如我要保障一个东西的性能非常高的时候，要牺牲掉很多别的东西，可能你要引入一个非常新的框架或者基础设施来提升性能，但它的稳定性可能是不那么成熟的，但是从容量规划的角度看，只有这套系统性能足够好，才能承担像双 11 那样的大访问量。



店铺也是一套经历了很多年的系统，在应用层上的优化基本上已经做到极致了，我们就转变思路，在操作系统层能不能做一些优化，这里借助了一个比较好的工具 perf，在操作系统层面告诉你系统调用的开销是集中在哪里，从 perf 上就可以定位到有一个百分比，可以看到是比如数组分配还是 GC 产生了大量的开销。

最初我们发现是异常带来的开销，就会看为什么这个系统的异常会导致 20% 以上的 CPU 开销，最后用 BTrace 跟了一下异常的构造函数，发现是我们依赖的开源的三方包里通过异常做控制流，每一次它处理结束的时候，就抛一个 EOFException 出来，这个就导致了非常大的开销，我们就把开源包替换掉了。

当你依赖一些底层的东西的时候，如果对原理不太了解会给你带来一些意料之外的事情。JVM 里是有一个常量池存储字符串常量的地方，就是一个哈希表，如果说这个表的大小不足够大，就会从哈希查询变成链表查询，性能就会特别低。

再谈一个 warm up 的问题，当我们应用刚刚启动的时候，还没有把字节码编译成 native code，延迟非常高，用户就得到一个有损的服务。我们现在在内部的 JVM 做一个功能，会采集线上系统的调用，把热点方法收集下来做分析，在应用把真实流量挂上去之前，已经预先把所有的热点方法编译成 native code 保证这个性能。开源界也有其他的方案，比如 Azul 的 Zing 有个 ReadyNow，IBM 的 J9 有个 AOT，也是做类似的事情。

 

缓存设计



谈到缓存，Cache 里有一些小技巧，在做双十一备战时发现一个店铺的基础服务平时每天日常就有 100 亿的调用量，当时是几十台机器估了一下可能要成倍增长，成本是非常高的，怎么解决这个问题，当时写了个富客户端，让业务方先去查我们分布式 Cache，如果命中就直接返回来，如果不命中再走我们的服务端查。这种情况下，只要你能够保证命中率足够高，比如 98% 的命中率，就意味着只有 2% 是需要后端服务器承担剩下的请求，用非常少的服务器去承担非常大的流量，这是成本和性能间的权衡。

在缓存方面，我们很少会关心缓存的高可用是怎么部署的，它是一个偏运维的内容，我把缓存的部署简化成一个双机房的模型，因为它在高可用里是最简单的场景。

对于缓存来说有两种经典部署模式，第一种叫共享集群部署，在 IDC 里我的应用是分机房部署的，Cache 集群也是分机房部署，对于应用服务器来说，两边的 Cache 对他来说逻辑上是一个集群，会往 IDC 1 的 Cache 写一半过去，往 IDC 2 也写一半过去，这种部署的好处在于，机房间网络断掉的时候，有一半的数据是在缓存的，保证一半的数据能够命中，不会直接死掉，另外对成本上相对比较友好，没有浪费任何一个 Cache 的节点，这个 Cache 本身是复用的。

但是也正如刚才说的问题，如果中间断掉了，有一半的命中率是有损的，所以就诞生了另外的一个部署模式，就是独立部署，不管你哪个机房挂掉，命中率是基本不变的，两边同时保持了 98% 的命中率，但是它是成本不友好的，两边要同时部署，同时承担副本的作用，并且失效时，要同时失效另外一个 IDC 2，这样才保证一致性。

在缓存上，我认为一切东西都是可以被缓存的，通常我们认为缓存跟实际数据库里存在的东西可能是不一样的，有几毫秒的延迟或者怎么样，所以我们设计一个系统的时候，对一致性要求非常高的时候，会倾向于不用缓存，用数据库扛这个流量。

但以 MySQL 为例，InnoDB 里有一个很重要的缓存 Buffer Pool，对于一个数据库，在冷库的情况下用一堆 SQL 去查它，和慢慢预热完再查它的时候效果是不一样的，这个是我们当初在做异地多活时面临的一个问题。例如我已经有一个机房，希望建立一个新单元去承担这个机房的流量，当我建完这个单元，把所有的应用都部署好了后，把流量切 50% 过来会怎么样，假设这两个单元的机器数一样，这个单元会挂，因为这个数据库是冷的，缓存是空的，不能承担之前那个单元数据库所能承担的 QPS。

现在业界有很多叫 API 网关或者 CDN，他们在边缘节点也做了一层短暂的 Cache，可能只 Cache 50 或者 100 毫秒，但是当你系统受到攻击的时候可以拯救你后端的应用系统，攻击引发的命中率通常比较高，有这 50 毫秒的缓存，可能后端只有几百个 QPS 过来，那个流量你是可以承受的。

在高可用里两个非常经典的做法是限流和降级，在阿里双 11，有一位老兵说过一句话，他说当双 11 到来的时候，任何一个系统都可能出问题，你要做的是对你的上游限流，对你的下游限流。怎么理解，当上流的流量超过你的能力的时候就要限流，当下游比如 DBA 告诉你数据库压力很大了，那就对下游限流，只要保证住这个限流，你基本不会挂，每个系统都做到这个的时候，整个系统都是可用的。当流量超出你掌控的时候，这个做法可以让你成为这个暴风下的幸存者。



对限流降级的思考，第一限流降级考验的是什么问题，我认为本质上考验的是故障自恢复能力，在平时工作中会遇到机房断网或者停电，每半个月都会做断网演练，不告诉你发生什么，就把这个网切断，看你的应用 O 不 OK，一般是在晚上两三点，接到很多的机房报警，这个时候看你的架构设计的是否足够可用，如果足够可用就没问题，不会造成什么影响，继续睡觉，如果设计不好，就得爬起来立即处理。

而开关降级最大的作用，比如我们发现一些线上的问题，第一反映是赶紧回滚，但是当你的系统很大的时候，特别像 Java 这种，一个系统启动要启动几分钟，你的回滚完成，20 分钟都过去了，这个过程对用户来说都是有损的，而开关可以在一瞬间把所有的逻辑切到老的。这个是避免回滚时间导致的问题。开关有的时候能救命，如果没有这个开关的话，避免问题放大就只能回滚，所以开关是一个很大的价值所在。

 

容灾设计



另外一点非常重要的是，在设计一个技术方案的时候，就会把容灾的设计融入到方案里。比如在设计技术方案的时候，在最后一章单独有一个容灾设计，这个节点里任何服务挂掉的时候，你要保持什么样的方式保持这个服务是可用的。

在容灾设计时有几点必须考虑，比如我引了一个新 jar 包或者调了一个新的 RPC 的服务、引入了分布式的存储，以前没用过也不知道它稳不稳定，第一想法是它肯定会挂，它挂了我们怎么做，我们当时在做前台系统的异步化的时候，因为 Redis 支持 map 的数据结构，所以我们就是用 Redis 的 hmget 从这个 map 里拿出部分的 key 减少网卡的流量，但即使这个挂掉了，我们还会走老的 Cache，只不过网卡流量会大一些，但是对用户的服务是无损的，所以这里要考虑如果它挂了怎么做降级，有什么样的恢复流程。

另外是发布计划，在新系统上线时就会关注这些问题，比如这次有没有做数据迁移，比如以前我是 8 个库不够用了我拆到 16 个库或者 32 个库，中间一定是有数据迁移的，涉及到数据迁移一定要有一套对账系统保证这个数据是新数据和老数据是对得平的，不然一定有问题，因为我们是做交易相关的，订单、金额绝对不能出问题。

另外是你的发布顺序是不是有依赖，如果出了问题的时候，谁要先回滚，这里是取决于技术设计。另外是否要通过客服公告的方式告诉外部用户说有 5 分钟的不可用，如果真的有用户打电话有疑问客服同学可以向用户解释。

在高可用这个领域做久了会有一种直觉，这个直觉很重要，来源于你的经验转换成这种直觉，但是对于一个成熟的团队来说，需要把这种直觉转化为产品或工具。有很多牛人他们的技能都只能叫手艺，你需要把这种手艺转换成产品和工具。

 

公有云高可用设计

2015 年我去做云产品，这里给大家分享下我们是怎么样帮客户包括我们的系统在云上是做高可用的。

经典故障案例



首先看两个经典故障案例，第一个是 Gitlab 生产数据库删了，它恢复了很久，Snapshot 等全都没有生效，做了五六层的备份也都没有什么用。这个事情说明第一我们的故障要定期演练，比如中间件在做的线上故障演练，你说你的系统可用性好，我把这个主库断了，虚拟机挂掉几台试试，做这些演练就可以知道你这个容灾体系是不是可靠的，如果没有这个演练的话，当真正的故障发生时你才会发现这个东西是不 OK 的。

另外一个很典型的问题，Gitlab 对备份的原理是不够了解的。比如当时用的 PostgreSQL 的一个版本，当时是有问题的，没有验证，开发人员对这个又不是特别了解的情况下就会出现这个问题，这就是为什么要去了解你的依赖以及你依赖的依赖。

去年我们做压测，有个应用一边压测一边在优化做发布，发现第一批发的起不来了，就只是改了一两行代码加日志，他就去看什么原因，最后发现依赖的某个 jar 包依赖一个配置，而这个配置在压测中被降级了，一个 jar 包就把应用启动卡住了。如果在双十一当天或者在平时业务高峰期的时候发现这个问题是来不及修复的。所以这个时候，我们就要求，依赖的二方 jar 包必须看一下里面是怎么实现的，依赖哪些东西。

反过来说，别人依赖我的客户端就意味着他不仅依赖着我的服务还依赖着我的缓存，这个缓存出了问题对他也有影响，我们每年双十一前有一个强弱依赖梳理，不仅要梳理自己应用里面的，还有依赖的所有东西都梳理出来，中间任何一个节点挂掉了你应该怎么办，需要给一个明确答复。

第二个故障案例是今年发生的，AWS S3 敲错了一个命令把基础核心服务下线了，有一个对象索引服务和位置服务系统被 offline，后来也做了一些改进，每次敲的命令有一个静默期，让你有个反悔的机会，线上有个最小的资源保证服务。

这个给我们带来的启示是什么，云服务本身也是会发生故障的，比如买了云数据库，我们没有办法假设它是 100% 可用的，当它出现问题我们怎么办，是给云厂商提工单说什么时候能恢复，还是我自己能够有一个容灾的方案解决这个问题。从 2015 年开始，我们越来越多地发现，对架构可用性最大的威胁是什么？在市政施工里一定几率就会莫名其妙搞出光缆被挖断等故障，我们不得不考虑，当云服务本身出现问题我们该怎么办。

 

应对措施

所以我们需要有一套面向云的高可用架构。在很早以前有厂商提出类似 SDN 的一个概念，叫 SDI——软件定义基础设施，过去我们发现只有大厂可以做这个事情，设计一套很复杂的管理系统帮他实现，这里放一个路由器，这边放一台虚拟机，可以通过软件的控制流去控制这个东西。但是在云的时代，资源变得很容易获得。以阿里云为例子，可以用 API 随时创建新的虚拟机，新的负载均衡，或者是新的存储，都可以通过 API 随时创建随时销毁，这对于你的基础设施的灵活度非常有好处。

以前有的人会觉得，性能问题或者容量问题应该通过性能优化的方式解决，通过一些黑科技方式解决，加机器会觉得很 low。但我觉得一个问题如果能简单用加机器来解决是很不容易的，意味着对你的整个架构的水平扩展性要求非常高，而且解决效率很高，加机器就解决了，而对一些中心化的系统来说就比较麻烦，加机器都加不了，可能要把机器关掉升配置再重新拉起来。所以我们说，在公有云上面，在资源如此容易获得的情况下要充分利用这个特性，要做一个能够做水平扩展的架构。



那么第一步要做什么，前两年很火的容器、微服务，本质上都是解决了是无状态的应用怎么做自动化的扩容这个问题。右边这个图上面，上面是一个负载均衡，中间是一个前端的服务，后端是一个无状态的后端服务，底层是 MQ、对象存储、数据库这些东西，如果我们能够把前端和后端的无状态服务第一步先容器化，就可以做到当流量过来的时候，只要后端的存储没有问题，整套架构就是能够水平扩展的。

从去年公开的报道和故障来看，很多人有个误会是说云厂商的机器应该是不会挂的，我买了一台云厂商的虚拟机应该是随时可用的，即使不可用云厂商也要帮我解决热迁移的问题，热迁移在业界是很复杂的问题，不光涉及到磁盘存储的迁移，也涉及到内存是要做迁移的，可能还要用 RDMA。并且对于传统的 IDC 来说，不管物理机还是虚拟机都是有可能挂的，对云也不例外。

当我们在使用公有云服务的时候，都是会挂的，这是个心理准备。不光是机器，包括负载均衡是不是也有可能挂，下面的消息队列或者数据库是不是也有可能会挂，当你基于任何东西都可能会挂的前提设计一个系统的时候，才能真正做到这个系统在任何情况下都不会受底层云服务的故障影响。



而对于不同的云服务来说是有不同的容灾策略。比如一台虚拟机挂了，通常来说负载均衡不管是 4 层还是 7 层都会做健康检查，挂了健康检查不通自动会把流量切断。如果我的负载均衡挂了怎么办，如果 DNS 有健康检查那就方便了，如果没有的话可能就要设计一个旁路系统解决这个问题，发现这个已经不通了，就自动把它从 DNS 上摘掉。

不管是云服务发生故障还是自己应用发生故障有个大原则是如何最快速解决问题，就是一个字，切。为什么要做异地多活，为什么要把流量往各个地方引，切流量是解决问题最快的，把坏流量切到好的地方马上就解决了，如果你要等定位问题解决问题再上线客户就流失掉了。对淘宝来说也是一样，当某一个单元低于我们认为的可用性的时候，我们会把这个单元的流量引到另外一个可用的单元，当然前提是那个单元的容量是足够的。

弹性是不是万能的？所有的云服务都是弹性的，弹性其实不是万能的，容量规划仍然是有必要的，不然就没必要做双十一备战了。这里有一个你需要付出的代价，弹性的过程往往是需要时间的，那么容量规划在这个环节中起到的作用就很重要，当真的逼不得已的时候，我要扩容了，怎么保证我扩完容之前系统不雪崩？就是要结合之前的限流，尽可能保障每个客户得到他应有的服务，但是也要保障系统的稳定性。

Region 和 Availability Zone 这两个，当实践的时候，购买虚拟机、负载均衡或者数据库，一定要选择多可能区的服务，比如阿里云买 SLB 是可选可用区的，有个主可用区和副可用区，如果一边挂了可以切换到另外一边，RDS 也是一样的。



这幅图是一套典型基于公有云的一套架构，不叫异地多活，应该叫跨区域设计。左右两个大框是两个城市，左边是北京，右边是上海，每个里面又有不同的机房可用区去承担这个流量，假如北京的挂掉了，就切，原来是在 A 可用区，就切到 B 可用区，这时候 A 可用区没有流量进来，通过切换的方式能够把这个服务快速恢复。下面画了一个跨区域复制，我们在异地多活项目里，涉及到了跨城市跨数据中心的复制，比如我的北京是提供写服务的，上海要提供读服务，就要通过这种方式同步数据过去。

 

=>更多文章请参考：《中国互联网业务研发体系架构指南》https://blog.csdn.net/Ture010Love/article/details/104381157

=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：