9.携程架构实践 --- 网站高可用

第9 章 网站高可用 
	网站可用性的提升，要同时从多方面入手，如软件架构设计实现，监控告警，紧急事件的响应，运维管理，容量管理，信息安全，灾备数据中心，故障演练等，这就是一个
"反脆弱"的过程。
	
9．1 可用性指标与度量 
		"没有测量，就没有管理；没有测量，就没有改善"。

		度量网站可用性的指标有很多，如下：
			1.系统指标：以系统或硬件层面的监控数据来测量网站的可用性；
			2.应用指标：如应用访问量，错误数，响应时长；
			3.业务指标：如业务订单数，用户登录数，支付成功率等。

		ATP(Availability To Promise)是基于业务指标来进行度量的标准，也是电商类通常使用的标准。

	9．1．1 Ctrip ATP 
		每增加0.5s的延迟就会导致20%左右的流量损失。

		网站可用性标准：
		Level       每年宕机时间	每季度宕机时间 	每天宕机时间 
		99			3.65天		21.84小时 		14分钟
		99.9		8.76小时 	2.184小时 		86秒
		99.99		52.6分钟		13.1分钟 		8.6秒
		99.999 		5.25分钟 	1.31分钟 		0.86秒
		99.9999 	31.5秒 		0.79秒 			8.6毫秒

	9．1．2 Ctrip ATP 算法 
		CTrip ATP 总共两个部分：全球总可用性标准和各产品线可用性标准。

		如，某网站故障起始时间为 10:19，结束时间为 10:49，共损失 酒店业务订单数为 预测交易数 - 实际交易数，
	则该事件对酒店业务线的ATP影响为 ：(预测交易数 - 实际交易数) / 预测交易数 * 1800s；
	对全球的ATP影响为 : (预测交易数 - 实际交易数) / 预测交易数 * 1800s * P%；

		其中，P% 为公司财报中酒店营收占公司总营收的百分比。

	9．1．3 Ctrip ATP 架构 
		ATP 系统需要从各个业务系统采集分钟订单数据，同时依赖于一个订单预测系统生成订单预测数据。当故障发生后，ATP系统会自动根据监控团队录入的故障开始时间，
	和结束时间，推算出故障对订单的影响时间，并对比实际值和预测值的差异，计算出故障对网站可用性影响的秒数。

	9．1．4 订单预测模型 
		1.日期对齐
		2.特殊节假日判断
		3.预测当日订单总数
		4.计算每分钟季节指数
		5.计算每分钟订单预测量

9．2 服务熔断、限流与降级 
	9．2．1 微服务架构下的可用性 
		雪崩效应是指单个或者少量服务提供方不可用，导致服务调用方的不可用，并且这种不可用逐渐传播与放大，最终导致整个系统可用性下降的现象。

		雪崩效应形成的大致过程如下：
			1.异常情况导致服务变慢，不可用
				a) 流量激增
				b) 外部依赖
				c) 服务自身问题
			2.用户或代码的重试逻辑对异常的放大效应
			3.任何系统都有容量上限

		我们通过以下3种方式提高服务的可用性：
			1.服务熔断
				服务熔断需要调用方持续监控服务调用状态，当目标服务调用反复出现超时或者其他异常时，需要快速中断该服务，即对后续请求直接抛出异常或返回预设结果，
			不占用额外资源(网络，线程等)，在目标服务正常后恢复调用。服务熔断机制设计的重点在于持续的状态监控，触发熔断与恢复服务的判断方法，对相关事件的日志与
			告警。

			2.服务限流
				服务限流通过预设最高调用频次，对高于频次的请求采用直接拒绝或者返回预设结果的方式，使其不占用后续资源。服务限流策略可以预防大流量导致的服务器过载，
			常见的实现方式包括TPS限流，最大并发数限流，常见的算法包括固定时间窗口，滑动时间窗口，令牌筒算法，漏桶算法等。

			3.服务降级
				服务降级是在服务压力过大或部分依赖不可用的情况下，对非关键依赖采取暂停或延迟生效的策略，以保证核心流程与业务正常运行。相比于限流与熔断，降级与业务
			有更强的相关性，常见的降级手段包括：功能降级，例如，在促销中主服务压力过大，或者部分弱依赖发生故障，可按实际情况降级；读写降级，利用多级缓存，消息等方式
			替代与DB的直接交互，由强一致降级为最终一致性，通常用于解决DB性能瓶颈。

	9．2．2 熔断、限流在携程的落地 
		xc的熔断和限流主要由两个组件组成：即 API Gateway 与 服务框架SOA。

		API Gateway 作为统一的外部流量入口，适合处理公共业务，其核心功能包括熔断与限流等。熔断与限流功能都依赖于 路由治理与资源隔离：将每条请求归类为不同的Route，
	对每类Route使用资源进行隔离，使其互不影响，并支持对各个Route区别的配置。限流又包括两个方面：一部分是对整体并发流量的限制，即对每台服务器提供的并发量预设一个上
	限，超出上限直接拒绝，这避免了大流量或者其他异常情况对网关的冲击，以牺牲一部分请求为代价换来了整体的稳定；另一部分是对每一个Route并发量限制。注意上述说的都是
	并发量，对应的QPS会根据服务响应时间变化而变化。

		另一方面，由于服务化进程的推进，xc目前绝大部分流量都是通过服务框架SOA实现进出的。熔断，限流作为微服务治理中的重要环节，SOA自然也收口了这两项功能，包括两类
	角色：一是客户端，支持熔断；二是服务端，支持熔断与限流。

		电路保护器，包含三大模块：
			1.采集模块
			2.计算模块
			3.电路保护模块

	9．2．3 熔断、限流的治理问题 
		1.配置与灵活性
		2.日志，监控与告警
		3.扩展性

