高可用

一、前言高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在零碎架构设计中必须思考的因素之一。明天咱们就来聊一聊三H中的高可用，也是咱们常说的零碎稳定性。 \> 本篇文章只聊思路，没有太多的深刻细节。浏览全文大略须要5~10分钟。 二、高可用的定义业界罕用 N 个 9 来量化一个零碎可用性水平，能够间接映射到网站失常运行工夫的百分比上。 可用性的计算公式： 大部分公司的要求是4个9，也就是年度宕机时长不能超过53分钟，理论要达到这个指标还是十分艰难的，须要各个子模块相互配合。 要想晋升一个零碎的可用性，首先须要晓得影响零碎稳定性的因素有哪些。 三、影响稳定性的因素首先咱们先梳理一下影响零碎稳定性的一些常见的问题场景，大抵可分为三类： 人为因素 不合理的变更、内部攻打等等软件因素 代码bug、设计破绽、GC问题、线程池异样、上下游异样硬件因素 网络故障、机器故障等上面就是隔靴搔痒，首先是故障前的预防，其次是故障后的疾速恢复能力，上面咱们就聊聊几种常见的解决思路。 四、晋升稳定性的几种思路4.1 零碎拆分拆分不是以缩小不可用工夫为目标，而是以缩小故障影响面为目标。因为一个大的零碎拆分成了几个小的独立模块，一个模块出了问题不会影响到其余的模块，从而升高故障的影响面。零碎拆分又包含接入层拆分、服务拆分、数据库拆分。 接入层&服务层 个别是依照业务模块、重要水平、变更频次等维度拆分。数据层 个别先依照业务拆分后，如果有须要还能够做垂直拆分也就是数据分片、读写拆散、数据冷热拆散等。::: hljs-center 4.2 解耦::: 零碎进行拆分之后，会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的，那么如果依赖方出问题了，也会受到牵连出问题。这时能够梳理整个流程的调用关系，做成弱依赖调用。弱依赖调用能够用MQ的形式来实现解耦。即便上游呈现问题，也不会影响以后模块。 4.3 技术选型能够在适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面进行全量评估，挑选出适宜以后业务场景的中间件&数据库。后期的调研肯定要充沛，先比照、测试、钻研，再决定，磨刀不误砍柴工。 4.4 冗余部署&故障主动转移服务层的冗余部署很好了解，一个服务部署多个节点，有了冗余之后还不够，每次呈现故障须要人工染指复原势必会减少零碎的不可服务工夫。所以，又往往是通过“主动故障转移”来实现零碎的高可用。即某个节点宕机后须要能主动摘除上游流量，这些能力基本上都能够通过负载平衡的探活机制来实现。 波及到数据层就比较复杂了，然而个别都有成熟的计划能够做参考。个别分为一主一从、一主多从、多主多从。不过大抵的原理都是数据同步实现多从，数据分片实现多主，故障转移时都是通过选举算法选出新的主节点后在对外提供服务（这里如果写入的时候不做强统一同步，故障转移时会失落一部分数据）。具体能够参考Redis Cluster、ZK、Kafka等集群架构。 4.5 容量评估在零碎上线前须要对整个服务用到的机器、DB、cache都要做容量评估，机器容量的容量能够采纳以下形式评估： 明确预期流量指标-QPS；明确可承受的时延和平安水位指标（比方CPU%≤40%，外围链路RT≤50ms）；通过压测评估单机在平安水位以下能反对的最高QPS（倡议通过混合场景来验证，比方依照预估流量配比同时压测多个外围接口）；最初就能够估算出具体的机器数量了。DB和cache评估除了QPS之外还须要评估数据量，办法大致相同，等到零碎上线后就能够依据监控指标做扩缩容了。 4.6 服务疾速扩容能力&泄洪能力现阶段不论是容器还是ECS，单纯的节点复制扩容是很容易的，扩容的重点须要评估的是服务自身是不是无状态的，比方： 上游DB的连贯数最多反对以后服务扩容几台？扩容后缓存是否须要预热？放量策略这些因素都是须要提前做好筹备，整顿出齐备的SOP文档，当然最好的形式是进行演练，实际上手操作，有恃无恐。 泄洪能力个别是指冗余部署的状况下，抉择几个节点作为备用节点，平时承当很小一部分流量，当流量洪峰来长期，通过调整流量路由策略把热节点的一部分流量转移到备用节点上。 比照扩容计划这种老本绝对较高，然而益处就是响应快，危险小。 4.7 流量整形&熔断降级 流量整形也就是常说的限流，次要是避免超过预期外的流量把服务打垮，熔断则是为了本身组件或者依赖上游故障时，能够疾速失败避免长期阻塞导致雪崩。对于限流熔断的能力，开源组件Sentinel基本上都具备了，用起来也很简略不便，然而有一些点须要留神。 限流阈值个别是配置为服务的某个资源能撑持的最高水位，这个须要通过压测摸底来评估。随着零碎的迭代，这个值可能是须要继续调整的。如果配置的过高，会导致系统解体时还没触发爱护，配置的过低会导致误伤。熔断降级-某个接口或者某个资源熔断后，要依据业务场景跟熔断资源的重要水平来评估应该抛出异样还是返回一个兜底后果。比方下单场景如果扣减库存接口产生熔断，因为扣减库存在下单接口是必要条件，所以熔断后只能抛出异样让整个链路失败回滚，如果是获取商品评论相干的接口产生熔断，那么能够抉择返回一个空，不影响整个链路。4.8资源隔离如果一个服务的多个上游同时呈现阻塞，单个上游接口始终达不到熔断规范（比方异样比例跟慢申请比例没达到阈值），那么将会导致整个服务的吞吐量降落和更多的线程数占用，极其状况下甚至导致线程池耗尽。引入资源隔离后，能够限度单个上游接口可应用的最大线程资源，确保在未熔断前尽可能小的影响整个服务的吞吐量。 说到隔离机制，这里能够扩大说一下，因为每个接口的流量跟RT都不一样，很难去设置一个比拟正当的可用最大线程数，并且随着业务迭代，这个阈值也难以保护。这里能够采纳共享加独占来解决这个问题，每个接口有本人的独占线程资源，当独占资源占满后，应用共享资源，共享池在达到肯定水位后，强制应用独占资源，排队期待。这种机制长处比拟显著就是能够在资源利用最大化的同时保障隔离性。 这里的线程数只是资源的一种，资源也能够是连接数、内存等等。 4.9系统性爱护 系统性爱护是一种无差别限流，一句话概念就是在零碎快要解体之前对所有流量入口进行无差别限流，当零碎复原到衰弱水位后进行限流。具体一点就是联合利用的 Load、总体均匀 RT、入口 QPS 和线程数等几个维度的监控指标，让零碎的入口流量和零碎的负载达到一个均衡，让零碎尽可能跑在最大吞吐量的同时保证系统整体的稳定性。 4.10 可观测性&告警 当零碎呈现故障时，咱们首先需找到故障的起因，而后才是解决问题，最初让零碎复原。排障的速度很大水平上决定了整个故障复原的时长，而可观测性的最大价值在于疾速排障。其次基于Metrics、Traces、Logs三大支柱配置告警规定，能够提前发现零碎可能存在的危险&问题，防止故障的产生。 4.11 变更流程三板斧变更是可用性最大的敌人，99%的故障都是来自于变更，可能是配置变更，代码变更，机器变更等等。那么如何缩小变更带来的故障呢？ 可灰度 用小比例的一部分流量来验证变更后的内容，减小影响用户群。可回滚 呈现问题后，能有无效的回滚机制。波及到数据批改的，公布后会引起脏数据的写入，须要有牢靠的回滚流程，保障脏数据的革除。可观测 通过观察变更前后的指标变动，很大水平上能够提前发现问题。除了以上三板斧外，还应该在其余开发流程上做标准，比方代码管制，集成编译、自动化测试、动态代码扫描等。 五、总结对于一个动静演进的零碎而言，咱们没有方法将故障产生的概率降为0，能做的只有尽可能的预防和缩短故障时的复原工夫。当然咱们也不必一味的谋求可用性，毕竟晋升稳定性的同时，保护老本、机器老本等也会跟着上涨，所以须要联合零碎的业务SLO要求，适宜的才是最好的。 如何做好稳定性和高可用保障是一个很宏大的命题，本篇文章没有太多的深刻细节，只聊了整体的一些思路，次要是为了大家在当前的零碎高可用建设过程中，有一套零碎的框架能够参考。最初感激急躁看完的同学。 文/新一 线下流动举荐： 工夫： 2023年6月10日（周六） 14:00-18:00主题： 得物技术沙龙总第18期-无线技术第4期地点： 杭州·西湖区学院路77号得物杭州研发核心12楼培训教室（地铁10号线&19号线文三路站G口出） ...