9．3 灾备数据中心 
		在确定DR建设模式前，企业需要评估业务连续性SLA，即当故障发生后最多可以承受多少数据量的丢失，承受多长时间的服务中断，以及企业愿意投入多少成本。这里有2个重要
	指标：RTO(Recovery Time Objective，恢复时间目标)是指网站容许服务中断的时间长度；RPO(Recovery Time Objective)是指服务恢复后，恢复得来的数据所对应的
	时间点。RTO和RPO均以时间为单位：RTO度量的是应用程序失败和包括数据恢复在内的完整可用性之间的时间间隔；RPO度量的是数据丢失和前一次备份之间的时间间隔。

		站点灾备的方案可以分为以下3种：
			1.冷备模式
			2.热备模式
			3.多活模式

	9．3．1 冷备模式 
	9．3．2 热备模式 
	9．3．3 多活模式 

9．4 网站单元化部署 
	若要解决跨数据中心的应用调用及数据读写问题引入的延迟问题，就需要把这些请求封装在一个数据中心内，减少甚至消除数据中心的调用和数据写操作。同时应用层要做到不进行
跨数据中心的调用；数据层要做到不出现不同单元对同一行数据进行修改的情况，要做到单元内数据的读写封闭。实现单元内高内聚，单元间松耦合。

	9．4．1 单元化架构 
		单元化是解决跨区域多活的一种主要思路，也需要考虑成本问题。

		单元化闭环，以用户请求数据流为例，即根据 DNS/GSLB，API Route 中定义的规则把用户的请求路由到数据中心，由那个单元提供服务，将该请求的后续服务请求和数据
	读写操作路由到本单元的服务提供者和数据存储，如果出现路由错误或者非法请求，就通过 UCS(Unit Control Service)进行控制，并通过 DRC(Data Replication Center)服务将数据同步到其他备用单元。

	9．4．2 单元化思路 
		多活的架构与业务特点密切相关，首先需要梳理业务的核心路径，确定路径上的关键数据有哪些，并结合用户体验和改造成本选择合适的维度进行数据切分，做到单元内数据的
	读写封闭，如打车业务，用户数据和车辆具有很好的局部性，这些数据的共性是地理位置，很适合单元化；外卖业务，买家，卖家和骑手都处于同一区域。

		在确定数据分割维度后，全局一致性路由控制要解决用户的访问请求及相关的服务调用都封闭在一个单元内，而单元化需要确保这个用户所产生的访问链路的路由规则都一致，
	封闭在上海数据中心内，这就需要机遇主数据维度设计 sharding key。根据sharding key和机房单元的映射规则，将请求路由到封闭单元的服务提供者。在某些情况下，路由
	会发生错误，产生跨数据中心或数据写操作，造成数据冲突或者写错误，因此组件层面需要有兜底机制，拒绝和报告这种错误。

		异地多活还需要解决数据同步的问题。