前言咱们常常会说互联网“三高”，那什么是三高呢？咱们常说的三高，高并发、高可用、高性能，这些技术是构建古代互联网应用程序所必须的。对于京东618备战来说，所有的中台零碎服务，无疑都是围绕着三高来开展的。对于一个程序员，或多或少都能说出一些跟三高零碎无关的技术点，而我本篇文章的目标，就是帮大家零碎的梳理一下三高零碎中的第一高：高可用性。 首先来说，互联网的业务特点决定了他必须保障“三高”， 同时，高并发，高可用，高性能，这三高之间并不是孤立的，而是强相干。一个高可用的零碎，肯定也须要应答高并发场景对系统带来的冲击，保证系统在高流量拜访状况下，零碎的服务的失常运行。同时，一个可能撑持高并发的零碎也肯定要满足高性能，否则也无奈实现高流量的承载。 回到咱们本文的宗旨，咱们这里所说的高可用性是指，零碎在遇到任何艰难的状况下仍能失常运行的能力。 在京东618备战期间，零碎的高可用对咱们来说至关重要，因为零碎的解体，不止带来间接经济上的损失，还会导致用户信赖的失落。接下来我通过一张思维导图开展我的分享，帮大家梳理一下一个高可用零碎所须要思考的技术点。 开发时1. 首先技术架构计划选型很重要,切记防止适度设计。比方咱们常说的单体利用架构和微服务架构，两种架构单纯来比照，单体利用架构的可用率要比微服务架构高的。因为多服务之间的依赖肯定会升高零碎的可用率，比方一个依赖10个微服务的对外接口，假如每个服务的可用率是99%，那么这个接口对外提供服务的整体可用率就间接降到了90.4%，这两头还要思考到服务之间的网络提早，数据一致性的问题。 还有例子就是中间件抉择，比方一个缓存业务场景，我能够用内存缓存，也能够应用redis分布式缓存，那么应用哪个呢？应用内存缓存零碎可用率会高，因为如果引来redis，零碎的可用率又得乘以一个redis的可用率。当然如果咱们的业务场景必须应用redis，那么也是齐全能够的，但这里切记零碎的适度设计，也是设计简单的零碎，也须要更多的高可用相干的保障，所付出的资源代价和运维代价也是几何增长。 2. 其次就是代码品质。其实这个可能是很多人疏忽的一点，因为很多人更喜爱高谈阔论分布式，集群，压测，故障演练等等，但在我看来，一个代码开发品质的好坏，或者说一个程序员对代码的掌控力，对系统可用性起到至关重要的作用。以下举几个代码维度的例子。 第一个就是异样解决。一个代码品质的好坏，要看他对异样解决能力，一个本科生的课程设计代码，可能都是主业务逻辑，一条路写到黑，不思考任何异常情况，而一个毕业几年的程序员，经验过线上业务的拷打，可能会用在代码里找到很多的try-catch，用于捕获各种不确定逻辑，而一个资深程序员，反而他的代码里你看不到任何try-catch, 因为他全副用AOP的形式实现了异样的捕获。这就是代码维度的考量，一个优良的代码，肯定是进攻式编程，同时还会配合单元测试等。 第二个讲述一个什么是对代码的掌控力。在大厂里，你更多场景是接手他人的老代码。想必所有程序员都深有体会，接手他人的老代码是一件极其苦楚的经验，尤其是他人写了一半的代码。老话前人种树后人乘凉，但在程序员圈，前人种树，前人只能凉凉了..... 调侃归调侃，但有些事件须要面对，后期你须要对业务场景和代码逻辑进行抽丝剥茧的梳理，这个很重要。如果你无奈对老代码进行充沛相熟，那么你就不敢去改写和重构它，如果在不相熟的前提下贸然批改代码或者配置，而后上线，那么很大几率会带来线上零碎问题，影响零碎可用率。换一个角度来说，咱们写的代码将来也可能交接给他人，如何不让他人苦楚，也是咱们的责任。所以正当应用设计模式，遵循代码标准，书写代码架构和设计文档，这些也是很重要的一点，他的重要可能会关乎零碎将来的可用率。 对于代码开发这块，京东技术平台也积淀了一些本人的教训。外部有本人的java代码开发标准阐明文档，也在京英学习平台上能够进行考试。而京东的coding平台，能够在你代码提交时，配置代码开发标准扫描和代码安全性扫描，同时，能够配置代码评审人，这些都能够用来晋升咱们代码品质。 部署时1. 冗余性和备份在部署维度，咱们首先思考的是冗余性和备份设计，这个可能是大家曾经很相熟的状况了，咱们能够通过集群的形式，多个服务器、磁盘或者网络接口来缩小故障点的数量。说到集群，依据实现形式和目标不同，我帮大家梳理一下集中集群类型： （1）高可用集群。 有多个独立服务器组成的零碎，旨在进步零碎可用性，当主节点呈现故障时，通过失败转移（Failover）让备用节点主动接管服务。这个咱们常见的有zookeeper集群，etcd集群等等，这类集群是基于共识算法实现的， 通过选举的形式，来保障当主节点故障时，能够有主动备份节点主动接管。 （2）负载平衡集群。 在负载平衡零碎中，流量被扩散到多个服务器中，每个服务器都独立地解决申请。当一个服务器负载过高或呈现故障时，申请会主动被转移到其余可用的服务器上，从而保证系统的可用性和性能。负载平衡能够在多个层面上实现，包含应用层、传输层和网络层。在应用层负载平衡中，负载均衡器通常通过HTTP代理来散发申请，并依据申请的特定属性（例如URL或Cookie）进行路由。在传输层负载平衡中，负载均衡器通常在传输层（例如TCP或UDP）上运行，并依据端口号或其余特定协定进行路由。在网络层负载平衡中，负载均衡器通常是一个独立的网络设备，用于在不同的服务器之间散发网络流量。 （3）数据库集群。 这里的数据库能够了解为狭义数据库，就是数据的存储媒介。对于数据库的的集群实现形式，分为如下几个：主从复制，复制集，分区。 对于这几种实现计划，这里能够elasticsearch举例说明。ES有分片和正本的概念，所谓的分片，就是将数据程度划分到多个节点，每个节点存储局部数据，当查问数据时，须要在多个节点上进行查问，最初将后果合并。分区能够实现数据的高可用性和可扩展性，但须要思考数据一致性问题。 同时ES的每个分片都能够配置多个正本，正本跟主从复制相似，或者说更像一个集群内的高可用子集，容许多个正本实例同时存在，并反对主动故障转移和成员选举，保障了数据的高可用性和负载平衡。 此外，对于集群计划来说，还要额定思考多机房部署问题，异地多活。换句话说，我所有服务实例，不能放在一个篮子里，因为网络的抖动和不稳定性，对系统可用性来说是很大的威逼。 2. 公布检测在部署维度，第二个关键点是公布检测。有统计数据表明，咱们大部分的稳定性问题来源于零碎变更，也就是零碎的公布上线。那么如何保障一个安稳的零碎上线呢？ 首先，要欠缺自动化测试和单元测试，每次发版前，必回归测试，当然这块如果交给人工来做，费时费力，不肯定能起到他的成果，所有说，欠缺的自动化测试流程，对于零碎稳定性部署来说，至关重要。 其次就是做好公布的自动化，在发版过程中，缩小人为参加，这样也就缩小了出错的可能性。京东的行云部署自身就反对部署编排，利用部署编排，能够稳固且高效的实线滚动发版。同时也能够在行云上的流水线中配置CI/CD流程，实现持续集成和继续部署的串联。 最初就是要实现发版的可观测，可灰度，可回滚。发版前要有checklist，发版时采纳灰度公布验证的形式，能够升高因为发版引起的线上故障。最初如果发版发现失败，能够实现疾速的回滚操作。这个就要在发版前的checkList里，做好回滚流程的备案。 运维时在运维时，咱们的指标是可能疾速止损线上问题，做到问题早发现，快定位，速解决。 1. 零碎全链路观测和监控在互联网零碎中，从用户申请开始，通过所有的零碎组件或服务，直到响应返回给用户，对整个零碎的性能、稳定性和可用性进行全面观测和监控的过程。这包含了对硬件、网络、存储、软件等方面的观测，监控。 在京东618备战期间，所有利用零碎都必须实现自建，欠缺UMP监控埋点，对外围接口办法的可用率，TP99，调用量进行实时监控，同时，也对须要对云主机，中间件等资源维度，包含CPU，内存，资源占有率进行实时监控。 此外，针对监控，要做好日志监控做好采集工作，因为日志记录了零碎中各个组件或服务的运行状态，能够提供丰盛的信息用于问题排查和剖析。 在京东外部采纳logbook进行日志采集，对于外围业务须要审计留存的，能够独自搭建ELK，将历史日志存入ES中。 2. 值班与报警。针对618备战期间，须要额定安顿固定人员进行每日值班，做到对线上问题能够及时反馈。 针对报警机制，有一点须要切记，要把握好报警的阈值问题，如果阈值偏低，会导致研发人员频繁收到报警，导致警惕性升高。而如果阈值偏高，会错过一些线上问题，导致问题没有及时发现，以致故障扩大化。 3. 故障演练及应急机制。京东外部有两大利器，一个是ForceBot，一个是Chaos Monkey。 前者是做全链路军演压测用的，个别618大促前要进行三次军演压测，通过这些军演，让各个利用零碎发现零碎中的薄弱点，并针对性解决。forcebot是通过部署在全国各地的CDN节点，模仿实在用户发动的大规模拜访流量，这种靠近实战的压测，能够让咱们做到防患于未然，同时，通过压测，能够针对性的优化服务资源，可能更针对性的进行扩容。 第二个咱们有时候会叫猴子捣鬼测试，也会叫混沌测试。它可能通过模仿包含网络，中间件，流量等在内的各种故障，通过故障的随机注入，来演练咱们对系统故障的反馈能力。 这里就该提到所谓的应急机制。该机制就像一本相似医院给发的急救指南手册，须要在日常做到对各种不确定的故障进行反馈能力。比方遇到突发高流量，零碎呈现了熔断，如何疾速扩容云主机和各类中间件资源；比方网络忽然产生提早，接口申请超时状况下，如何做好降级计划等等。 总结本文写于京东618备战开门红前夜值班之时。 以上的所有对于零碎高可用的总结，都源于一次次的前人的实际经验总结进去的。每次备策略细节有不同，但大的方向准则是不变的。 祝：京东618 大麦。 作者：京东物流 赵勇萍 起源：京东云开发者社区

作者：京东批发 刘慧卿 一 前言关于软件的高可用，是一个陈词滥调的话题。“高可用性”（High Availability）通常来形容一个零碎通过专门的设计，从而缩小复工工夫，而放弃其服务的高度可用性。其计算公式是：可用率=（总工夫-不可用工夫）/总工夫。 本文重点从落地实际的视角作为切入点，率领大家从合作效率，技术落地和经营标准几个方面来展示高可用的施行步骤和落地细节。为了不便了解，先来对立语言话术，看一下软件交付过程中的各个阶段，如下图： 为什么说软件的高可用会面临着诸多挑战呢？ ◦ 从需要交付链路来看，要实现指标交付，须要产品，研发，测试，运维，经营等多方利益相关者的密切配合。有些我的项目需要，合作者有时可能达到上百人，每个人职责分工各不相同，但却相互配合依赖，任何一个环节呈现纰漏，可用率就有可能受到影响； ◦ 从工夫角度来看，如果要达到全年99.99%的可用率，就意味着一年当中，容许有故障的工夫为：365*24*60*（100%-99.99%）=52分钟，如果要达到5个9的可用率，容许故障的工夫仅为5分钟，这差不多是咱们发现问题后，重启利用的耗时； ◦ 从迭代效率来看，不迭代，不上线，问题呈现的概率肯定会小很多。软件的迭代效率和可用率之间存在着负相关的关系，均衡好两者之间的关系，也会面临着不小的挑战。 总结一下，咱们具体面临的问题如下： ◦ 如何解决需要交付相干协作者多，链路长的问题？ ◦ 如何应答故障工夫容忍度低的问题？ ◦ 如何在频繁需要迭代的现状下，放弃可用率不受到大的冲击问题？ 二 合作效率保障认知误区从整个需要交付链路咱们能够发现，随着链路的逐级递增，信息的传递链路分支就会越多，传递层级就会越深。这会导致两个问题： 信息传递效率升高；信息准确性变差。这两个问题最终导致的后果，就是合作效率的升高。 一个没有实战经验的同学往往会认为减少人数，就会进步需要交付效率。其实这种想法不完全正确，具体关系参考下图： 这就像盖楼房，如果一个人循序渐进的建设，须要100天实现。如果请了100集体来帮忙，是否用1天的工夫实现房子建设呢？答案是否定的。 这外面有合作的老本，比方：团队默契（设计师，瓦工，泥工，水电工），岗位匹配，危险管制； 这外面有流程的依赖，比方：施工依赖于设计，软装总在硬装之后； 这外面有老本估算，比方：整个组织的人才梯度，规模大小（承建方，代理商，承包商）； 以上这些，都不是简略的通过人力铺设来解决的。 流程标准进步合作效率的底层逻辑是通过缩小交付链路层级，缩短信息传递链路，进而保障信息的准确性和传递效率。（组织建设层面的内容这里不做开展） 这就要求具备今日事，今日毕的口头力。组织层面这叫流程标准，集体层面这叫做事办法，责任心。 尽量避免将当下的事件迁延到下一个环节，否则就会影响后续链路的排期打算和交付效率，极其状况甚至会呈现返工的情景。简言之，思考分明，不埋坑。产品需要对研发，研发设计对测试，测试用例对产品等各个交付节点都是如此，交付物肯定是靠谱的。 三 技术落地保障在需要响应周期中，高质量的落实架构设计，编码实现，平安上线，部署经营等生产阶段，是软件高可用落地保障的前提和根底。 架构设计架构设计往往影响着零碎的后期实现老本（即ROI）和后续运维难度，属于软件的顶层设计，这外面既蕴含宏观的设计方案，也蕴含落地细节里的范式束缚。 • 流程保障 邀请架构师参加：外围交易节点、重大需要改变邀请架构师参加，这是闭坑最间接无效的形式； 器重设计文档：计划形容分明了，并获得相干利益者的认可，是走在正确路线上的前提。 • 设计保障 容灾设计：要预留后路，提前想分明，做好容灾设计。可回滚，可熔断，可重试，可降级。 鲁棒性设计：无状态设计，防重设计，幂等设计，数据一致性设计 编码实现如果说架构设计是骨架，那么编码实现就是神经，血管和肌肉。前者决定了能走多稳，走多久，后者决定着走多快，走多远。落实到编码层面，就是代码的苍老糜烂水平。 • 流程标准 代码评审机制：代码评审不仅仅是发现零碎中存在的问题这么简略。它是一种长期行为，是进行组织文化贯彻和传承的一种模式和载体。评审的过程中，明确了业务职责边界，设计与编码共识，优良的规范导向等研发共识。相当于通过具象化的案例，给出针对性的领导，这些都是保障团队战斗力的基石。 研发过程中的很多问题，通过代码评审机制能够被发现和解决，比方： ◦ 如何看待长期需要的设计与实现？ ◦ 如何对待“Hello World!”的N中写法？ ◦ 如何了解设计模式和适度设计的边界？ ◦ 如何评估以后阶段的交付物？ ◦ 是否有必要引入单元测试？ • 编码标准 ◦ 有没有对谬误进行解决？对于调用的内部服务，是否查看了返回值或解决了异样？ ◦ 设计是否听从已知的设计模式或我的项目中罕用的模式？ ◦ 开发者新写的代码是否用已有的SDK/Framework中的性能实现？在本我的项目中是否存在相似的性能能够调用而不必全副从新实现？ ...

作者：京东云 张久志 本文以2022年一个理论我的项目为根底，来演示在京东云上构建高可用业务的整个过程。私有云及公有云客户可通过应用京东云的弹性IAAS、PAAS服务，创立高可用、高弹性、高可扩大、高平安的云上业务环境，晋升业务SLA,晋升运维自动化程度，升高资源老本及运维老本。有业务迁徙上云需要，心愿构建云上高可用业务架构的客户或对云上高可用架构布局有趣味的读者能够一看。 客户业务为典型的web利用，在京东云上创立一个通过公网IP/域名拜访的高可用的web网站，蕴含通用利用的规范框架，包含拜访接入层、APP层、缓存层、数据库层。整体业务架构设计提供可用区(AZ)级别的高可用等级。 本文演示场景包含单AZ呈现故障导致的主机故障、数据库故障、缓存故障场景下，业务可能提供继续拜访能力。并保障数据的完整性和一致性，同时，可能在无人干涉的条件下，实现业务的弹性扩大，保障业务高并发的场景下有良好的响应工夫。 阐明： 本文的架构为演示架构，_并未严格遵循生产环境_的业务性能及平安的整体规划步骤及要求，在生产环境中，至多应该对主机及CFS的存储性能进行压测，确保可能满足理论业务需要，同时，通过域名拜访的web服务，倡议应用WAF等平安防护产品，保障业务的入口平安。 1、京东云高可用架构设计业务架构以某单位的业务需要为根底，模仿其业务生产环境，布局京东云上的业务整体架构，其中，  NAT网关、负载平衡、堡垒机均创立在公网拜访子网，其余主机及数据库等，创立在外部子网内。 其中利用主机应用高可用组创立， LB后端间接挂载高可用组。 应用高可用组的指标是实现业务高峰期故障时，计算资源能主动退出负载平衡后端，自动化扩大业务处 理能力。缩小运维干涉老本。 2、资源需求（所有IP及URL均调整为非实在IP及URL） 3、利用部署3.1 根底环境筹备业务以一个典型的wordpress的网站为例，业务容器化部署于云主机上，高可用依赖京东云的云主机高可用组，主机装置docker，并配置docker服务主动启动。 #创立利用数据目录 配置目录权限、装置docker等 mkdir -p /wp chmod 777 /wp yum install docker vim -y systemctl enable docker systemctl start docker #挂载CFS文件作为利用数据目录 yum install nfs-utils -y systemctl enable rpcbind     systemctl start rpcbind mount -t nfs -o vers=3 -o noresvport 10.0.0.200:/cfs /wp#配置启动主动挂载CFS及启动服务，通过rc.local实现：#[root@wpha0 wp]# cat /etc/rc.local#!/bin/bash# THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES## It is highly advisable to create own systemd services or udev rules# to run scripts during boot instead of using this file.## In contrast to previous versions due to parallel execution during boot# this script will NOT be run after all other services.## Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure# that this script will be executed during boot.touch /var/lock/subsys/localmount -t nfs -o vers=3 -o noresvport 10.0.0.200:/cfs /wp#（阐明，生产环境可在/etc/fstab挂载）bash /root/start.shstart.sh见以下代码[root@wpha0 wp]# cat /root/start.shdocker stop wordpresssleep 3docker rm wordpresssleep 3docker run -d --name=wordpress --restart=unless-stopped -p 443:443 -p 80:80 -v /wp:/var/www/html wordpress#[root@wpha0 wp]##启动脚本编辑实现后，并写入rc.local后，rc.local调整成可执行，以实现启动主机运行脚本， rc.local实现了主机启动后主动挂载CFS到指定目录，而后，通过start.sh主动革除旧数据，从新拉起wordpress服务。chmod +x /etc/rc.d/rc.local#拉取利用所需镜像 docker pull wordpress#拉取镜像后，运行服务。docker run -d --name=wordpress --restart=unless-stopped    -p 443:443 -p 80:80  -v /wp:/var/www/html  wordpress 留神，这个场景下，次要调整了几个地位： ...

一、前言高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在零碎架构设计中必须思考的因素之一。明天咱们就来聊一聊三H中的高可用，也是咱们常说的零碎稳定性。 本篇文章只聊思路，没有太多的深刻细节。浏览全文大略须要5~10分钟。二、高可用的定义业界罕用N个9来量化一个零碎可用性水平，能够间接映射到网站失常运行工夫的百分比上。 可用性的计算公式： 大部分公司的要求是4个9，也就是年度宕机时长不能超过53分钟，理论要达到这个指标还是十分艰难的，须要各个子模块相互配合。 要想晋升一个零碎的可用性，首先须要晓得影响零碎稳定性的因素有哪些。 三、影响稳定性的因素首先咱们先梳理一下影响零碎稳定性的一些常见的问题场景，大抵可分为三类： 人为因素不合理的变更、内部攻打等等软件因素代码bug、设计破绽、GC问题、线程池异样、上下游异样硬件因素网络故障、机器故障等上面就是隔靴搔痒，首先是故障前的预防，其次是故障后的疾速恢复能力，上面咱们就聊聊几种常见的解决思路。 四、晋升稳定性的几种思路4.1 零碎拆分拆分不是以缩小不可用工夫为目标，而是以缩小故障影响面为目标。因为一个大的零碎拆分成了几个小的独立模块，一个模块出了问题不会影响到其余的模块，从而升高故障的影响面。零碎拆分又包含接入层拆分、服务拆分、数据库拆分。 接入层&服务层个别是依照业务模块、重要水平、变更频次等维度拆分。数据层个别先依照业务拆分后，如果有须要还能够做垂直拆分也就是数据分片、读写拆散、数据冷热拆散等。4.2 解耦零碎进行拆分之后，会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的，那么如果依赖方出问题了，也会受到牵连出问题。这时能够梳理整个流程的调用关系，做成弱依赖调用。弱依赖调用能够用MQ的形式来实现解耦。即便上游呈现问题，也不会影响以后模块。 4.3 技术选型能够在适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面进行全量评估，挑选出适宜以后业务场景的中间件&数据库。后期的调研肯定要充沛，先比照、测试、钻研，再决定，磨刀不误砍柴工。 4.4 冗余部署&故障主动转移服务层的冗余部署很好了解，一个服务部署多个节点，有了冗余之后还不够，每次呈现故障须要人工染指复原势必会减少零碎的不可服务工夫。所以，又往往是通过“主动故障转移”来实现零碎的高可用。即某个节点宕机后须要能主动摘除上游流量，这些能力基本上都能够通过负载平衡的探活机制来实现。 波及到数据层就比较复杂了，然而个别都有成熟的计划能够做参考。个别分为一主一从、一主多从、多主多从。不过大抵的原理都是数据同步实现多从，数据分片实现多主，故障转移时都是通过选举算法选出新的主节点后在对外提供服务（这里如果写入的时候不做强统一同步，故障转移时会失落一部分数据）。具体能够参考Redis Cluster、ZK、Kafka等集群架构。 4.5 容量评估在零碎上线前须要对整个服务用到的机器、DB、cache都要做容量评估，机器容量的容量能够采纳以下形式评估： 明确预期流量指标-QPS；明确可承受的时延和平安水位指标（比方CPU%≤40%，外围链路RT≤50ms）；通过压测评估单机在平安水位以下能反对的最高QPS（倡议通过混合场景来验证，比方依照预估流量配比同时压测多个外围接口）；最初就能够估算出具体的机器数量了。DB和cache评估除了QPS之外还须要评估数据量，办法大致相同，等到零碎上线后就能够依据监控指标做扩缩容了。 4.6 服务疾速扩容能力&泄洪能力现阶段不论是容器还是ECS，单纯的节点复制扩容是很容易的，扩容的重点须要评估的是服务自身是不是无状态的，比方： 上游DB的连贯数最多反对以后服务扩容几台？扩容后缓存是否须要预热？放量策略这些因素都是须要提前做好筹备，整顿出齐备的SOP文档，当然最好的形式是进行演练，实际上手操作，有恃无恐。 泄洪能力个别是指冗余部署的状况下，抉择几个节点作为备用节点，平时承当很小一部分流量，当流量洪峰来长期，通过调整流量路由策略把热节点的一部分流量转移到备用节点上。 比照扩容计划这种老本绝对较高，然而益处就是响应快，危险小。 4.7 流量整形&熔断降级 流量整形也就是常说的限流，次要是避免超过预期外的流量把服务打垮，熔断则是为了本身组件或者依赖上游故障时，能够疾速失败避免长期阻塞导致雪崩。对于限流熔断的能力，开源组件Sentinel基本上都具备了，用起来也很简略不便，然而有一些点须要留神。 限流阈值个别是配置为服务的某个资源能撑持的最高水位，这个须要通过压测摸底来评估。随着零碎的迭代，这个值可能是须要继续调整的。如果配置的过高，会导致系统解体时还没触发爱护，配置的过低会导致误伤。熔断降级-某个接口或者某个资源熔断后，要依据业务场景跟熔断资源的重要水平来评估应该抛出异样还是返回一个兜底后果。比方下单场景如果扣减库存接口产生熔断，因为扣减库存在下单接口是必要条件，所以熔断后只能抛出异样让整个链路失败回滚，如果是获取商品评论相干的接口产生熔断，那么能够抉择返回一个空，不影响整个链路。4.8资源隔离如果一个服务的多个上游同时呈现阻塞，单个上游接口始终达不到熔断规范（比方异样比例跟慢申请比例没达到阈值），那么将会导致整个服务的吞吐量降落和更多的线程数占用，极其状况下甚至导致线程池耗尽。引入资源隔离后，能够限度单个上游接口可应用的最大线程资源，确保在未熔断前尽可能小的影响整个服务的吞吐量。 说到隔离机制，这里能够扩大说一下，因为每个接口的流量跟RT都不一样，很难去设置一个比拟正当的可用最大线程数，并且随着业务迭代，这个阈值也难以保护。这里能够采纳共享加独占来解决这个问题，每个接口有本人的独占线程资源，当独占资源占满后，应用共享资源，共享池在达到肯定水位后，强制应用独占资源，排队期待。这种机制长处比拟显著就是能够在资源利用最大化的同时保障隔离性。 这里的线程数只是资源的一种，资源也能够是连接数、内存等等。 4.9系统性爱护 系统性爱护是一种无差别限流，一句话概念就是在零碎快要解体之前对所有流量入口进行无差别限流，当零碎复原到衰弱水位后进行限流。具体一点就是联合利用的 Load、总体均匀 RT、入口 QPS 和线程数等几个维度的监控指标，让零碎的入口流量和零碎的负载达到一个均衡，让零碎尽可能跑在最大吞吐量的同时保证系统整体的稳定性。 4.10 可观测性&告警 当零碎呈现故障时，咱们首先需找到故障的起因，而后才是解决问题，最初让零碎复原。排障的速度很大水平上决定了整个故障复原的时长，而可观测性的最大价值在于疾速排障。其次基于Metrics、Traces、Logs三大支柱配置告警规定，能够提前发现零碎可能存在的危险&问题，防止故障的产生。 4.11 变更流程三板斧变更是可用性最大的敌人，99%的故障都是来自于变更，可能是配置变更，代码变更，机器变更等等。那么如何缩小变更带来的故障呢？ 可灰度用小比例的一部分流量来验证变更后的内容，减小影响用户群。可回滚呈现问题后，能有无效的回滚机制。波及到数据批改的，公布后会引起脏数据的写入，须要有牢靠的回滚流程，保障脏数据的革除。可观测通过观察变更前后的指标变动，很大水平上能够提前发现问题。除了以上三板斧外，还应该在其余开发流程上做标准，比方代码管制，集成编译、自动化测试、动态代码扫描等。五、总结对于一个动静演进的零碎而言，咱们没有方法将故障产生的概率降为0，能做的只有尽可能的预防和缩短故障时的复原工夫。当然咱们也不必一味的谋求可用性，毕竟晋升稳定性的同时，保护老本、机器老本等也会跟着上涨，所以须要联合零碎的业务SLO要求，适宜的才是最好的。 如何做好稳定性和高可用保障是一个很宏大的命题，本篇文章没有太多的深刻细节，只聊了整体的一些思路，次要是为了大家在当前的零碎高可用建设过程中，有一套零碎的框架能够参考。最初感激急躁看完的同学。 *文/新一  关注得物技术，每周一三五晚18:30更新技术干货要是感觉文章对你有帮忙的话，欢送评论转发点赞～