9．5 基础组件支持 
	9．5．1 路由调度 
		如何保证路由调度的高可用呢？
			首先，我们将应用集合根据产品线，服务划分成不同的逻辑服务单元，如订单单元，支付单元等。服务单元可以完全独立部署，其内部包含提供服务所必须的应用。路由
		调度从应用路由抽象为服务单元的路由，而服务单元的路由规则由API Route实现的。API Route 会根据请求中包含的标识信息，决定将请求转发到哪个服务单元，请求
		标识可以是用户的ID，地域，产品线类型等。用户的真实请求和跨服务单元的访问请求都会被转发至API Route，并由API Route选择转发至哪个服务单元，目标服务单元
		可以处于不同的数据中心。

			然后，我们打开网站，App或小程序，发起一组网络请求，请求会通过dns解析到就近的API Route节点；API Route会根据请求中包含的标识信息，选择目标服务单元，
		将请求转发至该服务单元的入口地址；服务单元可以进行异地灾备部署，只要在API Route进行调整即可实现流量切换，A/BTesting，容灾恢复等。服务单元唯一的入口地址
		一般指向每一个数据中心最外层的SLB或者TCP Gateway(TCP网关服务)，它们分别处理http/https协议的路由转发和tcp/sotp协议(自定义私有协议)的路由转发。slb
		维护了Host和URI域应用的路由关系表，可以根据Host和URI匹配目标应用，并将流量转发到应用的服务器组。tcp gateway则维护了一份 Service Code和目标URL的路由
		关系表，负责从tcp/sotp协议的请求头中获取Service Code信息，并根据Service Code路由关系表将请求转发到对应的URL，即请求被转发至SLB，由SLB负责将请求路由
		到目标应用。

			在数据中心内网环境中，应用间的调用方式主要有两种：通过slb调用和通过rpc框架调用。通过slb调用时，应用发起http/https请求，请求的目标域名dns会指向slb，
		再由slb根据Host和URI匹配对应的目标应用。而在通过rpc框架调用时，rpc框架治理中心会将目标应用的服务器组下发到应用进程中的rpc客户端，由rpc客户端直接发起请求
		到目标应用服务器组。

	9．5．2 数据复制 
		系统一般分为有状态和无状态服务。为解决高可用问题，无状态服务只需要进行水平扩容即可，有状态服务则比较复杂。有状态服务必须做好数据复制，保证一个节点宕机后，冗余
	节点可以提供数据服务。但数据复制会带来一致性问题。

		1.非多活模式下的数据复制
			经典的数据复制一般是 master-slave模式，用户的写请求在master上执行，并在执行后由master将执行的命令传播给slave。数据同步一般分为全量同步和增量同步。

			a) MySQL数据复制
				异步复制，即写操作在master节点完成后立即返回，无需等待slave节点确认；为了减少异步复制可能造成数据丢失的情况，对数据可靠性要求比较高的数据库需要
			开启半同步复制。同步复制要求B节点将数据提交后返回，半同步复制要求B节点将数据写入本地日志后返回，可以解决同步复制的延迟问题，同时尽量保证A,B节点的数据
			一致性。

			b) Redis数据复制

		2.多活模式下的数据复制
			master-slave复制可以解决高可用，读扩展的问题。与之对应的模式是 Multi Master Replication，此模式支持在多个Master同时写入。一般有两种类型：
				a)类型一，在每次写入时使用一致性协议(如Paxos)和集群内其他master进行通信，保证各master数据的最终一致性。
				b)类型二，只写入当期master，然后通过数据复制将数据扩散到其他节点。

			第一种性能比较差，第二种面临如何保证数据一致性问题。

			并发写带来了数据冲突，所谓数据冲突，即多个master对同一份数据进行了并发的写操作，解决方案如下：
				a) 是保证多个master写入的是不同的数据 
				b) 写入的是相同的数据，在遇到冲突时进行冲突的解决

			xc DRC 系统：
				数据冲突的解决方案是不同的 master 写入不同的数据：
				1.DRC解决的问题
					a)mysql已读机房高可用
					b)数据一致性
					c)分区容错性
					d)业务访问低延时

				2.系统核心指标
					a) 实时双向复制
					b) 数据高一致性
					c) 高可用

				3.关键问题处理
					双向复制要解决的另外一个重要问题是循环复制，可以识别一个更改动作是来自业务，还是来自DRC工具本身。来自业务的需要变更，而来自DRC的数据变更
				不需要复制。采用的是GTID，采用mysql的uuid来标记数据来源。

				4.数据并发写冲突识别，处理
					db每张表必须加 updatetime字段。