作者：姚嵩 地球人，爱好音乐，动漫，电影，游戏，人文，美食，游览，还有其余。尽管都很菜，但毕竟是喜好。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 参数阐明：https://github.com/openark/or... ⽬的：⽤ orchestrator 配置 MySQL 集群的⾃动切换。 已接管的数据库实例(1主1从架构)：10.186.65.5:330710.186.65.11:3307orchestrator 的相干参数： "RecoveryIgnoreHostnameFilters": [], "RecoverMasterClusterFilters": ["*"], "RecoverIntermediateMasterClusterFilters":["*"], "ReplicationLagQuery": "show slave status" "ApplyMySQLPromotionAfterMasterFailover": true, "FailMasterPromotionOnLagMinutes": 1,局部测试场景(因为orch是⾼可⽤架构，所以以下试验命令都是在raft-leader节点上执⾏) 案例1:场景：敞开 master，确认是否会切换(提早 < FailMasterPromotionOnLagMinutes) 操作：# 确认已有的集群 orchestrator-client -c clusters# 查看集群拓扑，集群为 10.186.65.11:3307 orchestrator-client -c topology -i 10.186.65.11:3307 # 敞开master节点 ssh [email protected] "service mysqld_3307 stop" # 再次确认已有的集群，原集群会拆分为2个集群 orchestrator-client -c clusters # 查看集群拓扑，此时集群为 10.186.65.5:3307 orchestrator-client -c topology -i 10.186.65.5:3307 论断：切换胜利；新的master节点read_only 和 super_read_only 都敞开了，能够读写；试验截图： 案例2场景：敞开master，确认是否会切换(提早 > FailMasterPromotionOnLagMinutes) FailMasterPromotionOnLagMinutes 配置的是1分钟，也就是60s ...

作者：姚嵩 地球人，爱好音乐，动漫，电影，游戏，人文，美食，游览，还有其余。尽管都很菜，但毕竟是喜好。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 参考：https://github.com/openark/or... https://github.com/openark/or... https://github.com/github/orc... https://github.com/openark/or... 版本：https://github.com/openark/or... 环境阐明：orchestrator主机环境 10.186.65.5 10.186.65.11 10.186.65.26 orchestrator 后端数据库链接(MySQL 数据库) 10.186.65.29:3307 装置步骤# 下载指定版本orchestrator(此处以3.2.6为例) yum -y install wget jq dir_software="/opt/software/" mkdir -p ${dir_software} cd ${dir_software} wget -c https://github.com/openark/or... # 装置 dir_software="/opt/software/" cd / tar -zxvf /${dir_software}/orchestrator-3.2.6-linux-amd64.tar.gz # (后端数据库)设置后端数据库账号 -- 创立orchestrator的元数据存储schema CREATE DATABASE IF NOT EXISTS orchestrator; -- 创立数据库账号，以便orchestrator连贯后端数据库 CREATE USER 'orchestrator'@'10.186.65.5' IDENTIFIED BY 'Orch@123'; GRANT ALL PRIVILEGES ON orchestrator.* TO 'orchestrator'@'10.186.65.5'; CREATE USER 'orchestrator'@'10.186.65.11' IDENTIFIED BY 'Orch@123'; ...

文章、博客、商品等性能常常须要一个字段统计用户的点击量（访问量），该字段通常须要长久化到数据库中，但数据库是不适宜间接应答用户操作，这种场量如何实现高负载？ 支流的零碎高负载解决方案，通常把数据同步到分布式的ES，多节点的 Redis 集群中。但点击量这个字段，须要在页面中实时展现，用户刷新页面时，须要直观的看到点击量的变动。 咱们首先能想到的，是将点击量间接存入Redis，展现页面时从Redis实时读取，并实时累加， 键名格局： article : [id] : hits键值格局：点击量 这样设计仅为满足点击量性能问题不大，俚进一步的需要来了：热门文章，热门商品等性能，须要跟据点击量进行排序，或者聚合更多字段进行查问。因而，点击量还是是须要更新到数据库和ES中的。但又不能实时更新，因而能够在 redis 存储点击量时，减少一个计数器，当计数器未达到临界值时，仅累加Redis，不写入数据库，当计数器达到临界值时，写入数据库，计数器归0 键名格局： article : [id] : hits示例值：article:10:hits 键值格局： 点击量,计数器示例值：123,10，示意以后点击量为123，计数器为10 下次访问后，示例值变为：124,11，示意以后点击量为124,11，计数器为11。当计数器值达到 1000 时（示例值为：1113,1000），计数据归 0 （1113,0），将 1113 更新到数据库并触发ES更新 流程图如下： 另外，还能够进一步简化设计，不设置计数器，用点击量取模临界值（点击量 % 临界值 === 0），余数为0时更新数据库。 本文原始网址：https://www.liu12.com/article...，转载请保留出处

1、高可用性的目标是什么？ 高可用性的指标是以最小的停机工夫提供间断的服务（惟一真正具备 "零 "停机工夫的设施是心脏起搏器和核武器中的安全装置）。这意味着，如果一个组件产生故障，另一个组件能够立刻接管其性能，而不会实质性地中断对系统用户的服务。高可用性还要求有能力检测到一个或多个组件产生故障，而后采取纠正措施使其从新投入使用。 2、如何掂量高可用性？ 向客户提供的高可用性程度在SLA（"服务水平协定"）中以可量化的术语定义，包含容许的停机工夫，在5G世界中，简直没有。5G网络--包含提供免费和政策等要害性能的业务支持系统（BSS）--必须每年提供99.999%，或 "五个九 "的数据可用性。这相当于每年只有6分钟的非计划性停机工夫。 你应该晓得两件事： 大多数互联网公司每年按用户来掂量。因而，一个领有一百万用户的公司可能有一个用户停机一年，但依然宣称合乎 "五个九 "的要求。当你问他们的服务水平协定是什么时，简直所有的供应商都会伪装他们上面的堆栈是100%牢靠的。3、为什么高可用性很重要？ 高可用性对企业来说是至关重要的，因为它能够确保他们总是可能不受任何烦扰地提供服务和产品，从而更好地保留客户并缩小客户散失。 随着咱们应用的越来越多的货色变得越来越依赖于继续连贯到其余中央的货色，高可用性变得越来越重要。随着咱们的连贯越来越多，停机的老本也越来越高。 当思考到5G带来的大量新的商业机会和新的企业应用时，商业赌注变得更高。可能失落的数据越多，放弃你的零碎失常运行就越重要。 抓住5G的全副商业后劲须要数据立刻可用、有弹性和统一，无论用户的地理位置如何。由未解决的数据抵触和网络攻击造成的数据中心故障和数据失落基本不可能产生，因为它们的代价太高了。 简而言之，可能提供高可用性会产生踊跃的影响有—— ➤服务水平协定➤客户关系➤数据安全➤品牌名誉所有这些联合起来，有可能使企业沉没或援救。 4、如何实现高可用性？ 实现高可用性须要本地冗余和天文复制。本地冗余意味着在一个部件产生故障时有备份部件，而天文复制则是在多个物理地位上复制数据，这样数据就能够在一个地理位置的损失中幸存下来。 然而，在一个反对5G的世界里实现高可用性并不容易。故障切换解决方案、冗余和网络负载平衡须要肯定水平的外部专业知识和资源来正确执行，如果你的数据平台不反对高可用性，你很快就会发现你的总领有老本飙升，因为你要增加技术栈组件来满足日益严格的可用性SLA。 5、Volt Active Data如何确保高可用性 Volt Active Data平台的设计是为了确保高可用性，即便在硬件故障的状况下也能保障业务连续性。 Volt Active Data通过主动的集群内和集群间复制，非常简单和经济地实现了24x7x365操作的高可用性。在解决申请之前，传入的申请被存储在不同服务器的多个物理磁盘上，这意味着单个服务器的损失将产生最小的影响，因为幸存者将是齐全最新的。如果须要，这些写入能够是同步的。这提供了对单节点故障的耐久性。 Volt有客户在生产中应用三被动跨数据中心复制，以实现地理分布的弹性，反对5G级的服务质量，而且Volt很快将认证四路复制。尽管许多数据平台和数据库技术公司提供某种模式的跨数据中心复制，但没有多少公司提供真正的被动-被动跨数据中心复制，这意味着在不同的物理地位应用两个数据库正本，这两个正本都能够实时更改，并且都会将其更改流传给对方。 被动-被动零碎的性质容许同一个数据在两个或更多的中央同时被扭转，然而如何解决由此产生的抵触，决定了一个特定的被动-被动解决方案的实用性和有效性。天真的解决方案是让最近的变动获胜，但这意味着稍早实现的交易将从内部世界的角度隐没。Volt是惟一可能捕获抵触解决事件并使其可被拜访的数据平台，从而加重抵触解决的负面效应。 凭借其取得专利的Active(N)无损跨数据中心复制，Volt还为第三个数据中心减少了后劲，这意味着即便一个数据中心意外宕机，而另一个数据中心正在进行有打算的保护，您的应用程序将持续运行，您的零碎将放弃失常。 在5G时代，有能力的客户治理、BSS和支出保障意味着没有服务故障。你的客户放弃高兴和虔诚，你在欺诈者有机会在你的网络内造成毁坏之前就把他们赶走。有了高可用性，你就能够缩小停机的负面影响，实现系统故障的主动复原，转化为更好的投资回报率，最终取得更持重的底线。 如果您心愿集成VoltActiveData到您的技术栈中，请与咱们分割！

作者：涂鸦 微服务的稳定性始终是开发者十分关注的话题。随着业务从单体架构向分布式架构演进以及部署形式的变动，服务之间的依赖关系变得越来越简单，业务零碎也面临着微小的高可用挑战。利用高可用服务 AHAS (Application High Availability Service) 是经阿里巴巴外部多年高可用体系积淀下来的云产品，以流量与容错为切入点，从流量管制、不稳固调用隔离、熔断降级、热点流量防护、零碎自适应爱护、集群流控等多个维度来帮忙保障服务和网关的稳定性，同时提供秒级的流量监控剖析性能。AHAS 不仅在阿里外部淘宝、天猫等电商畛域有着宽泛的利用，在互联网金融、在线教育、游戏、直播行业和其余大型政央企行业也有着大量的实际。 流量漏斗防护原在分布式系统架构中，每个申请都会通过很多层解决，比方从入口网关再到 Web Server 再到服务之间的调用，再到服务拜访缓存或 DB 等存储。在高可用流量防护体系中，咱们通常遵循流量漏斗准则进行高可用流量防护。在流量链路的每一层，咱们都须要进行针对性的流量防护与容错伎俩，来保障服务的稳定性；同时，咱们要尽可能地将流量防护进行前置，比方将一部分 HTTP 申请的流量管制前置到网关层，提前将一部分流量进行管制，这样能够防止多余的流量打到后端，对后端造成压力同时也造成资源的节约。 Ingress/Nginx 网关流量管制Nginx 为目前比拟风行的高性能开源服务器，Ingress 则为理论的 Kubernetes 集群流量入口。AHAS Sentinel 为 Ingress/Nginx 网关提供原生的入口流量控制能力，将流量防护进行前置，提前对多余的流量进行拦挡，保障后端服务的稳定性。近期公布的新版 AHAS Nginx 流量防护插件基于 Sentinel C++ 原生版本实现，与旧版本 sidecar 版本相比进行了大量的性能优化，在上万 QPS 的场景也能够保障准确流量管制，同时不会对网关自身的性能带来很大影响。 AHAS Nginx/Ingress 防护具备以下外围能力及劣势： 低应用老本：仅需简略配置即可疾速将 Nginx/Ingress 网关接入 AHAS 流量防护，并在控制台进行可视化的监控、规定与返回行为配置控制台动静配置流控规定，实时失效，无需 reload Nginx精准的入口总流量管制：AHAS Nginx/Ingress 防护反对上万 QPS 量级精准的入口总流量管制，反对自定义流控粒度（如某一组 Host, URL 维度，甚至能够细化到参数、IP 维度）配套的可观测能力，实时理解网关流量与防护规定失效状况上面咱们就来用一个示例来介绍一下，如何疾速将 Kubernetes 集群中的 Ingress 网关接入 AHAS 来玩转流控能力，保障服务稳定性。 疾速玩转 AHAS Ingress 流量防护首先，咱们假如咱们已有一个创立好的阿里云容器服务的 ACK 集群（如果集群中没有 Ingress，能够在 ACK 组件治理中手动装置），咱们只须要在 kube-system 命名空间的 nginx-configuration 配置项 (ConfigMap) 中增加以下两个字段： ...

摘要：在第七届寰球软件大会上，华为软件工程师杜志刚，就为宽广开发者分享了华为云官网的高可用保障计划，深度剖析了网站在各类极其重大劫难场景下，如何疾速复原的计划和工程化实际。本文分享自华为云社区《网站拜访故障背地产生了什么？华为工程师教你疾速应答【寰球软件技术大会技术分享】》，原文作者：技术火炬手 。 最近，某CDN服务故障，导致海内少量出名新闻网站无奈失常拜访或加载，一石激起千层浪。的确，随着越来越多的业务上云，一个网站或者某个业务是否保障继续的在线，十分考验背地的高可用、高牢靠方案设计。 在第七届寰球软件大会上，华为软件工程师杜志刚，就为宽广开发者分享了华为云官网的高可用保障计划，深度剖析了网站在各类极其重大劫难场景下，如何疾速复原的计划和工程化实际。 网站不靠谱，损失不可估量从网站所有者角度来看：网站不可用间接导致的是经济支出方面的影响，特地对于电商类网站，每分每秒都在产生交易，一旦拜访中断，经济损失的影响不言而喻。除此之外，从客户角度来看，面对网站不可拜访，最直观的感触是不靠谱，对网站以及网站背地的企业品牌产生不可挽回的口碑及信任度方面的负面影响。 从近十年的互联网重大故障事件来看，DNS、CDN导致的大范畴影响历历在目，其余IT基础设施导致的区域型及全局型故障也影响甚大。 业界宽泛应用的网站可用性指标包含网站不可用工夫及网站年度可用率，不同类型的网站和利用对可用性的要求也不尽相同。 其中网站不可用工夫（故障工夫）=故障复原工夫点-故障产生工夫点。网站年度可用率（Yearly Uptime Percentage）=（1-网站不可用工夫/年度总工夫）*100%。 华为云官网作为云基础设施提供商的互联网拜访入口，对可用性有着极高的要求，面向最终用户的外围页面要做到7*24小时在线，如果呈现重大故障，如云服务区级别，或基础设施导致的单云全局故障，5分钟内告警告诉到相干责任人，15分钟内实现故障切换。 网站拜访呈现故障，背地产生了什么？上面联合图例剖析一下网站页面拜访的整体流程及要害故障点： 在①处，DNS故障会通常会导致网站整体不可拜访，到了②是CDN故障会让局部天文区域用户不可拜访，③是单云全局故障会导致网站整体不可拜访，④是云服务区级别故障会导致分流到该区域的用户不可拜访，⑤是云服务可用区级别故障会导致路由到故障AZ的用户不可拜访，⑥是容器集群故障导致路由到对应容器服务的用户不可拜访，⑦是服务节点故障会导致路由到故障服务节点的用户不可拜访。 综上，云化场景下，页面拜访面临诸多的关键技术挑战，包含 单个DNS服务商整体故障如何应答?单个CDN厂商整体或多个区域故障如何应答？基础设施故障导致的单云整体故障如何保障页面还能够失常拜访？单个云服务区级别故障如何对用户拜访影响工夫降到最小？页面拜访依赖的后端服务泛滥，如何最大限度较少故障点，升高计划整体复杂度及老本，保障计划通用可行？四个计划，轻松应答网站各种故障针对以上要害挑战，通过华为云官网近几年的实际，总结了4个计划分享给大家，咱们将一一拆解，为大家展现这些计划的实际效果。 1、单个DNS服务商整体故障：双DNS服务商解析DNS是相对来说十分重要但却没有失去应有器重的薄弱环节，对于可用性要求极高的商业门户网站，将DNS依靠于一家服务商，不出问题惊涛骇浪，一旦产生全局性故障，导致的影响可能是灾难性的。 咱们以后的策略是：采纳双DNS厂商域名解析计划，在一家服务商产生局部或整体故障时，能够在短时间内主动实现故障切换，将域名解析工作交给其余服务商实现。此外，咱们还构建了对立运维平台实现多厂商域名解析的对立配置，以及DNS可用性监控、故障服务的疾速剔除能力。 双厂商DNS配置如图所示： 这个配置的前提是域名注册商及域名解析商反对多厂商Name Server配置。具体配置方面，首先将域名注册托管迁徙到反对多厂商NS配置的注册商，而后同步DNS厂商配置的解析记录到新厂商，最初域名注册服务及解析服务同时配置NS记录指向双厂商Name Server（0~72小时失效） 这样配置能够在单个产商Name Server产生故障时，ISP Local DNS主动将故障Name Server升高抉择优先级（BIND SRTT算法，失败惩办），应用优选的Name Server进行A记录或CNAME域名解析。 演练步骤能够拆解为： 第一步：双厂商NS记录配置。 第二步：通过浏览器查看服务可失常拜访。 第三步：拨测Name Server可用性，验证不同地区ISP是否应用了不同厂商的Name Server进行域名解析。 第四步：关停Bind模仿单个厂商DNS故障。 最初，通过HTTP从多个地区拨测服务是否能够失常拜访。 2、单个CDN厂商区域性故障：多CDN服务商计划上面介绍一下多CDN厂商的配置与切换，如图所示： 应用这个计划的限度条件有三个：DNS协定不反对多厂商CDN的CNAME解析配置；DNS智能解析反对不同地区或网络配置不同的CNAME解析记录；CDN呈现整体故障概率较低，更多是区域性故障。 多CDN厂商的配置要先对国内及海内拜访别离做主备CDN减速，而后CDN CNAME解析TTL设置为60s，让单CDN厂商服务不可用时，故障切换失效工夫更短；最初是构建CDN治理平台，对接多厂商DNS治理API，事后配置切换和回切策略，呈现故障一键切换。 最初的配置成果也很显著，CDN告警厂商A大面积故障后，可通过CDN运维治理平台，将对应区域的CNAME解析Failover到厂商B提供服务，失效工夫1分钟。 下图是咱们运维平台的切换界面示例，可按不同二级域名分国内及海内用户拜访场景别离切换。 2020年和2021年咱们都遇到了理论的现网故障，CDN的故障切换性能失去了无效利用，让页面拜访实现了疾速故障复原。 3、区域性天文劫难场景：页面拜访异地多活计划这里介绍了咱们中国站和国内站双站异地多活的组网策略，如图所示： 如果产生区域性天文劫难场景，咱们应用站点多Region多活部署， 应用这个解决方案要保障内容治理服务公布的页面内容在多云服务区放弃同步。同时，LB及网关路由配置多活云服务区保持一致。 具体配置时，先将国内及海内用户CDN回源流量按比例分流至不同云服务区；随后配置健康检查策略，当呈现云服务区级别故障时告警，便于主动或手动切换回源流量至衰弱的云服务区；如果海内与国内服务存在差别时，通过云厂商外部专线在LB或网关进行跨云服务区路由。 这样，在非容灾场景下，多云服务区同时提供页面拜访服务，升高单云服务区回源压力。即使呈现云服务区级别故障时，也可通过CDN Admin API实现一键故障切换，CDN回源疾速回到可用状态。 如图所示，通过咱们的运维平台，在单个云服务区故障场景下，可实现故障云服务区的疾速剔除，这个过程次要通过批量切换二级域名Region级别回源DNS A记录实现的。 4、单云全局故障场景：网站备份与切换计划最初介绍一下整个高可用计划的最底层的保底计划：网站备份与故障切换，首先来看一下网站的备份流程，如图所示： 运维人员先配置站点元数据及配置备份策略，站点治理依据备份策略下发备份工作到调度服务，而后调度服务再定时调用备份服务执行备份工作。 采集的话是由备份服务启动Headless Browser加载入口页，再加载动态页面资源，执行页面脚本加载动静页面资源，而后执行预置脚本加载动静页面资源，最初辨认页面跳转URL，包含HTML标记及脚本触发的动静跳转点，启动新Headless Browser实例，实现级联爬取。 采集完是存储，页面主文档及相干页面资源加载实现后通过OBS接口转储到对象存储服务，再通过云厂商提供的对象存储跨Region同步能力实现页面内容异地容灾。跨云复制则通过跨云同步工具将备份站点页面内容，同步到其余云厂商对象存储服务，实现跨云容灾。 备份完结后，再看一下故障切换流程。当基础设施问题等起因导致的单云多Region故障使得Web服务整体不可用时，开始故障检测，页面可用性拨测服务监测到云服务区A、B不可用，在5分钟内收回告警。 往下是故障转移，成立重大问题应急解决作战小组，同时关上运维容灾治理平台，查看不可用区域、备份站点拨测是否失常。如果同云备份站点可用，优先切换同云备份站点；如果不可用，第三方云厂商备份站点可用，切换到备份站点。整个切换通过更新回源域名A记录解析地址指向OBS公网拜访地址实现。 最初是故障修复阶段，先定位解决问题，拨测Web Server可用，再手动执行故障回切，而后用户回归失常拜访。 总结以上是在各种极其场景下如何保障网站继续在线的一些实践经验的总结，相干计划曾经在理论场景下验证无效，并且做到继续的例行化演练。 另外，对于不同类型或规模的网站，高可用并没有具体量化的规范，能够给几个比拟粗的级别供参考：最根底的保障性能可用，不思考网元的单点问题。要求再高一点，思考应用服务集群化部署、DB、缓存等中间件进行相应的高可用部署，确保没有根本的单点问题。再往上思考多数据中心部署，解决单数据中心不可用问题。最初是思考异地多活或容灾，应答某一天文区域劫难的场景。 除了以上传统套路外，随着越来越多的企业都在上云，还要思考单个云厂商基础设施产生整体故障时如何疾速替换及逃生的问题，例如CDN，DNS等，这些都是网站拜访根底场景要重点思考的故障点。 福利本次，还有两位华为的专家给大家带来《华为云官网智能化实际的五大要害动作》和《华为云官网前端的技术演进与低代码实际》的分享，他们也答复了开发者关怀的问题，例如网站智能举荐的实际心得，低代码平台的选型等等。欢送扫码观看视频。 点击关注，第一工夫理解华为云陈腐技术~