9．6 全链路压测 
	全链路压测 是指对业务真实的调用链路进行整体性压测，用于评估真实的负载水平，由于其重在着眼于整体，能够评估局部节点的负载变化对整体调用链路的影响，因此称为容量
评估技术中的"新型武器"。

	9．6．1 技术选型与系统设计 
		目前业界主流的压测流量构造方式可以大致分为 流量回放与流量构造。
		
		流量回放指对应用集群的真实流量进行拷贝，制作成离线副本文件，并以N倍进行回放。这种使用真实的业务流量，解决了海量用户输入数据的问题。
	但是当生产链路趋于复杂的时候，使用流量回放模拟整个调用链路会变得异常困难，特别是某些"秒杀"业务特征比较明显，平时整个集群的流量非常小，拷贝的流量副本也比较小，
	即使可以实现百倍扩展，也难以匹配高负载的压力输入。

		流量构造是指人工编写的压测场景，依托于专业的压测工具(如Jmeter,LoadRunner等)发起远高于真实流量的负载。需要注意的是，基于人工构造的压测场景的方式难以
	模拟海量用户输入数据的组合场景，需要在压测数据的构造上下功夫。

		压测环境可以细分为 隔离环境与生产环境。隔离环境使用独立的环境进行压测，可以确保测试数据及测试流量不对生产的真实业务产生影响。但隔离环境往往使用的是老旧设备，
	无法模拟生产机器的性能表现，并且隔离环境上下游依赖的数据往往会缺失，从而导致测试结果与真实场景出现较大的偏差。而生产环境使用真实的线上环境进行压测，拥有丰富的
	数据场景，压测结果可以反映出真实的业务性能表现，具有比较可信的参考价值。

		cx 最终选择了生产环境作为全链路压测的运行环境，并使用人工构造的方式进行核心调用链路的模拟，同时结合流量回放解决海量用户输入数据的构造问题。

	9．6．2 构造与隔离压测数据 
		在数据隔离方面，部分产品采用"影子库"方案设计，通过将压测数据在中间件层面进行识别并转发到生产隔离数据库，可以保证压测数据不会污染生产数据库。

		但是，真实的业务场景需要精准感知数据库负载压力的变化，"影子库"方案并不适合xc。最终采用了基于构造的压测数据读写真实数据，并在压测后基于构造数据的特征清理
	脏数据的真实方案。

	9．6．3 全链路监控设计 
		1.链路维度
		2.熔断控制

9．7 运维工具高可用 
	9．7．1 哪些运维工具需要实现高可用 
		确定哪些运维工具需要实现高可用的原则是按照工具的功能区分是否属于核心运维工具，与网站故障恢复相关的工具才是核心的运维工具。
		1.首先，负责故障恢复的工具必须时刻保持服务可用，运维工具的首要职责是保障业务的连续性和可用性。
		2.其次，是监控工具需要保持高可用
		3.最后，资源交付工具，代码发布工具需要保持高可用

	9．7．2 工具的改造 
		1.保底方案
		2.减少依赖，取出循环依赖
		3.功能切换和降级
		4.准备快速恢复脚本
		5.完全Set化
		6.完善工具监控
		7.准备操作手册

	9．7．3 定期故障演练 