导读：本文整顿自高可用架构与数列科技联结举办的技术沙龙，数列科技资深架构师徐汉彬的主题演讲。围绕“峰值流量下的高并发实际”，次要介绍了其在腾讯QQ会员流动平台的高可用架构实际。以下为演讲摘录。 明天分享的主题的是《面向大规模流量流动的高可用架构实际》，在开始之前先做个简略的自我介绍，我叫徐汉彬，在进入数列科技之前负责过QQ会员流动经营平台，把这个平台从日PV百万级别做到10亿级别，在应答大流量流动这一块积攒了肯定的教训，明天就这个主题方向跟大家做一个探讨。 分享的内容次要分为三个局部：1.大流量流动的零碎扩容评估办法2.零碎高可用架构设计实际3.大规模流量流动的实际案例 大流量流动的零碎扩容评估办法大流量流动有多种形式，除了咱们常见的电商大促（双11、618等），近几年还衰亡了一种新模式——直播卖货。一个出名主播在比拟短的工夫里，疏导粉丝大量下单，这是一种典型的大流量场景，对系统的稳定性收回较高挑战。另外一种比拟常见的流动模式是营销流动，例如春节红包、周年庆。流动的流量起源，包含外部资源、内部付费购买的广告资源和第三方单干导流。公司在流动上投入了大量的资金，参加用户泛滥，如果流动中途呈现问题，不仅对产品口碑的影响十分负面，而且会有金钱损失，还波及到与第三方单干失败的问题。 举个例子，假如你的流动跟春晚单干，春晚到了某个环节让大家拿起手机现场扫码，这时零碎挂了，扫码失败，这种情景就十分难堪。遇到这种状况，第一个找你的可能不是你的领导，而是内部的第三方单干商，由此可见，关键时刻的零碎高可用有多重要。 大流量流动面临的挑战次要分为三个局部。第一个挑战是流量评估难，扩容的量级并不是张口就来，如果你跟运维说要裁减10倍容量，他肯定会反诘你为什么，你要拿出扩容的正当根据。第二个挑战是架构扩容难，即便咱们评估出了比拟精确的流量峰值，又该怎么进行零碎扩容呢？古代IT零碎架构的复杂度越来越高，尤其是当初风行的微服务架构，它的节点数越来越多，服务之间的调用关系非常复杂，链路的梳理自身也是一大难点。第三个挑战是怎么进行高可用施行。咱们把流量评估和链路梳理扩容都做好了，流动在大流量到来的那天就没有问题了吗？当然不是，所以第三个问题就是怎么进行高可用施行。 想要解决上述挑战，绕不开业务和零碎的双重复杂度问题。微服务架构的复杂性，加之业务的复杂性，使得整个零碎盘根错节、难以被人类了解。即便是公司的架构师、业务研发同学也很难讲清楚零碎整个链路的每一个细节和服务之间的调用关系，因为此时的零碎曾经是一张宏大又相互交织的的网络了。要解决流量评估的问题就得进行精密的链路梳理，梳理的第一步就是画架构简图，把每个架构大的模块画进去，再依据架构简图进行业务性能链路拆解。 链路图梳理实现后，咱们就能够开始预估扩容量了，这里波及到三个重要的指标：推广量、环节转化率、单UV的申请总数。第一个指标推广量，个别状况下会以每秒广告的曝光量计算。将不同广告渠道的曝光量加起来就能失去预估的推广量级了。还有一种形式是计算APP利用顶峰每秒用户的登录数，这个数值约等于推广的每秒曝光量。个别预测的每秒推广量都在零碎现有容量的10倍以上，按这个推广量去扩容，零碎根本没有问题，但会它会造成比较严重的资源节约。这时则须要用第二个参数来辅助咱们进行更粗疏的评估，它叫做环节转化率。以红包流动为例，用户看见红包流动，但不肯定会点击进入页面，进入页面也不肯定会支付红包，每一个环节都有环节转化率。预估环节转化率个别有两种办法，一种是根据过往的教训数据进行估算；另一种就是提前演习，提前给局部用户推送流动，疾速精确地收集到每一个环节转化率，有条件的公司个别会采纳这种形式。还有一个参数是咱们须要特地留神的，就是单UV的申请总数，为什么要特地关注呢？因为用户进入一个流动页面，他可能会查问个人信息、查看流动记录，通常不止一个申请动作，所以你在计算后端压力时不能只算用户进入流动的每秒峰值，还要算上其余申请动作。假如用户均匀有4个申请动作，那你的流量就要乘以4，它有一个放大效应。通过后面3个指标咱们就能计算出后端会接受多少流量压力，进而得出扩容的预估值。最初把扩容容量设置为预估值的3倍，这个3倍并不是凭空臆想，而是从过往大量的流动扩容教训中总结得来的法则，流动当天的峰值通常是惯例均值的3倍。具体怎么计算咱们来举个例子，假如咱们是100/S的曝光量，只有60%用户进入了支付页面，这其中又只有50%点击了支付按钮，那后端收到的申请是30/S，依据单UV的申请总数来说，整个后端起码要撑持120/S的压力，加上3倍准则那么后端最终的扩容也就是360/S。支付页面的流量峰值则为180/S，这时你带着数据去找运维扩容就有理有据了。 某流动容量评估失去后果是9.6W/S，依据三倍准则，整个业务链路要扩容到30W/S，然而，在实操扩容过程中会发现局部利用很难扩容。举个例子，像Web server这种很容易做平行扩容，只有机器足够就能够扩容下来，但有些接口日常也就2000-3000/S的QPS，要扩到10万QPS根本就是不可能的，也没有那么多的资源和精力。这就波及到扩容的具体实际了，也是咱们接下来要说的零碎高可用架构设计的实际内容。 零碎高可用架构设计实际通常来说，咱们零碎高可用架构实际有三大扩容因素：全链路QPS、机器带宽、存储大小。 全链路QPS最容易被大家了解，咱们也最关注，就不做过多的开展。机器带宽问题，流量越大越容易遇到。假如CGI申请达到10W/S，通常它的申请存储不是一次，过后咱们的惯例业务申请存储高达7-8次，包含查问流动配置、查问用户参加记录、查问其余关联信息等。这个10W/S就象征存储端须要接受大几十万每秒甚至百万每秒的量，如果一个存储占1KB或者大几百KB，在这个量级下存储数据就相当宏大了，应用百兆级别网卡显然就会遇到网络带宽瓶颈问题。接下来说说存储大小，这里说的存储大小通常不是指硬盘的存储大小，而是指内存，它也比拟容易遇到瓶颈。大多数公司有应用Redis类的Key-value存储，也有局部公司应用自研的Key-value存储，通常写入的数据会先写入内存，再通过定时淘汰机制，同步到本地的SSD或者磁盘。在大流量场景下，内存很容易被写满，如果没有事先评估，流动当天几百G的内存会霎时被写满。还有一个不得不提的内容就是动态资源，它是咱们网页申请的图片、JavaScript和CSS款式，通常它的瓶颈不在零碎自身。个别状况下，如果不思考带宽的限度，在一台配置很一般的机器上搭建一个Nginx来压测动态资源的申请性能，能够轻松达到数千QPS。然而，如果思考到动态资源的大小，加上单个用户关上一个页面就会申请很多动态资源的理论状况，申请的动态资源的大小很较容易就超过1M了。这时第一个撑不住的就是机器的进口带宽，而不是动态资源服务器自身的性能。 针对动态资源问题，咱们有罕用的应答办法——离线包推送机制。在流动开始前几天就把动态资源推送到沉闷用户的的手机里，这样流动当天九成以上的流量都是本地的，他基本没有发动网络申请，以此来解决CDN的申请压力，解决带宽问题。实现扩容只能说在实践上没问题，接下来说说高可用架构建设的要害要点。概括起来就是几个点：过载爱护、柔性可用、容灾建设、轻重拆散、监控体系、数据对账。 监控体系很重要，咱们须要探知这个零碎处于什么状态，并且呈现问题时须要一些计划去应答它。后面的分享提到过一个问题，有些接口日常也就2000-3000/S的量，没有那么多的资源和精力扩到10万/s， 那怎么办呢？对于零碎链路架构优化，咱们罕用的形式有三种，第一种是异步化，这个好了解，临时没有这个能力执行完，就放到音讯队列里缓缓消化。第二种是内存级的缓存，把须要拜访的数据提前放到内存级的Cache里。第三种是服务降级，这个比拟罕用，就不做过多介绍了。通过这些办法就能够把链路的性能晋升起来。 对于过载爱护它的的外围指标是局部不可用至多比彻底不可重要强，次要的实现伎俩是进行分层流量管制。这些层级蕴含推广层、前端层、CGI层和后端服务层。针对推广层，只能在最坏的状况应用，因为它要对广告进行下架解决，不到万不得已，公司也不违心采纳这个形式，它也会影响流动的业务成果。针对前端层，能够实现随机弹出倒计时，限度用户1分钟内不能发动新的网络申请，有助于削平流量峰值。其余流量管制层的实现大同小异，不做过多的开展。 对于部署，咱们应该把重要的外围的一些操作给爱护起来，例如，在上述案例中，比拟重要的是发货，它不应该被其余操作影响。如果查问操作不可用，用户再刷新一次页面就好了，但如果发货不到账，用户会间接投诉，所以上述案例就把发货操作拆出来独立部署了一套异步发货集群。 柔性可用咱们应该怎么实现呢？个别有两个方向，第一种是设置超短的超时工夫，例如，给平安接口设置超时工夫为30毫秒，假如那天平安接口真的挂了，30毫秒对于一个百毫秒级别的申请来说，用户也不太能感知到，流动的体验还是好的。另外一种，就是间接不等网络回包的形式，例如UDP服务。 在容灾建设中，咱们要大胆提出假如，假如各个外围的服务和存储都可能挂掉，依据假如去制订对应的容灾和解决方案。比方应答机房停电、网络故障，咱们能够做跨机房跨网络部署，这样即便电信光纤被挖断，服务还能放弃根本失常。另外要做好应急预案，把所有要害节点故障的假如对应的解决计划全副做成开关模式，防止在流动当天还要去跑日志和写解决脚本。 针对监控与对账，咱们必须建设多维度的监控体系，在流量峰值的压力下局部监控可能会呈现问题，多维度的监控能帮忙咱们探知零碎的实在状态，有助于咱们采取正确的应答措施。对于对账能力，如果发货失败了，当天值班的同学须要看跑线上日志和写补发脚本，那么半个小时、一个小时就过来了。值班同学通常都比较忙，所以最好的形式就是提开发好，当天如果发现问题，它就能主动去检测失败的日志并且进行补发。 大规模流量流动的实际案例后面讲了比拟多对于大流量流动的架构筹备工作，这一部分咱们讲讲具体的实际案例。第一个案例是某年某业务的春节红包流动，只管后期做了十分度多的筹备，流动上线时还是呈现了一系列问题，但好在都在咱们的预案之内，算是有惊无险。 预先咱们也进行了反思回顾，呈现那么多问题是为什么？首先就是没有遵循3倍扩容准则，再比如说链路梳理没有到位，上面就是咱们的一些总结内容。 依据咱们的过往教训，最危险的流动反而不是大型流动，因为为了确保大流动的顺利开展，公司会抽调很多骨干参加进来，即便呈现问题通常也是小问题。而中小型流动的流量不会太大，没有什么威逼。最容易出问题的恰好是那些中大型流动，接下来具体讲讲另一个中大型流动案例。在某游戏的年度流动我的项目中，咱们做了一些评估和筹备工作，但不可能看待每个流动都像看待春节红包流动那样。过后咱们派了2集体看了一下，各个线上模块团队负责压测各自的模块，都反馈没问题，流动就上线了。流动当天凌晨我被电话叫醒，零碎出问题了，过后有很多用户曾经无奈加入流动了。 过后的Web零碎是基于PHP和Apache，采纳Apache的多过程模式（perfork）。一个后端服务响应工夫个别在几十毫秒，一个worker过程1秒钟应该能够解决十多个申请，但到了顶峰期间，在大流量的压力下，后端服务的响应工夫从几十毫秒飙到了几百毫秒甚至是1秒。这个时候1个wrker过程1秒钟只能解决1个申请，无奈及时处理最终导致申请沉积。咱们趁着玩家在凌晨的休息时间去做了不少补救工作，包含降级及其他的动作，通过一个通宵的致力，用户能够失常进入流动了，但还没有齐全解决。第二天下午咱们又到公司持续，48小时连轴转从新发版后终于解决了问题，安稳度过了那次流动危机。这种大中型的流动最容易出问题，因为通常咱们不会给与足够的关注度。 总结一下大流量流动后期须要做的一些总体的教训和流程，首先是绝对正当的评估&梳理计划，再进行架构上的优化和调整，最初就是整顿紧急预案。 我间断加入过三年春节红包流动流动，每一年都提前大略一个多月招集外围骨干来出具计划，每年都做很多筹备，可每年都有一些小问题。反思为什么投入大量人力物力资源，零碎还是出问题？究其实质，我感觉次要是三个方面：第一很多时候测试环境、甚至性能环境无奈代表实在的生产环境；第二，各个部分高可用不代表整体高可用；第三是零碎的成长性，简单的业务零碎在继续迭代、收缩，明天没性能问题，不代表今天没问题。 想让生产环境的性能取得保障，不出问题，从这个点登程咱们有一个明确的摸索方向——常态化的生产环境性能测试。大量的筹备工作都是为了保障线上环境可能达到肯定的性能指标，所以最好的形式就是间接在生产环境去做最实在的性能测试。比方选在凌晨两三点钟没有什么业务流量的时候执行性能测试，看零碎能不能达到我的指标性能。 那想要真正做到在生产环境施行性能压测有哪些关键点呢？次要有三点，测试流量辨认、测试流量标识的传递以及最重要的测试流量隔离。做生产环境压测防止不了波及一些写入申请，如果把大量虚伪的数据写入生产环境数据库必定不适合，后续还要去做数据清理。所以只有后面提到的三个关键点可能解决，在线性能测试就能实现。 这是咱们基于JAVA做的一套性能测试平台，因为咱们能够在JAVA有两头字节码这一层做加强，通过agent探针在不侵入用户业务代码状况上来做一些管制。正式流量放弃不变，咱们会对压测的流量做一些管制。举个例子，比如说零碎有一个mysql数据库，咱们就会在线上建一套影子数据库，跟原来数据库一样，只是数据可能少一点或是空的（只有表构造）。当有流量进来时agent就会进行辨认，辨认出压测流量时，agent会把连贯的数据库替换成影子数据库。无论是音讯队列还是Cache存储都能够用相似的形式来实现。另外咱们还做了一个货色叫挡板，它是干嘛的呢？假如有个第三方的短信接口，业务流量去调用这个接口是能够的，但测试流量间接去调用必定是不行的，因为第三方不可能配合你做一个影子发短信的零碎。挡板的作用就是通过agent来实现一个mock，在调用第三方接口时间接返回，避免测试流量调用第三方接口时对生产数据产生影响。 这是数列的生产环境全链路性能测试的计划，在此基础上咱们还研发了链路主动梳理的性能。对于简单业务以及简单零碎，它内含很多个微服务节点和业务节点，没有人能齐全搞清楚整个链路的所有的环节。咱们能够通过agent探针，利用技术手段搞清零碎链路流向，帮助进行链路梳理，与业务相结合就能梳理出业务调用的链路。联合E2E巡检平台不仅可能晓得这条链路的性能如何，还能定位到具体环节的具体性能瓶颈，不便及时精确地进行性能调优，梳理业务链路视图，最终实现零碎的高可用指标。 想要进一步进群交换或者对产品感兴趣想要申请试用，能够扫码增加【小树】企业微信，还会不定期分享干货内容哦～ 数列科技成立于2016年，是国内当先的零碎高可用专家，由多名阿里巴巴资深专家发动成立。旨在以解决微服务架构治理及性能问题为外围，为企业零碎的性能和稳定性提供全方位保障，构建了笼罩全链路压测、E2E巡检、故障演练等多模块的残缺产品矩阵，致力于帮忙企业将零碎可用性晋升至99.99%。

本文转自@TWT社区，【作者】杨建旭。 【摘要】本文介绍在有业务压力下的存储高可用切换测试，从中发现的影响切换工夫的问题，以及对问题的剖析。 个别状况下，咱们压力测试关注的都是交易系统吞吐量、业务的响应工夫，批处理零碎的解决工夫，然而咱们很少关注某一个计算机部件的故障而导致的高可用切换过程的业务中断工夫，以及切换过程中的性能体现。这其实也是咱们性能测试所关注的，因为在有压力和没有压力的状况下，这个业务中断的工夫是不一样的；切换过程和失常处理过程中零碎性能的体现也是不一样的。 本文介绍在有业务压力下的存储高可用切换测试，从中发现的影响切换工夫的问题，以及对问题的剖析。 一、 存储服务器高可用的类型存储的高可用类型很多，先来介绍一种存储的高可用类型 GAD 连贯备存储也相似，但不管利用指向主存储还是备存储，先落盘的都是主存储。然而这些不是本文的要害。 二、 单台故障后会产生什么？当主存储故障，备存储会主动切换为主存储（扭转了身份），并且利用会通过多路径软件辨认出主存储故障（当达到超时工夫），切换到备存储。 当备存储故障，利用也会通过多路径软件辨认出备存储故障，把 IO 门路切换到主存储。 三、 测试后果在这个测试当中，咱们除了关注咱们通常所关注的肯定吞吐量状况下业务响应工夫、数据库 IO 响应工夫、磁盘 IO 响应工夫，咱们还会关注单台存储故障后的切换时长和切换过程的性能体现。 上面是带着压力，存储高可用切换过程中的 CPU 利用率的图。 在主存储故障后大概 40 多秒后，仿佛利用发现了主存储故障，之后切到备存储做业务，但仿佛直到 3 分钟之后，业务量才齐全起来，两头 40 秒 ~3 分钟的过程中，有毛刺状 CPU 。但即便是吞吐量复原之后，依然偶然有吞吐量忽然降落的状况。 四、 问题剖析一般来说，存储高可用的过程 40 秒就足够了，咱们做了 LVM 模式高可用的测试，确实在 40 秒实现存储切换，那么： 1、为什么 GAD 切换工夫比 LVM 长？首先从原理上讲， LVM 模式是这样的 都是主存储，一个存储坏了，只有利用本人发现了，多路径软件间接切到另一个存储就功败垂成了。 而 GAD 的主存储出了故障，岂但利用要把门路切换到备存储，并且，存储自身要做调整。即备存储要把本人的身份变成主存储。为什么要变身份呢？因为，在一个存储故障的状况下，写 IO 的逻辑也和平时不一样。仲裁要通知备存储，你当初变成主了，而且是没有备机的主机。 这么一来，就会多一些工夫上的耽误。当然，这个耽误也本不该这么长（ 2 分钟） 2、 为什么有 CPU 的毛刺， 3 分钟之后才完全恢复这是这个 CPU 图中的疑点。明明故障产生 40 秒之后，曾经在备存储上看到了有 IO 读写，并且，业务零碎也开始做业务了，为什么 CPU 忽高忽低呢？业务的吞吐量也没有齐全起来，直到 3 分钟当前。 ...

小 T 导读：常常有用户在 TDengine 的 GitHub 上递交标签为「help wanted」的 Issue。这些 Issue 大都不是 Bug，只是因为不相熟或者不理解 TDengine 的机制而让用户感到困惑的应用问题。咱们会定期分享一些具备共性的 Issue，心愿大家能从中有所播种。本期分享「实现 TDengine 客户端高可用的解决办法」。 原文首发于「GitHub问题精选」TDengine 如何做到客户端高可用？ 最近，在 TDengine 的 GitHub 上咱们遇到了两位集群用户，他们都提到了TDengine客户端高可用的问题： 用户独特的疑难阐明了这个问题是很有代表性的，所以咱们精选进去，心愿能够从用户的角度对产品的优化造成更多的思考。 咱们将这个问题细化一下就是「在 TDengine 客户端应用 taos -h FQDN -P port 连贯集群的过程中，如果客户端所在节点呈现了宕机，本次连贯是不是就会以失败而告终呢？」答案显然是「是的」。 一位用户和咱们示意：TDengine服务端的高可用都做好了，客户端的高可用却没有跟上，切实是太惋惜了。 事实上，连贯失败不假。但其实 TDengine 并不激励用户应用如上的形式连贯集群。为什么这么说呢，咱们来给大家认真梳理一下。 假如一个用户在连贯 TDengine 集群时，他所连贯的节点挂掉了。在这一刻，咱们会须要两种高可用：一是来自服务端，二是来自客户端。 服务端的高可用，指的是当 TDengine 的节点产生故障且超出规定工夫无响应时，集群立即产生零碎报警信息并踢掉损坏节点，同时触发主动的负载平衡，零碎主动把该数据节点上的数据转移到其余数据节点。 而客户端的高可用，指的是 TDengine 在连贯失败时立刻指定其余可用的数据库服务端供客户端持续连贯。 重点来了，TDengine 能实现这样的性能吗？当然能够。 上面就是咱们并不倡议大家在 url 或者 taos 等连贯形式中指定 FQDN，而是应用客户端配置文件 taos.cfg 去连贯集群的真正起因。后者，客户端会主动连贯咱们配置好的参数 firstEP 节点，如果在连贯霎时这个节点挂掉了，则会持续连贯参数 secondEP 所代表的节点。 值得注意的是，只有这两个节点有一个连贯胜利，客户端的应用就曾经没有问题了。因为 firstEP 和 secondEP 只在连贯的霎时会被应用，它提供的并不是残缺服务列表，而是连贯指标。只有在这短暂的零点几秒内集群连贯胜利，该节点就会主动获取治理节点的地址信息。而只在连贯的这一瞬间，两个节点同时宕机掉的可能性是极低的。后续，即便 firstEP 和 secondEP 两个节点全都坏掉，只有集群能够对外服务的根本规定没有被突破，就依然能够失常应用。这就是 TDengine 保护客户端高可用的办法。 ...