9．8 混沌工程 
	9．8．1 混沌工程的起源 
		"通过不断的失败来避免失败"。Netflix 开发了 Chaos Monkey，使用这种主动制造故障的方法来宏观的验证业务的容灾性和恢复能力。 

	9．8．2 混沌工程的5 条原则 
		1.第一条原则：假设稳定的状态
			混沌工程是将预想的事情与实际发生的事情进行对比和参照，所以第一条原则的根本思想是需要具有可测量的，显性的指标来表明系统正常运行时的状态，以及故障注入后
		系统发生的变化。为了更准确的表明分布式系统的运行状态，与采用cpu利用率，请求响应时间等系统级监控指标相比，更推荐采用业务指标，如酒店的每分钟订单量等。这些指标
		都需要尽可能的实时采集，才能及时发现混沌实验前后系统的变化。

		2.第二条原则：在生产环境中进行混沌实验
			在通常情况下，系统的功能测试，性能测试甚至破坏性测试在测试环境中进行。但混沌工程的原则恰恰与此相反。由于线下测试环境的流量行为，场景覆盖率，数据规模与
		生产环境有显著差异，在测试环境中进行混沌工程的结果的有效性，真实性并不能表明生产环境中具有同样的效果。而混沌工程的目的是建立对生产环境系统可用性的信心，所以
		混沌实验应当在生产环境中进行。

		3.第三条原则：持续的，自动的运行实验
			生产环境每周都有数千次的代码发布和运维变更，同时每次的发布，变更都会引入新的风险点，所以定期进行大规模故障演练的有效性会随着时间衰减。并且，人力成本大，
		往往很难长期坚持。如果想混沌工程变得像代码发布一样常态化和高频率，就需要更简单的自动化的混沌实验工具和平台来替代人工操作，如自动注入故障，自动收集指标并
		检测异常，发现异常后自动恢复，从而降低实时混沌工程的复杂度和门槛。

		4.第四条原则：最小化爆炸半径
			混沌工程并不代表要产生实际的混乱。混沌工程的目的是探寻故障会造成的未知的，不可预见的影响，让系统的薄弱环节能显现出来而又不会产生不可接受的影响，这就是
		"最小化爆炸半径"。

			在实施混沌实验之前必须深入的评估风险范围，然后在可控的范围内采用循序渐进的方式展开实验。所以，在进行混沌试验时并不是"一步到位"的把整个机房宕机，而是
		需要通过小规模的，小范围的实验来一点点建立信心。另外，一旦实验的影响即将超出可控范围，就应当及时停止实验。

		5.第五条原则：多样化的故障场景
			在混沌工程中，需要尽可能多的模拟真实环境下的各种故障事件，以覆盖各种困难的故障场景。

		混沌工程落地的2个关键因素：
			1.混沌意识的接受度
			2.混沌实验平台的成熟度

	9．8．3 如何进行一个混沌实验 
		混沌实验可以帮助我们识别未被发现的强依赖，以及没有被正确降级的弱依赖。

		1.定义稳态
		2.创建假设
		3.注入故障
		4.观察对照
		5.完善改进


9．9 数据驱动运营 
	在网站持续运营过程中积累的数据是一笔宝贵的财富，这些数据包括 网站的流量数据，产品数据，用户数据，订单数据，服务数据及监控数据等，这些数据可以对网站的运营情况
进行分析和挖掘，如网站的用户分布，活跃用户的订单贡献，产品推广效果，未来的流量增长变化，业务高峰的资源投入等。

	9．9．1 智能运维AIOps 
		AIOps即智能化运维，它基于积累的运维数据(日志数据，监控数据，应用数据等)，通过机器学习的方式来进一步解决自动化运维所无法解决的问题，以此来提升系统的预判
	能力，稳定性，以及降低网站成本。

	9．9．2 AI 算法在运维领域的典型场景 
		AIOps 主要围绕质量，成本和效率等方面展开实践，目前比较成熟的应用场景包括 异常监测，故障诊断，故障预警，故障自愈，容量预测，容量规划，资源优化，性能优化，
	智能问答，智能预测等。

	9．9．3 运维数据仓库 
		数据仓库(DW)是一个面向主题的，集成的，相对稳定的，反映历史变化的数据集合。

		从模型层面来说，OPSDW可以分为3层：
			1.ODS层：操作数据层，保存最原始的数据
			2.DWD层：数据仓库明细数据，根据主题定义好事实及维度表，保存最细粒度的事实数据
			3.DM层：数据集市/汇总层，在DWD层的基础上，根据不同的业务需求进行汇总

9．10 GNOC 
	NOC 是 Network Operation Center 的缩写，通常在网站可用性保障工作中扮演者重要的角色。

	1.告警产生阶段
	2.故障处理阶段
	3.故障事件定级
	4.故障事件RCA回顾