DolphinDB提供数据、元数据以及客户端的高可用计划，使得数据库节点产生故障时，数据库仍然能够失常运作，保障业务不会中断。 与其它时序数据库不同的是，DolphinDB的高可用确保强一致性。 1. 概述DolphinDB database采纳多正本机制，雷同数据块的正本存储在不同的数据节点上。即便集群中某个或多个数据节点宕机，只有集群中还有至多1个正本可用，那么数据库就能够提供服务。 元数据存储在管制节点上。为了保障元数据的高可用，DolphinDB采纳Raft协定，通过构建多个管制节点来组成一个Raft组，只有宕机的管制节点少于半数，集群依然可提供服务。 DolphinDB API提供了主动重连和切换机制，如果以后连贯的数据节点宕机，API会尝试重连，若重连失败就会主动切换连贯到其余数据节点执行工作。切换数据节点对用户是通明的，用户不会感知到以后连贯的节点曾经切换。 如果要应用高可用性能，请先部署DolphinDB集群。高可用性能仅在集群中反对，在单实例中不反对。集群部署请参考多服务器集群部署教程。 数据高可用为了保证数据的平安和高可用，DolphinDB反对在不同的服务器上存储多个数据正本，并且数据正本之间放弃强一致性。即便一台机器上的数据损坏，也能够通过拜访其余机器上的正本数据来保障数据服务不中断。 正本的个数可由在controller.cfg中的dfsReplicationFactor参数来设定。例如，把正本数设置为2： dfsReplicationFactor=2默认状况下，DolphinDB容许雷同数据块的正本散布在同一台机器上。为了保证数据高可用，须要把雷同数据块的正本散布在不同的机器上。可在controller.cfg增加以下配置项： dfsReplicaReliabilityLevel=1上面通过一个例子直观地解释DolphinDB的数据高可用。首先，在集群的数据节点上执行以下脚本以创立数据库： n=1000000date=rand(2018.08.01..2018.08.03,n)sym=rand(`AAPL`MS`C`YHOO,n)qty=rand(1..1000,n)price=rand(100.0,n)t=table(date,sym,qty,price)if(existsDatabase("dfs://db1")){ dropDatabase("dfs://db1")}db=database("dfs://db1",VALUE,2018.08.01..2018.08.03)trades=db.createPartitionedTable(t,`trades,`date).append!(t)分布式表trades被分成3个分区，每个日期示意一个分区。DolphinDB的Web集群治理界面提供了DFS Explorer，能够不便地查看数据分布状况。trades表各个分区的散布状况如下图所示： 以20180801这个分区为例，Sites列显示，date=2018.08.01的数据分布在18104datanode和18103datanode上。即便18104datanode宕机，只有18103datanode失常，用户依然对date=2018.08.01的数据进行读写操作。 元数据高可用数据存储时会产生元数据，例如每个数据块存储在哪些数据节点上的哪个地位等信息。如果元数据不能应用，即便数据块残缺，零碎也无奈失常拜访数据。 元数据寄存在管制节点。咱们能够在一个集群中部署多个管制节点，通过元数据冗余来保障元数据服务不中断。一个集群中的所有管制节点组成一个Raft组，Raft组中只有一个Leader，其余都是Follower，Leader和Follower上的元数据放弃强一致性。数据节点只能和Leader进行交互。如果以后Leader不可用，零碎会立刻选举出新的Leader来提供元数据服务。Raft组可能容忍小于半数的管制节点宕机，例如蕴含三个管制节点的集群，能够容忍一个管制节点呈现故障；蕴含五个管制节点的集群，能够容忍两个管制节点呈现故障。要设置元数据高可用，管制节点的数量至多为3个，同时须要设置数据高可用，即正本数必须大于1。 通过以下例子来介绍如何要为一个已有的集群启动元数据高可用。假如已有集群的管制节点位于P1机器上，当初要减少两个管制节点，别离部署在P2、P3机器上。它们的内网地址如下： P1: 10.1.1.1P2: 10.1.1.3P3: 10.1.1.5(1) 批改已有管制节点的配置文件 在P1的controller.cfg文件增加下列参数：dfsReplicationFactor=2, dfsReplicaReliabilityLevel=1, dfsHAMode=Raft。批改后的controller.cfg如下： localSite=10.1.1.1:8900:controller1dfsReplicationFactor=2dfsReplicaReliabilityLevel=1dfsHAMode=Raft(2) 部署两个新的管制节点 别离在P2、P3下载DolphinDB服务器程序包，并解压，例如解压到/DolphinDB目录。 在/DolphinDB/server目录下创立config目录。在config目录下创立controller.cfg文件，填写以下内容： P2 localSite=10.1.1.3:8900:controller2dfsReplicationFactor=2dfsReplicaReliabilityLevel=1dfsHAMode=RaftP3 localSite=10.1.1.5:8900:controller3dfsReplicationFactor=2dfsReplicaReliabilityLevel=1dfsHAMode=Raft(3) 批改已有代理节点的配置文件 在已有的agent.cfg文件中增加sites参数，它示意本机器代理节点和所有管制节点的局域网信息，代理节点信息必须在所有管制节点信息之前。例如，P1的agent.cfg批改后的内容如下： localSite=10.1.1.1:8901:agent1controllerSite=10.1.1.1:8900:controller1sites=10.1.1.1:8901:agent1:agent,10.1.1.1:8900:controller1:controller,10.1.1.3:8900:controller2:controller,10.1.1.5:8900:controller3:controller如果有多个代理节点，每个代理节点的配置文件都须要批改。 (4) 批改已有管制节点的集群成员配置文件 在P1的cluster.nodes上减少管制节点的局域网信息。例如，P1的cluster.nodes批改后的内容如下： localSite,mode10.1.1.1:8900:controller1,controller10.1.1.2:8900:controller2,controller10.1.1.3:8900:controller3,controller10.1.1.1:8901:agent1,agent10.1.1.1:8911:datanode1,datanode10.1.1.1:8912:datanode2,datanode(5) 为新的管制节点增加集群成员配置文件和节点配置文件 管制节点的启动须要cluster.nodes和cluster.cfg。把P1上的cluster.nodes和cluster.cfg复制到P2和P3的config目录。 (6) 启动高可用集群 启动管制节点别离在每个管制节点所在机器上执行以下命令： nohup ./dolphindb -console 0 -mode controller -home data -config config/controller.cfg -clusterConfig config/cluster.cfg -logFile log/controller.log -nodesFile config/cluster.nodes &启动代理节点在部署了代理节点的机器上执行以下命令： nohup ./dolphindb -console 0 -mode agent -home data -config config/agent.cfg -logFile log/agent.log &启动、敞开数据节点以及批改节点配置只能在Leader的集群治理界面操作。 ...

作者 | 远跖、瀚阑起源|阿里巴巴云原生公众号 前言因为外部环境的简单以及硬件的不牢靠，互联网服务的高可用面临着微小的挑战，因为断网、断电等事变导致的各大互联网公司服务不可用的案例也不在少数。业务不可用，小到带来经济损失影响企业口碑，大到微信、支付宝这些国民级利用，影响国计民生。面对难以避免的天下大乱，容灾架构的建设就成为了数字化企业的迫切诉求。 2020 年 12 月份，阿里云利用高可用产品 AHAS（Application High Availability Service）公布了新的功能模块 AHAS-MSHA，它是在阿⾥巴巴电商业务环境演进进去的多活容灾架构解决⽅案。本篇文章咱们首先介绍容灾畛域的几个重要概念，而后将联合一个的电商微服务案例，分享一下如何基于 AHAS 的异地多活能力（AHAS-MSHA）和混沌工程能力（AHAS-Chaos）帮忙业务实现容灾架构的高可用实际。 容灾与评估指标1. 什么是容灾？容灾（Disaster Tolerance）是指在相隔较远的异地，建设两套或多套性能雷同的零碎，零碎之间能够互相进行衰弱状态监督和性能切换，当一处零碎因意外（如火灾、洪水、地震、人为蓄意毁坏等）进行工作时，整个利用零碎能够切换到另一处，使得该零碎性能能够持续失常工作。 2. 容灾能力如何评估？容灾零碎次要为了在劫难产生时业务不产生中断，那么容灾能力如何评估和量化呢？这里须要介绍一下业界通常采纳的容灾能力评估指标： RPO（Recovery Point Objective）即数据恢复点指标，以工夫为单位，即在劫难产生时，零碎和数据必须复原的工夫点要求。RPO 标记零碎可能容忍的最大数据失落量，零碎容忍失落的数据量越小，RPO 的值越小。 RTO（Recovery Time Objective）即复原工夫指标，以工夫为单位，即在劫难产生后，信息系统或业务性能从进行到必须复原的工夫要求。RTO 标记零碎可能容忍的服务进行的最长工夫，零碎服务的紧迫性要求越高，RTO 的值越小。 AHAS-MSHA1. 介绍MSHA（Multi-Site High Availability）是一个多活容灾架构解决⽅案（解决方案=技术产品+咨询服务+生态搭档），能够将业务复原和故障复原解耦，反对故障场景下业务的疾速复原，助⼒企业的容灾稳定性建设。 1）产品架构MSHA 采纳异地多活的容灾架构，核心思想是 “隔离的冗余”，咱们将各个冗余的逻辑数据中心称为单元，MSHA 做到了业务流量在单元内关闭，单元之间隔离，把故障爆炸半径管制在一个单元内，不仅能解决容灾问题，晋升业务连续性，并且能实现容量的扩大。 2）支流容灾架构比照 2. 性能个性故障疾速复原秉承先复原，再定位的准则，MSHA 提供了容灾切流能力，在数据保护的前提下让业务复原工夫和故障复原工夫解耦合，保障业务连续性。 容量异地扩大业务⾼速倒退，受限于单地无限资源，也存在数据库瓶颈等问题。应用 MSHA 能够在其它地区、机房疾速扩建业务单元，实现疾速程度扩容的目标。 流量调配与纠错MSHA 提供了从接入层到应用层的层层流量纠错和校验，将不合乎流量路由规定的调用从新转发，将故障爆炸半径可管制在一个单元内。 数据防脏写多单元写数据可能造成脏写笼罩的问题，MSHA 提供流量打入谬误单元时的禁写爱护，以及切流数据同步延时期间的禁写/禁更新爱护。 3. 利用场景MSHA 可实用于以下典型业务场景的多活容灾架构建设： 读多写少型业务 业务场景：典型的业务场景就是资讯、导购类服务（如商品浏览、新闻资讯）。数据特点：读多写少型业务，外围是读业务，可能承受写业务的临时不可用。流水单据型业务 业务场景：典型的业务场景就是电商交易、账单流水类服务（如订单、通话记录等）。数据特点：数据能够按肯定的维度进行分片且能承受数据的最终统一。业务容灾实际上面咱们通过一个电商微服务案例，来介绍不同场景的容灾架构建设案例。 1. 电商业务背景1）业务利用frontend，入口 WEB 利用，负责和用户交互cartservice，购物车利用。记录用户的购物车数据，应用自建的 Redisproductservice，商品利用。提供商品、库存服务，应用 RDS MySQLcheckoutservice，下单利用。将购物车中的商品生成购买订单，应用 RDS MySQL2）技术栈SpringBootRPC 框架：SpringCloud，注册核心应用自建的 Eureka3）电商利用架构 1.0电商业务初期，跟很多互联网企业一样，没有思考容灾问题，只在单地区进行了部署。 ...