高可用

一、前言高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在零碎架构设计中必须思考的因素之一。明天咱们就来聊一聊三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电商业务初期，跟很多互联网企业一样，没有思考容灾问题，只在单地区进行了部署。 ...

2017年开始阿里HBase走向公有云，我们有计划的在逐步将阿里内部的高可用技术提供给外部客户，目前已经上线了同城主备，将作为我们后续高可用能力发展的一个基础平台。本文分四个部分回顾阿里HBase在高可用方面的发展：大集群、MTTF&MTTR、容灾、极致体验，希望能给大家带来一些共鸣和思考。 大集群一个业务一个集群在初期很简便，但随着业务增多会加重运维负担，更重要的是无法有效利用资源。首先每一个集群都要有Zookeeper、Master、NameNode这三种角色，固定的消耗3台机器。其次有些业务重计算轻存储，有些业务重存储轻计算，分离模式无法削峰填谷。因此从2013年开始阿里HBase就走向了大集群模式，单集群节点规模达到700+。 隔离性是大集群的关键难题。保障A业务异常流量不会冲击到B业务，是非常重要的能力，否则用户可能拒绝大集群模式。阿里HBase引入了分组概念“group”，其核心思想为：共享存储、隔离计算 如上图所示，一个集群内部被划分成多个分组，一个分组至少包含一台服务器，一个服务器同一时间只能属于一个分组，但是允许服务器在分组之间进行转移，也就是分组本身是可以扩容和缩容的。一张表只能部署在一个分组上，可以转移表到其它的分组。可以看到，表T1读写经过的RegionServer和表T2读写经过的RegionServer是完全隔离的，因此在CPU、内存上都物理隔离，但是下层使用的HDFS文件系统是共享的，因此多个业务可以共享一个大的存储池子，充分提升存储利用率。开源社区在HBase2.0版本上引入了RegionServerGroup。 坏盘对共享存储的冲击：由于HDFS机制上的特点，每一个Block的写入会随机选择3个节点作为Pipeline，如果某一台机器出现了坏盘，那么这个坏盘可能出现在多个Pipeline中，造成单点故障全局抖动。现实场景中就是一块盘坏，同一时间影响到几十个客户给你发信息打电话！特别如果慢盘、坏盘不及时处理，最终可能导致写入阻塞。阿里HBase目前规模在1万+台机器，每周大概有22次磁盘损坏问题。我们在解决这个问题上做了两件事，第一是缩短影响时间，对慢盘、坏盘进行监控报警，提供自动化处理平台。第二是在软件上规避单点坏盘对系统的影响，在写HDFS的时候并发的写三个副本，只要两个副本成功就算成功，如果第三个副本超时则将其放弃。另外如果系统发现写WAL异常（副本数少于3）会自动滚动产生一个新的日志文件（重新选择pipeline，大概率规避坏点）。最后HDFS自身在高版本也具备识别坏盘和自动剔除的能力。 客户端连接对Zookeeper的冲击：客户端访问hbase会和Zookeeper建立长连接，HBase自身的RegionServer也会和Zookeeper建立长连接。大集群意味着大量业务，大量客户端的链接，在异常情况下客户端的链接过多会影响RegionServer与Zookeeper的心跳，导致宕机。我们在这里的应对首先是对单个IP的链接数进行了限制，其次提供了一种分离客户端与服务端链接的方案 HBASE-20159 MTTF&MTTR稳定性是生命线，随着阿里业务的发展，HBase逐步扩大在线场景的支持，对稳定性的要求是一年更比一年高。衡量系统可靠性的常用指标是MTTF（平均失效时间）和MTTR（平均恢复时间） MTTF（mean time to failure）造成系统失效的来源有：硬件失效，比如坏盘、网卡损坏、机器宕机等自身缺陷，一般指程序自身的bug或者性能瓶颈运维故障，由于不合理的操作导致的故障服务过载，突发热点、超大的对象、过滤大量数据的请求依赖失效，依赖的HDFS、Zookeeper组件出现不可用导致HBase进程退出 下面我介绍一下阿里云HBase在稳定性上遇到的几个代表性问题：（注：慢盘、坏盘的问题已经在大集群一节中涉及，这里不再重复） 周期性的FGC导致进程退出在支持菜鸟物流详情业务的时候，我们发现机器大概每隔两个月就会abort一次，因为内存碎片化问题导致Promotion Fail，进而引发FGC。由于我们使用的内存规格比较大，所以一次FGC的停顿时间超过了与Zookeeper的心跳，导致ZK session expired，HBase进程自杀。我们定位问题是由于BlockCache引起的，由于编码压缩的存在，内存中的block大小是不一致的，缓存的换入换出行为会逐步的切割内存为非常小的碎片。我们开发了BucketCache，很好的解决了内存碎片化的问题，然后进一步发展了SharedBucketCache，使得从BlockCache里面反序列化出来的对象可以被共享复用，减少运行时对象的创建，从而彻底的解决了FGC的问题。 写入HDFS失败导致进程退出HBase依赖俩大外部组件，Zookeeper和HDFS。Zookeeper从架构设计上就是高可用的，HDFS也支持HA的部署模式。当我们假设一个组件是可靠的，然后基于这个假设去写代码，就会产生隐患。因为这个“可靠的”组件会失效，HBase在处理这种异常时非常暴力，立即执行自杀（因为发生了不可能的事情），寄希望于通过Failover来转移恢复。有时HDFS可能只是暂时的不可用，比如部分Block没有上报而进入保护模式，短暂的网络抖动等，如果HBase因此大面积重启，会把本来10分钟的影响扩大到小时级别。我们在这个问题上的方案是优化异常处理，对于可以规避的问题直接处理掉，对于无法规避的异常进行重试&等待。 并发大查询导致机器停摆HBase的大查询，通常指那些带有Filter的Scan，在RegionServer端读取和过滤大量的数据块。如果读取的数据经常不在缓存，则很容易造成IO过载；如果读取的数据大多在缓存中，则很容易因为解压、序列化等操作造成CPU过载；总之当有几十个这样的大请求并发的在服务器端执行时，服务器load会迅速飙升，系统响应变慢甚至表现的像卡住了。这里我们研发了大请求的监控和限制，当一个请求消耗资源超过一定阈值就会被标记为大请求，日志会记录。一个服务器允许的并发大请求存在上限，如果超过这个上限，后来的大请求就会被限速。如果一个请求在服务器上运行了很久都没有结束，但客户端已经判断超时，那么系统会主动中断掉这个大请求。该功能的上线解决了支付宝账单系统因为热点查询而导致的性能抖动问题。 大分区Split缓慢在线上我们偶尔会遇到某个分区的数量在几十GB到几个TB，一般都是由于分区不合理，然后又在短时间内灌入了大量的数据。这种分区不但数据量大，还经常文件数量超级多，当有读落在这个分区时，一定会是一个大请求，如果不及时分裂成更小的分区就会造成严重影响。这个分裂的过程非常慢，HBase只能从1个分区分裂为2个分区，并且要等待执行一轮Compaction才能进行下一轮分裂。假设分区大小1TB，那么分裂成小于10GB的128个分区需要分裂7轮，每一轮要执行一次Compaction（读取1TB数据，写出1TB数据），而且一个分区的Compaction只能由一台机器执行，所以第一轮最多只有2台机器参与，第二轮4台，第三轮8台。。。，并且实际中需要人为干预balance。整个过程做下来超过10小时，这还是假设没有新数据写入，系统负载正常。面对这个问题我们设计了“级联分裂”，可以不执行Compaction就进入下一次分裂，先快速的把分区拆分完成，然后一把执行Compaction。 前面讲的都是点，关于如何解决某个顽疾。导致系统失效的情况是多种多样的，特别一次故障中可能交叉着多个问题，排查起来异常困难。现代医学指出医院应当更多投入预防而不是治疗，加强体检，鼓励早就医。早一步也许就是个感冒，晚一步也许就变成了癌症。这也适用于分布式系统，因为系统的复杂性和自愈能力，一些小的问题不会立即造成不可用，比如内存泄漏、Compaction积压、队列积压等，但终将在某一刻引发雪崩。应对这种问题，我们提出了“健康诊断”系统，用来预警那些暂时还没有使系统失效，但明显超过正常阈值的指标。“健康诊断”系统帮助我们拦截了大量的异常case，也在不停的演进其诊断智能。 MTTR（mean time to repair）百密终有一疏，系统总是会失效，特别的像宕机这种Case是低概率但一定会发生的事件。我们要做的是去容忍，降低影响面，加速恢复时间。HBase是一个可自愈的系统，单个节点宕机触发Failover，由存活的其它节点来接管分区服务，在分区对外服务之前，必须首先通过回放日志来保证数据读写一致性。整个过程主要包括Split Log、Assign Region、Replay Log三个步骤。hbase的计算节点是0冗余，所以一个节点宕机，其内存中的状态必须全部回放，这个内存一般可以认为在10GB~20GB左右。我们假设整个集群的数据回放能力是 R GB/s，单个节点宕机需要恢复 M GB的数据，那么宕机N个节点就需要 M * N / R 秒，这里表达的一个信息是：如果R不足够大，那么宕机越多，恢复时间越不可控，那么影响R的因素就至关重要，在Split Log、Assign Region、Replay Log三个过程中，通常Split Log、Assign Region的扩展性存在问题，核心在于其依赖单点。Split Log是把WAL文件按分区拆分成小的文件，这个过程中需要创建大量的新文件，这个工作只能由一台NameNode来完成，并且其效率也并不高。Assign Region是由HBase Master来管理，同样是一个单点。阿里HBase在Failover方面的核心优化是采用了全新的MTTR2架构，取消了Split Log这一步骤，在Assign Region上也做了优先Meta分区、Bulk Assign、超时优化等多项优化措施，相比社区的Failover效率提升200%以上 从客户角度看故障，是2分钟的流量跌零可怕还是10分钟的流量下降5%可怕？我想可能是前者。由于客户端的线程池资源有限，HBase的单机宕机恢复过程可能造成业务侧的流量大跌，因为线程都阻塞在访问异常机器上了，2%的机器不可用造成业务流量下跌90%是很难接受的。我们在客户端开发了一种Fast Fail的机制，可以主动发现异常服务器，并快速拒绝发往这个服务器的请求，从而释放线程资源，不影响其它分区服务器的访问。项目名称叫做DeadServerDetective 容灾容灾是重大事故下的求生机制，比如地震、海啸等自然灾害造成毁灭性打击，比如软件变更等造成完全不可控的恢复时间，比如断网造成服务瘫痪、恢复时间未知。从现实经验来看，自然灾害在一个人的一生中都难遇到，断网一般是一个年级别的事件，而软件变更引发的问题可能是月级别的。软件变更是对运维能力、内核能力、测试能力等全方位的考验，变更过程的操作可能出错，变更的新版本可能存在未知Bug。另一个方面为了不断满足业务的需求又需要加速内核迭代，产生更多的变更。 容灾的本质是基于隔离的冗余，要求在资源层面物理隔离、软件层面版本隔离、运维层面操作隔离等，冗余的服务之间保持最小的关联性，在灾难发生时至少有一个副本存活。阿里HBase在几年前开始推进同城主备、异地多活，目前99%的集群至少有一个备集群，主备集群是HBase可以支持在线业务的一个强保障。主备模式下的两个核心问题是数据复制和流量切换 数据复制选择什么样的复制方式，是同步复制还是异步复制，是否要保序？主要取决于业务对系统的需求，有些要求强一致，有些要求session一致，有些可以接受最终一致。占在HBase的角度上，我们服务的大量业务在灾难场景下是可以接受最终一致性的（我们也研发了同步复制机制，但只有极少的场景），因此本文主要专注在异步复制的讨论上。很长一段时间我们采用社区的异步复制机制（HBase Replication），这是HBase内置的同步机制。 同步延迟的根因定位是第一个难题，因为同步链路涉及发送方、通道、接受方3个部分，排查起来有难度。我们增强了同步相关的监控和报警。 热点容易引发同步延迟是第二个难题。HBase Replication采用推的方式进行复制，读取WAL日志然后进行转发，发送线程和HBase写入引擎是在同一台RegionServer的同一个进程里。当某台RegionServer写入热点时，就需要更多的发送能力，但写入热点本身就挤占了更多的系统资源，写入和同步资源争抢。阿里HBase做了两个方面的优化，第一提高同步性能，减少单位MB同步的资源消耗；第二研发了远程消耗器，使其它空闲的机器可以协助热点机器同步日志。 资源需求、迭代方式的不匹配是第三个难题。数据复制本身是不需要磁盘IO的，只消耗带宽和CPU，而HBase对磁盘IO有重要依赖；数据复制的worker本质上是无状态的，重启不是问题，可以断点续传，而HBase是有状态的，必须先转移分区再重启，否则会触发Failover。一个轻量级的同步组件和重量级的存储引擎强耦合在一起，同步组件的每一次迭代升级必须同时重启HBase。一个重启就可以解决的同步问题，因为同时要重启hbase而影响线上读写。一个扩容CPU或者总带宽的问题被放大到要扩容hbase整体。 综上所述，阿里HBase最终将同步组件剥离了出来作为一个独立的服务来建设，解决了热点和耦合的问题，在云上这一服务叫做BDS Replication。随着异地多活的发展，集群之间的数据同步关系开始变得复杂，为此我们开发了一个关于拓扑关系和链路同步延迟的监控，并且在类环形的拓扑关系中优化了数据的重复发送问题。 流量切换在具备主备集群的前提下，灾难期间需要快速的把业务流量切换到备份集群。阿里HBase改造了HBase客户端，流量的切换发生在客户端内部，通过高可用的通道将切换命令发送给客户端，客户端会关闭旧的链接，打开与备集群的链接，然后重试请求。 切换瞬间对Meta服务的冲击：hbase客户端首次访问一个分区前需要请求Meta服务来获取分区的地址，切换瞬间所有客户端并发的访问Meta服务，现实中并发可能在几十万甚至更多造成服务过载，请求超时后客户端又再次重试，造成服务器一直做无用功，切换一直无法成功。针对这个问题我们改造了Meta表的缓存机制，极大地提高了Meta表的吞吐能力，可以应对百万级别的请求。同时在运维上隔离了Meta分区与数据分区，防止相互影响。 ...

10月30日，以“地理智慧 深度进化”为主题的2019 GIS软件技术大会（简称GTC 2019）在北京国际会议中心开幕。超图联合阿里云在主论坛完成产品合作发布。超图软件SuperMap GIS与阿里巴巴新一代自研云数据库POLARDB实现 “引擎级”深度对接，构建了自治、弹性、高可用的云原生时空数据管理平台联合解决方案，推出了业界首个“云原生数据库+云原生GIS”的全国产化平台。 阿里云POLARDB POLARDB是阿里云自主研发的国内首个云原生数据库，兼容三种数据库引擎：MySQL、PostgreSQL、Oracle。采用了存储计算分离、软硬一体化等创新设计，满足大规模业务场景上云需求。POLARDB集成Ganos时空引擎，基于属性-时间-空间一体化数据管理、4D移动对象建模以及空间异构计算并行加速构建时空PaaS基础服务。 超图SuperMap GIS SuperMap GIS是北京超图软件股份有限公司研发的，具有完全自主知识产权的大型地理信息系统软件平台。最新推出的SuperMap GIS 10i产品构建形成大数据GIS、人工智能GIS、新型三维GIS、云原生GIS和跨平台GIS“BitCC”五大技术体系。在GIS基础软件领域的中国市场份额稳居第一，用户遍布100多个国家和地区。 1+3+N联合方案 双方联合开发的云原生时空数据管理平台包含1+3+N布局： 1：统一云原生数据库和云原生GIS，完成近600个GIS标准案例库严格测试，获得双方兼容性认证，为用户构建自治、弹性、高可用的云原生时空大数据管理平台提供了强有力的基础软件平台支撑。3：三个重磅特性：a. 支持全空间建模与时空多模，可综合管理地表地下、室内室外、空/天以及时空各类地物对象；b. 独具一库多平台兼容性，平台高度兼容Oracle和PostgreSQL，而GIS空间数据同时兼容Ganos和SuperMap接口访问，已有应用程序均可平滑迁移；c. 双引擎融合性能加速，SuperMap空间数据引擎与Ganos时空引擎通过深度融合获得极致性能提升。N：多形态输出：支持公有云和私有IDC环境部署，其中IDC支持专有云、纯软许可或POLARDB BOX一体机方式输出，充分满足安全合规需求。 不一样：“引擎级”深度对接 为提升GIS平台在千万以及亿级空间记录下的查询分析性能，此次双方平台的对接采用了“计算下推”的深度融合模式。SuperMap GIS平台的空间数据引擎SDX+将空间查询和分析计算直接下推到POLARDB， POLARDB利用空间并行查询优化以及云原生时空引擎Ganos的调度，实现模型的高效映射、空间索引快速过滤以及近百个查询分析的计算下推。经某时空信息云平台实际应用环境验证，较传统商用数据库对接方式有成倍的性能提升。 结语 POLARDB与SuperMap的深度融合，践行了阿里云的被集成战略，顺应了“一横一竖”的平台策略。通过“一竖”完成垂直整合，即SuperMap借助技术集成POLARDB提升了系统整体性能和跨数据库平台兼容性，而POLARDB借助SuperMap拓宽了空间业务能力宽度。一横是通过品牌叠加，共同打造了时空数据服务的平台生态，为联合开拓数字政府、城市大脑、智慧城市/园区/建筑等强GIS数字化领域应用提供了地上地下、室内室外领先、专业的全空间数字化解决方案能力。 “一横一竖”整合，扩大了空间数据服务的“面积”。 阿里云双11领亿元补贴，拼手气抽iPhone 11 Pro、卫衣等好礼，点此参与：http://t.cn/Ai1hLLJT 本文作者：ganos 阅读原文 本文为云栖社区原创内容，未经允许不得转载。

前言概述本文介绍了使用函数计算部署深度学习 AI 推理的最佳实践, 其中包括使用 FUN 工具一键部署安装第三方依赖、一键部署、本地调试以及压测评估， 全方位展现函数计算的开发敏捷特性、自动弹性伸缩能力、免运维和完善的监控设施。 1.1 DEMO 概述 通过上传一个猫或者狗的照片， 识别出这个照片里面的动物是猫还是狗 DEMO 示例效果入口： http://sz.mofangdegisn.cnDEMO 示例工程地址： https://github.com/awesome-fc/cat-dog-classify1.2 解决方案 如上图所示， 当多个用户通过对外提供的 url 访问推理服务时候，每秒的请求几百上千都没有关系， 函数计算平台会自动伸缩， 提供足够的执行实例来响应用户的请求， 同时函数计算提供了完善的监控设施来监控您的函数运行情况。 1.3. Serverless 方案与传统自建服务方案对比1.3.1 卓越的工程效率 自建服务函数计算 Serverless基础设施需要用户采购和管理无开发效率除了必要的业务逻辑开发,需要自己建立相同线上运行环境， 包括相关软件的安装、服务配置、安全更新等一系列问题只需要专注业务逻辑的开发, 配合 FUN 工具一键资源编排和部署学习上手成本可能使用 K8S 或弹性伸缩( ESS )，需要了解更多的产品、名词和参数的意义会编写对应的语言的函数代码即可1.3.2 弹性伸缩免运维 自建服务函数计算 Serverless弹性高可用需要自建负载均衡 (SLB)，弹性伸缩，扩容缩容速度较 FC 慢FC系统固有毫秒级别弹性伸缩，快速实现底层扩容以应对峰值压力，免运维监控报警查询ECS 级别的 metrics提供更细粒度的函数执行情况，每次访问函数执行的 latency 和日志等， 更加完善的报警监控机制1.3.3 更低的成本 函数计算 (FC) 固有自动伸缩和负载均衡功能，用户不需要购买负载均衡 (SLB) 和弹性伸缩。具有明显波峰波谷的用户访问场景(比如只有部分时间段有请求，其他时间甚至没有请求)，选择按需付费，只需为实际使用的计算资源付费。对于明显波峰波谷或者稀疏调用具有低成本优势， 同时还保持了弹性能力，以后业务规模做大以后并没有技术切换成本，同时财务成本增长配合预付费也能保持平滑。部分请求持续平稳的场景下,可以配合预付费解决按需付费较高单价问题。函数计算成本优化最佳实践文档。假设有一个在线计算服务，由于是CPU 密集型计算， 因此在这里我们将平均 CPU 利用率作为核心参考指标对成本，以一个月为周期，10台 C5 ECS 的总计算力为例，总的计算量约为 30% 场景下， 各解决方案 CPU 资源利用率使用情况示意图大致如下: ...

本文首发于 vivo互联网技术 微信公众号 https://mp.weixin.qq.com/s/bV8AhqAjQp4a_iXRfobkCQ 作者简介：郑志彬，毕业于华南理工大学计算机科学与技术（双语班）。先后从事过电子商务、开放平台、移动浏览器、推荐广告和大数据、人工智能等相关开发和架构。目前在vivo智能平台中心从事 AI中台建设以及广告推荐业务。擅长各种业务形态的业务架构、平台化以及各种业务解决方案。博客地址：http://arganzheng.life。背景最近要把原来做的那套集中式日志监控系统进行迁移，原来的实现方案是: Log Agent => Log Server => ElasticSearch => Kibana，其中Log Agent和Log Server之间走的是Thrift RPC，自己实现了一个简单的负载均衡(WRB)。 原来的方案其实运行的挺好的，异步化Agent对应用性能基本没有影响。支持我们这个每天几千万PV的应用一点压力都没有。不过有个缺点就是如果错误日志暴增，Log Server这块处理不过来，会导致消息丢失。当然我们量级没有达到这个程度，而且也是可以通过引入队列缓冲一下处理。不过现在综合考虑，其实直接使用消息队列会更简单。PRC，负载均衡，负载缓冲都内建实现了。另一种方式是直接读取日志，类似于logstash或者flume的方式。不过考虑到灵活性还是决定使用消息队列的方式，反正我们已经部署了Zookeeper。调研了一下，Kafka是最适合做这个数据中转和缓冲的。于是，打算把方案改成: Log Agent => Kafka => ElasticSearch => Kibana。 Kafka介绍一、Kafka基本概念Broker：Kafka集群包含一个或多个服务器，这种服务器被称为broker。Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。Message 消息是Kafka通讯的基本单位，有一个固定长度的消息头和一个可变长度的消息体（payload）构成。在Java客户端中又称之为记录(Record)。消息结构各部分说明如下: CRC32: CRC32校验和，4个字节。magic: Kafka服务程序协议版本号，用于做兼容。1个字节。attributes: 该字段占1字节，其中低两位用来表示压缩方式，第三位表示时间戳类型（0表示LogCreateTime，1表示LogAppendTime），高四位为预留位置，暂无实际意义。timestamp: 消息时间戳，当 magic > 0 时消息头必须包含该字段。8个字节。key-length: 消息key长度，4个字节。key: 消息key实际数据。payload-length: 消息实际数据长度，4个字节。payload: 消息实际数据在实际存储一条消息还包括12字节的额外开销（LogOverhead）: 消息的偏移量: 8字节，类似于消息的Id。消息的总长度: 4字节Partition： Partition（分区）是物理上的概念，每个Topic包含一个或多个Partition。每个分区由一系列有序的不可变的消息组成，是一个有序队列。每个分区在物理上对应为一个文件夹，分区的命名规则为${topicName}-{partitionId}，如__consumer_offsets-0。分区目录下存储的是该分区的日志段，包括日志数据文件和两个索引文件。每条消息被追加到相应的分区中，是顺序写磁盘，因此效率非常高，这也是Kafka高吞吐率的一个重要保证。kafka只能保证一个分区内的消息的有序性，并不能保证跨分区消息的有序性。LogSegment: 日志文件按照大小或者时间滚动切分成一个或者多个日志段(LogSegment)，其中日志段大小由配置项log.segment.bytes指定，默认是1GB。时间长度则是根据log.roll.ms或者log.roll.hours配置项设置；当前活跃的日志段称之为活跃段(activeSegment)。不同于普通的日志文件，Kafka的日志段除了有一个具体的日志文件之外，还有两个辅助的索引文件: 数据文件 数据文件是以 .log 为文件后缀名的消息集文件(FileMessageSet)，用于保存消息实际数据命名规则为：由数据文件的第一条消息偏移量，也称之为基准偏移量(BaseOffset)，左补0构成20位数字字符组成每个数据文件的基准偏移量就是上一个数据文件的LEO+1（第一个数据文件为0）偏移量索引文件 文件名与数据文件相同，但是以.index为后缀名。它的目的是为了快速根据偏移量定位到消息所在的位置。首先Kafka将每个日志段以BaseOffset为key保存到一个ConcurrentSkipListMap跳跃表中，这样在查找指定偏移量的消息时，用二分查找法就能快速定位到消息所在的数据文件和索引文件然后在索引文件中通过二分查找，查找值小于等于指定偏移量的最大偏移量，最后从查找出的最大偏移量处开始顺序扫描数据文件，直到在数据文件中查询到偏移量与指定偏移量相等的消息需要注意的是并不是每条消息都对应有索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引，我们可以通过index.interval.bytes设置索引跨度。时间戳索引文件 Kafka从0.10.1.1版本开始引入了一个基于时间戳的索引文件，文件名与数据文件相同，但是以.timeindex作为后缀。它的作用则是为了解决根据时间戳快速定位消息所在位置。Kafka API提供了一个 offsetsForTimes（Map<TopicPartition, Long> timestampsToSearch）方法，该方法会返回时间戳大于等于待查询时间的第一条消息对应的偏移量和时间戳。这个功能其实挺好用的，假设我们希望从某个时间段开始消费，就可以用offsetsForTimes()方法定位到离这个时间最近的第一条消息的偏移量，然后调用seek(TopicPartition, long offset)方法将消费者偏移量移动过去，然后调用poll()方法长轮询拉取消息。Producer： 负责发布消息到Kafka broker。生产者的一些重要的配置项： request.required.acks: Kafka为生产者提供了三种消息确认机制(ACK)，用于配置broker接到消息后向生产者发送确认信息，以便生产者根据ACK进行相应的处理，该机制通过属性request.required.acks设置，取值可以为0, -1, 1，默认是1。 acks=0: 生产者不需要等待broker返回确认消息，而连续发送消息。acks=1: 生产者需要等待Leader副本已经成功将消息写入日志文件中。这种方式在一定程度上降低了数据丢失的可能性，但仍无法保证数据一定不会丢失。因为没有等待follower副本同步完成。acks=-1: Leader副本和所有的ISR列表中的副本都完成数据存储时才会向生产者发送确认消息。为了保证数据不丢失，需要保证同步的副本至少大于1，通过参数min.insync.replicas设置，当同步副本数不足次配置项时，生产者会抛出异常。但是这种方式同时也影响了生产者发送消息的速度以及吞吐率。message.send.max.retries: 生产者在放弃该消息前进行重试的次数，默认是3次。retry.backoff.ms: 每次重试之前等待的时间，单位是ms，默认是100。queue.buffering.max.ms: 在异步模式下，消息被缓存的最长时间，当到达该时间后消息被开始批量发送；若在异步模式下同时配置了缓存数据的最大值batch.num.messages，则达到这两个阈值的任何一个就会触发消息批量发送。默认是1000ms。queue.buffering.max.messages: 在异步模式下，可以被缓存到队列中的未发送的最大消息条数。默认是10000。queue.enqueue.timeout.ms： ...

背景高可用是构建分布式系统的基石。一方面，出于成本考虑， 分布式系统往往采取比较廉价的硬件，其可靠性相对于小型机、专有硬件有很大的不足， 而分布式系统的规模一般比较大，假如硬件的可靠性只有三个9(99.9%)， 一个1000台机器规模的集群每天将面临1台机器宕机的风险，在如此大规模的情况下，存储介质，比如硬盘可能会随时都有损坏，结点之间的网络可能随时都会有抖动，机房可能局部或整体断电，地区或数据中心可能会出现不可用，如果不在设计时考虑这些问题，当这些情况出现的时候，系统将很快处于不可用的状态；另一方面，分布式系统的程序在设计与实现上也更为复杂，软件上既要容错硬件的不可靠，同时软件自身也有可能有问题， 在对外部环境容错的同时需要考虑对软件BUG的容错。 OceanBase在设计之初就充分考虑了高可用问题，确保OceanBase有能力在这些异常出现后，仍然能最大可能的提供服务。 高可用的基本策略冗余是实现高可用的通用方法，为防止数据丢失，将数据冗余多份；为防止系统中某些节点故障，对某些功能节点进行冗余。 冗余带来的好处是可以抵御某些节点的损失，而带来的坏处则主要是成本、性能和一致性问题。 成本主要包括额外的存储、网络、机柜等硬件成本，这是构建高可用分布式系统的必不可少的开销，其总体成本较专有硬件仍然要低，因为专有硬件实际上也需要在内部对某些模块进行冗余以获取高可用性。 性能和一致性问题则是高可用分布式系统必须要处理问题，这两个问题直接影响整个系统正确性、延时与吞吐量。 在传统myql或oracle中，我们往往通过添加备机来实现高可用，且为了实现高性能和高可用，一般会使用“最大可用”模式: 主机尽力将数据同步到备机，而不管是否同步成功，当主机挂掉以后，将备机升级成主机以继续提供服务，这就意味着如果主机在宕机前有数据没有同步到备机，要么通过某种特殊的手段将数据从宕掉的主机同步到备机，要么就接受暂时的数据不一致而继续提供服务，在这种情况下，如果出现主机永久损坏，则会造成数据丢失： 为了解决这个问题，可以使用最大保护模式(早期的MySQL版本不支持)，即主机将日志同步到备机成功后再应答客户，这样会引入另外一个问题，即备机故障或网络抖动会导致失败，影响可用性； 小微引入了共享存储，将数据库redo log放在共享存储上，主机宕机以后，备机需要确保主机所有的数据都已经同步才能对外提供服务： 这样在主机宕机时，备机作一些额外的检查后升级为主机继续提供服务，这样可以确保数据一致性，但引入了共享存储。传统的主备模式还有另外一个问题是主备之间无法通过自身决出主备，需要人工切换或者使用一个第三方组件： 但是又引入了HA模块的稳定性问题，如果HA模块和主机的网络不通， HA将不能识别主机是活着还是网络有问题，此时HA如果进行切换而主机还活着则会造成后果很严重的双主问题。 OceanBase高可用策略故障可以分为单机故障(磁盘、内存等硬件介质损坏或单台软件Crash都属于单机故障)，机架/机房故障(比如整个机架或机房的电源断电)以及地区/数据中心(比如地区地震造成该区网络隔离)故障，一般来说，故障单位越小，出现频率越高，而除非自然灾害，一个地区出现故障的概率极小，故障单位越小，实现高可用的难度和成本越低，故障单位越大，由于引入环境、距离等因素，实现高可用的难度和成本会呈指数倍增长。比如为了预防单机故障，只需要在本机房预备冗余节点，故障时通过某些技术方案，可以做到实时切换；而为了预防数据中心故障，则需要在另外一个地区预备冗余的数据中心，在故障时由于通信距离等原因，基本上无法做到无损切换。 OceanBase虽然在设计之初就考虑到了硬件和软件的不可靠，但OceanBase的高可用并非一蹴而就，在实现过程中，为了快速实现或者绕过某个暂时无法攻克的技术难点，会进行综合权衡，只实现一些出现概率较高的基本高可用策略，而通过人肉或其它手段来保证在某些很难出现的灾难出现后可以尽快恢复。然后通过逐步迭代，逐渐完善，将高可用的范围提高，比如OceanBase最初的时候只考虑单机故障的高可用，到目前为止已经可以实现同城IDC之间的容灾。 分布式系统为了设计与实现的简单，往往会在系统中设置一个全局单点，来负责相对比较轻量的管理任务， OceanBase中的rootserver就是这样一个角色；它主要负责集群中其它角色的管理并作为用户的入口，通常其压力不高且无本地数据需要存储，所需信息都可以通过其它角色的汇报来重建。 而作为一个分布式数据库，OceanBase面临着两个很难解决的问题：数据一致性与分布式事务，在早期的OceanBase版本中，采取的策略是暂时绕过这两个问题，等技术积累到一定程度后再回过头来解决，所以在OceanBase中另外增加了一个单写入节点，这个节点的压力很高，数据无法通过其它节点来恢复，我们需要保证这些单节点的高可用。另外一个是保存基线数据结点的高可用，这些结点被设计成可以弹性伸缩，本身具备高可用属性，但仍然需要考虑磁盘故障以及数据副本之间的一致性。 我们会在下面的章节分别描述对这两类节点的高可用策略。 系统单点在早期OceanBase的版本中，主要依靠主备来为单点提供高可用， 使用两台机器，其中的一台角色为主的机器对外提供服务，另外一台机器做为热备， 当主机挂掉后，备机切换为主，继续提供服务。 如前所述，这种“最大可用”模式的主备机制主要有两个问题：第一个问题在于这两台机器无法通过自身来决出主备，必须要依赖于一个第三方组件，早期我们使用了HA(linux-ha.org) 来做为仲裁组件，HA使用VIP机制，两台机器共享VIP， 同一时刻VIP只会加载在其中的一台机器， VIP会提供给外部应用程序作为OceanBase集群的入口地址，即VIP加载在哪一台机器上，该机就会作为主对外提供服务，程序可以通过不断检测VIP是否存在来判断本机是否为主机，当HA通过我们提供的检测程序检测到主机故障后，就会将VIP切换到备机， 此时外部请求就会路由到原来的备机，原来的备机检测到VIP“飘”到本机后，会将自己的角色置为主： 使用HA主要有几个问题： HA为了防止网络抖动带来的误判，要求将两台机器使用网线直连， 这就限制了两台机器只能放在一个机柜，如果整个机柜断电，则服务不可用，这样就不能抵御机柜以及机房的容灾。数据一致性不能保证，一般不要求使用HA的角色持久化特别重要的数据。 其数据应该能通过其他角色的汇报而重建。另外一个问题在于这种机制无法保证数据不丢失， 某些极端情况下需要停机恢复，如果有机器永久损失，则可能会造成数据的丢失，在某些业务上可能无法接受。 而Updateserver是OceanBase中至关重要的节点，其数据丢失直接影响用户，也不能通过其它类型节点来重建，所以Updateserver最早抛弃HA模式，而改为通过Rootserver来选主： Updateserver每次写入都会生成一条日志，每条日志有一个惟一且单调递增的日志号， 各Updateserver向Rootserver汇报自己的日志号， Rootserver选取日志号最大的Updateserver为主并发放租约，备Updateserver同时需要向主Updateserver注册，由主Updateserver发放租约。Updateserver使用一主多备的形式， 每次写入必须要写入多数派个节点成功才能应答客户，写入请求首先发送到主Updateserver，主Updateserver生成日志并同步到备机，收到多数派个成功回应以后应答客户。如果收不到足够多的回应，则不会应答客户端，该条写入可能生效，也可能不生效。 由于要求写入多数派个节点才算成功，所以主备间的网络延迟不能太高，目前OceanBase要求updateserver主备分布在同城的不同IDC， 如果采取一主两备的模式， 最大可以容忍一个同城IDC故障。 当某一台机器同步日志失败时，主机会将其剔除在恢复之前不再向其同步日志， 这对网络要求很高，如果网络连续出现抖动，则会造成可用性问题。在最新版本OceanBase， 将同步日志的方式也改为Paxos方式，一条日志只需要写到多数派个结点上成功便为成功，不需要各台备机顺序回应，进一步容忍短暂的网络问题。 虽然Updateserver去掉了对HA的依赖，但Rootserver仍然需要HA来选主，由于HA无法部署在两个IDC，所以我们对IDC之间的容灾使用的策略是在另外一个IDC部署一个备集群，在主集群出现故障时，通过人肉的方式将备集群切换为主来提供服务。 基于这个原因，OceanBase 在0.5里彻底取消了基于HA的主备机制，而是通过使用类似paxos的算法来进行选举： 让程序自身投票来决出主备， 当一台机器得到多数派的认可，它即可以成为主，这样系统能容忍一定数量节点的不可用，比如，如果是2台，则不能容忍有机器宕机，3台则可以容忍一台机器宕机， 3台机器可以部署在不同的机房以容忍机房故障。 Updateserver仍然通过Rootserver来选主，但这样也存在一个问题，当Updateserver和Rootserver同时故障的时候，Updateserver必须要等Rootserver恢复完成后才能恢复，增加了故障恢复的时间 。在后续的OceanBase版本中，将去除Updateserver这个单写入节点，并将其选主的权力下放到自身，摆脱由Rootserver选主的局面。届时Rootserver的工作会更为简单，单点不会成为OceanBase的瓶颈。 基线数据Rootserver/Updateserver是通过冗余节点来进行容灾，备节点一般不提供服务或只提供有限的服务，基线数据则是通过冗余数据来实现高可用与扩展服务能力。通过冗余3~6份数据来提供更多的服务能力。冗余的数据不能存储在相同的机器上，以避免机器宕机后损失可用性。同时在可能的情况下，数据需要分布在不同的机架上，以抵御整机架断电或断网，OceanBase在早期的实现中，为了简化实现与对机器分布的要求，未考虑数据分布在不同的机柜，曾出现过整机架断网而造成服务不可用。 基线数据的副本数决定了一个集群同时有多少台机器可以宕机，如果使用三副本，则同时可以有两台机器宕机，每个基线数据结点都和Rootserver保持心跳，当该结点宕机以后，rootserver会检测到并根据目前系统中所拥有的副本数量启动复制，为了避免因网络抖动所带来的不必要的副本复制，我们设定在安全的情况下(比如剩余副本数大于1) 可以容忍副本丢失一段时间(比如8小时)，当副本丢失超出该时长后才启动复制。 ...

“点击获取上云帮助文档” 尊敬的阿里云用户： 您好！为方便您试用开源 RocketMQ 客户端访问阿里云MQ，我们申请了专门的优惠券，优惠券可以直接抵扣金额。请填写下您公司账号信息，点击上图，了解更多哦。 一、DLedger引入目的 在 RocketMQ 4.5 版本之前，RocketMQ 只有 Master/Slave 一种部署方式，一组 broker 中有一个 Master ，有零到多个 Slave，Slave 通过同步复制或异步复制的方式去同步 Master 数据。Master/Slave 部署模式，提供了一定的高可用性。 但这样的部署模式，有一定缺陷。比如故障转移方面，如果主节点挂了，还需要人为手动进行重启或者切换，无法自动将一个从节点转换为主节点。因此，我们希望能有一个新的多副本架构，去解决这个问题。 新的多副本架构首先需要解决自动故障转移的问题，本质上来说是自动选主的问题。这个问题的解决方案基本可以分为两种： 利用第三方协调服务集群完成选主，比如 zookeeper 或者 etcd。这种方案会引入了重量级外部组件，加重部署，运维和故障诊断成本，比如在维护 RocketMQ 集群还需要维护 zookeeper 集群，并且 zookeeper 集群故障会影响到 RocketMQ 集群。利用 raft 协议来完成一个自动选主，raft 协议相比前者的优点是不需要引入外部组件，自动选主逻辑集成到各个节点的进程中，节点之间通过通信就可以完成选主。因此最后选择用 raft 协议来解决这个问题，而 DLedger 就是一个基于 raft 协议的 commitlog 存储库，也是 RocketMQ 实现新的高可用多副本架构的关键。 二、DLedger 设计理念1. DLedger 定位 Raft 协议是复制状态机的实现，这种模型应用到消息系统中就会存在问题。对于消息系统来说，它本身是一个中间代理，commitlog 状态是系统最终状态，并不需要状态机再去完成一次状态构建。因此 DLedger 去掉了 raft 协议中状态机的部分，但基于raft协议保证commitlog 是一致的，并且是高可用的。 另一方面 DLedger 又是一个轻量级的 java library。它对外提供的 API 非常简单，append 和 get。Append 向 DLedger 添加数据，并且添加的数据会对应一个递增的索引，而 get 可以根据索引去获得相应的数据。因此 DLedger 是一个 append only 的日志系统。 ...

十年文案老司机，不如网易评论区。 网易云音乐自2013年上线后，业务保持了高速增长。云音乐除了提供好听的音乐外，还留下了我们在乐和人上的美好回忆。本文整理自网易云音乐消息队列负责人林德智在近期 Apache Flink&RocketMQ Meetup 上海站的分享，通过该文，您将了解到： 网易云音乐消息队列改造背景网易云音乐业务对消息队列要求网易云音乐消息队列架构设计网易云音乐消息队列部分高级特性介绍网易云音乐消息队列落地使用情况网易云音乐消息队列未公开规划背景网易云音乐从13年4月上线以来，业务和用户突飞猛进。后台技术也从传统的 Tomcat 集群到分布式微服务快速演进和迭代，在业务的不断催生下，诞生了云音乐的 RPC，API 网关和链路跟踪等多种服务，消息队列也从 RabbitMQ 集群迁移到 Kafka集群。对于消息队列，更多处于使用阶段，也在使用中出现很多问题。因此我们期望提供一种完全可控，出现问题我们自己能排查，能跟踪，可以根据业务需求做定制改造的消息队列。 调研结果 RabbitMQ 由于持久化场景下的吞吐量只有2.6万，不能满足我们业务吞吐量的需求，云音乐在 2017 年将消息队列从 RabbitMQ 迁移到 Kafka 也是这个原因，因此不再考虑范围之内。由于云音乐整体业务的 QPS 较高，因此，ActiveMQ 也不在考虑范围。 这里主要对比 RocketMQ 与 Kafka： Kafka 更偏向大数据，日志处理，缺少死信，消费失败自动重试，事物消息，定时消息，消息过滤，广播消息等特性，另外 Kafka 没有同步刷盘。云音乐的业务更偏向于多 Topic，死信可溯源，消费失败可收敛自动重试，高可用，自动 Failover 等特性。对于商城和社交业务来说，事物，顺序 Topic 使用会比较多。Kafka 和RocketMQ 对比 ： http://jm.taobao.org/2016/03/24/rmq-vs-kafka 经过 RabbitMQ，Kafka 和 RocketMQ（ ActiveMQ 性能较差，暂不考虑）的调研和分析后，我们发现 RocketMQ 比较适合云音乐的通用业务，但是开源 RocketMQ 也有一些缺陷，只有我们解决了这些缺陷才能在业务中大规模使用。 开源 RocketMQ 的基本架构如下：（基本介绍参考） 开源 RocketMQ 主要问题有： Broker 仅提供了 Master 到 Slave 的复制，没有 Failover 切换的能力；事物消息不开源（我们开始研发时不开源）；消息发送消费无追踪（我们开始研发时不开源）；告警与监控体系没有；开源控制台不完善。云音乐业务对消息队列的要求 ...

背景阿里云InfluxDB®是阿里云基于开源版InfluxDB打造的一款时序数据库产品，提供更稳定的持续运行状态、更丰富强大的时序数据计算能力。在现有的单节点版本之外，阿里云InfluxDB®团队还将推出多节点的高可用版本。 我们知道现有的开源版InfluxDB只提供单节点的能力，早期开源的集群版本功能不完善、且社区不再提供更新与支持。经过对官网商业版InfluxDB现有文档的研究，我们猜测在商业版InfluxDB集群方案中，meta信息集群是基于一致性协议Raft做同步的，而数据是异步复制的。这种分离的方式虽然有优点，但也引起了一系列的一致性问题，在一些公开的文档中，官方也承认这种数据复制方案并不令人满意。 因此，团队在参考多项技术选型后，决定采用最为广泛使用并有较长历史积累的ETCD/Raft作为核心组件实现阿里云InfluxDB®的Raft内核，对用户所有的写入或一致性读请求直接进行Raft同步（不做meta信息同步与数据写入在一致性过程中的拆分），保证多节点高可用版本拥有满足强一致性要求的能力。 有幸笔者参与到多节点的高可用版本的开发中，期间遇到非常多的挑战与困难。其中一项挑战是ETCD的Raft框架移植过程中，在移除了ETCD自身较为复杂、对时序数据库没有太多作用的Raft日志模块后，所带来的一系列问题。本文就业界Raft日志的几种不同实现方案做讨论，并提出一种自研的Raft HybridStorage方案。 业内方案ETCD由于我们采用了ETCD/Raft的方案，绕不开讨论一下ETCD本家的Raft日志实现方式。 官网对Raft的基本处理流程总结参考下图所示，协议细节本文不做扩展： 对于ETCD的Raft日志，主要包含两个主要部分：文件部分（WAL）、内存存储部分（MemoryStorage）。 文件部分（WAL），是ETCD Raft过程所用的日志文件。Raft过程中收到的日志条目，都会记录在WAL日志文件中。该文件只会追加，不会重写和覆盖。 内存存储部分（MemoryStorage），主要用于存储Raft过程用到的日志条目一段较新的日志，可能包含一部分已共识的日志和一些尚未共识的日志条目。由于是内存维护，可以灵活的重写替换。MemoryStorage有两种方式清理释放内存：第一种是compact操作，对appliedId之前的日志进行清理，释放内存；第二种是周期snapshot操作，该操作会创建snapshot那一时刻的ETCD全局数据状态并持久化，同时清理内存中的日志。 在最新的ETCD 3.3代码仓库中，ETCD已经将Raft日志文件部分（WAL）和Raft日志内存存储部分（MemoryStorage）都抽象提升到了与Raft节点（Node）、Raft节点id以及Raft集群其他节点信息（*membership.RaftCluster）平级的Server层级，这与老版本的ETCD代码架构有较大区别，在老版本中Raft WAL与MemoryStorage都仅仅只是Raft节点（Node）的成员变量。 一般情况下，一条Raft日志的文件部分与内存存储部分配合产生作用，写入时先写进WAL，保证持久化；随之马上追加到MemoryStorage中，保证热数据的高效读取。 无论是文件部分还是内存存储部分，其存储的主要数据结构一致，都是raftpb.Entry。一条log Entry主要包含以下几个信息： 参数描述Termleader的任期号Index当前日志索引Type日志类型Data日志内容此外，ETCD Raft日志的文件部分（WAL）还会存储针对ETCD设计的一些额外信息，比如日志类型、checksum等等。 CockroachDBCockroachDB是一款开源的分布式数据库，具有NoSQL对海量数据的存储管理能力，又保持了传统数据库支持的ACID和SQL等，还支持跨地域、去中 心、高并发、多副本强一致和高可用等特性。 CockroachDB的一致性机制也是基于Raft协议：单个Range的多个副本通过Raft协议进行数据同步。Raft协议将所有的请求以Raft Log的形式串行化并由Leader同步给Follower，当绝大多数副本写Raft Log成功后，该Raft Log会标记为Committed状态，并Apply到状态机。 我们来分析一下CockroachDB Raft机制的关键代码，可以很明显的观察到也是从鼻祖ETCD的Raft框架移植而来。但是CockroachDB删除了ETCD Raft日志的文件存储部分，将Raft日志全部写入RocksDB，同时自研一套热数据缓存（raftentry.Cache），利用raftentry.Cache与RocksDB自身的读写能力（包括RocksDB的读缓存）来保证对日志的读写性能。 此外，Raft流程中的创建snapshot操作也是直接保存到RocksDB。这样实现的原因，个人推测是可能由于CockroachDB底层数据存储使用的就是RocksDB，直接使用RocksDB的能力读写WAL或者存取snapshot相对简单，不需要再额外开发适用于CockroachDB特性的Raft日志模块了。 自研HybridStorage移除snapshot在阿里云InfluxDB多节点高可用方案实现过程中，我们采用了ETCD/Raft作为核心组件，根据移植过程中的探索与InfluxDB实际需要，移除了原生的snapshot过程。同时放弃原生的日志文件部分WAL，而改用自研方案。 为什么移除snapshot呢？原来在Raft的流程中，为了防止Raft日志的无限增加，会每隔一段时间做snapshot，早于snapshot index的Raft日志请求，将直接用snapshot回应。然而我们的单Raft环架构如果要做snapshot，就是对整个InfluxDB做，将非常消耗资源和影响性能，而且过程中要锁死整个InfluxDB，这都是不能让人接受的。所以我们暂时不启用snapshot功能，而是存储固定数量的、较多的Raft日志文件备用。 自研的Raft日志文件模块会周期清理最早的日志防止磁盘开销过大，当某个节点下线的时间并不过长时，其他正常节点上存储的日志文件如果充足，则足够满足它追取落后的数据。但如果真的发生单节点宕机太长，正常节点的日志文件已出现被清理而不足故障节点追取数据时，我们将利用InfluxDB的backup和restore工具，将落后节点还原至被Raft日志涵盖的较新的状态，然后再做追取。 在我们的场景下，ETCD自身的WAL模块并不适用于InfluxDB。ETCD的WAL是纯追加模式的，当故障恢复时，正常节点要相应落后节点的日志请求时，就有必要分析并提取出相同index且不同term中那条最新的日志，同时InfluxDB的一条entry可能包含超过20M的时序数据，这对于非kv模式的时序数据库而言是非常大的磁盘开销。 HybridStorage设计我们自研的Raft日志模块命名为HybridStorage，即意为内存与文件混合存取，内存保留最新热数据，文件保证全部日志落盘，内存、文件追加操作高度一致。 HybridStorage的设计思路是这样的： （1）保留MemoryStorage：为了保持热数据的读取效率，内存中的MemoryStorage会保留作为热数据cache提升性能，但是周期清理其中最早的数据，防止内存消耗过大。 （2）重新设计WAL：WAL不再是像ETCD那样的纯追加模式、也不需要引入类似RocksDB这样重的读写引擎。新增的日志在MemoryStorage与WAL都会保存，WAL文件中最新内容始终与MemoryStorage保持完全一致。 一般情况下，HybridStorage新增不同index的日志条目时，需要在写内存日志时同时操作文件执行类似的增减。正常写入流程如下图所示： 当出现了同index不同term的日志条目的情况，此时执行truncate操作，截断对应文件位置之后一直到文件尾部的全部日志，然后重新用append方式写入最新term编号的日志，操作逻辑上十分清晰，不存在Update文件中间的某个位置的操作。 例如在一组Raft日志执行append操作时，出现了如下图所示的同index（37、38、39）不同term的日志条目的情况。在MemoryStorage的处理方式是：找到对应index位置的内存位置（内存位置37），并抛弃从位置A以后的全部旧日志占用的内存数据（因为在Raft机制中，这种情况下内存位置37以后的那些旧日志都是无效的，无需保留），然后拼接上本次append操作的全部新日志。在自研WAL也需要执行类似的操作，找到WAL文件中对应index的位置（文件位置37），删除从文件位置37之后的所有文件内容，并写入最新的日志。如下图分析： 方案对比ETCD的方案，Raft日志有2个部分，文件与内存，文件部分因为只有追加模式，因此并不是每一条日志都是有效的，当出现同index不同term的日志条目时，只有最新的term之后的日志是生效的。配合snapshot机制，非常适合ETCD这样的kv存储系统。但对于InfluxDB高可用版本而言，snapshot将非常消耗资源和影响性能，而且过程中要锁死整个InfluxDB。同时，一次Raft流程的一条entry可能包含超过20M的时序数据。所以这种方案不适合。 CockroachDB的方案，看似偷懒使用了RocksDB的能力，但因其底层存储引擎也是RocksDB，所以无何厚非。但对于我们这样需要Raft一致性协议的时序数据库而言，引入RocksDB未免过重了。 自研的Raft HybridStorage是比较符合阿里云InfluxDB®的场景的，本身模块设计轻便简介，内存保留了热数据缓存，文件使用接近ETCD append only的方式，遇到同index不同term的日志条目时执行truncate操作，删除冗余与无效数据，降低了磁盘压力。 总结本文对比了业内常见的两种Raft日志的实现方案，也展示了阿里云InfluxDB®团队自研的HybridStorage方案。在后续开发过程中，团队内还会对自研Raft HybridStorage进行多项优化，例如异步写、日志文件索引、读取逻辑优化等等。也欢迎读者提出自己的解决方案。相信阿里云InfluxDB®团队在技术积累与沉淀方面会越做越好，成为时序数据库技术领导者。 本文作者：德施阅读原文 本文为云栖社区原创内容，未经允许不得转载。

本文来自阿里巴巴高可用架构团队高级开发工程师肖长军（花名穹谷）在 GIAC（全球互联网架构大会）上的分享，包含三部分内容：（阿里巴巴中间件公众号对话框发送“混沌工程”，获取分享PPT） 混沌工程的定义、价值、原则和流程；混沌工程如何在企业中落地，以及 ChaosBlade 和混沌实验平台 AHAS Chaos 架构设计；结合两个具体案例介绍了分布式服务下的混沌工程实践；大家好，我是来自阿里的肖长军，今天给大家分享混沌工程在分布式服务架构下的具体实践。 先做个自我介绍，我来自于阿里高可用架构团队，花名穹谷，做过分布式系统设计和 APM 研发相关工作，现在专注于高可用架构和混沌工程领域，是阿里云产品 AHAS 底层技术负责人和开源项目 ChaosBlade 负责人，并且承担集团内故障演练、突袭演练、攻防演练相关的研发工作。今天分享的内容包含以下三个方面。 先从混沌工程的定义、价值、原则和实施步骤介绍混沌工程，然后分享混沌工程如何在企业中落地，最后介绍分布式服务下混沌工程实践案例。我们先来看一下什么是混沌工程。 混沌工程理论一文中提到，其是在分布式系统上进行实验的学科，核心目的是提高生产环境中系统的容错性和可恢复性。尼采的这句话: "打不倒我的必使我强大"，也很好的诠释了混沌工程反脆弱的思想。除了这里提到的目的，实施混沌工程还有哪些价值呢？ 这里我从四个角色来说明，对于架构师来说，可以验证系统架构的容错能力，比如验证现在提倡的面向失败设计的系统；对于开发和运维，可以提高故障的应急效率，实现故障告警、定位、恢复的有效和高效性。对于测试来说，可以弥补传统测试方法留下的空白，之前的测试方法基本上是从用户的角度去做，而混沌工程是从系统的角度进行测试，降低故障复发率。对于产品和设计，通过混沌事件查看产品的表现，提升客户使用体验。所以说混沌工程面向的不仅仅是开发、测试，拥有最好的客户体验是每个人的目标。我们知道，系统发生故障的那一刻不是由你来选择的，而是那一刻选择你，你所能做，只能是为之做好准备。了解了混沌工程的价值，我们再来看一下实施混沌工程的一些原则。 前面 Vilas 老师也提到了，我这里重点来介绍一下这五项原则。第一条：”建立一个围绕稳定状态行为的假说“，其包含两个含义，一个是定义能直接反应业务服务的监控指标，需要注意的是这里的监控指标并不是系统资源指标，比如CPU、内存等，这里的监控指标是能直接衡量系统服务质量的业务监控。举个例子，一个调用延迟故障，请求的 RT 会变长，对上层交易量造成下跌的影响，那么这里交易量就可以作为一个监控指标。这条原则的另一个含义是故障触发时，对系统行为作出假设以及监控指标的预期变化。第二个指模拟生产环境中真实的或有理论依据的故障，第三个建议在生产环境中运行实验，但也不是说必须在生产环境中执行，只是实验环境越真实，混沌工程越有价值。持续的执行才能持续的降低故障复发率和提前发现故障，所以需要持续的自动化运行试验，最后一个，混沌工程很重要的一点是控制爆炸半径，也就是试验影响面，防止预期外的资损发生，后面会介绍控制爆炸半径的方式。依据这些指导原则可以更有效实施混沌工程，那么混沌工程的实施步骤是什么？ 主要细分为这 8 步，指定试验计划，定义稳态指标，做出系统容错假设，执行实验，检查稳态指标，记录、恢复 实验，修复发现的问题，然后做持续验证。以上是对混沌工程理论相关的介绍，那么如何在企业中落地混沌工程呢? 我这里分为三个阶段，首先要坚定价值，因为你会受到来自多方面的挑战，其次引入混沌工程技术，最后在企业中推广混沌工程文化。在实施混沌工程之前，必须能说清楚混沌工程的价值，而且当受到挑战时，意志要坚定。 比如来自老板的挑战，”如何衡量混沌工程的价值？“，可以向老板表达出，”从故障的应急效率、故障复发率、线上故障发现数来衡量“等等。所以这些问题自己要想清楚。有了坚定的意志，就要开始落地，首先要先了解自己的系统。 这里系统成熟度分 5 个等级，也可以说是业务系统所处的阶段，列出了每个阶段适合什么故障场景。刚才也有听众问，”我的服务就是单点的，还有没有实施混沌工程的必要？“，有必要，可以实施简单的实验场景，比如 CPU 满载等，来验证监控告警，如果发现没有监控告警，就要去推动完善它，然后再推动服务多实例部署，通过混沌工程一级一级的去推动系统的演进，最终实现具有韧性的系统。根据系统成熟度了解自己系统所适合的场景，接下来就要选择一款合适的混沌实验工具。 这里列举了五个维度：场景丰富度、工具类型、易用性等。可以从 awesome-chaos-engineering github 项目查找或者从 CNCF Landscpage 中查看混沌实验工具。阿里今年开源的 ChaosBlade 也已经加入到 CNCF Landscape 中，后面会对此项目做重点介绍，先来看阿里混沌工程技术的演进。 2012 年阿里内部就上线了 EOS 项目，用于梳理分布式服务强弱依赖问题，同年进行了同城容灾的断网演练。 15 年 实现异地多活，16 年内部推出故障演练平台 MonkeyKing，开始在线上环境实施混沌实验，然后 18 年输出了 ACP 专有云产品 和 AHAS 公有云产品，其中 AHAS 旨在将阿里的高可用架构经验以产品的形式对外输出，服务于外部。19 年推出 ChaosBlade 项目，将底层的故障注入能力对外开源，同年也推出混沌实验平台专有云版本 AHAS Chaos，接下来重点介绍一下 ChaosBlade 项目。 ...

2019年6月28日，在中国国际软件博览会上，蚂蚁金服金融科技产品技术总监杨冰发表主题演讲，分享了蚂蚁金服在过去的十多年里，是如何通过商业创新与技术创新的双轮驱动，创造出数字时代的普惠金融“奇迹”。 十多年以前，大概很难有人能想象到如今我们习以为常的生活场景：只要带上手机就可以放心出门，从购物到餐饮，从打车到住宿，甚至理财和贷款，都只需轻点几下屏幕。 十多年以前，大概也很难有人能想象到金融业会发生如此深刻的变革：人满为患的实体网点、冗长的申请表单和繁复的审批流程都逐渐成为过去时；传统金融行业因成本和风控问题而难以触达的用户，比如小微企业和个人，也日渐成为银行的目标用户群体。 越便捷的服务，需要越强大的技术蚂蚁金服为金融业的变革做了些什么？ 在过去的十五年中，它通过技术重塑了支付服务小微贷款服务，让普惠金融服务对于每一个普通的中国人来说，都变得触手可及。 基于互联网和移动互联网，蚂蚁金服的产品为用户带来了前所未有的轻松和便捷：转账无需再去银行排队，在只需在手机上轻点几下；消费无需现金，二维码支付已经遍布中国的大街小巷；即使没有信用卡，只要开通花呗即可先付后还；余额宝可以让用户通过手机就能实现理财，而如果一名小微企业主想要贷款，只需要花3分钟在网上填写申报材料，1秒钟就能实现贷款到账，整个过程中零人工干预。 但是，用户对于快捷和便利的要求不断增长，也给金融机构带来的全新的挑战。在挑战面前，唯有技术的创新和发展才是最有力的武器。 通过智能手机，用户可以随时随地发起交易，线上交易流量远非传统银行柜台业务可比。在类似“双十一”的大促活动中，每秒的交易峰值可达数十万笔，在这样巨大的流量面前，如何保持交易系统的稳定、安全、高可用，保证数据没有任何丢失和偏差，这是互联网时代的“新型银行”必须面对的难题。 金融交易技术中，最关键的是分布式数据库能力。随着蚂蚁金服的业务量突飞猛进，依靠开源的分布式系统已经不足以解决问题。2009 年，蚂蚁金服自主研发金融级分布式关系数据库 OceanBase，这是一个专长于高可用、一致性的分布式数据库，结合蚂蚁自研的金融级分布式中间件，整个系统具备百万级每秒的伸缩支付能力，成功经受住了“双十一”交易量每年翻三倍的考验。 金融交易的另一个关键点是风控，这关系到金融业务的生命线。传统金融机构用严格的审核来控制风险，但在互联网时代，为了用户体验及时流畅，消费、信贷、保险等交易的审核都必须在尽可能短的时间内完成。 对于金融机构而言，这可谓压力山大：交易是否违规？是否虚假交易？是否合谋套现？如何在不借助担保材料的情况下来判断借款者是否可靠？如何甄别诈骗和洗钱？如何避免坏账和资金损失？这一系列复杂的问题，都要在毫秒级的时间中里找到正确答案。 传统金融机构依靠人力来审核的做法显然是行不通的，不但成本高企，时间也不允许，因此必须要有一套数据和算法构筑的庞大、复杂而精密的平台，依靠海量的计算来做出精准的决策。 这不是一件简单的事，因为每一笔交易都关系到真金白银，出错就会带来资损，金融级对于精确和稳定的要求非常高，尤其在延时性要求也非常苛刻的情况下，对技术是很大的考验。举例而言，如果要甄别一个花呗账号是否有套现嫌疑，既要做实时的特征计算，还要用图计算去查看与这个账号关联的资金情况。如果在多种计算模式之间来回切换，不仅会增加成本，还会带来延时，影响用户体验。 蚂蚁金服：不是取代者，而是支持者强大的技术支持，让蚂蚁金服实现了快、稳、准，许多本来难以享受金融服务的企业和个人，如今也可以享受到普惠金融带来的便利。在传统金融机构看来，像这样的新型科技金融机构是强有力的竞争者，发达国家的许多银行家担心，新兴科技公司的崛起将挤压他们的份额。 但在蚂蚁金服看来，这种担心是多余的：蚂蚁金服不会取代传统机构，而是扮演支持者的角色，通过技术开放帮助机构提升服务效率和质量。 自研技术的基础上，蚂蚁金服还一直在扮演着推动技术开放，为传统金融业赋能的角色。因为蚂蚁金服定义中的普惠金融，不仅是自身要服务大量的用户，让原本难以享受到便捷金融服务的用户受益；还要通过技术的开放，让更多的金融机构具备更好地服务大量用户的能力。 在金融业变革的大势之中，许多传统金融机构都走上了数字化转型的道路。转型之中，他们不约而同地遇到了相似的门槛：如何快速搭建线上业务？如何利用互联网获客、扩大业务规模和覆盖范围？如何基于互联网用户群体的特性开发新的产品？ 蚂蚁将自己沉淀下来的技术和经验开放出来，让传统金融机构在面对这类问题时，手握更具效率的工具，也少走了很多弯路。 三大PaaS产品都是蚂蚁金服技术开放的结晶：mPaaS（mobile PaaS）能够快速帮助这些机构开发移动APP；bPaaS（business PaaS）是凝结了蚂蚁金服多年来积累的分布式金融核心能力的套件，能帮助这些机构在最短三个月内快速“复制支付宝的能力”；dPaaS作为一个数据智能平台，借助强大的底层数据引擎，通过海量的计算，能帮助这些机构获得基于大数据的业务分析洞察能力和实时智能决策能力。 mPaaS自2017年下半年开始推广以来，已经帮助多家股份制银行和城市商业银行完成互联网金融升级，如广发银行，华夏银行，苏州银行等。mPaaS团队仅用了不到三个月的时间，就帮助铁路售票系统12306 App完成重构，极大提升了性能和效率。此外，mPaaS还和上海地铁深入合作，推出了“Metro大都会 App”，实现扫码进站，为日均客流量超过1100万人次的上海地铁解决了排队买票的问题。 bPaaS的面世，为传统金融机构的转型提供的现成的平台，让他们不必再从零开始摸索和开发自己的分布式业务系统，节约大量时间的同时，也极大减少了分布式技术在核心业务中的落地难度。bPaaS中整合的是蚂蚁金服十几年来在金融业务实践中经过无数次验证的技术和解决方案，在保持银行传统核心稳定的前提下，bPaaS可以根据不同银行差异化的业务场景，快速定制新业务场景。随着bPaaS的开放，金融机构在最短三个月内“复制蚂蚁金服的核心技术能力”，完全可能成为现实。 dPaaS则针对传统金融机构转型中使用数据门槛过高的痛点，主要提供“三合一”的数据智能能力：处理海量数据的工具，收集和存储数据的标准，使用数据的方法论。在风控和营销场景之中，dPaaS都有突出的表现，在dPaaS的帮助之下，传统金融机构能够更为顺畅地使用数据来提升业务，将手中的数据资产切实有效地转化为业务能力，实现数据的价值。 《经济学人》特别指出，技术对金融业的意义深远。科技创新可以孕育更灵活、便利、开放的金融系统，而智能手机和数字技术在金融业的广泛应用将成为推动社会经济发展和普惠的最佳途径之一。在运用数据和数据技术规避风险、降低成本、促进业务成长、推动普惠金融等方面，以蚂蚁金服为代表的中国金融科技公司已经走出了一条自己的道路，同时，也在不断将技术进步的趋势推广到全世界。 本文作者：华蒙阅读原文 本文为云栖社区原创内容，未经允许不得转载。

团队介绍：高可用架构团队是阿里巴巴保障稳定性的护航舰队，提供的高可用架构基础设施直面双11洪峰流量，包括全链路压测、容量规划、准入控制、限流降级、流量调度等；通过攻防演练、环境隔离、业务对账等常态稳定性保障技术，提前暴露风险，低成本发现系统隐患；通过同城双活、异地多活、单元化体系建设，支撑阿里巴巴电商链路的分钟级故障切换，保证业务稳定运行。 目前团队的技术，已经通过开源和商业化渠道进行外部输出。开源框架包括Sentinel、ChaosBlade，商业化产品包括PTS、AHAS，帮助云原生用户低成本提升高可用能力。 如果对纯技术感兴趣，可以直接成为顶级开源项目的核心开发。如果对技术结合实际场景感兴趣, 可以深度参与多个高可用领域系统的建设, 一起探索世界独一无二复杂高并发的双十一高可用、AIOPS等场景如果对产品、业务感兴趣，可以投身于将我们的高可用系统做成产品，推动实现全世界的“互联网+”趋势如果对云感兴趣，可以参与到性能压测、应用高可用和异地多活等云产品建设中来，感受与 AWS、Azure 等全球领先技术的追云逐浪【团队开源产品】限流降级 Sentinel（https://github.com/alibaba/Se...）故障演练 ChaosBlade（https://github.com/chaosblade...） 【团队商业化产品】性能测试服务 PTS（https://www.aliyun.com/produc...）应用高可用服务 AHAS（https://www.aliyun.com/produc...） 工作地点：杭州 招聘岗位：JAVA 开发工程师Go 开发工程师C++ 开发工程师招聘要求：有技术热情，计算机基础良好，熟练使用 Java/C++/Go/C 至少一门语言；拥有良好的 Linux 系统认知和实践经验，掌握初步的系统问题分析和排查能力；具备强烈的进取心和责任感，有较强的学习能力和探索精神，面对压力敢于迎难而上；有较强的逻辑思维能力和表达能力，有良好的团队合作精神；有大赛获奖经验、发表优秀论文、开源项目经验者优先。校招和社招简历投递方式请发送简历, 校招文件命名为 [姓名-学校-联系方式-岗位] ，社招 [姓名-联系方式-岗位]到 jiuli.qk@alibaba-inc.com，有疑问也可以直接发邮件。 Q&A提前批是否会影响正式秋招?提前批如果表现不佳, 对正式秋招也无任何影响, 秋招正式开始时仍然可继续投递阿里其它团队。对毕业时间有没有什么要求?国内院校2020年毕业, 海外院校2020年11月前毕业。

概述水平拆分的概念随着分布式数据库的推广已为大部分人熟知。分库分表、异构索引、小表广播、这些功能几乎是产品功能需求标配。然而有些客户使用分布式数据库后的体验不尽如意。本文尝试从数据的角度总结分布式数据的复制（replication）和分区（partition）技术原理和方案，其中分区也有称为分片（sharding），希望能引起读者一些思考，在分布式数据库选型中能注意这些细节的区别，选择适合业务的数据水平拆分方案。 分布式数据库架构分布式数据库以集群形式存在，有多个节点。集群架构有共享磁盘架构（shared-disk）和无共享架构（shared-nothing）。后者有时也称为水平扩展（horizontal scale）或向外扩展（scale out），本文主要总结无共享架构方案。 无共享架构的各个节点之间的通信都是软件层面使用网络实现，不同产品在架构不同导致这个细节也不同。有些架构是计算与存储分离。计算节点特点是无状态（即数据不要求持久化），通过集群方式管理，可以水平扩展；存储节点有数据，使用复制和分区技术，节点间任务集中调度或者独立交互。了解这个架构细节都可用性分析会更加具体。具体分布式数据库架构有哪些请参考《一些关系数据库的架构总结》。 这里节点的实际体现形式可以是一个机器，也可以是机器上的一个实例。比如说有些数据库支持单机安装多个实例，如MySQL。每个节点具备一定的资源和能力。资源指的是CPU、内存和磁盘，能力是提供数据读写和存储能力。分布式数据库需要把多个节点的能力聚集到一起集中管理，只是不同分布式数据库产品对资源的管理能力各有特点。 在分布式数据库里，数据随处可见，这是最容易让人混淆的地方。因为数据经过复制和分区后会有两种存在形式：副本(replica)和分区(partition)。 数据的复制（replication）复制（replication）指在几个不同的节点上保存数据的相同副本（replica）。复制提供了冗余的能力。其作用一是提供高可用能力：如果一个节点不可用，剩余的节点可以快速提供数据服务。作用二是提供读写分离能力。常见的有两副本和三副本架构。 多个副本内容相同，角色会有区分。常见的是一个副本是Leader角色（有的也称主副本），默认提供读写服务；其他副本是Follower角色（有的也称备副本），默认不提供服务。这种架构也称为基于单Leader的（Single Leader-based）。还有其他架构是多Leader的，每个Leader都有数据要复制到其他Leader或Follower，这种架构会有个明显的问题就是数据冲突处理。如果产品层面不处理，用户直接使用风险会很高。 后面讨论的是前者：基于单Leader副本架构。 多副本之间数据同步不是依赖业务多写，而是采用副本间复制事务日志（Redo）技术。复制的方式有同步复制和异步复制。使用同步复制方式，备副本要收到Redo并落盘主副本才能提交，也叫强同步；使用异步复制方式，Follower副本相对Leader副本内容会有延时，具体延时多少取决于Leader副本上事务量、网络传输速度、Follower副本所在节点的负载和能力。强同步的缺点时主副本写性能会下降，同时如果备副本不可用主副本也不能提供服务（变相的解决方案是复制方式降级为异步复制）。 传统关系型数据库还有一种用法一主两备架构，使用同步复制，只要任何一个备副本收到Redo，主副本的事务就可以提交。这个方案优点是保障了数据在多个副本中存在，高可用时有候选副本，也不用担心挂掉一个备副本会影响主副本。它的缺点是不能自动知道哪个候选副本拥有主副本最新最全的数据，也不强制要求两个备副本都要拥有全部数据。 还有一类三副本架构在复制时使用的是Paxos协议，三副本会就Redo落盘事件进行投票，有两个副本成功了Leader副本的事务即可提交。这个表面上跟上面传统一主两备的三副本效果一样，实际上还是有区别的。区别一是使用Paxos协议时，如果Leader副本自身投票慢了，两个Follower副本投票成功，Leader副本的事务也是能提交的；区别二是第三个副本最终也必须写Redo成功，否则其状态就是异常，产品自身可以发现并自动修复（如重新创建一个副本）；区别三是使用Paxos协议时，在Leader副本不可用时还可以自动选出新的Leader副本并且拥有老Leader副本的最新数据。这里其实说的是高可用机制。同样，这里对用户而言也不知道哪个Follower副本拥有最新最全的数据，如果访问Follower副本（读写分离），也可能发现数据有延时。 大部分数据库做副本复制使用的是Redo，也称为物理同步。在应用Redo的时候直接是数据块变更。使用物理同步机制的备副本是不提供写服务，不能修改。还有一类复制使用的是Binlog，也称为逻辑同步。Binlog里只包含已提交的事务，并且在应用的时候是通过执行SQL。使用逻辑同步的备副本通常也可能是主副本，可以修改（如MySQL的双向复制架构Master-Master)。如果目标端数据不对，应用SQL会失败，这个复制就会中断需要人介入处理。这也进一步加深了主备副本不一致的概率。 关于副本角色的粒度，有多种实现方案。 传统关系数据库主备架构，主副本或备副本的粒度就是实例。对于主实例（Primary）而言，里面所有数据库（或SCHEMA）的所有表的角色都是主；备实例（Standby）里数据则都是备副本。如果发生高可用切换，业务会中断几十秒或几分钟然后恢复(需要人工处理或自动化脚本处理）。 还有一种粒度是到表。即一个节点内有些表是Leader副本，有些表是Follower副本，这样这个节点就不能简单的说是主节点（实例）或备节点（实例）。这个副本角色细节业务也是可以获取的，如果发生高可用切换，业务会中断十几秒然后恢复。 还有一种粒度是存储级别的定长块。即一个节点的存储里，部分数据块是Leader副本，部分数据块是Follower副本。这种对业务就完全透明，业务基本不感知高可用切换。 数据的分区（partition）上面总结的是数据的复制（冗余，多副本），对于非常大的数据集（表）或者非常高的访问量（QPS），仅仅靠复制是不够的，还需要对数据进行分区（partition），也称为分片（sharding）。 分区粒度首先这里的分区（partition）是一种抽象概念，在不同数据库产品里这个体现是不一样的。如在MongoDB， Elasticsearch中体现为分片（shard），在HBase中体现为区域块（Region），Bigtable中体现为表块（tablet），ORACLE中体现为分区（partition），Couchbase中体现为虚拟桶（vBucket）。可见不同的数据库产品数据分区的粒度不同。在分布式关系数据库中间件中，分片的粒度是分表（物理表）；在真正的分布式关系数据库里，分片的粒度有分区（partition，同ORACLE）或者区域块（Region）。 分区粒度对业务研发的使用体验影响很大。 比如说中间件常用分库分表方案，使用时对开发和运维会有一些要求。如建很多同构的表并后期维护、要求SQL带上拆分键，还有一些功能限制（如跨库JOIN问题）、底层存储节点用的数据库自身高可用和多副本的数据一致问题等等。不同的中间件产品能力上也有区别，互联网大厂的产品由于内部场景培育很久，做的相对成熟一些。 体验最好的分区粒度就是存储级别的Region，业务研发完全不用关心分片细节，也无法干预分片细节。当有些场景追求性能需要干预数据分布特点时就不好处理。 介入这两种策略之间的就是分区。物理上业务只要创建一个分区表，根据业务特点指定分区策略（包含分区列、拆分算法、分区数目等）。 数据复制是为了冗余和高可用，数据分区主要是为了可扩展性。不管使用哪种分区方案，业务的每条数据（记录）属于且仅属于一个分区（或分片sharding），同一个分区（分片）只会存在于一个节点。前面说了每个节点代表了一定的资源和能力。当复制和分区（分片）一起使用的时候，注意区分你看到的数据。 分区策略分区的目标是将大量数据和访问请求均匀分布在多个节点上。如果每个节点均匀承担数据和请求，那么理论上10个节点就应该能承担10倍于单节点的数据量和访问量。这个理论是忽略了复制产生的Follower副本的存在。Follower副本的空间和内存是不可能跟其他Leader副本共享的，但是计算能力（CPU）是可以的。当所有节点都提供服务的时候（多活），是计算资源最大利用。 然而如果分区是不均匀的，一些分区的数据量或者请求量会相对比较高，出现数据偏斜（skew），这个可能导致节点资源利用率和负载也不均衡。偏斜集中的数据我们又称为热点数据。避免热点数据的直接方法就是数据存储时随机分配（没有规则）给节点，缺点是读取的时候不知道去哪个分区找该记录，只有扫描所有分区了，所以这个方法意义不大。实际常用的分区策略都是有一定的规则。 这个规则可以是业务规则，也可以不是。 业务规则的分区首先是选取一个或一组列作为分区键，然后选取拆分方法。比如说根据键的范围（Range）分区，分区数量和边界时确定的（后期还可以新增分区）。好处时针对分区键的范围扫描性能会比较好。分布式数据库中间件的分库分表、分区表的分区都支持RANGE 拆分函数。各个产品拆分细节上面会有一些创新。Range分区的缺点是某些特定的访问模式会导致热点。比如说根据时间列做RANGE分区，业务写入和读写数据集中在最近的时间，就可能导致各个分区负载不均衡。这只是一个缺点，业务层面还要考虑这样做的好处。比如说删除历史分区比较快。 还有种拆分方法是散列（HASH）分区，分区数量和边界是确定的（后期可以做分区分裂）。这时各个数据的分布是否均衡就取决于各个产品实现机制。大部分做法是使用一个散列（HASH）函数对Key计算一个值，然后针分段存储。 有的产品会使用这个HASH值对分区数取模，这个方法可能引起分区数据分布不均匀（若MySQL的Key分区）。此外如果要调整分区数，则需要移动所有数据。ORACLE的HASH分区时会先选取最接近分区数的一个2的幂值，对于分区数大于这个值的分区，会从前面分区里调过来。所以ORACLE 建议HASH分区数为2的幂。M有SQL建议Key分区数为奇数时数据分布最均匀。 此外在现有分区下还可以再做一次分区，分区键和分区方法都可以不一样。通常称为两级分区。比如说分库分表时，分库和分表策略不一样就是两级分区；分区表也支持两级分区。 有业务规则的分区方案的特点就是使用上。SQL如果要性能好建议带上分区键，这样分布式数据库才可以直接定位到所访问数据所在的分片；否则，数据库就要扫描所有分区去查询数据。通常分区键只能选取一个或一组业务字段，代表的是一个业务维度，那么另外一种业务维度的SQL请求性能就会不好。个别分布式数据库产品在HASH 方法上支持两种维度的分区列，其前提是在业务构造数据时让这两个列有着内部一致的分区逻辑。 详情可以参考《说说分库分表的一个最佳实践》。 另外一种分区策略就是无业务规则的，在存储级别按块的大小切分为多个定长块（Region）。这个分区对业务而言就是透明的，所以使用体验上会相对好一些。 不过，分布式数据库里的数据分区除了存储数据还要提供读写服务。业务读写数据的SQL本身是带业务逻辑的，如果一次SQL请求访问的数据分散到多个分区，而这些分区又散落在不同的节点上，不可避免的会发生跨节点的请求。如果是多表连接，这种情形更容易出现。如果这个业务请求有事务，那这就产生了分布式事务。分布式事务解决方案有两种，强一致的两阶段提交（XA）方案和最终一致的TCC方案。详情请参考《说说数据库事务和开发（下）—— 分布式事务》。 这里主要提示跨节点的请求带来的性能衰减。当然，硬件方面万兆网卡加RDMA技术下网络延时已经缩小很多，但是当分布式数据库的请求量（QPS）非常高时，或者分布式数据库是多机房部署（比如说两地三中心）时，跨机房的网络延时还是不可忽视，跨节点的请求带来的性能衰减也会很明显。所以有业务规则的分区策略可以提供策略给业务控制自己的数据分区分布特点，非常适合做异地多活和单元化类业务。此外还有个常用的规避跨节点请求读的方法就是小表广播，即将个别没有分区的表的数据复制到其他分区所在的节点，这样相关业务数据分区的JOIN就是在本地节点内部完成。这里就看复制使用的是物理同步还是逻辑同步，以及同步的延时是否满足业务需求。 分区数量关于分区数量也需要评估。如果是无规则的分区策略，由于每个分区（分片）是定长块，那么分区数量就由总数据大小除以定长块大小，对业务也是透明的。这里总结的是有业务规则的分区的数量。 使用分区的目的是为了扩展性，具体就是能将不同分区分散多多个节点上，发挥多个节点的资源和能力。所以分区数一定要大于可用的资源节点数，为了考虑到将来分布式数据库可能会扩容，分区数应该是数倍于当前规划的节点数。这是一个总的指导思想。由于不同的分布式数据库其节点的表示方法不一样，实施的时候会略有不同。 比如说在分布式数据库中间件架构里，数据存储的节点是实例，数据分区的粒度是分表（物理表），中间还有一层分库的维度。分布式数据库实例：总物理实例数：总物理分库数：总物理分表数=1:M:N:X 。X是分区的数量，N 是总分库数。X 是固定的，如果要调整分区数，成本非常高，所以一般都是提前规划好。N 是总分库数，是2的幂。 M 是实例的数量，也建议是2的幂，决定了最大能用多少节点的资源。 N/M 的结果决定了未来能扩容的倍数。分布式数据库中间件由于数据分区落在具体的节点后就不能自由移动，其扩容方式多是对每个实例一分为二，最好的途径就是利用数据库（MySQL)自身的主从复制搭建新的备实例扩容节点数。 此外分区数还要考虑到单个分区的容量和请求量是否满足需求。即分区是否到位。这个也是需要业务评估的。在使用分区表的分区方案的分布式数据库里，分区数也是结合上面两点考虑的。 当然分区数太大了，可能会增加分布数据库内部管理成本。分区数量跟分区粒度恰好是相反关系，二者都需要取一个合适的值。 分区数量一旦确定后，调整的成本非常高，通常会引起数据重分布。有些产品可以针对特定类型的分区做分区分裂。如RANGE分区可以分裂为两个RANGE， HASH分区也可以一分为二。只要这个分区分裂的逻辑是数据库内部逻辑实现，保证数据不丢，且对业务透明的，那么风险就很低值得考虑。 分区负载均衡随着时间的推移，数据库一直在发生各种变化。如QPS增加，数据集更大，或者新增/替换机器等。无论哪种都需要将部分数据分区和相应的请求从一个节点移动到另外一个节点，这个过程称为分区的再平衡（rebalance）。业务对再平衡的要求就是平衡过程中对业务当前读写影响要可控，数据读写服务不能中断。还有一点就是为了再平衡应尽可能少的迁移数据。 前面两个要求都不难满足，最后一个要求就考验各个分区方案的灵活度了。当分区粒度是存储级别的Region时，分区迁移的粒度就是Region，这个对业务也是透明的；分区粒度是分区时，这个取决于各个产品对节点资源管理的设计。比如说有的设计可以做到只需要迁移分区就可以调整各个节点的资源利用率和负载；如果分区方案是分库分表，此时分区粒度是分表。但是数据迁移的单位通常还是实例，利用数据库原生复制能力搭建新的级联备实例，然后新老实例分别删除一半分库数据。这里就迁移了不必要的很多数据分区。 分区访问路由 ...

“很多事情，说出来很多人都在做，但是只有真正做到极致，技术的差异性才会体现出来”，蚂蚁金服技术风险部研究员陈亮（花名：俊义）在接受 InfoQ 采访时如是说道。在此前的支付宝技术嘉年华，InfoQ 对支付宝数次技术架构升级的见证者及主导架构师陈亮进行了独家采访，首次系统了解稳定支撑“双十一”等多次实战背后的支付宝技术风险体系。 支付宝技术风险体系2007 年，陈亮加入支付宝，负责支付宝搜索及通信中间件架构。在之后的十年时间里，陈亮先后负责过支付宝交易拆分整体架构，这成为支付宝数据库拆分架构标准；支付宝三代架构单元化及容灾整体架构，实现异地多活，这成为支付宝单元化架构标准。如果简单总结在支付宝工作的前十年，陈亮表示： 前十年，我一直在做可扩展性相关的工作。在这期间，问题和需求驱动占据上风。陈亮回忆道：“最初的支付宝是单体架构，一个小型机加两个 Java 写的 APP，那年 DBA 就找过来说如果不进行数据库拆分，很难扛住业务发展”。 经过系列改造，这一工作终于完成。当时，陈亮以为这个架构起码可以支撑支付宝未来五到十年的发展。然而，双十一很快就来了，超大规模瞬时流量的冲击对架构提出了全新挑战，整个团队又开始马不停蹄地进行异地多活相关项目研发。 彼时，支付宝有两个主要应对技术风险的团队，一个叫技术质量团队，另一个则是运维团队。技术质量主要是各种功能测试，并解决程序 Bug、故障等问题；运维团队主要是生产偏基础设施以及应用、DB 运维管理保障，同时也会自发性地做一些技术风险相关的事情，但并未形成体系化的技术风险组织阵型及打法。 2013 年，支付宝技术团队提出质量 2.0 战略，其目的是希望在技术风险领域有一些延展，体系化沉淀 Bug 检测等方面的能力。自此，支付宝的技术风险体系建设逐渐步入正轨。 组织架构演进 2014 年，质量技术部成立希望从全域视角解决技术风险问题。但是，质量技术部并没有运维团队，主要就是通用质量检测和高可用保障相关的技术解决方案，并驱动各业务部门的技术团队落地。当时，质量技术部人员并不多，是一个小而精悍的中台部门。 经过一年多的发展，质量技术部发现仅仅依靠质量技术并不能解决生产上的各种故障风险。虽然，质量技术部会关注生产研发过程，但主要精力在于对各业务技术团队输出技术风险，比如高可用及通用质量检测的解决方案，高可用及资金保障方面尚未出现成型的平台体系。虽然当时的全链路压测和持续集成平台已有所成型，但关于高可用等并没有成型的平台。 当时，技术团队判断，不能只从质量角度看风险，而需要从更高的维度和更全面的视角看待风险。2015 年，质量技术部升级为技术风险部，专注研发及架构技术风险问题，做相应的解决方案和落地平台。 2016 年，陈亮一手打造了支付宝的 SRE（Site Risk Engineer，参考谷歌的 Site Reliability Engineer）体系。技术风险部增加 PE 和 DBA 团队，PE 团队直接对生产环节中的运营、操作等做技术风险防控，整个大团队的职能属于 SRE。据了解，这也是国内第一个 SRE 团队。 陈亮发现，传统的运维思路和文化已经无法彻底解决支付宝的稳定性问题，因此需要成立 SRE 团队。事实上，传统的运维方式侧重于靠人肉解决风险，不管是调参还是更改配置，都无法从本质上解决支付宝的稳定性问题，相反会让运维人员的工作成就感很低。说到底，运维领域的问题终究还是软件问题，需要建立软件平台更好地管理风险。 在组建 SRE 团队的过程中，陈亮认为最难的反而不是技术层面的推进，而是让团队工程师，包括整个公司认同 SRE 的价值，这需要让所有人理解 SRE 可以解决哪些新的问题以及传统的思维方式为何不可取。 据了解，支付宝的 SRE 团队主要由研发、运维和测试人员组成，八成运维人员都需要写稳定性相关的代码。团队组建完成即全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中，防抖要保证任何网络或基础设施抖动，用户都无感知；精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。 2016 年，SRE 团队建设了很多平台和能力。同时，技术团队发现了两个极为重要的现象，一是生产故障不是必然的，通常都是偶然性的；二是生产故障是低频的。这带来的问题就是故障样本很少，没有办法证明在真实故障到来时平台是否具备能力应对。也就是说，SRE 团队建设的防御系统的可靠性，无法充分验证。 2017 年，SRE 团队成立了专门的、独立职能的技术蓝军，其主要的工作就是发掘防御系统的弱点并发起真实的攻击。技术蓝军并不对各业务方负责，只对这套防御系统的稳定性和可靠性负责。 在技术蓝军看来，发生故障是必然的，只是时间早晚而已，技术蓝军会想尽办法触发这些故障，以保障在故障真实发生时，团队有足够的应付能力。目前，全栈级的技术攻防演练每周都在进行，而故障防御系统及不断优化的高可用架构则是由 SRE 团队的红军与各业务深度合作，沉淀、构建出来的。 ...

随着互联网架构的扩张，分布式系统变得日趋复杂，越来越多的组件开始走向分布式化，如微服务、消息收发、分布式数据库、分布式缓存、分布式对象存储、跨域调用，这些组件共同构成了繁杂的分布式网络。 在一次800多人的开发者调研中，当回答“现阶段构建一个高可用的分布式系统，您遇到的三个最大的难题是什么？”时，57%的开发者选择了全链路追踪。 6月12日，阿里云发布了链路追踪服务 Tracing Analysis，提供分布式系统的全链路追踪能力，帮助客户快速发现和定位分布式系统下的各类性能瓶颈，成本仅自建链路追踪系统的1/5甚至更少。 微服务架构下的分布式应用架构虽然满足了应用横向扩展需求，但是如何进行分布式应用诊断成为挑战。虽然，业内有链路追踪相关的开源解决方案，但存在着研发投入较高、自建成本较高、技术风险较大、运维难度较大的挑战。 链路追踪 Tracing Analysis源自阿里巴巴内部的经过大规模实战验证过的 EagleEye，基于 Opentracing 标准，全面兼容开源社区，可实现 Jaeger, Zipkin 和 Skywalking等开源方案在阿里云上的托管，客户无需搭建基础设施，节省运维投入和技术风险。同时，支持多语言客户端将应用的链路数据上报至链路追踪控制台，实现链路追踪的目的。 据介绍，链路追踪 Tracing Analysis 可用于链路拓扑分析，慢请求、异常请求、流量异常的问题发现和定位，并可以根据业务Tag 对业务进行统计。以某教育行业客户为例，链路追踪 Tracing Analysis 帮助客户将异常请求数从原先的3%降低到0.1%，排查5个以上线上问题。 此外，链路追踪 Tracing Analysis可帮助用户收集所有分布式微服务应用和相关PaaS产品的分布式调用信息，查看应用的依赖路径，用于业务分析和稳定性评估。以某金融行业客户为例，链路追踪 Tracing Analysis 帮助客户将将应用的平均响应时间从2秒降低到500毫秒。 值得注意的是，链路追踪 Tracing Analysis 省去了客户自建基础设施的本地存储费用，仅通过云端日志存储收取存储费用，总体的机器成本是自建全链路追踪系统的1/5或更少，并提供了每天1000请求数的免费使用额度。 目前，阿里云链路追踪 Tracing Analysis已应用于金融、游戏、教育、零售、人工智能等多个行业，帮助开发者高效的分析和诊断分布式应用架构下的性能瓶颈。 Q&A： Q1：可以通过 API 拉取链路追踪的数据吗？A1：支持，收集的链路可以通过OpenAPI的方式获取，也可以嵌入链路追踪的页面展示，也可以直接在日志服务中查看。 Q2：非阿里云服务，可以接入链路追踪？A2：链路是追踪是开放的，只要客户的应用可以访问公网，就可以接入，和有没部署在阿里云上没关系。 Q3：埋点对性能的影响有相关分析么？A3：埋点数据是异步批量上报的，会对性能有影响有限，一般在1%左右，主要看埋点的量，埋的多会影响大一点。从目前的压测数据来看，对性能影响比较小。 本文作者：中间件小哥原文链接  本文为云栖社区原创内容，未经允许不得转载。

本文发于infoq，https://www.infoq.cn/article/rhzs0KI2G*Y2r9PMdeNv 。转回自己的博客。 谈到 NoSQL，一定会提及一致性（Consistency），按照 CAP 定理，有些 NoSQL 数据库放弃了一致性，但是 NoSQL 放弃是必然的选择吗？ 从 1970’s，关系型数据库（RDB，Relational Database）被发明以来，关系型数据库就是构建应用的通常的选择。关系型数据库对用户提供 ACID 保证，非常方便开发者使用。从 1990’s 开始，NoSQL 系统开始出现。NoSQL 系统是一类对立于关系数据库的数据库系统，他们从架构上放弃了传统的关系型数据库的的关系模型和 SQL 的接口。 与 NoSQL 系统相伴而来的 2 个词是 BASE 和 CAP，这 2 个词对分布式系统有着非常深远的影响。我相信就是在这 2 个词的影响下，很多 NoSQL 系统从架构的初始就放弃了一致性（consistency）选择了一种最终一致性（Eventual consistency）和可用性 (Availability)。虽然我非常认同 CAP 和 BASE 这 2 个词，但是我不认为在 CAP 和 BASE 的作用下，NoSQL 系统选择放弃一致性是一个必然的事情。 首先来回顾一下 CAP 和 BASE 这 2 个概念的历史。这 2 个概念都是由 Eric Brewer 提出的，Brewer 目前是 Google 公司的基础设施部门（Infrastructure）的副总裁（VP，Vice President）。在 1997 年，在 SOSP(Symposium on Operating Systems Principles) 上，名为的演讲 [1] 总结了 Brewer 等人的近期工作，演讲中说他们正在工作的集群服务并没有采用当时公认的具有 ACID 特性的关系型数据库作为架构，而是在架构上放弃了关系型数据库的 ACID 特性。并且为他们的这个架构选择构造了一个新的词 BASE，BASE 这个词的选择有刻意为之成分，ACID 在英语里有酸性的意思，而 BASE 有碱性的意思，很明显 BASE 是与?ACID 对立的。 ...

一、背景对于互联网应用和企业大型应用而言，多数都尽可能地要求做到7*24小时不间断运行，而要做到完全不间断运行可以说“难于上青天”。为此，对应用可用性程度的衡量标准一般有3个9到5个9。 可用性指标计算方式不可用时间（分钟）99.9%0.1%*365*24*60525.699.99%0.01%*365*24*6052.5699.999%0.001%*365*24*605.256对于一个功能和数据量不断增加的应用，要保持比较高的可用性并非易事。为了实现高可用，宜信支付系统从避免单点故障、保证应用自身的高可用、解决交易量增长等方面做了许多探索和实践。 在不考虑外部依赖系统突发故障，如网络问题、三方支付和银行的大面积不可用等情况下，宜信支付系统的服务能力可以达到99.999%。 本文重点讨论如何提高应用自身的可用性，关于如何避免单点故障和解决交易量增长问题会在其他系列讨论。 为了提高应用的可用性，首先要做的就是尽可能避免应用出现故障，但要完全做到不出故障是不可能的。互联网是个容易产生“蝴蝶效应”的地方，任何一个看似很小的、发生概率为0的事故都可能出现，然后被无限放大。 大家都知道RabbitMQ本身是非常稳定可靠的，宜信支付系统最开始也一直在使用单点RabbitMQ，并且从未出现运行故障，所以大家在心理上都认为这个东西不太可能出问题。 直到某天，这台节点所在的物理主机硬件因为年久失修坏掉了，当时这台RabbitMQ就无法提供服务，导致系统服务瞬间不可用。 故障发生了也不可怕，最重要的是及时发现并解决故障。宜信支付系统对自身系统的要求是，秒级发现故障，快速诊断和解决故障，从而降低故障带来的负面影响。 二、问题以史为鉴。首先我们简单的回顾一下，宜信支付系统曾经碰到的一些问题： (1) 新来的开发同事在处理新接入的三方通道时，由于经验不足忽视了设置超时时间的重要性。就是这样一个小小的细节，导致这个三方队列所在的交易全部堵塞，同时影响到其他通道的交易； (2) 宜信支付系统是分布式部署的，并且支持灰度发布，所以环境和部署模块非常多而且复杂。某次增加了一个新模块，由于存在多个环境，且每个环境都是双节点，新模块上线后导致数据库的连接数不够用，从而影响其他模块功能； (3) 同样是超时问题，一个三方的超时，导致耗尽了当前所配置的所有worker threads, 以至于其他交易没有可处理的线程； (4) A三方同时提供鉴权，支付等接口，其中一个接口因为宜信支付系统交易量突增，从而触发A三方在网络运营商那边的DDoS限制。通常机房的出口IP都是固定的，从而被网络运营商误认为是来自这个出口IP的交易是流量攻击，最终导致A三方鉴权和支付接口同时不可用。 (5) 再说一个数据库的问题，同样是因为宜信支付系统交易量突增引发的。建立序列的同事给某个序列的上限是999，999，999，但数据库存的这个字段长度是32位，当交易量小的时候，系统产生的值和字段32位是匹配的，序列不会升位。可是随着交易量的增加，序列不知不觉的升位数了，结果导致32位就不够存放。 类似这样的问题对于互联网系统非常常见，并且具有隐蔽性，所以如何避免就显得非常重要了。 三、解决方案下面我们从三个方面来看宜信支付系统所做的改变。 3.1 尽可能避免故障3.1.1 设计可容错的系统 比如重路由，对于用户支付来说，用户并不关心自己的钱具体是从哪个通道支付出去的，用户只关心成功与否。宜信支付系统连接30多个通道，有可能A通道支付不成功，这个时候就需要动态重路由到B或者C通道，这样就可以通过系统重路由避免用户支付失败，实现支付容错。 还有针对OOM做容错，像Tomcat一样。系统内存总有发生用尽的情况，如果一开始就对应用本身预留一些内存，当系统发生OOM的时候，就可以catch住这个异常，从而避免这次OOM。 3.1.2 某些环节快速失败“fail fast原则”Fail fast原则是当主流程的任何一步出现问题的时候，应该快速合理地结束整个流程，而不是等到出现负面影响才处理。 举个几个例子： (1)支付系统启动的时候需要加载一些队列信息和配置信息到缓存，如果加载失败或者队列配置不正确，会造成请求处理过程的失败，对此最佳的处理方式是加载数据失败，JVM直接退出，避免后续启动不可用； (2)支付系统的实时类交易处理响应时间最长是40s，如果超过40s前置系统就不再等待，释放线程，告知商户正在处理中，后续有处理结果会以通知的方式或者业务线主动查询的方式得到结果； (3)宜信支付系统使用了redis做缓存数据库，用到的地方有实时报警埋点和验重等功能。如果连接redis超过50ms，那么这笔redis操作会自动放弃，在最坏的情况下这个操作带给支付的影响也就是50ms，控制在系统允许的范围内。 3.1.3 设计具备自我保护能力的系统系统一般都有第三方依赖，比如数据库，三方接口等。系统开发的时候，需要对第三方保持怀疑，避免第三方出现问题时候的连锁反应，导致宕机。 （1）拆分消息队列 宜信支付系统提供各种各样的支付接口给商户，常用的就有快捷，个人网银，企业网银，退款，撤销，批量代付，批量代扣，单笔代付，单笔代扣，语音支付，余额查询，身份证鉴权，银行卡鉴权，卡密鉴权等。与其对应的支付通道有微信支付，ApplePay，支付宝等30多家支付通道，并且接入了几百家商户。在这三个维度下，如何确保不同业务、三方、商户、以及支付类型互不影响，宜信支付系统所做的就是拆分消息队列。下图是部分业务消息队列拆分图： （2）限制资源的使用 对于资源使用的限制设计是高可用系统最重要的一点，也是容易被忽略的一点，资源相对有限，用的过多了，自然会导致应用宕机。为此宜信支付系统做了以下功课： 限制连接数随着分布式的横向扩展，需要考虑数据库连接数，而不是无休止的最大化。数据库的连接数是有限制的，需要全局考量所有的模块，特别是横向扩展带来的增加。 限制内存的使用内存使用过大，会导致频繁的GC和OOM，内存的使用主要来自以下两个方面： A:集合容量过大； B:未释放已经不再引用的对象，比如放入ThreadLocal的对象一直会等到线程退出的时候回收。 限制线程创建线程的无限制创建，最终导致其不可控，特别是隐藏在代码中的创建线程方法。 当系统的SY值过高时，表示linux需要花费更多的时间进行线程切换。Java造成这种现象的主要原因是创建的线程比较多，且这些线程都处于不断的阻塞（锁等待，IO等待）和执行状态的变化过程中，这就产生了大量的上下文切换。 除此之外，Java应用在创建线程时会操作JVM堆外的物理内存，太多的线程也会使用过多的物理内存。 对于线程的创建，最好通过线程池来实现，避免线程过多产生上下文切换。 限制并发做过支付系统的应该清楚，部分三方支付公司是对商户的并发有要求的。三方给开放几个并发是根据实际交易量来评估的，所以如果不控制并发，所有的交易都发给三方，那么三方只会回复“请降低提交频率”。 所以在系统设计阶段和代码review阶段都需要特别注意，将并发限制在三方允许的范围内。 我们讲到宜信支付系统为了实现系统的可用性做了三点改变，其一是尽可能避免故障，接下来讲后面两点。 3.2 及时发现故障故障就像鬼子进村，来的猝不及防。当预防的防线被冲破，如何及时拉起第二道防线，发现故障保证可用性，这时候报警监控系统的开始发挥作用了。一辆没有仪表盘的汽车，是无法知道车速和油量，转向灯是否亮，就算“老司机”水平再高也是相当危险的。同样，系统也是需要监控的，最好是出现危险的时候提前报警，这样可以在故障真正引发风险前解决。 3.2.1 实时报警系统如果没有实时报警，系统运行状态的不确定性会造成无法量化的灾难。宜信支付系统的监控系统指标如下： 实时性-实现秒级监控；全面性-覆盖所有系统业务，确保无死角覆盖；实用性-预警分为多个级别，监控人员可以方便实用地根据预警严重程度做出精确的决策；多样性-预警方式提供推拉模式，包括短信，邮件，可视化界面，方便监控人员及时发现问题。报警主要分为单机报警和集群报警，而宜信支付系统属于集群部署。实时预警主要依靠各个业务系统实时埋点数据统计分析实现，因此难度主要在数据埋点和分析系统上。 3.2.2 埋点数据要做到实时分析，又不影响交易系统的响应时间，宜信支付系统在各个模块中通过redis实时做数据埋点，然后将埋点数据汇总到分析系统，分析系统根据规则进行分析报警。 3.2.3 分析系统分析系统最难做的是业务报警点，例如哪些报警只要一出来就必须出警，哪些报警一出来只需要关注。下面我们对分析系统做一个详细介绍： (1)系统运行架构 (2)系统运行流程 ...

GitLab简介GitLab是一个利用 Ruby on Rails 开发的开源应用程序，实现一个自托管的Git项目仓库，可通过Web界面进行访问公开的或者私人项目。Ruby on Rails 是一个可以使你开发、部署、维护 web 应用程序变得简单的框架。GitLab拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。由于Git的分布式特性，即使Gitlab不可用，开发人员仍然可以在本地提交代码。但是,某些Gitlab功能，比如CI，问题跟踪和持续集成会不可用，也会严重影响线上使用。因此高可用架构还是不可缺少的。GitLab软件架构如下图所示： GitLab高可用设计主备模式：启动2个实例，只有一个工作提供服务，数据通过分布式存储保持一致 主主模式(scales)：Rails server启动多个，同时提供服务，数据库保持独立，数据通过NAS文件存储共享 GitLab高可用方案水平扩展 这种架构适用于许多Gitlab客户访问的使用场景，解决高API使用率，大量排队的Sidekiq作业的问题。 3 PostgreSQL nodes2 Redis nodes3 Consul/Sentinel nodes2 or more GitLab application nodes (Unicorn, Workhorse, Sidekiq, PGBouncer)1 NFS/Gitaly server 混合扩展 这种架构通过组件在专用节点上分离，提供高资源使各组件不会相互干扰，解决服务争用/高负载的问题。 3 PostgreSQL nodes1 PgBouncer node2 Redis nodes3 Consul/Sentinel nodes2 or more Sidekiq nodes2 or more GitLab application nodes (Unicorn, Workhorse)1 or more NFS/Gitaly servers1 Monitoring node (Prometheus, Grafana) ...

前言Kubernetes（k8s） 凭借着其优良的架构，灵活的扩展能力，丰富的应用编排模型，成为了容器编排领域的事实标准。越来越多的企业拥抱这一趋势，选择 k8s 作为容器化应用的基础设施，逐渐将自己的核心服务迁移到 k8s 之上。 可用性对基础设施而言至关重要。各大云计算厂商纷纷推出了高可用、可扩展的 k8s 托管服务，其中比较有代表性的有 Amazon EKS、Azure Kubernetes Service (AKS)、Google Kubernetes Engine、阿里云容器服务 Kubernetes 版等。 虽然公有云托管的 k8s 服务百花齐放，但很多企业仍有自建集群的需求。正是这样的原因，促进了一大批出色的 k8s 集群部署方案的诞生，他们的特点如下表所示。 部署方案特点Kubeadm1. 官方出品的部署工具，提供了 k8s 集群生命周期管理的领域知识。2. 旨在成为更高级别工具的可组合构建块。 Kubespray1. 支持在裸机和 AWS、GCE、Azure 等众多云平台上部署 k8s。2. 基于 Ansible Playbook 定义 k8s 集群部署任务。3. 支持大部分流行的 Linux 发行版。 || Kops | 1. 仅支持在 AWS、GCE 等少数云平台上部署 k8s。2. 建立在状态同步模型上，用于 dry-run 和自动幂等性。3. 能够自动生成 Terraform 配置。 || Rancher Kubernetes Engine（RKE） | 1. 著名的开源企业级容器管理平台 Rancher 提供的轻量级 k8s 安装工具。2. 支持在裸机、虚拟机、公有云上部署和管理 k8s 集群。 | ...

作者 | codedump codedump.info 博主，多年从事互联网服务器后台开发工作。可访问作者博客阅读 codedump 更多文章。 导读：Redis是被广泛使用的基础软件之一。对于工程师和架构师、运维人员来说，了解Redis的高可用方案和背后的原理，是必备的基础知识。本文作者深入分析了Redis高可用的方方面面，并且做了有效总结，相信对广大读者可以起到很好的领路作用。 Redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式： 主从复制数据。 采用哨兵监控数据节点的运行情况，一旦主节点出现问题由从节点顶上继续进行服务。 主从复制 Redis中主从节点复制数据有全量复制和部分复制之分。 旧版本全量复制功能的实现 全量复制使用snyc命令来实现，其流程是： 从服务器向主服务器发送sync命令。 主服务器在收到sync命令之后，调用bgsave命令生成最新的rdb文件，将这个文件同步给从服务器，这样从服务器载入这个rdb文件之后，状态就会和主服务器执行bgsave命令时候的一致。 主服务器将保存在命令缓冲区中的写命令同步给从服务器，从服务器执行这些命令，这样从服务器的状态就跟主服务器当前状态一致了。最大的问题是从服务器断线重连时，即便在从服务器上已经有一部分数据了，也需要进行全量复制，这样做的效率很低，于是新版本的Redis在这部分做了改进。 新版本全量复制功能的实现 新版本Redis使用psync命令来代替sync命令，该命令既可以实现完整全同步也可以实现部分同步。 复制偏移量 执行复制的双方，主从服务器，分别会维护一个复制偏移量： 主服务器每次向从服务器同步了N字节数据之后，将修改自己的复制偏移量+N。 从服务器每次从主服务器同步了N字节数据之后，将修改自己的复制偏移量+N。 复制积压缓冲区 主服务器内部维护了一个固定长度的先进先出队列做为复制积压缓冲区，其默认大小为1MB。 在主服务器进行命令传播时，不仅会将写命令同步到从服务器，还会将写命令写入复制积压缓冲区。 服务器运行ID 每个Redis服务器，都有其运行ID，运行ID由服务器在启动时自动生成，主服务器会将自己的运行ID发送给从服务器，而从服务器会将主服务器的运行ID保存起来。 从服务器Redis断线重连之后进行同步时，就是根据运行ID来判断同步的进度： 如果从服务器上面保存的主服务器运行ID与当前主服务器运行ID一致，则认为这一次断线重连连接的是之前复制的主服务器，主服务器可以继续尝试部分同步操作。 否则，如果前后两次主服务器运行ID不相同，则认为是完成全同步流程。 psync命令流程 有了前面的准备，下面开始分析psync命令的流程： 如果从服务器之前没有复制过任何主服务器，或者之前执行过slaveof no one命令，那么从服务器就会向主服务器发送psync ? -1命令，请求主服务器进行数据的全量同步。 否则，如果前面从服务器已经同步过部分数据，那么从服务器向主服务器发送psync <runid> <offset>命令，其中runid是上一次主服务器的运行id，offset是当前从服务器的复制偏移量。 前面两种情况主服务器收到psync命令之后，会出现以下三种可能： 主服务器返回+fullresync <runid> <offset>回复，表示主服务器要求与从服务器进行完整的数据全量同步操作。其中，runid是当前主服务器运行id，而offset是当前主服务器的复制偏移量。 如果主服务器应答+continue，那么表示主服务器与从服务器进行部分数据同步操作，将从服务器缺失的数据同步过来即可。 如果主服务器应答-err，那么表示主服务器版本低于2.8，识别不了psync命令，此时从服务器将向主服务器发送sync命令，执行完整的全量数据同步。 哨兵机制概述 Redis使用哨兵机制来实现高可用(HA)，其大概工作原理是： Redis使用一组哨兵（sentinel）节点来监控主从redis服务的可用性。 一旦发现Redis主节点失效，将选举出一个哨兵节点作为领导者（leader）。 哨兵领导者再从剩余的从Redis节点中选出一个Redis节点作为新的主Redis节点对外服务。 以上将Redis节点分为两类： 哨兵节点（sentinel）：负责监控节点的运行情况。 数据节点：即正常服务客户端请求的Redis节点，有主从之分。 以上是大体的流程，这个流程需要解决以下几个问题： 如何对Redis数据节点进行监控？ 如何确定一个Redis数据节点失效？ 如何选择出一个哨兵领导者节点？ 哨兵节点选择新的主Redis节点的依据是什么？ 以下来逐个回答这些问题。 三个监控任务 ...

本文整理自虎牙中间件团队在 Nacos Meetup 的现场分享，阿里巴巴中间件受权发布。 这次分享的是全球 DNS 秒级生效在虎牙的实践，以及由此产生的一些思考，整体上，分为以下5各部分： 背景介绍；方案设计和对比；高可用；具体实践和落地；规划；背景介绍虎牙用到的基础技术很多，DNS 是其中比较重要的一个环节。 DNS 的解析过程很关键，例如上图中的 DNS 解析器通过一个定位解析追踪到我们的 DNS，再到本地域名服务器迭代解析，经过根域再到.com名，最后到huya.com的根域名，获取最终的解析结果。 在这个过程中， DNS解析是天然的分布式架构，每一层都会有缓存，上一层出现问题挂掉，下一层都会有缓存进行容灾。另外，整个 DNS 协议支持面广，包括手机和 PC，我们用的编程框架里也有 DNS 解析器，服务器也会配 DNS 解析引擎，因此，DNS 在虎牙的基础设施中是很重要的部分。 虎牙的 DNS 的应用现状虎牙当前主要是依赖于公共的 DNS，相信在座的小伙伴们或多或少都会遇到过下面这些问题： 依赖公共 localDNS，解析不稳定，延迟大。记录变更生效时间长，无法及时屏蔽线路和节点异常对业务的影响。例如，权威 DNS 全球各节点数据同步时间不可控，全局生效时间超过10分钟；localDNS 缓存过期时间不可控，部分 localDNS 不遵循TTL时间，缓存时间超过48小时。内部 DNS 功能缺失，无法解决内部服务调用面临挑战。例如，时延大、解析不准、支持多种调度策略。无法满足国外业务的快速发展，虽然一些海外云厂商提供了基于 DNS 的快速扩容方案，以及基于 DNS 的数据库切换方案。方案设计和对比基于以上的问题，我们开始重新规划 DNS 的设计。 名字服务架构 整个规划会分三个方面，核心是我们做了「名字服务」的中心点，基于此，可以满足我们的需求。 一方面通过 Nacos Sync，将现有多个注册中心的服务， 同步到「名字服务」中， 通过 DNS 实现不同框架之间的 Rest 服务方式的调用， 实现例如 Eureka，Consul，Taf等框架之间的服务调用。 另一方面，在全球负载均衡的场景下，由于虎牙是以音视频业务为主，而音视频业务对节点的延迟是非常敏感的，所以我们希望一旦出现节点延迟的情况，能立马做切换。 第三个是传统 DNS 的场景， 可以满足容器和物理机的 DNS 需求， 提供本机 Agent 和集群两种方案， 通过缓存和 prefect 大大提高 DNS 解析的可用性和加快生效时间。 ...

在分布式架构环境下，服务间的依赖日益复杂，可能没有人能说清单个故障对整个系统的影响，构建一个高可用的分布式系统面临着很大挑战。在可控范围或环境下，使用 ChaosBlade 工具，对系统注入各种故障，持续提升分布式系统的容错和弹性能力，以构建高可用的分布式系统。 ChaosBlade 是什么？ChaosBlade 是一款遵循混沌工程实验原理，建立在阿里巴巴近十年故障测试和演练实践基础上，并结合了集团各业务的最佳创意和实践，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具。点击这里，了解详情。 ChaosBlade 无需编译，下载解压即可使用，支持基础资源、Java 应用、容器服务类的混沌实验，特点是操作简洁、无侵入、扩展性强。 ChaosBlade @GitHub，点击进入 下面我们以微服务分布式系统举例，一步一步构建高可用的分布式系统。 构建高可用的分布式系统ChaosBlade 的使用方式 ChaoBlade 通过 CLI 方式调用，比如我们模拟 A 服务调用 B 提供的 com.alibaba.demo.HelloService 服务下的 hello 服务延迟 3 秒，我们可以在 B 应用上注入延迟故障，仅需两步操作：第一步：准备阶段。由于 Java 应用的故障注入是通过 Java Agent 机制实现，所以首先要先挂载 agent，执行的命令是 blade prepare jvm --process <PROCESS NAME OF B APPLICATION>第二步：执行阶段，注入故障。执行命令是 blade create dubbo delay --time 3000 --service com.alibaba.demo.HelloService --methodname hello --provider，即对 B 服务提供方提供的 com.alibaba.demo.HelloService#hello 服务注入 3 秒延迟。 ChaosBlade 使用简洁，如果想了解命令的如何使用，可在命令后面添加 -h 参数，比如 blade create dubbo delay -h。更详细的 chaosblade 操作，可详见新手指南 ...

阿里妹导读：近日，蚂蚁金服副CTO 胡喜应邀做了《蚂蚁金服十五年技术架构演进之路》的演讲，分享蚂蚁金服对金融科技未来的判断，并首次对外公开蚂蚁金服技术人才培训体系以及 BASIC College 项目。主要观点：蚂蚁金服过去十五年，通过技术重塑了支付和微贷业务。Blockchain (区块链)、ArtificialIntelligence（人工智能）、Security（安全）、 IoT（物联网）和 Cloud computing（云计算），这五大 BASIC 技术仍会是金融科技的基石。BASIC 里最基础的能力是计算能力，只有不断提升计算能力，才能适应未来应用场景的千变万化。金融交易技术的核心是金融分布式中间件，关键是分布式数据库的能力。对数据不丢失，业务不停机是金融级高可用的极致追求，同时，更要具备主动发现风险和自我恢复的能力。金融级分布式系统，最终将走向云原生化。现有的中间件能力将通过 service mesh 形式下沉至基础设施。安全可信的执行环境是金融级系统的底线，安全容器将成为金融行业的强需求。金融级数据智能未来的趋势是 Big Data Base，我们需要开放式的计算架构，从统一存储规范，可插拔的引擎组件，融合计算引擎，到统一的智能 SQL，数据处理与人工智能系统将会进一步融合，最终形成开放智能计算架构的最佳实践。多样化的计算，如流、图、机器学习经常并存于业务场景中，蚂蚁金服联合 Berkeley 大学推进的新一代计算引擎 Ray，着力于打造一个多模，融合的金融级计算引擎，帮助业务以简单的函数式编程实现多样化的分布式计算功能。蚂蚁金服最新开源的SQLFlow，抽象出端到端从数据到模型的研发过程，配合底层的引擎及自动优化，我们希望让人工智能应用像 SQL一样简单。以下是蚂蚁金服副CTO胡喜的分享内容全文：蚂蚁金服过去十五年，通过技术重塑了支付服务小微贷款服务。我们认为 Blockchain (区块链)、Artificial intelligence（人工智能）、Security（安全）、 IoT（物联网）和 Cloud computing（云计算），这五大 BASIC 技术仍会是金融科创新发展的基石。 但是，在 BASIC 技术中最基础的能力是计算能力，只有不断提升计算能力，才能适应未来应用场景的千变万化。对蚂蚁来说，要解决两个最关键的计算问题，一个是在线交易支付的问题，另外就是解决金融级数据智能的问题，狭义来讲就是 OLTP 和 OLAP 的问题。 1、金融级云原生，让交易支付更简单讲到金融在线交易，肯定要讲到“双十一”。因为“双十一”是整个中国 IT 届技术驱动力的盛世，蚂蚁在“双十一”的发展过程当中，可以看到金融支付几乎每年都是三倍的增长，到今天，整个系统具备百万级每秒的伸缩支付能力。 背后到底怎么做的？有些技术能力就跟跳水项目的规定动作一样，一定要具备这些能力。比如怎么做分布式、微服务，消息队列的问题。具体到蚂蚁，更重要的是解决分布式事务的问题，怎么做高可用，怎么做一致性，数据不能有任何丢失，不能有任何偏差，到最后怎么能够完成金融级的分布式中间件，到现在为止，我们可以看到一点，在高可用，一致性方面我们已经做到在任何情况下的数据最终一致，保证每一笔支付扣款的资金安全。并且我们去年对整体内部的中间件进行了开源，SOFAStack 是我们这么多年沉淀在金融级的最佳实践，我们期待这些实践能够帮助到更多人，从最近开源的数据来看，有 23000 的 Star，100 多个同学来参与贡献，欢迎大家更多地去试用。 刚刚讲中间件是能够在跟数据库无关前提的情况下，能够把整个金融交易做好，这是我们基本的要求，但金融交易技术中最关键的是分布式数据库能力。2009 年，蚂蚁启动自主研发数据库 OceanBase，这是一个非常偏向于高可用，一致性分布式的数据库，通过 Paxos 算法解决内部一致性的问题，到今天为止，蚂蚁整个数据库全部跑在 OceanBase 之上。 我常常会说什么才是核心技术？有些人说，核心技术只要投入人就可以做好，其实不是这么回事，核心技术不仅仅是有人有资源，还需要时间的积累，是需要天时地利人和，还需要公司、整个业务的支持，才能发展到今天，做技术还是需要一点技术情怀，蚂蚁就是一直这样坚持下去，十年左右的时间坚持开发自己的数据库，从零开始写第一行代码，到现在为止，OceanBase 数据库集群最大处理峰值是 4200 万次 / 秒，单集群最大的节点超过 1000 台，最大存储容量超过 2PB，单表最大的行数是超过 3200 亿行，并且在少数副本故障的情况下，能够做到 RPO=0，RTO<30 秒，这个是我们对于数据库层面上所做一些努力。 ...

阿里妹导读：谈及国产自研数据库，就不得不提 OceanBase。与很多人想象不同的是，OceanBase 并非衔着金钥匙出生的宠儿。相反，它曾无人看好、困难重重，整个团队甚至数度濒临解散。从危在旦夕到浴火重生，OceanBase 这十年经历了什么？今天，我们一起了解它背后不为人知的故事。 OceanBase 是完全由阿里巴巴和蚂蚁金服自主研发、全球首个应用于金融核心业务的分布式关系数据库。OceanBase 的研发始于 2010 年 6 月，因为选择从零开始，研发之路从一开始就磨难重重，中途因为找不到愿意使用的业务，团队曾经濒临解散。 最终 OceanBase 还是跨越了死亡之谷，在蚂蚁金服实现了全面替代 Oracle，成功支撑了过去 5 年“双 11”蚂蚁金服全部核心业务的重压，创造了 25.6 万笔 / 秒支付峰值和 4200 万笔 / 秒请求数处理峰值这一业内全新的纪录。自 2017 年开始，OceanBase 开始走向外部商用，目前已经在数十家商业银行落地，其中包括南京银行、浙商银行、苏州银行、人保健康险等。OceanBase 帮助南京银行共同打造“鑫云 +”互金开放平台，实现贷款交易处理能力 10 倍提升，轻资产模式显著降低成本，从原有的 30~50 元 / 账户降低到上线后的 4 元 / 账户。日处理百万笔放款，平均处理时间小于 1 秒，让老百姓借钱更方便，真正实现了普惠金融。 站在现在这个时间点上顾盼今昔，蚂蚁金服高级研究员、OceanBase 创始人阳振坤认为，OceanBase 的成功其实有行业和时代的必然性。 时 机2009 年开始，大量新的非关系型数据库如雨后春笋般涌出，在整个数据库行业掀起了一场空前盛大的 NoSQL 革命，如今赫赫有名的 Redis、MongoDB 皆诞生于那一年。NoSQL 的拥护者们积极提倡使用非关系型的数据存储，从而获得丰富而随需应变的可伸缩性。这时候的关系数据库早已过了而立之年，在此期间虽然曾短暂爆发过一些所谓终结关系数据库的革命，但最终都失败了，丝毫没有动摇到关系数据库的主导地位。 但这一次似乎与以往不同，火热发展的云计算带来了对更大规模数据库的需求，而关系数据库的缺点则相应地被越来越多人诟病：不能够扩展、容量小、处理能力不够、成本又非常高。在当时的很多人看来，关系数据库的末日是真的要来了。2010 年，NoSQL 革命愈演愈烈，有行业专家发文直指“云计算时代属于 NoSQL，关系数据库已经日薄西山”。 那时阳振坤已经做了两年多的自研分布式系统，十分看好云计算系统的发展机会。同一年，阳振坤加入阿里巴巴，开始了分布式关系数据库 OceanBase 的研发。 数据库从诞生起已经有几十年的时间了，但基本上它的市场格局就没有多少变化，最早起来的几家厂商今天还是占据着统治地位。因为数据库非常难被替换，它处在整个产品或者产业链最底层的位置，替换风险很大，但收益相比起来却小得多。这也是为什么像 IBM、微软这样的后来者也无法取代 Oracle。这就导致了数据库变成了一个门槛极高、强者恒强的领域，后来者很难居上。前有 Oracle 挡道、后有 NoSQL 数据库追赶，在大部分人看来，那时候怎么也不会是自研关系数据库的好时机，但阳振坤却不这么想。 ...

轻松筹首创了“大病救助”模式，帮助了众多病患在第一时间解決了医疗资金等问题，为了从源头解决了医疗资金问题。而在轻松筹这样全球5.5亿用户信赖的大病筹款平台的背后，是日益增长的各种数据。面对这样数据量所造成的巨大挑战，阿里云POLARDB是如何帮助轻松筹践行“善DNA”的呢？本文就为大家分享。 关于轻松筹2014年9月,轻松筹成立。“轻松筹”作为公司旗下的首要产品,“善DNA”可谓贯穿了整个发展历程。轻松筹将目标聚焦在公众健康保障领域，各功能板块都与百姓的健康息息相关。由轻松筹首创的“大病救助”模式帮助众多病患在第一时间解決了医疗资金等问题。 为了从源头解决医疗资金问题,轻松筹于2016年4月推出了“轻松互助”业务,其目的在于抱团抵抗大病风险,一人患病,众人均推救助金。并与多家保险公司达成合作，推出多款会员定制的保险产品，至此,轻松筹“全民健康保障体系”正式建成。 目前,轻松筹在自主研发的“区块链”技术的加持下,再一次开创了行业先河。“阳光链”将大病救助、公益机构及互助行动的捐赠记录、资金流向公开透明，为公益事业及大病救助的发展指明了新方向。历时4年,轻松筹体系(包含大病救助、轻松互助、轻松e保、轻松公益、轻松健康)在全球183个国家和地区的用户总数超过5.5亿、筹款总额超过255亿元。 轻松筹的“大病救助”场景由轻松筹首创的“大病救助”模式，通过社交强关系为大病患者提供高效便捷的筹款渠道，目前已经帮助235万个大病家庭，筹集了255亿元善款。 轻松筹大病救助平台能够为多达千万的用户提供筹款服务，每周增加的相关数据量多达10GB，包括发起筹款的项目信息、用户分享信息、订单数据等，不断增加的数据，很容易在目前的RDS数据库上，达到存储的上限。轻松筹通过将数据迁移至阿里云POLARDB，很好的解决了存储容量和性能的瓶颈。 轻松筹基于阿里云POLARDB的简单架构设计轻松筹最为看重就是阿里云POLARDB存储容量大和免分库分表的特性。因为阿里云POLARDB采用了集群架构，并且采用了计算和存储分离以及读写分离的机制，所以其存储容量最高能够支持100TB，用户无需因为单机容量的天花板而去购买多个MySQL实例做分片，并且也不需要考虑分库分表，因此就简化应用的开发，同时也降低了运维的负担。 其次，轻松筹还看中了POLARDB强大的读写分离能力。当应用程序使用集群地址时，POLARDB通过内部的代理层对外提供服务，应用程序的请求都先经过代理，然后才访问到数据库节点。Proxy不仅可以做安全认证和保护，还可以解析SQL，把写操作发送到主节点，把读操作均衡地分发到多个只读节点，实现自动的读写分离。对于轻松筹的小程序而言，在后台使用POLARDB集群就像使用一个单点的MySQL数据库一样简单。 此外，在性能方面，阿里云POLARDB利用基于Redo的物理复制代替基于Binlog的逻辑复制，提升主备复制的效率和稳定性，即使对大表进行加索引、加字段等DDL操作，也不会造成数据库的延迟，能够实现毫秒级延迟。此外，POLARDB内置并行查询引擎，对执行时长超过1分钟的复杂分析类SQL加速效果明显。这样的性能优势能够很好地满足轻松筹的需求。 POLARDB助力“大病救助”平台数据管理效率提升 在阿里云POLARDB的强大能力的基础之上，轻松筹的“大病救助”平台的数据管理效率有了非常大的提升，其主要体现在以下三个方面： 自适应数据增长 轻松筹的大病筹款项目随着时间的累积，每年以上T以上的结构化数据进行新增进行存储。每年新增数据表达到数百个，单表数据量更是达到亿级别。由于POLARDB采用分布式存储服务，能够根据数据增长自适应增加存储空间，按照实际数据使用量进行计费，不必为数据容量的限制和升级所担忧。 724 高可用服务 阿里云POLARDB采用自带读写分离的Active-Active多活高可用集群架构 ，能够更好的监测故障和进行快速故障自动恢复，确保99.95%的高可用服务的同时，集群自带只读节点，使得系统的聚合读取性能成倍提升。 即时数据检索和查询 大病筹款的数据需要周期性批量写入到POLARDB，而同时又需要支持即时的检索查询和分析处理，POLARDB的读写分离架构，很好的支撑了这类场景。同时，POLARDB还能够在几分钟以内在线增加只读节点，进一步提升系统的吞吐处理能力，结合读写分离连接地址，自动进行请求的识别转发，通过自适应负载均衡处理，让集群的计算力能够发挥到最大，消除了计算瓶颈。 本文作者：桐碧2018阅读原文 本文为云栖社区原创内容，未经允许不得转载。

Redis实现了不定长压缩前缀的radix tree，用在集群模式下存储slot对应的的所有key信息。本文将详述在Redis中如何实现radix tree。核心数据结构raxNode是radix tree的核心数据结构，其结构体如下代码所示：typedef struct raxNode { uint32_t iskey:1; uint32_t isnull:1; uint32_t iscompr:1; uint32_t size:29; unsigned char data[];} raxNode;iskey：表示这个节点是否包含key0：没有key1：表示从头部到其父节点的路径完整的存储了key，查找的时候按子节点iskey=1来判断key是否存在isnull：是否有存储value值，比如存储元数据就只有key，没有value值。value值也是存储在data中iscompr：是否有前缀压缩，决定了data存储的数据结构size：该节点存储的字符个数data：存储子节点的信息iscompr=0：非压缩模式下，数据格式是：[header strlen=0][abc][a-ptr][b-ptr]c-ptr，有size个字符，紧跟着是size个指针，指向每个字符对应的下一个节点。size个字符之间互相没有路径联系。iscompr=1：压缩模式下，数据格式是：[header strlen=3][xyz]z-ptr，只有一个指针，指向下一个节点。size个字符是压缩字符片段Rax Insert以下用几个示例来详解rax tree插入的流程。假设j是遍历已有节点的游标，i是遍历新增节点的游标。场景一：只插入abcdz-ptr指向的叶子节点iskey=1，使用了压缩前缀。场景二：在abcd之后插入abcdef从abcd父节点的每个压缩前缀字符比较，遍历完所有abcd节点后指向了其空子节点，j = 0， i < len(abcded)。查找到abcd的空子节点，直接将ef赋值到子节点上，成为abcd的子节点。ef节点被标记为iskey=1，用来标识abcd这个key。ef节点下再创建一个空子节点，iskey=1来表示abcdef这个key。场景三：在abcd之后插入abab在abcd能找到前两位的前缀，也就是i=len(ab)，j < len(abcd)。将abcd分割成ab和cd两个子节点，cd也是一个压缩前缀节点，cd同时被标记为iskey=1，来表示ab这个key。cd下挂着一个空子节点，来标记abcd这个key。场景四：在abcd之后插入abABCabcABC在abcd中只找到了ab这个前缀，即i < len(abcABC)，j < len(abcd)。这个步骤有点复杂，分解一下：step 1：将abcd从ab之后拆分，拆分成ab、c、d 三个节点。step 2：c节点是一个非压缩的节点，c挂在ab子节点上。step 3：d节点只有一个字符，所以也是一个非压缩节点，挂在c子节点上。step 4：将ABC 拆分成了A和BC， A挂在ab子节点上，和c节点属于同一个节点，这样A就和c同属于父节点ab。step 5：将BC作为一个压缩前缀的节点，挂在A子节点下。step 6：d节点和BC节点都挂一个空子节点分别标识abcd和abcABC这两个key。场景五：在abcd之后插入Aabcabcd和Aabc没有前缀匹配，i = 0，j = 0。将abcd拆分成a、bcd两个节点，a节点是一个非压缩前缀节点。将Aabc拆分成A、abc两个节点，A节点也是一个非压缩前缀节点。将A节点挂在和a相同的父节点上。同上，在bcd和abc这两个节点下挂空子节点来分别表示两个key。Rax Remove删除删除一个key的流程比较简单，找到iskey的节点后，向上遍历父节点删除非iskey的节点。如果是非压缩的父节点并且size > 1，表示还有其他非相关的路径存在，则需要按删除子节点的模式去处理这个父节点，主要是做memove和realloc。合并删除一个key之后需要尝试做一些合并，以收敛树的高度。合并的条件是：iskey=1的节点不能合并子节点只有一个字符父节点只有一个子节点（如果父节点是压缩前缀的节点，那么只有一个子节点，满足条件。如果父节点是非压缩前缀的节点，那么只能有一个字符路径才能满足条件）结束语云数据库Redis版（ApsaraDB for Redis）是一种稳定可靠、性能卓越、可弹性伸缩的数据库服务。基于飞天分布式系统和全SSD盘高性能存储，支持主备版和集群版两套高可用架构。提供了全套的容灾切换、故障迁移、在线扩容、性能优化的数据库解决方案。欢迎各位购买使用:云数据库 Redis 版本文作者：羽洵阅读原文本文为云栖社区原创内容，未经允许不得转载。

全面云化的时代已经到来，面对一系列的新技术和挑战，数据库市场将面临怎样的变革？作为云服务提供商，如何帮助更多的企业级用户把握“云”潮，提供最高效、最具价值的数据库解决方案？日前，在阿里云峰会·北京站的数据库专场上，阿里巴巴集团副总裁、达摩院首席数据库科学家、阿⾥云智能事业群数据库产品事业部总负责⼈李飞飞针对下一代云原生数据库的技术与挑战进行了精彩分享。数据库发展与技术演进之路根据DB-Engine 2019年1月份的数据库市场趋势分析，关系型数据库依旧占据着最核心的市场份额。与此同时，数据库市场也在不断细分，图数据库、文档数据库以及NoSQL等数据库细分市场正在崛起。另一大趋势则是：以Oracle、DB2和Microsoft SQL Server三大巨头为代表的传统商业数据库所占据的市场份额不断下降，而开源和第三方数据库市场持续增长。数据库技术诞生至今，虽然已经历40多年的发展历程，但仍旧处于蓬勃发展的时期。如今，各大云计算厂商也达成了共识：数据库是连接IaaS和云上智能化应用的重要组成部分，因此从数据的产生、存储以及消费等各个环节，云产商都需要提升全链路的能力，进而满足用户连接IaaS和智能化应用的需求。随着数据库技术的不断发展，不仅出现了OLTP系统来实现事务的处理，可以实现对交易数据的实时记录；还出现了OLAP系统，借助OLAP系统可实现对于海量数据的实时分析。除此之外，还需要各类的数据库服务和管控工具支持核心的OLTP和OLAP系统。在此基础之上，针对半结构化数据和非结构化数据，NoSQL数据库解决方案应运而生。上世纪70年代末到80年代初，诞生了关系型数据库，产生了SQL查询语言以及OLTP交易处理系统。随着数据的爆发式增长以及复杂分析需求的出现，诞生了数据仓库，以及OLAP在线分析处理系统以及ETL等数据处理技术。技术发展到今天，图、文档以及时空、时序等多元异构数据量持续增长，因此也对应地出现了关系型数据库之外的NoSQL和NewSQL数据库系统。云原生时代 我们需要怎样的数据库？传统数据库往往采用单节点架构，而到了如今的云原生时代，云原生数据库通常会采用共享存储的架构方式。阿里云POLARDB所采用的就是共享存储架构，通过高速网络构建共享存储，在此之上实现存储与计算的分离，进而可以快速弹性扩容出多个计算节点。与此同时，POLARDB还可以根据用户的具体需求在存储和计算两个维度迅速地实现扩缩容。而对于用户而言，无需修改任何业务逻辑，就可以使用基于共享存储的POLARDB数据库，可以实现无侵入式迁移。除了云原生的共享存储技术之外，面对高并发、海量数据访问的挑战，也需要借助分布式架构来解决，比如为了应对每年的双11大促，阿里巴巴自身就需要去探索分布式架构。此外，针对数据的多模多态需求，阿里云也希望在用户侧提供不同查询接口，比如SQL。在存储侧，阿里云希望能够支持用户将数据存储到不同地方，并通过像SQL这样的统一接口实现对不同数据类型的统一查询访问。目前，阿里云所提供数据湖服务就是针对上述场景所演进来的云原生技术。正如前面所提到的OLTP和OLAP系统，传统的解决方案希望将读写冲突隔离开，让OLTP负责事务处理，让OLAP负责海量数据的分析任务。而在云原生时代，阿里云会借助新硬件所带来的技术红利，尽可能降低数据迁移的成本，将事务处理和数据分析整合在同一个引擎中，通过一套系统为用户无缝解决两种问题。阿里云目前已经服务了大量企业级客户，这些客户通过虚拟化、存储与计算分离来使用阿里云所提供的云资源池。因此，我们需要对于云上全部资源进行智能化监控和调配，做到快速响应，并且为用户提供最高质量的服务。而智能化的背后需要利用机器学习以及人工智能技术，从数据迁移、数据保护、弹性调度等各个维度实现自感知、自决策、自恢复以及自优化。在云原生时代，另外一个重要技术就是软硬件一体化设计。新硬件的发展为数据库系统带来了许多可不断利用的技术红利，比如RDMA网络、SSD、NVM、GPU、IPG加速等。阿里云的POLARDB共享存储就利用了RDMA网络，因此可以做到像本地节点一样快速访问远程数据库节点。对于很多云上的客户而言，可能也有金融级高可用的需求。利用高可用协议，阿里云数据库可以采用三副本架构，在本地可以实现数据库之间的无缝实时切换，在异地也可以满足不同用户对于灾备的需求，借助Binlog技术实现异地数据同步，实现金融级高可用。此外，云上用户对数据的安全性尤为看重，阿里云数据库服务从数据落盘开始，就提供了加密技术，确保全链路的数据安全。阿里云数据库服务：全域布局自主可控 兼具创新与商用价值阿里云数据库所提供的工具类产品包括数据备份、数据迁移、数据管理、混合云数据管理以及智能化诊断与优化系统等，可以帮助客户实现快速上云并且打造混合云解决方案。我们提供的核心引擎产品中，既有自主可控的自研产品，也有第三方以及开源的产品。希望通过商业数据库以及开源产品为用户提供丰富的选择，同时也希望将云计算的技术红利整合到自研数据库产品中去，进一步做深做透，真正地帮助客户解决应用第三方或者开源数据库所无法解决的痛点和问题。在OLTP方向，阿里云数据库所提供的核心产品是POLARDB以及其分布式版本POLARDB X。除此之外，阿里云也提供主流的MySQL、PostgreSQL、SQLServer以及针对于Oracle兼容的PPAS等一系列服务。针对OLAP系统，我们的核心产品是AnalyticDB、针对多源异构数据所提供的数据湖服务DLA，以及针对IoT场景的时序时空数据库TSDB。而在NoSQL领域，阿里云则提供了丰富的第三方数据库产品供客户选择，比如HBase、Redis、MongoDB以及阿里云自研的图数据库GDB等。阿里云数据库的管控平台与全链路监控服务为用户提供了智能化的全链路检测与分析，保障阿里云数据库能够为用户提供最高级别的Service Level。阿里云帮助客户打造了一条线上线下混合云数据存储的链路，从客户迁移上云开始，其可以选择阿里云DTS服务进行实时的数据上传和同步。数据上云之后，客户可选择POLARDB等云原生数据库产品进行存储，也可以借助DLA或者AnalyticDB等产品进行数据分析。而针对特定场景进行数据分析可以选用文档数据库、图数据库或者时序时空数据库等解决方案，可以借助DTS系统实现线上线下的数据同步备份，并且还可以借助HDM来进行混合云数据库管理。此外，阿里云数据库服务还提供了数据库管理套件，可以支撑用户对数据库进行管理和开发，使得管理和开发流程更为高效。这里主要为大家介绍两种云原生数据库产品，POLARDB和AnalyticDB。POLARDBPOLARDB利用RDMA网络实现了高效的共享分布式存储，借助于共享存储技术，多个计算节点中可以实现“一写多读”，并且可以根据客户的工作量需求，快速弹出多个只读节点来满足客户在高峰时刻对于计算的需求，同时也可以在存储节点上实现快速缩扩容。针对客户的应用场景以及其业务峰值峰谷的波动情况，POLARDB可以做到按量按需使用和计费，进而大大地提升了客户的数据库使用效率，节省了所需要成本。总体而言，POLARDB就是一个超级MySQL，后续POLARDB还会陆续推出兼容PostgreSQL和Oracle的版本。在一些场景下，用户需要面对高并发和海量数据访问的挑战，因此需要突破共享存储的容量上限。分布式架构的POLARDB X则利用Sharding Partition解决方案实现了存储容量的无限水平扩展。POLARDB X分布式版本也会在后续进行公测，欢迎大家试用。AnalyticDB对海量数据进行分析的时候，读写会产生一定的冲突。如果需要读取大量数据并进行分析将会极为复杂，因此推荐大家使用阿里云的实时交互式分析数据库系统AnalyticDB。AnalyticDB最核心的特点是具有支持高吞吐写入的能力，并且具有针对于行列存储所研发的存储引擎，因此可以实现实时的交互式分析。在海量数据以及高并发场景下，AnalyticDB在响应时间方面的表现都非常优秀。AnalyticDB兼容了MySQL生态，因此可以将MySQL里面的数据直接导入AnalyticDB中，可以实现对上百亿级别的数据的毫秒级查询以及百万TPS级别的写入。数据传输云服务DTS除了核心的云原生数据库产品，我们还有多款数据库工具型产品，比如数据传输云服务DTS。DTS所解决的痛点是云下客户上云所需要进行的数据传输问题，以及其在上云之后，云上与云下数据库或者从TP到AP系统之间进行实时的数据同步问题。利用DTS，用户可以实现快速、高效地增量数据同步，保证了实时数据一致。DTS还提供了数据订阅能力，可以通过不同的协议和接口来接入更多不同的数据源。数据库家族迎来新成员：图数据库GDB这里为大家介绍一款阿里云新的数据库产品——阿里云图数据库GDB，该产品目前正在阿里云官网进行公测。GDB是一种支持属性图模型，用于处理高度连接数据查询与存储的实时可靠的在线数据库，其利用了大量的云原生技术，比如存储与计算分离等。GDB支持标准的图查询语言，兼容Gremlin语法，这一点与市场主流的图数据库保持一致。GDB另外一个最核心的特点就是支持实时更新、支持OLTP级别的数据一致性，能够帮助大家在对海量的属性图进行分析存储时保证数据的一致性。GDB具有服务高可用、易于维护等云原生数据库产品的特性。比较典型的应用场景有社交网络、金融欺诈检测、实施推荐等，同时GDB还支持知识图谱等形态以及神经网络等。以赋能客户为本：降本提效 无忧发展阿里云数据库团队的目标是为客户提供企业级的云原生数据库服务，利用自身全域布局、自主可控的技术为企业客户提供快速数据上云、云上云下统一数据管理以及数据安全等服务。举例而言，阿里云数据库服务目前在杭州等城市支撑了像城市大脑这样复杂的应用，其既需要存储结构化数据也需要存储非结构数据，并且对于OLTP、OLAP、工具类产品等都提出了巨大的挑战，而借助阿里云AnalyticDB、POLARDB、DTS等利用了云原生技术的产品可以无缝地支撑城市大脑这样的复杂应用场景。以POLARDB为例，该产品于2018年8月份进行公测，2018年的年底进行商业化，到目前为止实现了在公有云平台上的快速增长。POLARDB呈现快速增长背后的核心原因就是阿里云真正地帮助客户解决自身的痛点问题，不是利用新技术来“造完锤子找钉子”，而是真正地“看到钉子再去造锤子”。POLARDB最为核心的特点就是云原生、分钟级别的弹性存储和计算、高性价比、灵活弹性的使用计费方式、高并发能力，可快速扩容多个只读节点、大容量支持、通过共享分布式存储做到了类似单机数据库的体验，对用户的业务逻辑无侵入，并且高度兼容MySQL。AnalyticDB则是一个实时交互式分析系统，无论是自制数据还是从大数据系统中获取的存储数据，都可以借助DTS工具将其迁移到AnalyticDB集群上，进行深入的商业分析、可视化以及交互式查询等。AnalyticDB能够支持上百个表的连接查询，可为客户提供毫秒级的查询服务。如今，无数用户正在阿里云上使用POLARDB和AnalyticDB这样的云原生数据库，云原生数据库也正在真正地改变客户在应用中所遇到的痛点，为他们带来更多的业务价值。总结而言，云原生时代出现了一系列的新技术和新挑战。面对这些挑战，需要对于数据库内核产品、管控平台以及数据库工具进行有机整合，才能够为客户提供最高效、最具有价值的解决方案。阿里云诚挚地邀请大家体验自身的产品和技术，希望能够与更多的客户一起合作，解决问题，也希望更多的开发者和生态合作伙伴能够基于阿里云的数据库服务和产品打造针对特定行业和领域的深度解决方案，使得云原生时代的数据库市场更加繁荣。本文作者：七幕阅读原文本文为云栖社区原创内容，未经允许不得转载。

“如果大家当时能看见原来十年后OceanBase能长成这样，可能十年前OceanBase得到的支持会好很多。但是这种如果是不存在的，很多时候你要先证明自己。” 根据工信部数据显示，1998年，中国软件企业5000家，市场规模325亿；到了2018年底，中国软件企业3.78万家，收入规模超过6.3万亿元，营收增长了193.8倍。可在最核心的基础设施三大件芯片、操作系统和数据库上，过去我们并未取得商用意义上的重大突破。不过，相比芯片和操作系统，国内数据库领域的局面要略微乐观一些。除了传统的数据库厂商、数据服务商，互联网巨头、云计算厂商、硬件厂商、新兴的创业公司也越来越多地投入到数据库的研发中。而谈及国产自研数据库，就不得不提OceanBase。OceanBase是完全由阿里巴巴和蚂蚁金服自主研发、全球首个应用于金融核心业务的分布式关系数据库。OceanBase的研发始于2010年6月，因为选择从零开始，研发之路从一开始就磨难重重，中途因为找不到愿意使用的业务，团队曾经濒临解散。最终OceanBase还是跨越了死亡之谷，在蚂蚁金服实现了全面替代Oracle，成功支撑了过去5年“双11”蚂蚁金服全部核心业务的重压，创造了25.6万笔/秒支付峰值和4200万笔/秒请求数处理峰值这一业内全新的纪录。自2017年开始，OceanBase开始走向外部商用，目前已经在数十家商业银行落地，其中包括南京银行、浙商银行、苏州银行、人保健康险等。OceanBase帮助南京银行共同打造“鑫云+”互金开放平台，实现贷款交易处理能力10倍提升，轻资产模式显著降低成本，从原有的3050元/账户降低到上线后的4元/账户。日处理百万笔放款，平均处理时间小于1 秒，让老百姓借钱更方便，真正实现了普惠金融。站在现在这个时间点上顾盼今昔，蚂蚁金服高级研究员、OceanBase创始人阳振坤认为，OceanBase的成功其实有行业和时代的必然性。这是最坏的时代，也是最好的时代2009年开始，大量新的非关系型数据库如雨后春笋般涌出，在整个数据库行业掀起了一场空前盛大的NoSQL革命。这时候的关系数据库早已过了而立之年，在此期间虽然曾短暂爆发过一些所谓终结关系数据库的革命，但丝毫没有动摇到关系数据库的主导地位。但这一次似乎与以往不同，火热发展的云计算带来了对更大规模数据库的需求，而关系数据库的缺点则相应地被越来越多人诟病：不能够扩展、容量小、处理能力不够、成本又非常高。在当时的很多人看来，关系数据库的末日是真的要来了。那时阳振坤已经做了两年多的自研分布式系统，他十分看好云计算系统的发展机会。同一年，阳振坤加入阿里巴巴，开始了分布式关系数据库OceanBase的研发。数据库从诞生起已经有几十年的时间了，但基本上它的市场格局就没有多少变化，最早起来的几家厂商今天还是占据着统治地位。因为数据库非常难被替换，它处在整个产品或者产业链最底层的位置，替换风险很大，但收益相比起来却小得多。这也是为什么像IBM、微软这样的后来者也无法取代Oracle。这就导致了数据库变成了一个门槛极高、强者恒强的领域，后来者很难居上。前有Oracle挡道、后有NoSQL数据库追赶，在大部分人看来，那时候怎么也不会是自研关系数据库的好时机，但阳振坤却不这么想。加入阿里之后，阳振坤发现无论对淘宝还是支付宝，关系数据库都扮演着十分关键的角色，在使用上根本不可能摆脱。但已有的数据库，无论是商业数据库还是开源数据库，都有非常多的局限，远远无法满足如淘宝、支付宝这样的互联网和金融业务对高扩展、高并发、高可用和低成本的需求。单机数据库已经走到了尽头，下一步只能走向分布式，而分布式恰好是阳振坤所擅长的。如果能将分布式技术揉到数据库里面，解决单机数据库存在的各种问题，对当时整个互联网的基础设施都会是一个巨大的帮助和进步。阳振坤认为他们赶上了一个“天时地利人和”的好机会。“天时”指的是互联网的爆发式增长对数据库的高并发、大数据量提出了很大的需求，有了需求去推动就会容易得多；“地利”指的是阿里内部从淘宝到蚂蚁金服拥有大量需要使用数据库的场景，OceanBase可以从不是特别重要的应用场景开始尝试，一步步地将数据库做成关键系统；“人和”指的是当时单机数据库已经走到了尽头，下一步一定是走向分布式，而当时团队成员大多是研究分布式出身，做的就是自己最擅长的工作。用阳振坤的原话就是：“这是千载难逢的机会，我们一定要做，而且一定能做成。”一个不断“破格”的人“一个不断破格的人”，这是早前某次采访中记者对阳振坤的评价。1984年阳振坤考入北京大学数学系，硕士师从本系的张恭庆院士，后又转向计算机领域，博士师从计算机系的王选院士。需要强调的是，他修完大学课程只用了3年，硕士只用了一年多，成为王选院士博士生的时候他只有24岁。1995年其所在团队研究成果获国家科技进步一等奖（排名第四），1997年也就是他32岁那年被破格晋升为教授。在他人或许都安于现状之时，他却毅然选择了离校。个中原因也不复杂，他的工作更偏于工程，而在工业界有更多的机会，也能发挥更大的作用。2002年离开北大/方正的时候，阳振坤内心很清楚自己必须要做点不一样的事情。他先是加入联想研究院担任首席研究员，负责无线通信领域的研究；后来接触到分布式系统并看好其前景，在微软亚洲研究院、百度所从事的工作都属于分布式这个范畴，前者侧重研究，后者偏重工程实践。回想在北大的那些年，阳振坤觉得特别感激的是，学数学让他有了一个很好的数学基础，后来转到计算机系以后，碰到了王选老师，又打下了一个比较牢靠的计算机基础，这才有了他后来的今天。作为对阳振坤影响最大的人，恩师王选有两点让他至今受益：一是如何判断一件事情是否有价值，二是“顶天立地”的技术理念，“顶天”就是技术上要不断追求新突破，“立地”就是要把技术做成通用产品，让整个社会都能普遍使用。其实2010年去淘宝的时候，阳振坤根本不知道自己会做什么事情。加入淘宝之后，摆在他面前的有两个选择，一个是加入正在快速发展的淘宝业务团队，去主管技术，这是一条已经能看到很大的发展机会、相对轻松的道路；另一条是阳振坤后来自己选的，从头组建团队做一个技术平台，也就是今天我们看到的OceanBase数据库。从加入淘宝到选择做自研数据库，一共只花了两个星期的时间。这不是一个容易的选择，但阳振坤相信自己的判断：“2010年选这个项目的时候，我是觉得这件事情需要做。当时互联网迅速发展带来了对大数据量、高并发的需求，大家对传统单机数据库有很大的抱怨，觉得它既没有扩展能力，又没有高并发的能力，成本还非常高，但是互联网根本就离不开关系数据库。这件事情怎么看都是一件应该要做、需要做的事情。”阳振坤没有说出来的是，这件事到底有多难。那时候阿里巴巴刚开始要“去IOE”，几乎没人想着说要自己从头做一个数据库。传统关系数据库都是通过外部硬件来保证可用性，用便宜的PC机替换高端服务器之后，硬件更容易出故障了，如何保证数据库高可用？高可用和数据一致性如何同时保证？分布式系统怎么同时实现CAP的要求？几十年来这么多做数据库的厂商，国内国外基本没有人成功过。而且从公司的业务发展的角度，也不可能等你几年把数据库做出来，再去发展业务，更可行的做法是基于开源做出一些东西，让业务先往前走。因此OceanBase立项之初，除了阳振坤和他当时的直属领导，其他人对这个项目要么不关心，要么不赞成。从零开始自研分布式关系数据库并全面替换Oracle，在当时有多少人会相信这真的能做成呢？当时整个淘宝一共只有两三千人，而Oracle有十几万人，就算整个淘宝的人全部去做数据库，跟Oracle比起来也只是很小很小的一个比例。在阳振坤看来，如果一件事情几乎所有的人都认为它很重要、需要做，这件事情就已经不是创新了。当所有人都认为这件事情要做的时候，其实做这件事情的时机已经过去了一大半。作为最底层的基础软件设施，数据库需要很长时间的积累，不可能今年做，明年就能真正大规模地用起来。 虽然在2010年选择做数据库的时候，没有太多人看重和支持，对于团队来说这可能反而是一件好事。无人关注，反倒给了团队几年积累发展的时间。阳振坤不只要自研，还要把OceanBase定位成恩师王选所说的“顶天立地”的技术产品——走标准化的路，做一个通用的关系数据库产品，而不是一个仅仅在公司内部使用的产品。每个公司使用任何产品其实都只用了其中很小的一部分功能，如果只做满足公司自用需求的数据库，可能只需要投入十分之一、五分之一的人力物力时间。而要做成通用产品就意味着必须实现所有功能，这要困难得多，团队的投入、花费的精力和时间也要大好多倍。但也因为阳振坤最初的坚持，今天的OceanBase才得以走出蚂蚁金服，走进众多银行系统。不过这都是后话了。做数据库就像在黑暗中前行，守得住寂寞、担得了压力，甚至要有近乎偏执的性格才可能跨越死亡之谷，到达最终目的地。阳振坤团队中一位新人曾经向他表达过自己的困惑，当时这位新人入职三个月了，因为有太多东西要学，什么也没做出来，而跟他同时入职天猫的新员工才来了一个月，做的系统就已经在线上使用了。阳振坤当时给新人讲了一个故事，他说：“你过三年再看，没有人还记得那个同学三年前在天猫上把网页做了什么改版，可是三年以后你今天做的东西还会在生产系统中使用。”十年蛰伏，一飞冲天OceanBase的第一个客户来自淘宝收藏夹。当时的淘宝收藏夹正处于业务高速发展期，数据库的访问量飞快增长，面临着第二年服务器数量需要翻一倍甚至几倍的局面。业务方忙于寻找解决方案的时候，阳振坤主动找上门去提出了可以用OceanBase帮他们解决问题，把服务器数量降低一个数量级。四个月出Demo，八个月出试用版，一年后系统正式上线，淘宝收藏夹就这样成了第一个吃OceanBase螃蟹的业务，新数据库取得了非常好的效果。这时候是2011年，收藏夹项目成为了OceanBase第一个小小的里程碑。但在后续一年多的时间里，OceanBase团队一直在寻找更多业务，也确实有一些业务用了，却再也没有找到像淘宝收藏夹效果这么显著的业务。做数据库难度大、周期长，前几年的投入也许有那么一点点产出，但其实跟投入比几乎微不足道，团队面临的压力可想而知。数据库少不了人力投入，OceanBase团队从最早只有阳振坤一个人，后来发展到2012年已经有30多个人了。占了这么多人头，但在公司里却没有足够多、足够重要的业务，没能产生足够大的价值和效益。团队陷入了一个比较困难的时期，甚至数度濒临解散。当被问及“中间有没有想过这事如果没做成，怎么办？”，阳振坤回答得云淡风轻：“不是每件事都能做成，那太难了。如果每件事在做之前都想着它能不能做成，那最后做成的事就会很少。”在最困难也最危险的时候，团队迎来了一丝转机。2012年底，公司把OceanBase整个团队调到了支付宝。支付宝属于金融领域，面临的数据库挑战会比其他业务更大，这相当于给了OceanBase团队一次从头开始的机会。2013年夏天，支付宝也开始启动“去IOE”，并希望能够把Oracle数据库替换掉。阳振坤又一次主动出击，向当时的主管、也是现在蚂蚁金服的CTO程立自荐了OceanBase的解决方案。金融行业数据库，最怕的就是突发故障导致数据丢失，涉及到钱的事，多了少了都是不可接受的。为了解决高可用与主备库数据一致的矛盾，OceanBase将可用性做到了数据库系统内部，用一主两备或一主多备代替一主一备。主库到备库同步的时候不要求同步到每个备库，而是同步到包括主库在内的多数库（超过半数），也就是说总共三个库中如果有两个成功了，这个事务就成功了。如果任何一台机器出了问题，这个系统的可用性和数据一致性都是可以保证的。程立认可了阳振坤提出的方案，OceanBase团队开始埋头开发，第一个要攻克的目标是支付宝交易库。2014年双11，OceanBase迎来了第一次大考。大促开始前的凌晨，各个团队都在自己的作战室里热火朝天地准备。当时任蚂蚁金服董事长的彭蕾去了OceanBase团队的作战室，问大家：“有没有信心？”阳振坤跟彭蕾开了个玩笑说：“你看我们窗子都已经打开了，如果等会出问题，我们就准备从这跳下去。”在一开始的计划里，双11交易流量的1%会切给OceanBase，但因为当时的Oracle数据库系统支撑不了汹涌而来的巨大流量，最后OceanBase成功支撑了2014年双11中10%的交易流量。经过了双11的考验之后，OceanBase得到了更多的认可和支持。后来OceanBase团队获得了2015年蚂蚁金服的CEO大奖，这也是第一次由技术团队拿到这个奖。彭蕾希望借这个奖鼓励那些能够沉下心来、扎扎实实地把一项技术做好做扎实的技术人们。2015年春夏，支付宝交易库和支付库都换成了OceanBase；2016年，支付宝账务系统上线，这也标记着OceanBase真正在金融系统最核心最关键的领域站住了脚。从2017年开始，OceanBase开始走出支付宝、走出蚂蚁金服，在商业银行推广使用，最早的两家客户是浙商银行和南京银行。仅仅用了两年多的时间，OceanBase已经在人保健康险、常熟农商行、苏州银行、广东农信等数十家商业银行和保险机构上线。2017年10月，南京银行“鑫云+”互金开放平台正式发布，这是阿里云、蚂蚁金服合作整体输出的第一次尝试，通过“鑫云”+平台的建设，南京银行互金核心系统在交易处理能力、成本控制和对接效率都得到了极大的提升。南京银行传统的线下消费金融业务开展10年，余额100亿，而与互联网平台合作开展线上业务仅一年时间业务量已达到100亿。南京银行“鑫云+”平台上线后，业务快速增长，贷款交易处理能力全面升级，从原有的10万笔/天到上线后实现100万笔/天，对普惠金融起到了更有利的支撑。轻资产模式使得单账户管理成本约为传统IOE架构的1/5至1/10，从原有的3050元/账户降到了上线后的4元/账户。“鑫云+”平台的维护人员较传统银行业务系统约为1/5左右。以往合作时银行需要分别与各个互联网平台进行对接，自项目上线后，只需对接鑫云+一家平台即可实现多家互联网平台的对接，大大减少了重复建设，提高对接效率，同时也降低了中小银行以及互联网平台的对接成本。从濒临解散到浴火重生，OceanBase已经走了快十年，但在自研关系数据库这条漫漫长路上，OceanBase才仅仅走出了一小步。在阳振坤看来，OceanBase现在“开了很大的一朵花，但是结了很小的一个果”，虽然它已经向所有人证明了通用的分布式关系数据库是能够做成的，而且能真正应用在生产系统中，但今天OceanBase的应用还很有限，远远没有充分发挥它的价值。阳振坤告诉我们，OceanBase当初没有选择基于开源或已有的技术思路开发，而是选择走分布式自研这条路，虽然走得艰难，但做成之后就会成为不可替代的优势。过去这十来年正好是分布式系统发展的十来年，转型到分布式已经成为所有人都认可的一个选择。如今，以蚂蚁金服的OceanBase为代表的分布式关系数据库，不仅解决了关系数据库的扩展性问题，也极大地降低了关系数据库的成本，还提升了可用性。现在，兼容Oracle的工作是OceanBase的重中之重。OceanBase团队的目标是，用两年时间做到Oracle业务的平滑迁移，不需要修改一行代码、不需要业务做任何调整就能够将数据库迁移过来。在阳振坤看来，能够把最早的一些想法一些创新变成产品，真的是非常艰难甚至说过程中充满痛苦的一条道路。但是OceanBase做的所有事情其实还是从业务、从客户中出发，只有技术真的能够落到生产中去，落到用户中去才是真正有价值的，否则做得再好也只是一个空中楼阁。相信未来，OceanBase还会走得更快、更远。本文作者：华蒙阅读原文本文为云栖社区原创内容，未经允许不得转载。

阿里妹导读：减少故障的最好方法就是让故障经常性的发生。通过不断重复失败过程，持续提升系统的容错和弹性能力。今天，阿里巴巴把六年来在故障演练领域的创意和实践汇浓缩而成的工具进行开源，它就是 “ChaosBlade”。如果你想要提升开发效率，不妨来了解一下。高可用架构是保障服务稳定性的核心。阿里巴巴在海量互联网服务以及历年双11场景的实践过程中，沉淀出了包括全链路压测、线上流量管控、故障演练等高可用核心技术，并通过开源和云上服务的形式对外输出，以帮助企业用户和开发者享受阿里巴巴的技术红利，提高开发效率，缩短业务的构建流程。例如，借助阿里云性能测试 PTS，高效率构建全链路压测体系，通过开源组件 Sentinel 实现限流和降级功能。这一次，经历了 6 年时间的改进和实践，累计在线上执行演练场景达数万次，我们将阿里巴巴在故障演练领域的创意和实践，浓缩成一个混沌工程工具，并将其开源，命名为 ChaosBlade。ChaosBlade 是什么？ChaosBlade 是一款遵循混沌工程实验原理，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具，可实现底层故障的注入，特点是操作简洁、无侵入、扩展性强。ChaosBlade 基于 Apache License v2.0 开源协议，目前有 chaosblade 和 chaosblade-exe-jvm 两个仓库。chaosblade 包含 CLI 和使用 Golang 实现的基础资源、容器相关的混沌实验实施执行模块。chaosblade-exe-jvm 是对运行在 JVM 上的应用实施混沌实验的执行器。ChaosBlade 社区后续还会添加 C++、Node.js 等其他语言的混沌实验执行器。为什么要开源？很多公司已经开始关注并探索混沌工程，渐渐成为测试系统高可用，构建对系统信息不可缺少的工具。但混沌工程领域目前还处于一个快速演进的阶段，最佳实践和工具框架没有统一标准。实施混沌工程可能会带来一些潜在的业务风险，经验和工具的缺失也将进一步阻止 DevOps 人员实施混沌工程。混沌工程领域目前也有很多优秀的开源工具，分别覆盖某个领域，但这些工具的使用方式千差万别，其中有些工具上手难度大，学习成本高，混沌实验能力单一，使很多人对混沌工程领域望而却步。阿里巴巴集团在混沌工程领域已经实践多年，将混沌实验工具 ChaosBlade 开源目的，我们希望：让更多人了解并加入到混沌工程领域；缩短构建混沌工程的路径；同时依靠社区的力量，完善更多的混沌实验场景，共同推进混沌工程领域的发展。ChaosBlade 能解决哪些问题？衡量微服务的容错能力通过模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，预案是否有效，同时观察系统整体的 QPS 或 RT 是否受影响。在此基础上可以缓慢增加故障节点范围，验证上游服务限流降级、熔断等是否有效。最终故障节点增加到请求服务超时，估算系统容错红线，衡量系统容错能力。验证容器编排配置是否合理通过模拟杀服务 Pod、杀节点、增大 Pod 资源负载，观察系统服务可用性，验证副本配置、资源限制配置以及 Pod 下部署的容器是否合理。测试 PaaS 层是否健壮通过模拟上层资源负载，验证调度系统的有效性；模拟依赖的分布式存储不可用，验证系统的容错能力；模拟调度节点不可用，测试调度任务是否自动迁移到可用节点；模拟主备节点故障，测试主备切换是否正常。验证监控告警的时效性通过对系统注入故障，验证监控指标是否准确，监控维度是否完善，告警阈值是否合理，告警是否快速，告警接收人是否正确，通知渠道是否可用等，提升监控告警的准确和时效性。定位与解决问题的应急能力通过故障突袭，随机对系统注入故障，考察相关人员对问题的应急能力，以及问题上报、处理流程是否合理，达到以战养战，锻炼人定位与解决问题的能力。功能和特点场景丰富度高ChaosBlade 支持的混沌实验场景不仅覆盖基础资源，如 CPU 满载、磁盘 IO 高、网络延迟等，还包括运行在 JVM 上的应用实验场景，如 Dubbo 调用超时和调用异常、指定方法延迟或抛异常以及返回特定值等，同时涉及容器相关的实验，如杀容器、杀 Pod。后续会持续的增加实验场景。使用简洁，易于理解ChaosBlade 通过 CLI 方式执行，具有友好的命令提示功能，可以简单快速的上手使用。命令的书写遵循阿里巴巴集团内多年故障测试和演练实践抽象出的故障注入模型，层次清晰，易于阅读和理解，降低了混沌工程实施的门槛。场景扩展方便所有的 ChaosBlade 实验执行器同样遵循上述提到的故障注入模型，使实验场景模型统一，便于开发和维护。模型本身通俗易懂，学习成本低，可以依据模型方便快捷的扩展更多的混沌实验场景。ChaosBlade 的演进史EOS（2012-2015）：故障演练平台的早期版本，故障注入能力通过字节码增强方式实现，模拟常见的 RPC 故障，解决微服务的强弱依赖治理问题。MonkeyKing（2016-2018）：故障演练平台的升级版本，丰富了故障场景（如：资源、容器层场景），开始在生产环境进行一些规模化的演练。AHAS（2018.9-至今）：阿里云应用高可用服务，内置演练平台的全部功能，支持可编排演练、演练插件扩展等能力，并整合了架构感知和限流降级的功能。ChaosBlade（2019.3）：是 MonkeyKing 平台底层故障注入的实现工具，通过对演练平台底层的故障注入能力进行抽象，定义了一套故障模型。配合用户友好的 CLI 工具进行开源，帮助云原生用户进行混沌工程测试。近期规划功能迭代：增强 JVM 演练场景，支持更多的 Java 主流框架，如 Redis，GRPC增强 Kubernetes 演练场景增加对 C++、Node.js 等应用的支持社区共建：欢迎访问 ChaosBlade@GitHub，参与社区共建，包括但不限于：架构设计模块设计代码实现Bug FixDemo样例文档、网站和翻译本文作者：中亭阅读原文本文来自云栖社区合作伙伴“ 阿里技术”，如需转载请联系原作者。 ...

一、 需求分析当前kubernetes集群中的worker节点可以支持添加多可用区中的ECS，这种部署方式的目的是可以让一个应用的多个pod（至少两个）能够分布在不同的可用区，起码不能分布在同一个可用区，已达到高可用或者同城灾备的部署。二、 效果图三、 实现原理为了实现上述的效果，kubernetes提供了pod的亲和性和反亲和性来保证pod在节点级别，可用区级别的高可用部署；具体的值为topologyKey：failure-domain.beta.kubernetes.io/zone。四、 实现步骤在ACK上创建完集群后，不论从哪个可用区添加节点，都会对该节点打上对应的可用区标签，比如，一个节点是属于北京可用区a的，那么在加入到kubernetes集群后，该节点上会有一个这样的标签：failure-domain.beta.kubernetes.io/zone: cn-beijing-a。在有了上述标签后，对应用进行多可用区部署时，我们就可以使用一下yaml文件来使不同的pod分配到不同的可用区。 Yaml文件示例：apiVersion: apps/v1kind: Deploymentmetadata: name: redis-cachespec: selector: matchLabels: app: store replicas: 3 template: metadata: labels: app: store spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: “failure-domain.beta.kubernetes.io/zone” containers: - name: redis-server image: redis:3.2-alpine上面yaml文件中的podAntiAffinity:部分规定了node的反亲和性，并且由于使用了topologyKey: “failure-domain.beta.kubernetes.io/zone”，如果failure-domain.beta.kubernetes.io/zone这个key有三种value，比如cn-beijing-a，cn-beijing-b，cn-beijing-c；那么pod会被分配在这三个不同的可用区。并且由于使用了preferredDuringSchedulingIgnoredDuringExecution，所以如果pod个数大于可用区个数的话，pod会尽可能的放在不同的可用区，最后会出现多出来的pod会与原有pod在同一个可用区。上面的使用方式还有很多种，包括node级别的，详细请参考：https://kubernetes.io/docs/co…由于云盘不能跨可用区挂载，如果有pod使用了存储卷，该pod需要被调度到与存储卷相同的可用区的机器上。其他存储卷比如NAS，OSS是可以采用上述部署方式的。本文作者：朱延生阅读原文本文为云栖社区原创内容，未经允许不得转载。

2019阿里云云上Hi购季活动已经于2月25日正式开启，从已开放的活动页面来看，活动分为三个阶段： 2月25日-3月04日的活动报名阶段、3月04日-3月16日的新购满返+5折抢购阶段、3月16日-3月31日的续费抽豪礼+5折抢购阶段。做为整个Hi购季非常重要的一个分会场——基础云产品分会场，3月04开放售卖！下面，云栖社区小编就为各位开发者分享该会场的攻略：丨基础云产品分会场活动阵地：https://www.aliyun.com/acts/product-section-2019/products丨关键词：全场低至5折、报名立享满返，最高可返7500元代金券丨该会场必买爆款清单报名立享新购满返，最高可返7500元代金券报名链接：https://www.aliyun.com/acts/product-section-2019/products活动规则：（一）【活动对象】满足以下全部条件的阿里云用户：1、阿里云官网已实名认证的注册会员用户2、通过本活动页面点击“立即报名”，主动确认参与活动（二）【活动时间】2019年3月4日-3月15日（满返报名时间：2月25日-3月15日）（三）【活动规则】1、活动期间，用户在阿里云官网新购、升级时长1年及以内的预付费云产品(不包括域名、商标、云通信、虚拟主机、云市场产品、专有云产品)，且累计有效消费金额满3000元，即可获得对应金额的阿里云云产品代金券具体如下：累计有效消费金额3000-9999元，每满1000返80累计有效消费金额10000-29999元，每满5000返600累计有效消费金额30000元及以上，每满5000返750，最高封顶75002、上述“有效消费金额”不包括：用户购买已享受5折及以下优惠折扣产品的消费金额、用户购买储值卡的金额、用户使用代金券支付的非实付消费金额、用户购买后又退款所产生的退款金额3、本活动仅适用于主动报名用户，未报名参加活动的用户在活动期间的消费不享受返代金券优惠4、同一用户使用多个阿里云账号参与本活动的，仅向其中有效消费金额最高的一个阿里云账号返回相应额度的代金券5、用户参与本活动所获得的代金券，将于2019年4月1日0点-24点前统一发放至对应的阿里云账户。代金券的使用有效期截至2019年4月30日24点，过期自动作废6、代金券仅限用户用于本账户下的新购、升级预付费云产品使用(不包括域名、商标、云通信、虚拟主机、云市场产品、专有云产品)，不得转让或出售，或以其他方式换取利益7、除特殊情况外，用户参加本活动购买的产品，不支持退订。如因特殊原因发生退订的，退订前需交回通过本活动所享受的相关权益，例如：补足差价、退还已使用的代金券金额、交回奖品等8、如用户在活动中存在隐瞒、虚构、作弊、欺诈或通过其他非正常手段规避活动规则、获取不当利益的行为，例如：作弊领取、恶意套现、网络攻击、虚假交易等，阿里云有权收回相关权益、取消用户的活动参与资格，撤销违规交易，必要时追究违规用户的法律责任9、活动名称仅为方便用户理解参考使用，不具有效力，实际活动内容以具体活动规则为准（四）【名词及解释】1、“阿里云官网”，是指包含域名为www.aliyun.com的网站以及阿里云客户端，如APP，但阿里云国际站，包括alibabacloud.com以及所有下属页面和jp.aliyun.com以及所有下属页面除外2、“同一用户”，是指根据不同阿里云账号在注册、登录、使用中的关联信息，阿里云判断其实际为同一用户。关联信息举例：同一证件、同一手机号、同一支付账号、同一设备、同一地址等3、“云产品”，是指阿里云官网售卖的国内节点（不含香港）的产品和服务，但不包括域名、虚拟主机、云市场产品、专有云产品，云通信产品4、活动中涉及的“打折”、“折扣”、“×折”或“省××元”，是指将本活动期间的某款产品的活动价格，与无任何活动期间的相同产品/的日常最小单位售价（例如：月价），按相同购买时长进行比较后，所获得的比较结果5、活动中涉及的“划线价格”，通常是指该产品曾经展示过的销售价，并非原价，仅供参考。但具体活动页面单独对划线价格进行说明的，以其表述为准6、“有效消费金额”，是指用户的实际付现消费金额。有效消费金额不包括：用户使用代金券、储值卡、提货券等非实付方式的消费金额；具体活动规则中明确排除的其他消费金额；退款金额等7、用户参与活动所获得的全部权益，均归属于参与活动的该阿里云账号所对应的实名认证主体8、活动中的“天”、“工作日”等均指该日的0点至24点（北京时间）9、阿里云可以根据活动的实际情况对活动规则进行变动或调整，相关变动或调整将公布在活动页面上，并于公布时即时生效；但不影响用户在活动规则调整前已经获得的权益为您省钱——上云必备云产品低至5折，助力普惠上云一、云服务器云服务器ECS、轻量应用服务器、云虚拟主机低至5折活动规则：（一）【活动对象】阿里云官网已实名认证的注册会员用户。（二）【活动时间】2019年3月4日至2019年3月31日。（三）【活动规则】1、活动期间，用户通过活动页面，购买指定产品，可享受相应的优惠折扣（以页面展示为准），具体如下：①购买如下规格的1年期ECS产品，可享受实例部分7折优惠： 计算型（c5）、通用型（g5）、内存型（r5）、网络增强型（sn1ne、sn2ne、se1ne）、高主频型（hfg5、hfc5）、异构计算（gn5i、ga1）、弹性裸金属服务器（ebmhfg5）、本地SSD型（i1、i2）；②购买如下规格的1年期ECS产品，可享受实例部分5折优惠：突发性能实例（T5）；③购买如下规格的1年期弹性计算产品，可享受5折优惠：轻量应用服务器、云虚拟主机。上述“实例部分”优惠是指仅实例部分享受优惠，不包含带宽与磁盘。2、迪拜与日本节点的弹性计算产品，不参与本次活动。3、金融云、专有云产品不在本次活动范围内。4、本活动仅限新购和升级，续费不享受本次活动优惠。5、同一用户购买5折类产品的，每款产品限购3台；同一用户拥有多个阿里云账号的，仅首个参加活动的账号可享受前述优惠折扣。6、用户参加活动所购买的相关产品及所获得的相应权益，仅限本账号使用，不得转让、出售或以其他方式换取利益。7、除特殊情况外，用户参加本活动购买的产品，不支持退订。如因特殊原因发生退订的，退订前需交回通过本活动所享受的相关权益，例如：补足差价、退还已使用的代金券金额、交回奖品等。8、如用户在活动中存在隐瞒、虚构、作弊、欺诈或通过其他非正常手段规避活动规则、获取不当利益的行为，例如：作弊领取、恶意套现、网络攻击、虚假交易等，阿里云有权收回相关权益、取消用户的活动参与资格，撤销违规交易，必要时追究违规用户的法律责任。9、活动名称仅为方便用户理解参考使用，不具有效力，实际活动内容以具体活动规则为准。（四）【名词及解释】1、“阿里云官网”，是指包含域名为www.aliyun.com的网站以及阿里云客户端，如APP，但阿里云国际站，包括alibabacloud.com以及所有下属页面和jp.aliyun.com以及所有下属页面除外。2、“同一用户”，是指根据不同阿里云账号在注册、登录、使用中的关联信息，阿里云判断其实际为同一用户。关联信息举例：同一证件、同一手机号、同一支付账号、同一设备、同一地址等。3、活动中涉及“打折”、“折扣”、“×折”或“省××元”，是指将本活动期间的某款产品/组件的活动价格，与无任何活动期间的相同产品/组件的日常最小单位售价（例如：月价），按相同购买时长进行比较后，所获得的比较结果。 4、除非有相反证据证明外，用户参与活动所获得的全部权益和相应责任，均归属于参与活动的该阿里云账号所对应的实名认证主体。5、活动中的“天”、“工作日”等均指该日的0点至24点（北京时间）。 6、阿里云可以根据活动的实际情况对活动规则进行变动或调整，相关变动或调整将公布在活动页面上，并于公布时即时生效；但不影响用户在活动规则调整前已经获得的权益。二、网络每月低至￥320.45元三、云数据库1年付7折 每年低至￥840.00元四、云安全每年每年低至￥612.00元五、云存储六、CDN&视频云七、云通信八、中间件九、企业应用十、其他产品为您省心——上云必备上云必备组合，一站式上云新体验一、互联网通用场景介绍：搭配加速产品的高可用、高可靠的弹性计算服务，带给用户最佳的访问体验免安装运维的天生高可用数据库，保障重要数据不丢失业内领先的“智能”WAF保障业务不受恶意攻击影响二、小程序场景介绍：微信小程序要求必须提供域名和SSL证书，阿里云SSL证书统一生命周期管理，一键分发到SLB负载均衡上，简化证书部署实时游戏数据优先在阿里云Redis上存取，提高用户体验，并定时持久化到RDS中去三、电商通用场景介绍：电商平台快速搭建，云产品随时升级扩容，应对高突发抢购等交易场景专业安全解决方案为电商企业保驾护航，保障业务的稳定、安全产品高效容灾，负载均衡消除单点故障，云数据库高可用性，确保企业数据安全可靠四、游戏通用场景介绍：SCDN满足未动静分离的场景下高防IP和CDN同时需要的场景多副本MongoDB满足位置信息等非结构化数据高qps访问身份认证产品助您满足未成年防沉迷系统要求五、用户营销通用场景介绍：短信、APP、邮件全方位触达客户号码认证给予客户全新的身份验证体验阿里云专属通道，内容灵活，事宜各种场景六、备份通用场景介绍：混合云备份可以将企业数据中心的数据、分支机构数据，或云上资源数据备份到混合云备份的云上备份仓库DBS支持多种环境的数据库备份，可以通过简单的配置实现数据库全量备份、增量备份以及数据恢复七、视频直播服务场景介绍：基于阿里云优质CDN服务整合直播业务必备资源提供高效流畅的直播体验八、视频点播服务场景介绍：基于阿里云优质CDN服务整合点播业务必备资源提供流畅的播放体验狂欢已“种草”，有问题咨询怎么办？面对如此折扣力度，丰富的促销活动，如果有问题建议一定要提前向云小二询问，避开购买高峰期，售前咨询：95187转1。云小二会为大家提供全方位的购买咨询、精准的配置推荐 、灵活的价格方案、1对1的贴心服务。阅读原文本文为云栖社区原创内容，未经允许不得转 载。

照例附上项目github链接本项目实现的是将一个简单的天气预报系统一步一步改造成一个SpringCloud微服务系统的过程。本章主要讲解实现服务的高可用。什么是高可用高可用HA（High Availability）是分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计减少系统不能提供服务的时间。假设系统一直能够提供服务，我们说系统的可用性是100%。如果系统每运行100个时间单位，会有1个时间单位无法提供服务，我们说系统的可用性是99%。很多公司的高可用目标是4个9，也就是99.99%，这就意味着，系统的年停机时间为8.76个小时。如何保障系统的高可用我们都知道，单点是系统高可用的大敌，单点往往是系统高可用最大的风险和敌人，应该尽量在系统设计的过程中避免单点。方法论上，高可用保证的原则是“集群化”，或者叫“冗余”：只有一个单点，挂了服务会受影响；如果有冗余备份，挂了还有其他backup能够顶上。保证系统高可用，架构设计的核心准则是：冗余。有了冗余之后，还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。所以，又往往是通过“自动故障转移”来实现系统的高可用。下面我们重点讲解通过集成Eureka设置多节点的注册中心，从而实现服务的高可用。实现服务的高可用集成Eureka我们需要将前面拆分好的四个微服务：城市数据API微服务，天气数据采集微服务，天气数据API微服务，天气预报微服务，集成Eureka，实现服务的发现与注册功能。主要的操作步骤为：添加pom.xml配置添加application.yml配置添加注解至于如何进行添加，我在上一章进行了详细的讲述，这里就不展开了。启动服务我们将各个服务生成jar包，并通过命令行指定端口进行启动，启动命令如下：java -jar micro-weather-eureka-server-1.0.0.jar –server.port=8761测试结果从上图可以看到我们有4个微服务，每个微服务启动了两个实例。每个实例已经集成了Eureka客户端，并且在Eureka服务器中完成了注册。各个微服务之间可以通过应用的名称相互访问，每个微服务启动了多个实例，这样当我们的任何一个实例挂掉了，因为在其他节点有注册，所以还可以提供服务，如此一来我们便实现了服务的高可用！

在消息队列中，当消费者去消费消息的时候，无论是通过 pull 的方式还是 push 的方式，都可能会出现大批量的消息突刺。如果此时要处理所有消息，很可能会导致系统负载过高，影响稳定性。但其实可能后面几秒之内都没有消息投递，若直接把多余的消息丢掉则没有充分利用系统处理消息的能力。我们希望可以把消息突刺均摊到一段时间内，让系统负载保持在消息处理水位之下的同时尽可能地处理更多消息，从而起到“削峰填谷”的效果：上图中红色的部分代表超出消息处理能力的部分。我们可以看到消息突刺往往都是瞬时的、不规律的，其后一段时间系统往往都会有空闲资源。我们希望把红色的那部分消息平摊到后面空闲时去处理，这样既可以保证系统负载处在一个稳定的水位，又可以尽可能地处理更多消息，这时候我们就需要一个能够控制消费端消息匀速处理的利器 — AHAS 流控降级，来为消息队列削峰填谷，保驾护航。AHAS 是如何削峰填谷的AHAS 的流控降级是面向分布式服务架构的专业流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统保护等多个维度来帮助您保障服务的稳定性，同时提供强大的聚合监控和历史监控查询功能。AHAS 专门为这种场景提供了匀速排队的控制特性，可以把突然到来的大量请求以匀速的形式均摊，以固定的间隔时间让请求通过，以稳定的速度逐步处理这些请求，起到“削峰填谷”的效果，从而避免流量突刺造成系统负载过高。同时堆积的请求将会排队，逐步进行处理；当请求排队预计超过最大超时时长的时候则直接拒绝，而不是拒绝全部请求。比如在 RocketMQ 的场景下配置了匀速模式下请求 QPS 为 5，则会每 200 ms 处理一条消息，多余的处理任务将排队；同时设置了超时时间，预计排队时长超过超时时间的处理任务将会直接被拒绝。示意图如下图所示：RocketMQ Consumer 接入示例本部分将引导您快速在 RocketMQ 消费端接入 AHAS 流控降级 Sentinel。1. 开通 AHAS首先您需要到AHAS 控制台开通 AHAS 功能（免费）。可以根据 开通 AHAS 文档 里面的指引进行开通。2. 代码改造在结合阿里云 RocketMQ Client 使用 Sentinel 时，用户需要引入 AHAS Sentinel 的依赖 ahas-sentinel-client （以 Maven 为例）：<dependency> <groupId>com.alibaba.csp</groupId> <artifactId>ahas-sentinel-client</artifactId> <version>1.1.0</version></dependency>由于 RocketMQ Client 未提供相应拦截机制，而且每次收到都可能是批量的消息，因此用户在处理消息时需要手动进行资源定义（埋点）。我们可以在处理消息的逻辑处手动进行埋点，资源名可以根据需要来确定（如 groupId + topic 的组合）： private static Action handleMessage(Message message, String groupId, String topic) { Entry entry = null; try { // 资源名称为 groupId 和 topic 的组合，便于标识，同时可以针对不同的 groupId 和 topic 配置不同的规则 entry = SphU.entry(“handleMqMessage:” + groupId + “:” + topic); // 在此处编写真实的处理逻辑 System.out.println(System.currentTimeMillis() + " | handling message: " + message); return Action.CommitMessage; } catch (BlockException ex) { // 在编写处理被流控的逻辑 // 示例：可以在此处记录错误或进行重试 System.err.println(“Blocked, will retry later: " + message); return Action.ReconsumeLater; // 会触发消息重新投递 } finally { if (entry != null) { entry.exit(); } } }消费者订阅消息的逻辑示例：Consumer consumer = ONSFactory.createConsumer(properties);consumer.subscribe(topic, “*”, (message, context) -> { return handleMessage(message);});consumer.start();更多关于 RocketMQ SDK 的信息可以参考 消息队列 RocketMQ 入门文档。3. 获取 AHAS 启动参数注意：若在本地运行接入 AHAS Sentinel 控制台需要在页面左上角选择 公网 环境，若在阿里云 ECS 环境则在页面左上角选择对应的 Region 环境。我们可以进入 AHAS 控制台，点击左侧侧边栏的 流控降级，进入 AHAS 流控降级控制台应用总览页面。在页面右上角，单击添加应用，选择 SDK 接入页签，到 配置启动参数 页签拿到需要的启动参数（详情请参考 SDK 接入文档），类似于：-Dproject.name=AppName -Dahas.license=<License>其中 project.name 配置项代表应用名（会显示在控制台，比如 MqConsumerDemo），ahas.license 配置项代表自己的授权 license（ECS 环境不需要此项）。4. 启动 Consumer，配置规则接下来我们添加获取到的启动参数，启动修改好的 Consumer 应用。由于 AHAS 流控降级需要进行资源调用才能触发初始化，因此首先需要向对应 group/topic 发送一条消息触发初始化。消费端接收到消息后，我们就可以在 AHAS Sentinel 控制台上看到我们的应用了。点击应用卡片，进入详情页面后点击左侧侧边栏的“机器列表”。我们可以在机器列表页面看到刚刚接入的机器，代表接入成功：点击“请求链路”页面，我们可以看到之前定义的资源。点击右边的“流控”按钮添加新的流控规则：我们在“流控方式”中选择“排队等待”，设置 QPS 为 10，代表每 100ms 匀速通过一个请求；并且设置最大超时时长为 2000ms，超出此超时时间的请求将不会排队，立即拒绝。配置完成后点击新建按钮。5. 发送消息，查看效果下面我们可以在 Producer 端批量发送消息，然后在 Consumer 端的控制台输出处观察效果。可以看到消息消费的速率是匀速的，大约每 100 ms 消费一条消息：1550732955137 | handling message: Hello MQ 24531550732955236 | handling message: Hello MQ 91621550732955338 | handling message: Hello MQ 49441550732955438 | handling message: Hello MQ 55821550732955538 | handling message: Hello MQ 44931550732955637 | handling message: Hello MQ 30361550732955738 | handling message: Hello MQ 13811550732955834 | handling message: Hello MQ 14501550732955937 | handling message: Hello MQ 5871同时不断有排队的处理任务完成，超出等待时长的处理请求直接被拒绝。注意在处理请求被拒绝的时候，需要根据需求决定是否需要重新消费消息。我们也可以点击左侧侧边栏的“监控详情”进入监控详情页面，查看处理消息的监控曲线：对比普通限流模式的监控曲线（最右面的部分）：如果不开启匀速模式，只是普通的限流模式，则只会同时处理 10 条消息，其余的全部被拒绝，即使后面的时间系统资源充足多余的请求也无法被处理，因而浪费了许多空闲资源。两种模式对比说明匀速模式下消息处理能力得到了更好的利用。Kafka 接入代码示例Kafka 消费端接入 AHAS 流控降级的思路与上面的 RocketMQ 类似，这里给出一个简单的代码示例：private static void handleMessage(ConsumerRecord<String, String> record, String groupId, String topic) { pool.submit(() -> { Entry entry = null; try { // 资源名称为 groupId 和 topic 的组合，便于标识，同时可以针对不同的 groupId 和 topic 配置不同的规则 entry = SphU.entry(“handleKafkaMessage:” + groupId + “:” + topic); // 在此处理消息. System.out.printf(”[%d] Receive new messages: %s%n", System.currentTimeMillis(), record.toString()); } catch (BlockException ex) { // Blocked. // NOTE: 在处理请求被拒绝的时候，需要根据需求决定是否需要重新消费消息 System.err.println(“Blocked: " + record.toString()); } finally { if (entry != null) { entry.exit(); } } });}消费消息的逻辑：while (true) { try { ConsumerRecords<String, String> records = consumer.poll(1000); // 必须在下次 poll 之前消费完这些数据, 且总耗时不得超过 SESSION_TIMEOUT_MS_CONFIG // 建议开一个单独的线程池来消费消息，然后异步返回结果 for (ConsumerRecord<String, String> record : records) { handleMessage(record, groupId, topic); } } catch (Exception e) { try { Thread.sleep(1000); } catch (Throwable ignore) { } e.printStackTrace(); }}其它以上介绍的只是 AHAS 流控降级的其中一个场景 —— 请求匀速，它还可以处理更复杂的各种情况，比如：流量控制：可以针对不同的调用关系，以不同的运行指标（如 QPS、线程数、系统负载等）为基准，对资源调用进行流量控制，将随机的请求调整成合适的形状（请求匀速、Warm Up 等）。熔断降级：当调用链路中某个资源出现不稳定的情况，如平均 RT 增高、异常比例升高的时候，会使对此资源的调用请求快速失败，避免影响其它的资源导致级联失败。系统负载保护：对系统的维度提供保护。当系统负载较高的时候，提供了对应的保护机制，让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。您可以参考 AHAS 流控降级文档 来挖掘更多的场景。本文作者：中间件小哥阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

应用配置管理（Application Configuration Management，简称 ACM）是一款应用配置中心产品。基于ACM您可以在微服务、DevOps、大数据等场景下极大地减轻配置管理的工作量，同时保证配置的安全合规。ACM 有着丰富的使用场景，本文将介绍其在 AHAS 流控降级 中的应用。什么是 AHAS 流控降级AHAS 流控降级 是面向分布式服务架构的专业流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统保护等多个维度帮助您保障服务的稳定性，同时提供强大的聚合监控和历史监控查询功能。在 AHAS 流控降级中，我们需要针对不同的资源（比如服务接口、方法）配置不同的规则（流控规则、降级规则、系统保护规则等）。由于流量的不确定性，我们的规则也需要根据流量的实时情况进行动态管理。AHAS 流控降级使用了 ACM 作为动态配置中心，借助其实时动态推送的能力达到规则实时推送的效果。如何使用 ACMAHAS 流控降级分为两部分：客户端（基于开源的 Sentinel）以及AHAS 控制台。用户使用时只需要引入 AHAS Sentinel 客户端相关依赖 ahas-sentinel-client 并在启动时指定相关参数即可接入到 AHAS 流控降级控制台，在 AHAS 控制台上查看监控、配置规则。Sentinel 抽象出了动态数据源接口，可以方便地对接任意配置中心。Sentinel 推荐使用 push 模式的动态规则源，推送流程为 Sentinel 控制台 → 配置中心 → Sentinel 数据源 → Sentinel，非常清晰：AHAS 流控降级客户端提供了 ACM 动态规则源适配，实现了监听远程规则变更的逻辑，而 AHAS 流控降级控制台实现了相应的规则推送逻辑。用户在 AHAS 流控降级控制台保存规则的时候，AHAS 控制台会在保存规则后将规则推送至 ACM 相应的坐标上，ACM 会实时地将规则 push 到接入端。AHAS 流控降级客户端的动态配置源会自动注册当前应用对应坐标的监听器监听规则变化，当监听到变更时就将其加载到 Sentinel 的规则管理器中，新的规则就生效了。以上就是 ACM 在 AHAS 流控降级中的应用场景，有关 ACM 的更多信息可以参考官方文档。本文作者：中间件小哥阅读原文本文为云栖社区原创内容，未经允许不得转载。

限流每个API接口都是有访问上限的，当访问频率或者并发量超过其承受范围时候，我们就必须考虑限流来保证接口的可用性或者降级可用性。即接口也需要安装上保险丝,以防止非预期的请求对系统压力过大而引起的系统瘫痪。通常的策略就是拒绝多余的访问，或者让多余的访问排队等待服务，或者引流。如果要准确的控制QPS，简单的做法是维护一个单位时间内的Counter，如判断单位时间已经过去，则将Counter重置零。此做法被认为没有很好的处理单位时间的边界，比如在前一秒的最后一毫秒里和下一秒的第一毫秒都触发了最大的请求数，将目光移动一下，就看到在两毫秒内发生了两倍的QPS。限流算法常用的更平滑的限流算法有两种：漏桶算法和令牌桶算法。漏桶算法漏桶(Leaky Bucket)算法思路很简单，水(请求)先进入到漏桶里，漏桶以一定的速度出水(接口有响应速率)，当水流入速度过大会直接溢出(访问频率超过接口响应速率)，然后就拒绝请求，可以看出漏桶算法能强行限制数据的传输速率。示意图如下:可见这里有两个变量，一个是桶的大小，支持流量突发增多时可以存多少的水(burst)，另一个是水桶漏洞的大小(rate)。因为漏桶的漏出速率是固定的参数，所以，即使网络中不存在资源冲突(没有发生拥塞)，漏桶算法也不能使流突发(burst)到端口速率。因此，漏桶算法对于存在突发特性的流量来说缺乏效率。令牌桶算法令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法，更加容易理解。随着时间流逝，系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反，有个水龙头在不断的加水)，如果桶已经满了就不再加了。新请求来临时，会各自拿走一个Token，如果没有Token可拿了就阻塞或者拒绝服务。令牌桶的另外一个好处是可以方便的改变速度。一旦需要提高速率，则按需提高放入桶中的令牌的速率。一般会定时(比如100毫秒)往桶中增加一定数量的令牌，有些变种算法则实时的计算应该增加的令牌的数量。

本ppt结合滴滴稳定性团队在QCON全球架构师峰会上的演讲，整理并在内部分享。基本对高可用设计体系和技术点做了全面的介绍。

广为人知的阿里分布式事务解决方案：GTS（Global Transaction Service），已正式推出开源版本，取名为“Fescar”，希望帮助业界解决微服务架构下的分布式事务问题，今天我们一起来深入了解。FESCAR on GitHubhttps://github.com/alibaba/fe…微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当前被越来越多的开发者推崇，系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。 1. 什么是微服务化带来的分布式事务问题？首先，设想一个传统的单体应用（Monolithic App），通过 3 个 Module，在同一个数据源上更新数据来完成一项业务。很自然的，整个业务过程的数据一致性由本地事务来保证。随着业务需求和架构的变化，单体应用被拆分为微服务：原来的 3 个 Module 被拆分为 3 个独立的服务，分别使用独立的数据源（Pattern: Database per service）。业务过程将由 3 个服务的调用来完成。此时，每一个服务内部的数据一致性仍有本地事务来保证。而整个业务层面的全局数据一致性要如何保障呢？这就是微服务架构下面临的，典型的分布式事务需求：我们需要一个分布式事务的解决方案保障业务全局的数据一致性。2. Fescar 的发展历程阿里是国内最早一批进行应用分布式（微服务化）改造的企业，所以很早就遇到微服务架构下的分布式事务问题。2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用提供分布式事务服务。2016 年，TXC 经过产品化改造，以 GTS（Global Transaction Service）的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。2019 年起，基于 TXC 和 GTS 的技术积累，阿里中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。TXC/GTS/Fescar 一脉相承，为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。2.1 设计初衷高速增长的互联网时代，快速试错的能力对业务来说是至关重要的：一方面，不应该因为技术架构上的微服务化和分布式事务支持的引入，给业务层面带来额外的研发负担。另一方面，引入分布式事务支持的业务应该基本保持在同一量级上的性能表现，不能因为事务机制显著拖慢业务。基于这两点，我们设计之初的最重要的考量就在于：对业务无侵入：这里的“侵入”是指，因为分布式事务这个技术问题的制约，要求应用在业务层面进行设计和改造。这种设计和改造往往会给应用带来很高的研发和维护成本。我们希望把分布式事务问题在 中间件 这个层次解决掉，不要求应用在业务层面做额外的工作。高性能：引入分布式事务的保障，必然会有额外的开销，引起性能的下降。我们希望把分布式事务引入的性能损耗降到非常低的水平，让应用不因为分布式事务的引入导致业务的可用性受影响。2.2 既有的解决方案为什么不满足？既有的分布式事务解决方案按照对业务侵入性分为两类，即：对业务无侵入的和对业务有侵入的。业务无侵入的方案既有的主流分布式事务解决方案中，对业务无侵入的只有基于 XA 的方案，但应用 XA 方案存在 3 个方面的问题：要求数据库提供对 XA 的支持。如果遇到不支持 XA（或支持得不好，比如 MySQL 5.7 以前的版本）的数据库，则不能使用。受协议本身的约束，事务资源的锁定周期长。长周期的资源锁定从业务层面来看，往往是不必要的，而因为事务资源的管理器是数据库本身，应用层无法插手。这样形成的局面就是，基于 XA 的应用往往性能会比较差，而且很难优化。已经落地的基于 XA 的分布式解决方案，都依托于重量级的应用服务器（Tuxedo/WebLogic/WebSphere 等)，这是不适用于微服务架构的。侵入业务的方案实际上，最初分布式事务只有 XA 这个唯一方案。XA 是完备的，但在实践过程中，由于种种原因（包含但不限于上面提到的 3 点）往往不得不放弃，转而从业务层面着手来解决分布式事务问题。比如：基于可靠消息的最终一致性方案TCCSaga都属于这一类。这些方案的具体机制在这里不做展开，网上这方面的论述文章非常多。总之，这些方案都要求在应用的业务层面把分布式事务技术约束考虑到设计中，通常每一个服务都需要设计实现正向和反向的幂等接口。这样的设计约束，往往会导致很高的研发和维护成本。2.3 理想的方案应该是什么样子？不可否认，侵入业务的分布式事务方案都经过大量实践验证，能有效解决问题，在各种行业的业务应用系统中起着重要作用。但回到原点来思考，这些方案的采用实际上都是迫于无奈。设想，如果基于 XA 的方案能够不那么重，并且能保证业务的性能需求，相信不会有人愿意把分布式事务问题拿到业务层面来解决。一个理想的分布式事务解决方案应该：像使用本地事务一样简单，业务逻辑只关注业务层面的需求，不需要考虑事务机制上的约束。3. 原理和设计我们要设计一个对业务无侵入的方案，所以从业务无侵入的 XA 方案来思考：是否可以在 XA 的基础上演进，解决掉 XA 方案面临的问题呢？3.1 如何定义一个分布式事务？首先，很自然的，我们可以把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的 分支事务 达成一致，要么一起成功提交，要么一起失败回滚。此外，通常分支事务本身就是一个满足 ACID 的本地事务。这是我们对分布式事务结构的基本认识，与 XA 是一致的。其次，与 XA 的模型类似，我们定义 3 个组件来协议分布式事务的处理过程。Transaction Coordinator (TC)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。Transaction Manager (TM)：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。一个典型的分布式事务过程：TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。XID 在微服务调用链路的上下文中传播。RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。TM 向 TC 发起针对 XID 的全局提交或回滚决议。TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。至此，Fescar 的协议机制总体上看与 XA 是一致的。3.2 与 XA 的差别在什么地方？架构层次XA 方案的 RM 实际上是在数据库层，RM 本质上就是数据库自身（通过提供支持 XA 的驱动程序来供应用使用）。而 Fescar 的 RM 是以二方包的形式作为中间件层部署在应用程序这一侧的，不依赖与数据库本身对协议的支持，当然也不需要数据库支持 XA 协议。这点对于微服务化的架构来说是非常重要的：应用层不需要为本地事务和分布式事务两类不同场景来适配两套不同的数据库驱动。这个设计，剥离了分布式事务方案对数据库在 协议支持 上的要求。两阶段提交先来看一下 XA 的 2PC 过程。无论 Phase2 的决议是 commit 还是 rollback，事务性资源的锁都要保持到 Phase2 完成才释放。设想一个正常运行的业务，大概率是 90% 以上的事务最终应该是成功提交的，我们是否可以在 Phase1 就将本地事务提交呢？这样 90% 以上的情况下，可以省去 Phase2 持锁的时间，整体提高效率。这个设计，在绝大多数场景减少了事务持锁时间，从而提高了事务的并发度。当然，你肯定会问：Phase1 即提交的情况下，Phase2 如何回滚呢？3.3 分支事务如何提交和回滚？首先，应用需要使用 Fescar 的 JDBC 数据源代理，也就是 Fescar 的 RM。Phase1：Fescar 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务中提交。这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在。基于这样的机制，分支的本地事务便可以在全局事务的 Phase1 提交，马上释放本地事务锁定的资源。Phase2：如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），Phase2 可以非常快速地完成。如果决议是全局回滚，RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。3.4 事务传播机制XID 是一个全局事务的唯一标识，事务传播机制要做的就是把 XID 在服务调用链路中传递下去，并绑定到服务的事务上下文中，这样，服务链路中的数据库更新操作，就都会向该 XID 代表的全局事务注册分支，纳入同一个全局事务的管辖。基于这个机制，Fescar 是可以支持任何微服务 RPC 框架的。只要在特定框架中找到可以透明传播 XID 的机制即可，比如，Dubbo 的 Filter + RpcContext。对应到 Java EE 规范和 Spring 定义的事务传播属性，Fescar 的支持如下：PROPAGATION_REQUIRED：默认支持PROPAGATION_SUPPORTS：默认支持PROPAGATION_MANDATORY：应用通过 API 来实现PROPAGATION_REQUIRES_NEW：应用通过 API 来实现PROPAGATION_NOT_SUPPORTED：应用通过 API 来实现PROPAGATION_NEVER：应用通过 API 来实现PROPAGATION_REQUIRED_NESTED：不支持3.5 隔离性全局事务的隔离性是建立在分支事务的本地隔离级别基础之上的。在数据库本地隔离级别读已提交或以上的前提下，Fescar 设计了由事务协调器维护的 全局写排他锁，来保证事务间的写隔离，将全局事务默认定义在读未提交的隔离级别上。我们对隔离级别的共识是：绝大部分应用在 读已提交 的隔离级别下工作是没有问题的。而实际上，这当中又有绝大多数的应用场景，实际上工作在读未提交的隔离级别下同样没有问题。在极端场景下，应用如果需要达到全局的 读已提交，Fescar 也提供了相应的机制来达到目的。默认，Fescar 是工作在 读无提交 的隔离级别下，保证绝大多数场景的高效性。事务的 ACID 属性在 Fescar 中的体现是一个比较复杂的话题，我们会有专门的文章来深入分析，这里不做进一步展开。4. 适用场景分析前文所述的 Fescar 的核心原理中有一个重要前提：分支事务中涉及的资源，必须是支持ACID 事务的 关系型数据库。分支的提交和回滚机制，都依赖于本地事务的保障。所以，如果应用使用的数据库是不支持事务的，或根本不是关系型数据库，就不适用。另外，目前 Fescar 的实现还存在一些局限，比如：事务隔离级别最高支持到读已提交的水平，SQL 的解析还不能涵盖全部的语法等。为了覆盖 Fescar 原生机制暂时不能支持应用场景，我们定义了另外一种工作模式。上面介绍的 Fescar 原生工作模式称为 AT（Automatic Transaction）模式，这种模式是对业务无侵入的。与之相应的另外一种工作模式称为 MT（Manual Transaction）模式，这种模式下，分支事务需要应用自己来定义业务本身及提交和回滚的逻辑。4.1 分支的基本行为模式作为全局事务一部分的分支事务，除本身的业务逻辑外，都包含 4 个与协调器交互的行为：分支注册：在分支事务的数据操作进行之前，需要向协调器注册，把即将进行的分支事务数据操作，纳入一个已经开启的全局事务的管理中去，在分支注册成功后，才可以进行数据操作。状态上报：在分支事务的数据操作完成后，需要向事务协调器上报其执行结果。分支提交：响应协调器发出的分支事务提交的请求，完成分支提交。分支回滚：响应协调器发出的分支事务回滚的请求，完成分支回滚。4.2 AT 模式分支的行为模式业务逻辑不需要关注事务机制，分支与全局事务的交互过程自动进行。4.3 MT 模式分支的行为模式业务逻辑需要被分解为 Prepare/Commit/Rollback 3 部分，形成一个 MT 分支，加入全局事务。MT 模式一方面是 AT 模式的补充。另外，更重要的价值在于，通过 MT 模式可以把众多非事务性资源纳入全局事务的管理中。4.4 混合模式因为 AT 和 MT 模式的分支从根本上行为模式是一致的，所以可以完全兼容，即，一个全局事务中，可以同时存在 AT 和 MT 的分支。这样就可以达到全面覆盖业务场景的目的：AT 模式可以支持的，使用 AT 模式；AT 模式暂时支持不了的，用 MT 模式来替代。另外，自然的，MT 模式管理的非事务性资源也可以和支持事务的关系型数据库资源一起，纳入同一个分布式事务的管理中。4.5 应用场景的远景回到我们设计的初衷：一个理想的分布式事务解决方案是不应该侵入业务的。MT 模式是在 AT 模式暂时不能完全覆盖所有场景的情况下，一个比较自然的补充方案。我们希望通过 AT 模式的不断演进增强，逐步扩大所支持的场景，MT 模式逐步收敛。未来，我们会纳入对 XA 的原生支持，用 XA 这种无侵入的方式来覆盖 AT 模式无法触达的场景。5. 扩展点5.1 微服务框架的支持事务上下文在微服务间的传播需要根据微服务框架本身的机制，订制最优的，对应用层透明的解决方案。有兴趣在这方面共建的开发者可以参考内置的对 Dubbo 的支持方案，来实现对其他微服务框架的支持。5.2 所支持的数据库类型因为 AT 涉及 SQL 的解析，所以在不同类型的数据库上工作，会有一些特定的适配。有兴趣在这方面共建的开发者可以参考内置的对 MySQL 的支持方案，来实现对其他数据库的支持。5.3 配置和服务注册发现支持接入不同的配置和服务注册发现解决方案。比如：Nacos、Eureka、ZooKeeper 等。5.4 MT 模式的场景拓展MT 模式的一个重要作用就是，可以把非关系型数据库的资源，通过 MT 模式分支的包装，纳入到全局事务的管辖中来。比如，Redis、HBase、RocketMQ 的事务消息等。有兴趣在这方面共建的开发者可以在这里贡献一系列相关生态的适配方案。5.5 事务协调器的分布式高可用方案针对不同场景，支持不同的方式作为事务协调器 Server 端的高可用方案。比如，针对事务状态的持久化，可以是基于文件的实现方案，也可以是基于数据库的实现方案；集群间的状态同步，可以是基于 RPC 通信的方案，也可以是基于高可用 KV 存储的方案。6. Roadmap蓝图绿色部分是已经开源发布出来的，黄色 部分是将在后续版本中由阿里发布出来的，蓝色部分是我们和社区共建生态部分：对不同数据库的支持，开发者可以参考 MySQL 的实现。对不同微服务框架的支持，开发者可以参考 Dubbo 的实现。对 MQ、NoSQL 的支持，开发者可以参考 TCC 的实现。配置和服务注册发现：开发者通过少量的工作可以接入任何可以提供这类服务的框架。当然，非 蓝色 的部分也非常欢迎社区参与进来，贡献更优的解决方案。另外，XA 作为分布式事务的标准，是一个完备的分布式事务解决方案不可或缺的，远景的规划中，我们一定需要把 XA 的支持加入进来。初步的版本规划v0.1.0：微服务框架支持: Dubbo数据库支持: MySQL基于 Spring AOP 的 Annotation事务协调器: 单机版本v0.5.x：微服务框架支持: Spring CloudMT 模式支持 TCC 模式事务的适配动态配置和服务发现事务协调器: 高可用集群版本v0.8.x：Metrics控制台: 监控/部署/升级/扩缩容v1.0.0：General Availability: 生产环境适用v1.5.x：数据库支持: Oracle/PostgreSQL/OceanBase不依赖 Spring AOP 的 Annotation热点数据的优化处理机制RocketMQ 事务消息纳入全局事务管理NoSQL 纳入全局事务管理的适配机制支持 HBase支持 Redisv2.0.0：支持 XA当然，项目迭代演进的过程，我们最重视的是社区的声音，路线图会和社区充分交流及时进行调整。相关链接：FESCAR on GitHub：https://github.com/alibaba/fe… GTS on Aliyun：https://help.aliyun.com/produ…本文作者：amber涂南阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

双主 + keepalived 是一个比较简单的 MySQL 高可用架构，适用于中小 MySQL 集群，今天就说说怎么用 keepalived 做 MySQL 的高可用。1 概述1.1 keepalived 简介简单地说，keepalived 就是通过管理 VIP 来实现机器的高可用的，在使用 keepalived 的情况下，只有一台服务器能够提供服务(通过 VIP 来实现)，当 Master 主机宕机后，VIP 会自动飘移到另一台服务器keepalived 采用 Master/Slave 模式, 在 Master 上设置配置文件的 VIP，当 Master 宕机后，VIP 自动漂移到另一台 keepalived 服务器上keepalived 可以用来做各种软件的高可用集群，它会一直检测服务器的状态，如果有一台服务器宕机，或工作出现故障，keepalived 将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后 keepalived 自动将服务器加入到服务器群中。1.2 keepalived 配合双主keepalived 使用默认配置只能做到主机级别的高可用，但是我们的 MySQL 要做高可用至少要增加以下功能能够检测 MySQL 服务状态主节点 read_only=0，备节点 read_only=1切换时，备节点要等待主节点同步完成所以，keepalived 实现 MySQL 高可用需要使用自定义脚本来进行扩展2 环境准备2.1 数据库环境操作前已经准备好了一套主主架构数据库，搭建方法参考 MySQL集群搭建(2)-主主从模式节点信息IP系统端口MySQL版本节点读写说明10.0.0.247Centos6.533065.7.9Master读写主节点10.0.0.248Centos6.533065.7.9Standby只读,可切换为读写备主节点VIP 信息简称VIP类型RW-VIP10.0.0.237读写VIPMaster 参考配置[client]port = 3306default-character-set=utf8mb4socket = /data/mysql_db/test_db/mysql.sock[mysqld]datadir = /data/mysql_db/test_dbbasedir = /usr/local/mysql57tmpdir = /tmpsocket = /data/mysql_db/test_db/mysql.sockpid-file = /data/mysql_db/test_db/mysql.pidskip-external-locking = 1skip-name-resolve = 1port = 3306server_id = 2473306default-storage-engine = InnoDBcharacter-set-server = utf8mb4default_password_lifetime=0auto_increment_offset = 1auto_increment_increment = 2#### log ####log_timestamps=systemlog_bin = /data/mysql_log/test_db/mysql-binlog_bin_index = /data/mysql_log/test_db/mysql-bin.indexbinlog_format = rowrelay_log_recovery=ONrelay_log=/data/mysql_log/test_db/mysql-relay-binrelay_log_index=/data/mysql_log/test_db/mysql-relay-bin.indexlog_error = /data/mysql_log/test_db/mysql-error.log#### replication ####log_slave_updates = 1replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%#### semi sync replication settings #####plugin_dir=/usr/local/mysql57/lib/pluginplugin_load = “rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"loose_rpl_semi_sync_master_enabled = 1loose_rpl_semi_sync_slave_enabled = 1Slave 参考配置[client]port = 3306default-character-set=utf8mb4socket = /data/mysql_db/test_db/mysql.sock[mysqld]datadir = /data/mysql_db/test_dbbasedir = /usr/local/mysql57tmpdir = /tmpsocket = /data/mysql_db/test_db/mysql.sockpid-file = /data/mysql_db/test_db/mysql.pidskip-external-locking = 1skip-name-resolve = 1port = 3306server_id = 2483306default-storage-engine = InnoDBcharacter-set-server = utf8mb4default_password_lifetime=0auto_increment_offset = 2auto_increment_increment = 2#### log ####log_timestamps=systemlog_bin = /data/mysql_log/test_db/mysql-binlog_bin_index = /data/mysql_log/test_db/mysql-bin.indexbinlog_format = rowrelay_log_recovery=ONrelay_log=/data/mysql_log/test_db/mysql-relay-binrelay_log_index=/data/mysql_log/test_db/mysql-relay-bin.indexlog_error = /data/mysql_log/test_db/mysql-error.log#### replication ####log_slave_updates = 1replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%#### semi sync replication settings #####plugin_dir=/usr/local/mysql57/lib/pluginplugin_load = “rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"loose_rpl_semi_sync_master_enabled = 1loose_rpl_semi_sync_slave_enabled = 12.2 创建监控用的账号- 由于是测试环境，账号密码设置比较随便create user monitor@’localhost’ identified by ‘monitor’;grant all on . to monitor@’localhost’;flush privileges;2.3 安装 keepalived我们在 Master 和 Slave 上部署 keepalived1). yum 安装如果有对应的 yum 源，直接安装就可以了yum install -y keepalived2). 源码安装下载安装包, 下载地址 keepalived, 使用 1.2.24 版本举例# 安装依赖yum install -y gcc popt-devel openssl openssl-devel libssl-dev libnl-devel popt-devel libnfnetlink-devel# 下载包wget http://www.keepalived.org/software/keepalived-1.2.24.tar.gz# 解压安装tar -xvz -f keepalived-1.2.24.tar.gzcd keepalived-1.2.24./configure –prefix=/usr/local/keepalivedmake && make installcp /usr/local/keepalived/sbin/keepalived /usr/sbin/cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/mkdir /etc/keepalived/cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/3 配置高可用3.1 keepalived 配置打开 /etc/keepalived/keepalived.conf 文件, 按照实际情况加上下面的配置global_defs { router_id MYSQL_MM # 标识 vrrp_skip_check_adv_addr vrrp_strict # 严格执行 VRRP 协议规范 vrrp_garp_interval 0 vrrp_gna_interval 0}vrrp_script check_mysql { script “/bin/sh /etc/keepalived/keepalived_mysql_check.sh” # 检查脚本 interval 10 # 检查周期}vrrp_instance MYSQL_MM { state BACKUP # 都设为 BACKUP，避免起来后抢占 interface eth0 # 网卡名称，根据实际情况填写 virtual_router_id 243 # 用来区分 VRRP 组播的标记，取值 0-255 priority 100 advert_int 1 nopreempt # 设为非抢占 authentication { auth_type PASS auth_pass 1111 } # Master 节点可以注释掉下面语句，防止启动 keepalived 的时候执行脚本 notify_master “/bin/sh /etc/keepalived/keepalived_mysql_start.sh” # 变为 MASTER 时执行 virtual_ipaddress { 10.0.0.237 } # Slave 节点可以注释下面检查脚本，Slave 没有必要一直检查 track_script { check_mysql }}3.2 配置检查脚本打开 /etc/keepalived/keepalived_mysql_check.sh， 写入检测脚本#!/bin/sh# @Author: chengqm# MySQL 检测脚本MyPath=$(cd $(dirname $0); pwd)cd $MyPathThisTime=date '+%F %T'log_file=’/var/log/keepalived_mysql.log’# MySQL 连接方式，根据实际情况调整export MYSQL_PWD=‘monitor’MYSQL_USER=‘monitor’MYSQL_SOCKET="/data/mysql_db/test_db/mysql.sock"mysql_connect=“mysql -u${MYSQL_USER} -S${MYSQL_SOCKET} “# 美化输出function techo() { message=$1 message_level=$2 if [ -e $message_level ];then message_level=‘info’ fi echo “date '+%F %T' - [${message_level}] $message” >> $log_file}# 检查函数, 正常返回 0function check { ret=$mysql_connect -N -e 'select 1 as value' if [ $? -ne 0 ] || [ $ret -ne ‘1’ ];then return 1 else return 0 fi}function read_only { param=$1 $mysql_connect -e “set global read_only = ${param}” techo “设置是否只读 read_only ${param}”}# 失效转移function failover { techo “开始执行失效转移” # 1. 停止 keepalived killall keepalived # 2. 如果还能执行的话，设为 read_only read_only 1 if [ $? -eq 0 ];then # 3. 如果还能执行，kill 所有的连接 $mysql_connect -e “select concat(‘KILL ‘,id,’;’) from information_schema.processlist where user!=‘root’ AND db is not null into outfile ‘/tmp/kill.txt.${ThisTime}’;” if [ $? -eq 0 ];then $mysql_connect -e “source /tmp/kill.txt.${ThisTime};” fi fi # 4. 其他操作，比如说自动关机 techo “失效转移执行成功，当前数据库关闭访问”}# 有问题检查 4 次for ((i=1; i<=4; i ++)) do check if [ $? -eq 0 ];then techo “MySQL is ok” # 正常退出脚本 exit 0 else techo “Connection failed $i time(s)” sleep 1 fidonetecho ‘无法连接当前数据库’# 失效转移failover注意：脚本没有经过严格测试，需要根据实际情况调整3.3 配置提升为 Master 时执行的脚本打开 /bin/sh /etc/keepalived/keepalived_mysql_start.sh”, 写入脚本内容#!/bin/sh# @Author: chengqm# keepalived 变为 Master 时执行MyPath=$(cd $(dirname $0); pwd)cd $MyPathThisTime=date '+%F %T'log_file=’/var/log/keepalived_mysql.log’# MySQL 连接方式，根据实际情况调整export MYSQL_PWD=‘monitor’MYSQL_USER=‘monitor’MYSQL_SOCKET="/data/mysql_db/test_db/mysql.sock"mysql_connect=“mysql -u${MYSQL_USER} -S${MYSQL_SOCKET} “# 美化输出function techo() { message=$1 message_level=$2 if [ -e $message_level ];then message_level=‘info’ fi echo “date '+%F %T' - [${message_level}] $message” >> $log_file}# 检查函数, 正常返回 0function check { ret=$mysql_connect -N -e 'select 1 as value' if [ $? -ne 0 ] || [ $ret -ne ‘1’ ];then return 1 else return 0 fi}# 获取 slave status 的信息function slave_info() { tmp_file=/tmp/slave_info.tmp $mysql_connect -e ‘show slave status\G’ > /tmp/slave_info.tmp slave_sql=grep 'Slave_SQL_Running:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' seconds_behind_master=grep 'Seconds_Behind_Master:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' master_log_file=grep 'Master_Log_File:' $tmp_file | head -1 | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' master_log_pos=grep 'Read_Master_Log_Pos:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' relay_master_log_file=grep 'Relay_Master_Log_File:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}' exec_master_log_pos=grep 'Exec_Master_Log_Pos:' $tmp_file | sed 's/\s*//g' | tr "A-Z" "a-z" | awk -F":" '{print $2}'}# 设置是否可读function read_only { param=$1 $mysql_connect -e “set global read_only = ${param}” techo “设置是否只读 read_only ${param}”}# 处理数据同步function sync_master_log() { # 如果是数据一致性优先，等待同步完毕。如果是服务可用性优先，可以注销下面的代码 slave_info if [ $slave_sql == “yes” ];then techo “当前同步位置 Master ${master_log_file} ${master_log_pos}” techo “等待同步到 Master ${master_log_file} ${master_log_pos}” $mysql_connect -e “select master_pos_wait(’$master_log_file’, $master_log_pos);” > /dev/null techo “同步完毕” fi}techo “当前数据库提升为主库"checkif [ $? -ne 0 ];then techo “无法连接当前数据库” exit 1fi# 等待同步sync_master_log# 设为可写read_only 0注意：脚本没有经过严格测试，需要根据实际情况调整3.4 启动 keepalived由于配置了 BACKUP 模式，所以两个 keepalived 先起来的是主，先后在主备节点执行/etc/init.d/keepalived start检查 /var/log/message 日志，确认 keepalived 没有报错检查 Master IP 状态, 确认设置了 VIP[root@cluster01 shell]# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e🇩🇪80:33 brd ff:ff:ff:ff:ff:ff inet 10.0.0.247/16 brd 10.0.255.255 scope global eth0 inet 10.0.0.237/32 scope global eth0 inet6 fe80::f816:3eff:fede:8033/64 scope link valid_lft forever preferred_lft forever检查 MySQL 检测脚本执行情况，确认正常运行[root@cluster01 ~]# tail -f /var/log/keepalived_mysql.log …2019-01-28 15:04:18 - [info] MySQL is ok2019-01-28 15:04:28 - [info] MySQL is ok4 失效转移测试在 mytest 库里新建 nowdate 测试表，只有 id 和 ctime 字段，然后每秒插入一条数据[root@cluster03 ~]# while true; do date;mysql -h10.0.0.237 -P3306 -umytest -e ‘use mytest;insert into nowdate values (null, now());’; sleep 1;doneMon Jan 28 15:04:26 CST 2019Mon Jan 28 15:04:27 CST 2019…kill 掉 Master 进程killall mysqld查看旧 Master 日志2019-01-28 15:04:48 - [info] MySQL is ok2019-01-28 15:04:58 - [info] Connection failed 1 time(s)2019-01-28 15:04:59 - [info] Connection failed 2 time(s)2019-01-28 15:05:00 - [info] Connection failed 3 time(s)2019-01-28 15:05:01 - [info] Connection failed 4 time(s)2019-01-28 15:05:02 - [info] 无法连接当前数据库2019-01-28 15:05:02 - [info] 开始执行失效转移2019-01-28 15:05:02 - [info] 设置是否只读 read_only 12019-01-28 15:05:02 - [info] 失效转移执行成功，当前数据库关闭访问查看新 Master 日志2019-01-28 15:05:04 - [info] 当前数据库提升为主库2019-01-28 15:05:04 - [info] 当前同步位置 Master mysql-bin.000015 323382019-01-28 15:05:04 - [info] 等待同步到 Master mysql-bin.000015 323382019-01-28 15:05:04 - [info] 同步完毕2019-01-28 15:05:04 - [info] 设置是否只读 read_only 02019-01-28 15:05:05 - [info] MySQL is ok查看新 Master IP，确认 VIP 已经飘过来了[root@cluster02 ~]# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:66:7e:e8 brd ff:ff:ff:ff:ff:ff inet 10.0.0.248/16 brd 10.0.255.255 scope global eth0 inet 10.0.0.237/32 scope global eth0 inet6 fe80::f816:3eff:fe66:7ee8/64 scope link valid_lft forever preferred_lft forever查看插入数据执行情况，大概有 12 秒是不可用的Mon Jan 28 15:04:51 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:52 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:53 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:54 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:55 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:56 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:57 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:04:58 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:00 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:01 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:02 CST 2019ERROR 2003 (HY000): Can’t connect to MySQL server on ‘10.0.0.237’ (111)Mon Jan 28 15:05:03 CST 2019失效切换成功5 总结使用双主 + keepalived 的优点是部署简单，双主加半同步情况下，理论上不会丢数据，适用于中小型 MySQL 集群。缺点也比较明显，就是增加从节点的情况下，从节点不会主动切换同步对象，而且脚本需要自己实现，有一定风险。 ...

背景信息目标本文主要介绍如何让阿里云日志服务与您的SIEM方案(如Splunk)对接, 以便确保阿里云上的所有法规、审计、与其他相关日志能够导入到您的安全运维中心（SOC）中。名词解释LOG（SLS） - 阿里云日志服务，简写SLS表示（Simple Log Service）。SIEM - 安全信息与事件管理系统（Security Information and Event Management）,如Splunk, QRadar等。Splunk HEC - Splunk的Http事件接收器（Splunk Http Event Collector）, 一个 HTTP(s)接口，用于接收日志。审计相关日志安全运维团队一般对阿里云相关的审计日志感兴趣，如下列出所有存在于所有目前在日志服务中可用的相关日志（但不限于）：Regions化 - 时刻更新，请以最新的产品文档为准。阿里云日志服务阿里云的日志服务（log service）是针对日志类数据的一站式服务，无需开发就能快捷完成海量日志数据的采集、消费、投递以及查询分析等功能，提升运维、运营效率。日志服务主要包括 实时采集与消费、数据投递、查询与实时分析 等功能，适用于从实时监控到数据仓库的各种开发、运维、运营与安全场景：目前，以上各个阿里云产品已经与日志服务打通，提供近实时的日志自动采集存储、并提供基于日志服务的查询分析、报表报警、下游计算对接与投递的能力。集成方案建议概念项目（Project）项目（Project）是日志服务中的资源管理单元，用于资源隔离和控制。您可以通过项目来管理某一个应用的所有日志及相关的日志源。它管理着用户的所有日志库（Logstore），采集日志的机器配置等信息，同时它也是用户访问日志服务资源的入口。日志库（Logstore）日志库（Logstore）是日志服务中日志数据的收集、存储和查询单元。每个日志库隶属于一个项目，且每个项目可以创建多个日志库。分区（Shard）每个日志库分若干个分区（Shard），每个分区由MD5左闭右开区间组成，每个区间范围不会相互覆盖，并且所有的区间的范围是MD5整个取值范围。服务入口（Endpoint）日志服务入口是访问一个项目（Project）及其内部日志数据的 URL。它和 Project 所在的阿里云区域（Region）及 Project 名称相关。https://help.aliyun.com/document_detail/29008.html访问秘钥（AccessKey）阿里云访问秘钥是阿里云为用户使用 API（非控制台）来访问其云资源设计的“安全口令”。您可以用它来签名 API 请求内容以通过服务端的安全验证。https://help.aliyun.com/document_detail/29009.html假设这里假设您的SIEM（如Splunk）位于组织内部环境（on-premise）中，而不是云端。为了安全考虑，没有任何端口开放让外界环境来访问此SIEM。概览推荐使用SLS消费组构建程序来从SLS进行实时消费，然后通过Splunk API（HEC）来发送日志给Splunk。使用消费组编程协同消费库（Consumer Library）是对日志服务中日志进行消费的高级模式，提供了消费组（ConsumerGroup）的概念对消费端进行抽象和管理，和直接使用SDK进行数据读取的区别在于，用户无需关心日志服务的实现细节，只需要专注于业务逻辑，另外，消费者之间的负载均衡、failover等用户也都无需关心。Spark Streaming、Storm 以及Flink Connector都以Consumer Library作为基础实现。基本概念消费组（Consumer Group） - 一个消费组由多个消费者构成，同一个消费组下面的消费者共同消费一个logstore中的数据，消费者之间不会重复消费数据。消费者（Consumer） - 消费组的构成单元，实际承担消费任务，同一个消费组下面的消费者名称必须不同。在日志服务中，一个logstore下面会有多个shard，协同消费库的功能就是将shard分配给一个消费组下面的消费者，分配方式遵循以下原则：每个shard只会分配到一个消费者。一个消费者可以同时拥有多个shard。新的消费者加入一个消费组，这个消费组下面的shard从属关系会调整，以达到消费负载均衡的目的，但是上面的分配原则不会变，分配过程对用户透明。协同消费库的另一个功能是保存checkpoint，方便程序故障恢复时能接着从断点继续消费，从而保证数据不会被重复消费。部署建议硬件建议硬件参数：需要一台机器运行程序，安装一个Linux（如Ubuntu x64），推荐硬件参数如下：2.0+ GHZ X 8核16GB 内存，推荐32GB1 Gbps网卡至少2GB可用磁盘空间，建议10GB以上网络参数：从组织内的环境到阿里云的带宽应该大于数据在阿里云端产生的速度，否则日志无法实时消费。假设数据产生一般速度均匀，峰值在2倍左右，每天100TB原始日志。5倍压缩的场景下，推荐带宽应该在4MB/s（32Mbps）左右。使用(Python)这里我们描述用Python使用消费组进行编程。对于Java语言用法，可以参考这篇文章.注意：本篇文章的代码可能会更新，最新版本在这里可以找到：Github样例.安装环境强烈推荐PyPy3来运行本程序，而不是使用标准CPython解释器。日志服务的Python SDK可以如下安装：pypy3 -m pip install aliyun-log-python-sdk -U更多SLS Python SDK的使用手册，可以参考这里程序配置如下展示如何配置程序：配置程序日志文件，以便后续测试或者诊断可能的问题。基本的日志服务连接与消费组的配置选项。消费组的一些高级选项（性能调参，不推荐修改）。SIEM（Splunk）的相关参数与选项。请仔细阅读代码中相关注释并根据需要调整选项：#encoding: utf8import osimport loggingfrom logging.handlers import RotatingFileHandlerroot = logging.getLogger()handler = RotatingFileHandler("{0}_{1}.log".format(os.path.basename(file), current_process().pid), maxBytes=10010241024, backupCount=5)handler.setFormatter(logging.Formatter(fmt=’[%(asctime)s] - [%(threadName)s] - {%(module)s:%(funcName)s:%(lineno)d} %(levelname)s - %(message)s’, datefmt=’%Y-%m-%d %H:%M:%S’))root.setLevel(logging.INFO)root.addHandler(handler)root.addHandler(logging.StreamHandler())logger = logging.getLogger(name)def get_option(): ########################## # 基本选项 ########################## # 从环境变量中加载SLS参数与选项 endpoint = os.environ.get(‘SLS_ENDPOINT’, ‘’) accessKeyId = os.environ.get(‘SLS_AK_ID’, ‘’) accessKey = os.environ.get(‘SLS_AK_KEY’, ‘’) project = os.environ.get(‘SLS_PROJECT’, ‘’) logstore = os.environ.get(‘SLS_LOGSTORE’, ‘’) consumer_group = os.environ.get(‘SLS_CG’, ‘’) # 消费的起点。这个参数在第一次跑程序的时候有效，后续再次运行将从上一次消费的保存点继续。 # 可以使”begin“，”end“，或者特定的ISO时间格式。 cursor_start_time = “2018-12-26 0:0:0” ########################## # 一些高级选项 ########################## # 一般不要修改消费者名，尤其是需要并发跑时 consumer_name = “{0}-{1}".format(consumer_group, current_process().pid) # 心跳时长，当服务器在2倍时间内没有收到特定Shard的心跳报告时，服务器会认为对应消费者离线并重新调配任务。 # 所以当网络不是特别好的时候，不要调整的特别小。 heartbeat_interval = 20 # 消费数据的最大间隔，如果数据生成的速度很快，并不需要调整这个参数。 data_fetch_interval = 1 # 构建一个消费组和消费者 option = LogHubConfig(endpoint, accessKeyId, accessKey, project, logstore, consumer_group, consumer_name, cursor_position=CursorPosition.SPECIAL_TIMER_CURSOR, cursor_start_time=cursor_start_time, heartbeat_interval=heartbeat_interval, data_fetch_interval=data_fetch_interval) # Splunk选项 settings = { “host”: “10.1.2.3”, “port”: 80, “token”: “a023nsdu123123123”, ‘https’: False, # 可选, bool ’timeout’: 120, # 可选, int ‘ssl_verify’: True, # 可选, bool “sourcetype”: “”, # 可选, sourcetype “index”: “”, # 可选, index “source”: “”, # 可选, source } return option, settings数据消费与转发如下代码展示如何从SLS拿到数据后转发给Splunk。from aliyun.log.consumer import from aliyun.log.pulllog_response import PullLogResponsefrom multiprocessing import current_processimport timeimport jsonimport socketimport requestsclass SyncData(ConsumerProcessorBase): "”" 这个消费者从SLS消费数据并发送给Splunk """ def init(self, splunk_setting): “““初始化并验证Splunk连通性””” super(SyncData, self).init() assert splunk_setting, ValueError(“You need to configure settings of remote target”) assert isinstance(splunk_setting, dict), ValueError(“The settings should be dict to include necessary address and confidentials.”) self.option = splunk_setting self.timeout = self.option.get(“timeout”, 120) # 测试Splunk连通性 s = socket.socket() s.settimeout(self.timeout) s.connect((self.option[“host”], self.option[‘port’])) self.r = requests.session() self.r.max_redirects = 1 self.r.verify = self.option.get(“ssl_verify”, True) self.r.headers[‘Authorization’] = “Splunk {}".format(self.option[’token’]) self.url = “{0}://{1}:{2}/services/collector/event”.format(“http” if not self.option.get(‘https’) else “https”, self.option[‘host’], self.option[‘port’]) self.default_fields = {} if self.option.get(“sourcetype”): self.default_fields[‘sourcetype’] = self.option.get(“sourcetype”) if self.option.get(“source”): self.default_fields[‘source’] = self.option.get(“source”) if self.option.get(“index”): self.default_fields[‘index’] = self.option.get(“index”) def process(self, log_groups, check_point_tracker): logs = PullLogResponse.loggroups_to_flattern_list(log_groups, time_as_str=True, decode_bytes=True) logger.info(“Get data from shard {0}, log count: {1}".format(self.shard_id, len(logs))) for log in logs: # 发送数据到Splunk # 如下代码只是一个样例（注意：所有字符串都是unicode） # Python2: {u”time”: u"12312312", u"topic": u"topic", u"field1": u"value1", u"field2": u"value2"} # Python3: {"time": “12312312”, “topic”: “topic”, “field1”: “value1”, “field2”: “value2”} event = {} event.update(self.default_fields) if log.get(u"topic") == ‘audit_log’: # suppose we only care about audit log event[’time’] = log[u’time’] event[‘fields’] = {} del log[’time’] event[‘fields’].update(log) data = json.dumps(event, sort_keys=True) try: req = self.r.post(self.url, data=data, timeout=self.timeout) req.raise_for_status() except Exception as err: logger.debug(“Failed to connect to remote Splunk server ({0}). Exception: {1}”, self.url, err) # TODO: 根据需要，添加一些重试或者报告的逻辑 logger.info(“Complete send data to remote”) self.save_checkpoint(check_point_tracker)主逻辑如下代码展示主程序控制逻辑：def main(): option, settings = get_monitor_option() logger.info("** start to consume data…") worker = ConsumerWorker(SyncData, option, args=(settings,) ) worker.start(join=True)if name == ‘main’: main()启动假设程序命名为"sync_data.py"，可以如下启动：export SLS_ENDPOINT=<Endpoint of your region>export SLS_AK_ID=<YOUR AK ID>export SLS_AK_KEY=<YOUR AK KEY>export SLS_PROJECT=<SLS Project Name>export SLS_LOGSTORE=<SLS Logstore Name>export SLS_CG=<消费组名，可以简单命名为"syc_data">pypy3 sync_data.py限制与约束每一个日志库（logstore）最多可以配置10个消费组，如果遇到错误ConsumerGroupQuotaExceed则表示遇到限制，建议在控制台端删除一些不用的消费组。监测在控制台查看消费组状态通过云监控查看消费组延迟，并配置报警性能考虑启动多个消费者基于消费组的程序可以直接启动多次以便达到并发作用：nohup pypy3 sync_data.py &nohup pypy3 sync_data.py &nohup pypy3 sync_data.py &…注意: 所有消费者使用了同一个消费组的名字和不同的消费者名字（因为消费者名以进程ID为后缀）。因为一个分区（Shard）只能被一个消费者消费，假设一个日志库有10个分区，那么最多有10个消费者同时消费。Https如果服务入口（endpoint）配置为https://前缀，如https://cn-beijing.log.aliyuncs.com，程序与SLS的连接将自动使用HTTPS加密。服务器证书*.aliyuncs.com是GlobalSign签发，默认大多数Linux/Windows的机器会自动信任此证书。如果某些特殊情况，机器不信任此证书，可以参考这里下载并安装此证书。性能吞吐基于测试，在没有带宽限制、接收端速率限制（如Splunk端）的情况下，以推进硬件用pypy3运行上述样例，单个消费者占用大约10%的单核CPU下可以消费达到5 MB/s原始日志的速率。因此，理论上可以达到50 MB/s原始日志每个CPU核，也就是每个CPU核每天可以消费4TB原始日志。注意: 这个数据依赖带宽、硬件参数和SIEM接收端（如Splunk）是否能够较快接收数据。高可用性消费组会将检测点（check-point）保存在服务器端，当一个消费者停止，另外一个消费者将自动接管并从断点继续消费。可以在不同机器上启动消费者，这样当一台机器停止或者损坏的清下，其他机器上的消费者可以自动接管并从断点进行消费。理论上，为了备用，也可以启动大于shard数量的消费者。更多参考日志服务Python消费组实战（一）：日志服务与SIEM（如Splunk）集成实战日志服务Python消费组实战（二）：实时日志分发日志服务Python消费组实战（三）：实时跨域监测多日志库数据本文Github样例本文作者：成喆阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

Prometheus 联邦及高可用详解以下所有操作都是在k8s集群中完成，如果你是VM或者物理机在配置方面不会有太大区别;Prometheus 高可用当Exporter或者采集信息需要越来越多时就会考虑高可用，高可用优点不会因为集群中某个节点down而导致Prometheus不可用,可以让算力下沉; 缺点是A-Prometheus和B-Prometheus这两个实例会定时去scrape数据，并且存储在各本地，这样导致数据会存储两份;高可用配置将Prometheus启动两个实例，配置一样只需要暴露的service的端口不同，‘Nginx Controller’配置session-affinity的service名称;Prometheus 联邦在多个数据中心部署Prometheus需要将多数据中心数据合在一起管理，使用联邦模式非常合适，如果担心数据单点，可以在联邦的基础上再扩展高可用; 优点集中式管理数据,报警，不需要为每个Prometheus实例管理数据，如有些敏感节点报警要求高可以在Prometheus数据节点上加报警信息,可以按功能环境划分启动多个Prometheus采集实例; 缺点数据集中化，网络可能会延时，数据单点等问题;终级解决方案Prometheus 是支持远程读写TSDB数据库，请看官方网站支持哪些数据库的读写，因为有些数据只支持写而不支持读，你内网搭建TSDB集群，你所有启动的Prometheus实例都把数据写入到远程数据库，再使用高可用方案支持查询，只支持远程读，这样就可无限扩展采集实例和查询实例，非常的爽，作者没有实践过只是YY中;采集的Metrics远程写入TSDBPrometheus远程读TSDB文章会持续更新，文章中有不好之处欢迎留言

摘要： OceanBase是一个通用的分布式的关系型数据库，有很多独特的特点。比如数据库的多租户、高可用、极致弹性伸缩能力。如果把OceanBase当作单库使用，就没有把OceanBase的分布式优势发挥到极致。前言OceanBase是一个通用的分布式的关系型数据库，有很多独特的特点。比如数据库的多租户、高可用、极致弹性伸缩能力。如果把OceanBase当作单库使用，就没有把OceanBase的分布式优势发挥到极致。本文主要分享一个基于分布式架构的应用把OceanBase数据库的分布式优势发挥到极致所需要了解的OceanBase基础，这也是理解蚂蚁金服的基于OceanBase构建的三地五中心异地多活架构的基础。分布式数据库开发相关问题好的性能首先是设计出来的，应用如果追求极致的性能，就需要关注OceanBase里数据的相关事情。如：数据如何分布？数据如何读写？存储容量瓶颈怎么办？访问性能瓶颈怎么办？数据库出故障时数据可用性和可靠性具体怎样？应用需要做什么特殊处理么？数据库扩展时应用需要迁移数据么？数据迁移的时候对应用有什么影响？这些问题对理解OceanBase的分布式特点很有帮助。后面我们逐步看看OceanBase是如何应对。OceanBase集群外观首先简介一下OceanBase集群的外观。OceanBase是以集群形式运行的，由一堆服务器组成。上图是「三副本」部署，机器会分为三组，每组一个区域（称为Zone），各个机器通过网络互相访问。没有光纤交换机、共享存储以及直连网线等。服务器通常建议CPU、内存和磁盘尽可能的大，磁盘建议用普通SSD盘。普通服务器的好处是便宜，劣势是可靠性和性能可能不如小型机那么高。也就是说OceanBase可以部署在一组可靠性和性能不是特别高的普通服务器上，却提供了高性能、高可用和高可靠、弹性伸缩等多项能力。以上是一个OceanBase集群的外观和能力，但是提供给业务的并不是这个集群的全部资源和能力，而是其子集，即租户（Tenant）。OceanBase多租户特性OceanBase定义了一些基本的资源规格（Resource unit config，如4CPU8Gmem500Gdisk等），然后选取某类资源规格创建一组资源池（Resource Pool），此时集群资源就有一部分被分配出去了。最后将这个资源池关联到一个新建租户，则租户就可以使用这个资源池的能力。OceanBase默认有个sys租户，管理整个集群。用户租户必须在sys租户内部创建。如下示例就是创建租户的过程。#sys租户登录方法$mysql -hxxx.xx.11.11 -uroot@sys#obdemo -P2883 -proot oceanbase -A#资源规格（UnitConfig）create resourceunit S0_uc max_cpu=2,max_memory=‘5G’,…资源单元（Unit）create resourcepool Pool_01 unit=‘S0_uc’,unit_num=2,…租户（Tenant）create tenant test_ins resource_pool_list= (‘Pool_01’),…OceanBase兼容了大部分MySQL连接协议和语法，租户的使用体验跟MySQL实例很像。研发可以在租户里创建数据库（Database）、表（Table）。还包括分区表等。OceanBase里描述数据的最小粒度是分区。普通的表（非分区表）就是一个分区，分区表则包含多个分区。租户的示意图如下。租户之间数据是绝对隔离，资源有一定程度隔离。研发可以将业务先垂直拆分为多个独立的子业务，分别使用不同的租户或者集群。OceanBase资源单元租户里并不知道数据具体在哪个机器上，也可以说没必要知道。只是租户的性能还取决于运维为租户规划的资源池分布情况，所以了解一下资源单元的分布特点对性能规划也是有意义的。资源池（Resource Pool）是由一组资源单元（Resource Unit）组成。资源单元数量默认跟Zone的数量一致或者是它的倍数（可以配置具体分布在哪些Zone以及每个Zone里的Unit数量）。如下图资源单元具备一定的资源能力，是数据的容器。租户拥有的资源单元规格和数量决定了这个租户最大性能。资源单元可以在同一个Zone的不同节点之间自由迁移，OceanBase借此来维持各个节点的资源利用率尽可能维持一个均衡状态。OceanBase拆分设计数据库拆分数据库拆分有两种。一是垂直拆分。即按业务模块拆分到不同的实例或库里。为了模块之间互不影响，拆分到不同的实例比较好。在OceanBase里实现时可以是拆分到同一个集群里不同租户或者不同集群里的租户都可以，取决于业务规模和数据库集群规模。垂直拆分很好理解，后面不再赘述。一是水平拆分。即按某个业务维度将数据拆分到多个分片。这些分片可以是在一个库或者不同库或者不同实例的不同库下。水平拆分实现又有两类常用的选择。如下：分库分表。将一个业务表拆分到N个相同结构的物理表中。中间件做业务表（逻辑表）到分表（物理表）的映射路由以及其他相关操作（如结果聚合计算）等。这个N个物理表可以在不同实例的不同分库中。分库的维度和分表的维度可以不一样，比较灵活。分区表。将一个物理表设计为分区表，拆分到N个分区。分区表的各个分区结构是数据库内部保证一致。OceanBase选择的是分区表的水平拆分方式，并且支持二级分区表（即有2个不同的拆分维度叠加使用）。水平拆分示意图如下：上图是分库分表和分区表同时结合使用。业务表order先经过中间件拆分为100个分表（存在10个分库里），每个分表在OceanBase内部又是一个分区表（100个分区）。分库分表的维度和分区表分区的维度都是一致的，根据用户ID。分库分表和分区各有利弊。分库分表的好处是各个分表的结构一致性是在中间件层保证，比较好控制，比较适合灰度变更（允许部分分表结构不一致，最终必须全部一致）。此外更大的好处是，分库分表是实现异地多活单元话架构的必不可少的条件。缺点是中间件的SQL支持范围有限。分区的好处是在数据库内部解决了拆分问题。针对分区表的SQL功能是数据库SQL引擎的本质工作，相关特性（全局索引、二级分区等）会持续开发完善。分区分库分表架构设计，需要确定机器数、实例数、分库数和分表数的拓扑，性能理论上限取决于主实例所处的机器节点数。此后要做扩展就要调整这四个元素的数目及其联系。这种扩展很可能涉及到分表数据的迁移，需要借助外部工具或产品实现。分区架构设计，研发确定分区策略和分区数，运维确定租户的资源单元数量，OceanBase确定资源单元（Unit）在哪些机器节点上以及分区（Partition）在哪些资源单元里。同一个分区不能跨节点存储。如下图。此后要做扩展就是调整资源单元的规格、数量。OceanBase在确定Unit里的分区的位置时会尽量让每个节点的负载维持均衡。这个负载的计算方式比较复杂，会综合考虑OB节点内部CPU、内存和空间利用率等。分区随意分布对应用性能很可能有负面影响。当业务上有联系的两个表的分区分布在不同的资源单元里（同时也分布在不同的节点里），这两个表的连接就难以避免跨节点请求数据，网络上的延时会影响这个连接的性能。注： t1(p0) 表示表t1的0号分区。每个分区在集群里数据实际有三份，即三副本（Replica）。图中忽略了Zone2和Zone3的细节。三副本之间的数据同步靠把Leader副本的事务日志同步到其他Follower副本中。Paxos协议会保障这个事务日志传输的可靠性（事务日志在一半以上成员里落盘，剩余成员最终也会落盘），同时还有个以分区为粒度的选举机制，保障Leader副本不可用的时候，能快速从现有两个Follower副本里选举出新的Leader副本，并且数据还绝对不丢。这里就体现了故障切换时两个重要指标：RPO=0， RTO<30s。Locality图5中t0和t1业务上是有联系的表（如主表和详情表），两者都是分区表，分区策略和分片数都相同，OceanBase提供了一个表属性“表分组”（TableGroup）。设置为同一个表分组的不同表的分区数一定一样，并且同号分区组成一个“分区分组”（PartitionGroup）。同一个分区分组的分区一定会分配在同一个资源单元（Unit）内部（也就是会在同一个节点内部），彼此的连接逻辑就避免了跨节点请求。另外一个效果是如果一个事务同时修改两个有业务关联的分区，使用分区分组也可以规避跨节点的分布式事务。这个表分组属性的设置就是OceanBase的Locality特性之一——影响相关分区的分布。实际上每个分区都有三副本（Replica, 本文例子），图5中省略了t0(p0)和t1(p0)的其他两个副本都分别会在同一个Unit里分配。不仅如此，每个分区的三副本里都会有leader副本默认提供读写服务。leader副本是选举出来的。t0(p0)和t1(p0)的leader副本也一定会在同一个Unit里（即在同一个Zone里）。这样才彻底的避免了连接的时候跨节点请求。OceanBase的Locality特性还可以指定租户/数据库/表的默认Zone，这样下面的表的leader副本会优先被选举为这个Zone里副本。如下面例子，数据库和表会继承租户的默认设置，当然也可以自己修改primary_zone或者locality属性覆盖上层设置。：create tenant obtrans0primary_zone=‘hz1’;create table item (…)locality = ‘F@hz1, F@hz2, F@hz3,R{all_server}@hz1, R{all_server}@hz2, R{all_server}@hz3’注：F表示全功能副本，R表示只读副本。设置primary_zone后单个租户的所有表的读写都集中到一个Zone里，该租户在其他zone里的Unit就没有读写压力。通常这样做是源于业务应用的要求。如应用的请求都是来自于这个Zone，为了规避应用跨Zone读写数据性能下降。不过primary_zone更大的意义在于当集群里有很多租户的时候，可以将不同业务租户的读写压力分摊到不同Zone的机器，这样集群整体资源利用率提升，所有应用的总体性能也得到提升。后面要介绍的异地多活架构就充分利用OceanBase这个特性，在数据库层面将拆分的表的业务读写点尽可能分散到所有Zone的所有机器上。除了表与表之间可能有联系，业务模块之间也可能有联系。一个业务过程可能会横跨多个业务模块，前面这些模块的数据被垂直拆分到多个租户里。OceanBase的Locality特性“租户分组”（TenantGroup）还可以设置不同租户之间的联系。如下租户交易订单和支付订单在业务上是先后发生。create tenantgroup tgtrade tenant_array=(‘obtrade0’, ‘obpay0’);租户分组的意义依然是为了在分布式架构下尽可能将一个业务流程内多次数据库请求都约束在同一个Zone或者Region（注：OceanBase将地域相邻的Zone定义为一个Region）里。OceanBase异地多活架构异地多活概念异地多活的概念一直都有，只是内涵不断变化。以双机房多活为例，应用通常都是无状态的，可以多地部署。数据库有状态，传统数据库只有主库可以提供读写，备库最多只能提供只读服务（如ORACLE的Active Dataguard）：1. 应用双活，数据库A地读写，B地不可读写。这种只有应用多活，数据库是异地备份容灾（无并发）。2. 应用双活，数据库A地读写，B地只读。这种也是应用双活，数据库读写分离（实例级并发）。3. 应用双活，数据库双活，两地应用同时读写不同表。这种数据库双向同步，应用同时错开写不同的数据（表级并发）。4. 应用双活，数据库双活，两地应用同时读写相同表不同记录。这种数据库双向同步，应用同时错开写不同的数据（行级并发）。5. 应用双活，数据库双活，两地应用同时读写相同表相同记录。这种数据库双向同步，应用同时写相同的数据，最终会因为冲突一方事务回滚（行级并发写冲突）上面第1种情形，B地应用是跨地域远程读写数据库。两地距离较大的时候性能会很不好。2的B地应用是本地访问数据库。3，4，5三种情形两地数据库都提供读写服务，对应用而言是本地访问数据库，但到分布式数据库内部，其要读写的数据是否正好在本地就取决于业务和数据库的拆分设计。有这么一种情形，B地应用访问B地数据库实例，请求的数据的写入点恰好是A地，这样会走分布式数据库内部路由远程A地实例中拿到数据，性能上会有些下降，而业务可能不知道为什么。OceanBase水平拆分方案为了避免在分布式数据库OceanBase内部发生跨Zone请求，应用的请求流量的水平拆分规则和数据的水平拆分规则要保持一致并联动，就可以实现真正的应用向本地实例请求读写的数据恰好就是在本地实例种。这就是Locality的用途所在。首先业务架构层面能根据用户ID（uid）做拆分，将用户拆分为100分。x和y是用户直接相关的表，都根据uid拆分为100个分表，分布在5个不同的租户里。x[00-19]表示20个分表。每个租户的Leader分别分布在不同的Zone。uid:00-19表示 分到这20个分片的用户数据和用户流量。应用层面在某个环节能根据UID将用户请求转发到对应的机房（Zone），应用服务之间的请求信息都有这个UID信息，后面应用请求都在本机房流转，并且访问数据库时通过分库分表中间件（DBP）和OceanBase的反向代理（OBProxy）就路由到本机房的业务租户上。实际使用这个架构时，有几个隐含的前提，Zone1和Zone2是同城双机房，Zone3和Zone4是同城双机房，两个城市靠的比较近，Zone5 实际很远，所以一般不提供写入。为节省空间，Zone5里的副本放的是日志副本。应用异地多活架构上面要实现OceanBase在每个Zone的应用写入都是恰好是本地访问，关键点就是应用流量水平拆分规则跟数据水平拆分规则保持一致。而应用要维持这样一个规则，需要很多产品都要支持水平拆分等。如下图图中流量接入层的“负载均衡”环节负责调整用户流量到对应的机房（Zone），此后的应用之间的请求就都是本地访问。能使用这个解决方案的业务都是能按用户维度做水平拆分。有些业务的拆分维度跟用户维度是冲突的，或者有些业务的数据只支持集中写入等，不能做到上面这种多活，但也可以使用OceanBase，实现单点写入，多点读取的功能。OceanBase在异地容灾和多活架构方案中的价值就是支持水平拆分规则的定义、解决了多个机房间数据同步和一致性问题、始终具备高可用和弹性伸缩能力等。参考OceanBase负载均衡的魅力蚂蚁金服异地多活的微服务体系本文作者：mq4096阅读原文本文为云栖社区原创内容，未经允许不得转载。

GraphDB简介GraphDB图数据库适用于存储，管理，查询复杂并且高度连接的数据，图库的结构特别适合发现大数据集下数据之间的共性和特性，特别善于释放蕴含在数据关系之间的巨大价值。GraphDB引擎本身并不额外收费，仅收取云hbase费用。适合的业务场景在如下多种场景中图数据库比其他类型数据库（RDBMS和NoSQL）更合适推荐及个性化几乎所有的企业都需要了解如何快速并且高效地影响客户来购买他们的产品并且推荐其他相关商品给他们。这可能需要用到云服务的推荐，个性化，网络分析工具。如果使用得当，图分析是处理推荐和个性化任务的最有效武器，并根据数据中的价值做出关键决策。举个例子，网络零售商需要根据客户过往消费记录及订单推荐其他商品给这个客户。为了能成功的达到目的，当前回话下用户浏览操作等都可以实时集成到一张图中。图非常适合这些类似的分析用例，如推荐产品，或基于用户数据，过去行为，推荐个性化广告。电商商品推荐案例如何使用GraphDB做商品实时推荐安全和欺诈检测在复杂及高度相关的用户，实体，事务，时间，交互操作的网络中，图数据库可以帮助检测哪些实体，交易，操作是有欺诈性质的，从而规避风险。简而言之，图数据库可以帮助在数不清金融活动中产生的关系及事件组成的海量数据集中找到那根坏针。某深圳大数据风控案例客户介绍：该大数据有限公司专注于为银行、消费金融、三方支付、P2P、小贷、保险、电商等客户解决线上风险和欺诈问题。案例背景及痛点近几年互联网金融行业兴起，诞生了很多互联网金融企业，用户参加线上贷款，金融消费，P2P融资等金融活动门槛大大降低，在这些金融行为中如何有效规避风险，进行风控是每个金融企业面临的比较严峻的问题。用户的金融行为中会沉淀大量有价值的数据，在白骑士客户小贷场景中会产生一笔笔贷款记录关联的手机号，身份证，银行卡号，设备号等。这些数据代表一个个实体人，正常金融活动中，贷款，金融服务不是高频行为，一个实体人一般有一个唯一身份证，常用银行卡号，手机号，设备号。这几者顶点见不会产生高密度图，但有一些高危低信用用户可能会使用同一手机设备申请贷款进行骗贷。客户痛点在于如何高效识别这些高危低信用用户。解决方案建立图模型分别创建手机号，设备号，身份证，银行卡号四类顶点及相互关联的边，扩展属性便于查询。从原数据仓库清洗后通过graph-loader工具导入GraphDB在线评估用户信用资质在申请贷款流程中，可以通过使用图库可以实时查询图中任意一手机号关联的身份证数量（一跳/二跳查询），恶意申请有如下特点，关联子图各类顶点过多，并且可能关联上离线分析标注过得黑名单用户，说明当前用户存在恶意申请风险，实时拒掉贷款申请。下图显示如何与自身小贷平台打通，做实时风控预警，箭头方向代表数据流方向。主动识别黑名单用户借助spark graphframes分析能力，离线计算全图中各个顶点出入度及pagerank，主动挖掘超级顶点，超级顶点如一个手机号关联了多个身份证顶点，说明该用户金融活动频繁，背后的故事是一个实体人有多笔申请记录，分别关联了不同的身份证，手机号，说明该用户在进行恶意欺诈活动，人工标注黑名单用户，从源头禁掉用户金融活动。物联网物联网（IoT）是另一个非常适合图数据库领域。 物联网使用案例中，很多通用的设备都会产生时序相关的信息如事件和状态数据。在这种情况下，图数据库效果很好，因为来自各个独立的终端的流汇聚起来的时候产生了高度复杂性此外，涉及诸如分析根本原因之类的任务时，也会引入多种关系来做整体检查，而非隔离检查。GraphDB特性整体架构使用Apache TinkerPop构建GraphDB是Apache TinkerPop3接口的一个实现，支持Tinkerpop全套软件栈，支持Gremlin语言，可以快速上手。在GraphDB中，为应对不同的业务场景，数据模型已经做到尽可能的灵活。例如，GraphDB中点和边均支持用户自定义ID；自定义ID可以是字符串或数字；属性值可以是任意类型，包括map,数组，序列化的对象等。因此，应用不需要为了适应图数据库的限制而做多余的改造，只需要专注在功能的实现上面。GraphDB具有完善的索引支持。支持对顶点建立label索引和属性索引；支持对边建立label索引，属性索引和顶点索引；支持顶点索引和边索引的范围查询和分页。良好的索引支持保证了顶点In/Out查询和根据属性查找顶点/边的操作都具有很好的性能。与HBase深度集成GraphDB使用企业认证的HBase版本作为其持久数据存储。 由于与HBase的深度集成，GraphDB继承了HBase的所有主要优势，包括服务可用性指标，写/读/时刻都在线高可用功能，线性可扩展性，可预测的低延迟响应时间，hbase专家级别的的运维服务。 在此基础上，GraphDB增强了性能，其中包括自适应查询优化器，分片数据位置感知能力。使用spark graphframes做图分析借助阿里云HBase X-Pack提供的Spark产品，可以对GraphDB中的图数据进行分析。作为优秀的大数据处理引擎，Spark能够对任意数据量的数据进行快速分析，Spark支持scala、java、python多种开发语言，可本地调试，开发效率高。此外，阿里云HBase X-Pack的Spark服务通过全托管的方式为用户提供企业级的服务，大大降低了使用门槛和运维难度。Spark GraphX中内置了常见的图分析操作，例如PageRank、最短路径、联通子图、最小生成树等。云上大规模GraphDB优势全托管，全面解放运维，为业务稳定保驾护航大数据应用往往涉及组件多、系统庞杂、开源与自研混合，因此维护升级困难，稳定性风险极高。云HBase GraphDB提供的全托管服务相比其他的半托管服务以及用户自建存在天然的优势。依托持续8年在内核和管控平台的研发，以及大量配套的监控工具、跨可用区、跨域容灾多活方案，GraphDB的底层核心阿里云HBase提供目前业界最高的4个9的可用性（双集群），11个9的可靠性的高SLA的支持，满足众多政企客户对平台高可用、稳定性的诉求。使用阿里云GraphDBGraphDB引擎包含在HBase 2.0版本中，用户在购买云上HBase数据库服务时，可以选择GraphDB作为其图数据引擎。GraphDB引擎本身并不额外收费，对于需要使用图数据功能的用户而言，将大幅降低应用和开发成本。了解更多关于阿里云云数据库HBase及图引擎GraphDB请戳链接：产品入口：https://cn.aliyun.com/product/hbase?spm=5176.224200.100.35.7f036ed6YlCDxm帮助文档：https://help.aliyun.com/document_detail/92186.html?spm=a2c4g.11174283.6.610.260d3c2eONZbgs本文作者：恬泰阅读原文本文为云栖社区原创内容，未经允许不得转载。

还是熟悉的面孔，还是熟悉的味道，不同的是，这次的配方升级了。今年10月底，Spring Cloud联合创始人Spencer Gibb在Spring官网的博客页面宣布：阿里巴巴开源 Spring Cloud Alibaba，并发布了首个预览版本。随后，Spring Cloud 官方Twitter也发布了此消息。- 传送门时隔 51天，Spencer Gibb再次在Spring官网的博客页面宣布：Spring Cloud Alibaba发布了其开源后的第二个版本0.2.1，随后，Spring Cloud 官方Twitter也转发了此消息。圣诞节的前一周，Josh Long向他的老朋友许晓斌发来贺电：小编翻译：听闻阿里巴巴官方宣布使用Spring Cloud，我开心的一晚上没睡着，下周三我会在Spring Tips小视频里介绍Spring Cloud Alibaba。圣诞快乐，老哥！爱你视频地址新版本概要增加了两个新的模块， spring-cloud-alibaba-schedulerx 和 spring-cloud-stream-binder-rocketmq 。在 spring-cloud-alibaba-nacos 和 spring-cloud-alibaba-sentinel 中增加了一些新的 feature 。修复了之前版本的一些 bug 。注意: 版本 0.2.1.RELEASE 对应的是 Spring Cloud Finchley 的版本。这次发布也包含了一个适配 Spring Cloud Edgware 的版本 0.1.1.RELEASE，版本 0.1.1.RELEASE 也包含了 0.2.1.RELEASE 中新增的组件和特性。Spring Cloud Alibaba RocketMQ适配了 spring cloud stream 对于 message 抽象的 API。支持事务消息。Consumer 端支持以 tags、SQL表达式过滤消息。支持顺序、并发以及广播消费模式。Spring Cloud Alibaba SchedulerX提供了秒级、精准、高可靠、高可用的定时任务调度服务。提供了丰富的任务执行模型，包括单机执行，广播执行，以及子任务的分布式执行。Spring Cloud Alibaba Nacos Config将Nacos Client 的版本升级到 0.6.2 版本。支持从多个 dataid 和 groupid 中获取和监听配置，并支持优先级指定。优化了 动态监听的逻辑，只有配置了动态刷新的配置项才会实时刷新。Spring Cloud Alibaba Nacos Discovery将Nacos Client 的版本升级到 0.6.2 版本。支持在 Nacos Console 端将服务实例设置成不可用状态，服务发现会自动过滤此节点。支持服务发现在初始化时不使用本地缓存。Spring Cloud Alibaba Sentinel支持 Feign，兼容了 @FeignClient 所有的属性，包括 fallback、fallbackFactory。支持 热点参数限流和集群限流。重构了 ReadableDataSource 的设计，提供了更友好的配置 Sentinel 规则持久化的方式。优化了 Sentinel 对于 RestTemplate 的降级后的处理。调整并添加了一些 Sentinel 配置信息对应的属性，如日志目录，日志文件名等。新版本背后的思考Spring Cloud Alibaba Nacos DiscoveryNacos Discovery 在这个版本最大的更新就是支持在初始化的时候不使用本地文件缓存，目前初始化的时候已经默认不使用本地文件缓存。为什么要有缓存？首先我们来了解一下本地缓存的概念，为什么需要这个本地缓存？我们都知道，服务注册与发现应该只是服务调用中的辅助性的一个环节，而不是一个关键的环节。一个良好的服务注册与发现的设计，需要保证以下两点。服务注册与发现只是旁路，不应该参与具体的调用过程。在服务的运行过程中，即使服务注册中心偶然发生异常宕机后，也尽量不影响正常的业务调用。要实现以上两点，缓存就不可或缺，而为了适应不同的场景，缓存又可以分成内存缓存和本地文件缓存，他们的概念和适用场景如下。内存中的缓存将服务提供者列表维护在内存中，每次调用时直接从内存中的列表获取节点即可。内存缓存通过定时任务更新，或者在收到服务注册中心的推送之后再更新。确保了即使在服务注册中心宕机的情况下，也能保证服务仍能正常调用。本地文件缓存将上述提到的内存中的缓存，保留在本地的某个文件中，这样在调用服务注册中心失败的时候，可以从本机的文件缓存中获取服务提供者列表。这样就保证了在服务注册中心宕机的情况下，应用在重启后也能找到服务提供者。为什么要关闭有了以上背景知识后，读者可能会有疑问，既然缓存这么好，你们为什么默认要把它置为默认关闭呢？我们在发布出第一个版本之后，很多用户反馈，为什么我服务下线之后还是有节点，仍旧可以被查询到呢？这样导致我这个监控数据完全不准，你们这个有 bug，完全不对。其实这是阿里巴巴在多年业务积累的经验，对于服务发现来说，一个即使是已经过时的节点，也比没有任何数据好。而且还有可能其实这个服务只是和服务注册中心失去了心跳，但是应用本身是正常的。当然，这也暴露了我们设计中存在的一些问题，没有把服务发现本身，以及缓存的分层给做好，两者糅合在一块。所以在这一次的版本更新中我们还是选择适配开源标准，默认关闭了本地文件缓存，留了一个开关给用户自由选择。Spring Cloud Alibaba Nacos ConfigNacos Config 在这个版本中有两个大的特性，支持了“共享配置”，修正了动态刷新的语义和行为。共享配置的实现在第一个版本还没发布到时候，社区里对配置管理中心的讨论就没停止过，其中听到最多的反馈应该就是支持多个应用共享一个配置。我们也通过 github issue 的方式，征集了很多意见，详情见 #12 , #141。后来我们将这个模型抽象了一下，认清这些需求本质是一个应用可以从多个 DataID 和 GroupID 组合中获取配置，并且这些配置还可以单独指定优先级和是否动态刷新。最后我们推荐了这种使用方式，既保证了使用场景的灵活性，又保证了业务语义的明确性。更多详情可以参考 WIKI。# config external configuration# 1、Data Id 在默认的组 DEFAULT_GROUP,不支持配置的动态刷新spring.cloud.nacos.config.ext-config[0].data-id=ext-config-common01.properties# 2、Data Id 不在默认的组，不支持动态刷新spring.cloud.nacos.config.ext-config[1].data-id=ext-config-common02.propertiesspring.cloud.nacos.config.ext-config[1].group=GLOBAL_GROUP# 3、Data Id 既不在默认的组，也支持动态刷新spring.cloud.nacos.config.ext-config[2].data-id=ext-config-common03.propertiesspring.cloud.nacos.config.ext-config[2].group=REFRESH_GROUPspring.cloud.nacos.config.ext-config[2].refresh=true#优先级关系: spring.cloud.nacos.config.ext-config[n].data-id 其中 n 的值越大，优先级越高。注意 data-id 的值必须带文件扩展名，文件扩展名支持 properties、yaml 和 yml。通过这种自定义扩展的配置项，既可以支持一个应用从多个配置项中获取数据，也解决多个应用间配置共享的问题。头脑风暴，@fudali 同学还提出了更加灵活的一种方式 #161，就是可以通过一个配置项来配置所有的 DataID 的信息，然后可以通过修改这个配置项，可以修改整体配置项的逻辑。这是一个非常好的想法，只不过这一期中我们没有实现，原因是这种方式太灵活了。我们认为配置管理其实是一件很严肃的事情，太灵活导致生产中变更比较不可控。虽然目前的逻辑也可以支持这种用法，但是我们并没有把这种模式当做推荐模式，后续如果社区有更多的反馈认为这是一个强烈的需求，欢迎提 PR。动态刷新的修正简单好用、实时可监控的动态刷新也许是 Nacos Config 相对于其他开源中间件相比最核心的优势了，不同于 Spring Cloud Config Server 必须使用 Spring Cloud Bus 才能实现动态刷新，Nacos Config 无需依赖其他任何中间件就可以实现实时动态刷新，而且推送成功与否和刷新历史还支持实时查询。但是我们发现在第一个版本中的实现发现两个问题：动态刷新的实现方式不对：不应该直接调用 Context.refresh() 方法，而是应该 publish 一个 RefreshEvent。是否动态刷新的语义有误：对于那些被标记为不动态刷新的配置项来说，只是修改他们的时候不会触发动态刷新。但是当其他支持动态刷新的配置项触发了动态刷新时，应用的 Context 仍旧会去获取那些被标记为不动态刷新的配置项的内容，也就意味着这些配置项有可能被连带刷新了。在这个版本中，我们修复了这两个问题。首先，动态刷新不再是直接去调用 ContextRefresher.refresh() 方法，而是 publish 了一个 RefreshEvent，让 spring-cloud-commons 里的 RefreshEventListener 去触发这个 ContextRefresher.refresh() 方法。其次，我们修正了动态刷新的语义后，这一次是真正做到了，只有 refresh 属性为 true 的配置项，才会在运行的过程中变更为新的值，refresh 属性为 false 的配置项再也不用担心应用在运行的过程中发生莫名其妙的变更了。更深入一点，在上个月 SpringOne Tour 中，我们和 Spring Cloud 的创始人 Spencer 聊到 Spring Cloud 的 Context.refresh() 成本太高，会刷新整个 Spring Context。他反复强调了两次 Context.refresh() 只对 @RefreshScope 和 @ConfigurationProperties 有效，成本一点也不高。之前我们接收到很多社区的反馈都是 Nacos Config 动态刷新支不支持 xxxx，支不支持 xxxx。之前我们都是回答只支持 @RefreshScope 和 @ConfigurationProperties ，如果他内置没有支持，那就得自己加上相应的注解。今天我们可以很愉快地回复，他监听了 RefreshEvent 也能直接支持。而且如果添加 @RefreshScope 和 @ConfigurationProperties 都不满足你的需求时，可以通过实现自己的 RefreshEventListener 更多高级的玩法。Spring Cloud Alibaba SentinelSentinel 在这个版本中有三个大的特性：全面支持 FeignClient ，完善了 RestTemplate 的支持，添加了热点限流、集群限流。FeignClient 集成 Sentinel其实在这之前，Sentinel 支持 FeignClient 已经设计了很久了，之前我们的想法做一个兼容性较强的方案，支持 Sentinel 和 Hystrix 在 FeignClient 中同时使用，尽量做到对原有应用的侵入性做到最小。这个方案我们也思考调研了很久，但是实现难度确实比较大，需要修改 FeignClient 的代码才能实现两者共存。正好前段时间在 Spring Cloud 届最大的新闻就是 Hystrix 宣布不在维护了，于是我们就换了一个思路，直接使用 Sentinel 替代 Hystrix，不再去追求支持两者共存。我们实现了自己的 Feign.Builder，在构建的 FeignClient 执行调用的过程中，通过 SentinelInvocationHandler 完成 Sentinel 的流量统计和保护的动作。如果想使用 Sentinel 为 FeignClient 限流降级，首先需要引入 sentinel-starter 的依赖，然后打开 Sentinel 限流降级的开关 feign.sentinel.enabled=true ，就完成了 Sentinel 的接入。如果需要使用更加定制化的功能，则需要在 @FeignClient 添加 fallback 和 configuration 这些属性的配置。注意 @FeignClient 注解中的所有属性，Sentinel 都做了兼容。RestTemplate 集成 SentinelSpring Cloud Alibaba Sentinel 支持对 RestTemplate 的服务调用使用 Sentinel 进行保护，补全了 Hystrix 这一块的空白。接入的方式也不复杂，在构造 RestTemplate bean 的时候需要加上 @SentinelRestTemplate 注解，然后在控制台配置相应的规则即可。在触发了限流降级时，默认的处理方式是返回 RestTemplate request block by sentinel 信息。如果想自定义被限流之后的处理方式，还可以添加 blockHandlerClass，blockHandler 分别定制被限流后的处理类以及对于的处理方法。如果想自定义被降级之后的处理方式，还可以添加 fallback，fallbackClass 分别定制被降级后的处理类以及对于的处理方法。RestTemplate 的限流降级 ？Sentinel 也承包了！热点参数限流和集群限流首先解释一下什么是热点参数限流和集群限流。热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。热点参数限流可以看做是一种特殊的流量控制，仅对包含热点参数的资源调用生效。集群流控主要解决的问题是：当我们需要控制整个集群流量总量，但是单机流量可能会不均匀，如果是单机维度去限制的话会无法精确地限制总体流量，因此需要引入集群维度的流量控制。Sentinel v1.4.0 的 新功能 ，也能第一时间愉快地在 Spring Cloud Alibaba 上使用了。新组件Spring Cloud Alibaba RocketMQSpring Cloud Stream 是一个用于构建基于消息的微服务应用框架，它基于 SpringBoot 来创建具有生产级别的单机 Spring 应用，并且使用 Spring Integration 与 Broker 进行连接。它提供了消息中间件的统一抽象，推出了 publish-subscribe、consumer groups、partition 这些统一的概念。RocketMQ 是一款开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。具有以下特点：能够保证严格的消息顺序、提供丰富的消息拉取模式、高效的订阅者水平扩展能力、实时的消息订阅机制、亿级消息堆积能力。在这次的 Spring Cloud Stream Binder RocketMQ 的实现中，我们适配了 Spring Cloud Stream 对于 message 抽象的 API，支持了 RocketMQ 的事务消息。消息订阅时支持以 tags、SQL 表达式过滤消息，同时还支持顺序、并发、延迟以及广播消费模式。Spring Cloud Alibaba SchedulerXSchedulerX 是阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务，同时提供分布式的任务执行模型，如网格任务，网格任务支持海量子任务均匀分配到所有 Worker（schedulerx-client）上执行。简单易用的轻量分布式任务调度您不需要关心调度逻辑，只需要在在 JobProcessor 接口的实现中添加业务逻辑即可，然后在自主运维控制台配置上一个 Job 即可完成使用。高可用的分布式任务不管是 SchedulerX 服务端还是客户端都是分布式架构设计，任务可以在多台客户端机器里的任何一台机器执行，如果客户端出现宕机的情况，服务端会自动选择正常运行的客户端去执行 Job，每个 Job 在服务端的不同机器均有备份，SchedulerX 服务端任意宕掉部分机器仍能保证 Job 正常调度。友好的用户界面SchedulerX 提供了非常友好的页面方便您创建、删除或修改 Job，提供了立即触发执行一次的功能，方便您测试以及关键时刻手动立即执行一次，还提供了历史执行记录查询的功能，您可以看到任何一个 Job 过去 100 次的历史执行记录。功能强大提供了秒级、精准的定时任务调度服务，且提供了丰富的任务执行模型，包括单机执行，广播执行，以及子任务的分布式执行。What’s Next?Spring Cloud Alibaba Cloud SLS 针对日志类数据的一站式服务，在阿⾥巴巴集团经历大量大数据场景锤炼⽽成。您⽆需开发就能快捷地完成日志数据采集、消费、投递以及查询分析等功能，提升运维、运营效率，建立 DT 时代海量日志处理能力。Spring Cloud Alibaba Dubbo Dubbo 是一款流行的开源 RPC 框架，我们会把 Dubbo 整合到 Spring Cloud Alibaba 中，让大家在开发 Dubbo 时也能享受到 Spring Cloud 带来的便利。致谢Spring Cloud Alibaba 从开源建设以来，受到了很多社区同学的关注。社区的每一个 issue ，每一个 PR，都是对整个项目的帮助，都在为建设更好用的 Spring Cloud 添砖加瓦。我们真心地感谢为这个项目提出过 Issue 和 PR 的同学，特别是这些 contributor：HaojunRen、xiejiashuai、mengxiangrui007我们希望有更多社区的同学加入进来，一起把项目做好。还要特别感谢文档团队的倾芸，她帮忙将我们所有的 Reference Doc 翻译了英文，为Spring Cloud Alibaba 的国际化进程铺平了道路。亦盏，阿里巴巴中间件高级开发工程师，长期关注微服务领域，主要负责 Spring Cloud Alibaba 项目的开发和社区维护。本文作者：中间件小哥阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...

前面的文章介绍了怎么从单点开始搭建MySQL集群，列表如下MySQL 安装(二进制版)MySQL集群搭建(1)-主备搭建MySQL集群搭建(2)-主主从模式MySQL集群搭建(3)-MMM高可用架构MySQL集群搭建(4)-MMM+LVS+Keepalived今天说另一个常用的高可用方案: MHA1 概述1.1 MHA 简介MHA - Master High Availability 是由 Perl 实现的一款高可用程序，出现故障时，MHA 以最小的停机时间(通常10-30秒)执行 master 的故障转移以及 slave 的升级。MHA 可防止复制一致性问题，并且易于安装，不需要改变现有部署。MHA 由MHA manager和MHA node组成, MHA manager是一个监控管理程序，用于监控MySQL master状态; MHA node是具有故障转移的工具脚本，如解析 MySQL 二进制/中继日志，传输应用事件到Slave, MHA node在每个MySQL服务器上运行。出自 MHA WikiMHA manager调用MHA node工具脚本的方式是SSH到主机上然后执行命令，所以各节点需要做等效验证。1.2 MHA 怎么保证数据不丢失当Master宕机后，MHA会尝试保存宕机Master的二进制日志，然后自动判断MySQL集群中哪个实例的中继日志是最新的，并将有最新日志的实例的差异日志传到其他实例补齐，从而实现所有实例数据一致。然后把宕机Master的二进制日志应用到选定节点，并提升为 Master。具体流程如下：尝试从宕机Master中保存二进制日志找到含有最新中继日志的Slave把最新中继日志应用到其他实例，实现各实例数据一致应用从Master保存的二进制日志事件提升一个Slave为Master其他Slave向该新Master同步从切换流程流程可以看到，如果宕机Master主机无法SSH登录，那么第一步就没办法实现，对于MySQL5.5以前的版本，数据还是有丢失的风险。对于5.5后的版本，开启半同步复制后，真正有助于避免数据丢失，半同步复制保证至少一个 （不是所有）slave 在 master 提交时接收到二进制日志事件。因此，对于可以处理一致性问题的MHA 可以实现"几乎没有数据丢失"和"从属一致性"。1.3 MHA 优点和限制优点开源，用Perl编写方案成熟，故障切换时，MHA会做日志补齐操作，尽可能减少数据丢失，保证数据一部署不需要改变现有架构限制各个节点要打通SSH信任，有一定的安全隐患没有 Slave 的高可用自带的脚本不足，例如虚IP配置需要自己写命令或者依赖其他软件需要手动清理中继日志1.4 MHA 常用两种复制配置单 master，多 slave M(RW) |+——-+——-+S1(R) S2(R) S3(R)这种复制方式非常常见，当Master宕机时，MHA会选一个日志最新的主机升级为Master, 如果不希望个节点成为Master，把no_master设为1就可以。多 master, 多 slave M(RW)—-M2(R, candidate_master=1) |+——-+——-+S1(R) S2(R)双主结构也是常见的复制模式，如果当前Master崩溃, MHA会选择只读Master成为新的Master2 数据库环境准备本次演示使用复制方式是主主从，主主从数据库搭建方式参考以前文章2.1 节点信息IP系统端口MySQL版本节点读写说明10.0.0.247Centos6.533065.7.9Master读写主节点10.0.0.248Centos6.533065.7.9Standby只读,可切换为读写备主节点10.0.0.249Centos6.533065.7.9Slave只读从节点10.0.0.24Centos6.5–manager-MHA Manager10.0.0.237—–VIP2.2 架构图2.3 参考配置Master1[client]port = 3306default-character-set=utf8mb4socket = /data/mysql_db/test_db/mysql.sock[mysqld]datadir = /data/mysql_db/test_dbbasedir = /usr/local/mysql57tmpdir = /tmpsocket = /data/mysql_db/test_db/mysql.sockpid-file = /data/mysql_db/test_db/mysql.pidskip-external-locking = 1skip-name-resolve = 1port = 3306server_id = 2473306default-storage-engine = InnoDBcharacter-set-server = utf8mb4default_password_lifetime=0auto_increment_offset = 1auto_increment_increment = 2#### log ####log_timestamps=systemlog_bin = /data/mysql_log/test_db/mysql-binlog_bin_index = /data/mysql_log/test_db/mysql-bin.indexbinlog_format = rowrelay_log_recovery=ONrelay_log=/data/mysql_log/test_db/mysql-relay-binrelay_log_index=/data/mysql_log/test_db/mysql-relay-bin.indexlog_error = /data/mysql_log/test_db/mysql-error.log#### replication ####log_slave_updates = 1replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%#### semi sync replication settings #####plugin_dir=/usr/local/mysql57/lib/pluginplugin_load = “rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"loose_rpl_semi_sync_master_enabled = 1loose_rpl_semi_sync_slave_enabled = 1Master2[client]port = 3306default-character-set=utf8mb4socket = /data/mysql_db/test_db/mysql.sock[mysqld]datadir = /data/mysql_db/test_dbbasedir = /usr/local/mysql57tmpdir = /tmpsocket = /data/mysql_db/test_db/mysql.sockpid-file = /data/mysql_db/test_db/mysql.pidskip-external-locking = 1skip-name-resolve = 1port = 3306server_id = 2483306default-storage-engine = InnoDBcharacter-set-server = utf8mb4default_password_lifetime=0auto_increment_offset = 2auto_increment_increment = 2#### log ####log_timestamps=systemlog_bin = /data/mysql_log/test_db/mysql-binlog_bin_index = /data/mysql_log/test_db/mysql-bin.indexbinlog_format = rowrelay_log_recovery=ONrelay_log=/data/mysql_log/test_db/mysql-relay-binrelay_log_index=/data/mysql_log/test_db/mysql-relay-bin.indexlog_error = /data/mysql_log/test_db/mysql-error.log#### replication ####log_slave_updates = 1replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%#### semi sync replication settings #####plugin_dir=/usr/local/mysql57/lib/pluginplugin_load = “rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"loose_rpl_semi_sync_master_enabled = 1loose_rpl_semi_sync_slave_enabled = 1Slave[client]port = 3306default-character-set=utf8mb4socket = /data/mysql_db/test_db/mysql.sock[mysqld]datadir = /data/mysql_db/test_dbbasedir = /usr/local/mysql57tmpdir = /tmpsocket = /data/mysql_db/test_db/mysql.sockpid-file = /data/mysql_db/test_db/mysql.pidskip-external-locking = 1skip-name-resolve = 1port = 3306server_id = 2493306default-storage-engine = InnoDBcharacter-set-server = utf8mb4default_password_lifetime=0read_only=1#### log ####log_timestamps=systemlog_bin = /data/mysql_log/test_db/mysql-binlog_bin_index = /data/mysql_log/test_db/mysql-bin.indexbinlog_format = rowrelay_log_recovery=ONrelay_log=/data/mysql_log/test_db/mysql-relay-binrelay_log_index=/data/mysql_log/test_db/mysql-relay-bin.indexlog_error = /data/mysql_log/test_db/mysql-error.log#### replication ####log_slave_updates = 1replicate_wild_ignore_table = information_schema.%,performance_schema.%,sys.%#### semi sync replication settings #####plugin_dir=/usr/local/mysql57/lib/pluginplugin_load = “rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"loose_rpl_semi_sync_master_enabled = 1loose_rpl_semi_sync_slave_enabled = 13 安装配置 MHA3.1 下载 MHA进入 MHA 下载页面 Downloads, 下载Manager和Node节点安装包，由于我的服务器是centos6，所以下载了MHA Manager 0.56 rpm RHEL6和MHA Node 0.56 rpm RHEL63.2 安装 MHANode安装在所有主机(包括Manager)上执行# 安装依赖yum install perl perl-devel perl-DBD-MySQL# 安装 node 工具rpm -ivh mha4mysql-node-0.56-0.el6.noarch.rpmManager安装在 Manager 主机上执行# 安装依赖yum install -y perl perl-devel perl-DBD-MySQL perl-Config-Tiny perl-Log-Dispatch perl-Parallel-ForkManager perl-Time-HiRes# 安装 managerrpm -ivh mha4mysql-manager-0.56-0.el6.noarch.rpmMHA Installation3.3 创建 MHA 管理用户管理用户需要执行一些数据库管理命令包括STOP SLAVE, CHANGE MASTER, RESET SLAVEcreate user mha_manager@’%’ identified by ‘mha_manager’;grant all on . to mha_manager@’%’;flush privileges;3.4 增加 MySQL 用户 sudo 权限配置 VIP 需要有 sudo 权限打开/etc/sudoers文件, 增加一条root ALL=(ALL) ALL# 这个是增加的mysql ALL=(ALL) NOPASSWD: ALL然后把Defaults requiretty注释掉# Defaults requiretty3.5 配置各主机免密码登陆所有主机执行# 进入 mysql 用户su - mysql# 生成密钥对, 执行命令，然后按回车ssh-keygen -t rsa# 复制公钥到相应主机ssh-copy-id mysql@10.0.0.247ssh-copy-id mysql@10.0.0.248ssh-copy-id mysql@10.0.0.249ssh-copy-id mysql@10.0.1.243.6 配置 Manager新建/etc/masterha目录，我们把配置文件放到这里mkdir /etc/masterha创建配置文件/etc/masterha/app1.cnf, 写上配置[server default]manager_workdir=/etc/masterha # 设置 manager 的工作目录, 可以自己调整manager_log=/etc/masterha/manager.log # 设置 manager 的日志文件master_binlog_dir=/data/mysql_log/test_db # 设置 master binlog 的日志的位置master_ip_failover_script= /etc/masterha/script/master_ip_failover # 设置自动 failover 时的切换脚本, 脚本参考附件master_ip_online_change_script= /etc/masterha/script/master_ip_online_change # 设置手动切换时执行的切换脚本, 脚本参考附件user=mha_manager # 设置管理用户, 用来监控、配置 MySQL(STOP SLAVE, CHANGE MASTER, RESET SLAVE), 默认为 rootpassword=mha_manager # 设置管理用户密码repl_user=repl # 设置复制环境中的复制用户名repl_password=repl # 设置复制用户的密码ping_interval=1 # 发送 ping 包的时间间隔，三次没有回应就自动进行 failoverremote_workdir=/tmp # 设置远端 MySQL 的工作目录report_script=/etc/masterha/script/send_report # 设置发生切换后执行的脚本# 检查脚本secondary_check_script= /usr/bin/masterha_secondary_check-s 10.0.0.247 -s 10.0.0.248 shutdown_script=”” #设置故障发生后关闭故障主机脚本(可以用于防止脑裂)ssh_user=mysql #设置 ssh 的登录用户名[server1]hostname=10.0.0.247port=3306[server2]hostname=10.0.0.248port=3306candidate_master=1 # 设置为候选 master, 如果发生宕机切换，会把该节点设为新 Master，即使它不是数据最新的节点check_repl_delay=0 # 默认情况下，一个 Slave 落后 Master 100M 的中继日志，MHA 不会选择它作为新的 Master，因为这对于 Slave 恢复数据要很长时间，check_repl_delay=0 的时候会忽略延迟，可以和 candidate_master=1 配合用[server3]hostname=10.0.0.249port=3306no_master=1 # 从不将这台主机升级为 Masterignore_fail=1 # 默认情况下，如果有 Slave 节点挂了， 就不进行切换，设置 ignore_fail=1 可以忽然它创建配置文件/etc/masterha/app2.cnf, 以备用Master 为 Master, 方便切换后启动MHA[server default]manager_workdir=/etc/masterha # 设置 manager 的工作目录, 可以自己调整manager_log=/etc/masterha/manager.log # 设置 manager 的日志文件master_binlog_dir=/data/mysql_log/test_db # 设置 master binlog 的日志的位置master_ip_failover_script= /etc/masterha/script/master_ip_failover # 设置自动 failover 时的切换脚本master_ip_online_change_script= /etc/masterha/script/master_ip_online_change # 设置手动切换时执行的切换脚本user=mha_manager # 设置管理用户, 用来监控、配置 MySQL(STOP SLAVE, CHANGE MASTER, RESET SLAVE), 默认为 rootpassword=mha_manager # 设置管理用户密码repl_user=repl # 设置复制环境中的复制用户名repl_password=repl # 设置复制用户的密码ping_interval=1 # 发送 ping 包的时间间隔，三次没有回应就自动进行 failoverremote_workdir=/tmp # 设置远端 MySQL 的工作目录report_script=/etc/masterha/script/send_report # 设置发生切换后执行的脚本# 检查脚本secondary_check_script= /usr/bin/masterha_secondary_check -s 10.0.0.248 -s 10.0.0.247shutdown_script=”" #设置故障发生后关闭故障主机脚本(可以用于防止脑裂)ssh_user=mysql #设置 ssh 的登录用户名[server1]hostname=10.0.0.248port=3306[server2]hostname=10.0.0.247port=3306candidate_master=1 # 设置为候选 master, 如果发生宕机切换，会把该节点设为新 Master，即使它不是数据最新的节点check_repl_delay=0 # 默认情况下，一个 Slave 落后 Master 100M 的中继日志，MHA 不会选择它作为新的 Master，因为这对于 Slave 恢复数据要很长时间，check_repl_delay=0 的时候会忽略延迟，可以和 candidate_master=1 配合用[server3]hostname=10.0.0.249port=3306no_master=1 # 从不将这台主机升级为 Masterignore_fail=1 # 默认情况下，如果有 Slave 节点挂了， 就不进行切换，设置 ignore_fail=1 可以忽然它注意：使用的时候去掉注释3.7 配置切换脚本管理 VIP 方式MHA管理VIP有两种方案，一种是使用Keepalived，另一种是自己写命令实现增删VIP，由于Keepalived容易受到网络波动造成VIP切换，而且无法在多实例机器上使用，所以建议写脚本管理VIP。当前主机的网卡是eth0, 可以通过下列命令增删 VIPup VIPsudo /sbin/ifconfig eth0:1 10.0.0.237 netmask 255.255.255.255down VIPsudo /sbin/ifconfig eth0:1 down配置切换脚本master_ip_failover , master_ip_online_change和send_report脚本在附录里面更改 mysql 配置MHA的检测比较严格，所以我们把除Master外的节点设为read_only, 有必要可以写进配置文件里面# mysql shellset global read_only=1;MHA需要使用中继日志来实现数据一致性，所以所有节点要设置不自动清理中继日志# mysql shellset global relay_log_purge=0;也可以写入配置文件# my.cnfrelay_log_purge=0MHA 常用命令Managermasterha_check_ssh 检查 MHA 的 SSH 配置状况 masterha_check_repl 检查 MySQL 复制状况masterha_manger 启动 MHAmasterha_stop 停止 MHAmasterha_check_status 检测当前 MHA 运行状态masterha_master_monitor 检测 master 是否宕机masterha_master_switch 手动故障转移masterha_conf_host 添加或删除配置的 server 信息Nodesave_binary_logs 保存 master 的二进制日志apply_diff_relay_logs 对比识别中继日志的差异部分purge_relay_logs 清除中继日志(MHA中继日志需要使用这个命令清除)命令的使用方法可以通过执行命令 –help 得到验证 SSH 是否成功、主从状态是否正常在 manager 节点执行 masterha_check_ssh –conf=/etc/masterha/app1.cnf 检测SSH状态，下面是执行结果[mysql@chengqm ~]$ masterha_check_ssh –conf=/etc/masterha/app1.cnfThu Dec 20 19:47:18 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.Thu Dec 20 19:47:18 2018 - [info] Reading application default configuration from /etc/masterha/app1.cnf..Thu Dec 20 19:47:18 2018 - [info] Reading server configuration from /etc/masterha/app1.cnf..Thu Dec 20 19:47:18 2018 - [info] Starting SSH connection tests..Thu Dec 20 19:47:19 2018 - [debug] Thu Dec 20 19:47:18 2018 - [debug] Connecting via SSH from mysql@10.0.0.247(10.0.0.247:22) to mysql@10.0.0.248(10.0.0.248:22)..Thu Dec 20 19:47:19 2018 - [debug] ok.Thu Dec 20 19:47:19 2018 - [debug] Connecting via SSH from mysql@10.0.0.247(10.0.0.247:22) to mysql@10.0.0.249(10.0.0.249:22)..Thu Dec 20 19:47:19 2018 - [debug] ok.Thu Dec 20 19:47:19 2018 - [debug] Thu Dec 20 19:47:19 2018 - [debug] Connecting via SSH from mysql@10.0.0.248(10.0.0.248:22) to mysql@10.0.0.247(10.0.0.247:22)..Thu Dec 20 19:47:19 2018 - [debug] ok.Thu Dec 20 19:47:19 2018 - [debug] Connecting via SSH from mysql@10.0.0.248(10.0.0.248:22) to mysql@10.0.0.249(10.0.0.249:22)..Thu Dec 20 19:47:19 2018 - [debug] ok.Thu Dec 20 19:47:20 2018 - [debug] Thu Dec 20 19:47:19 2018 - [debug] Connecting via SSH from mysql@10.0.0.249(10.0.0.249:22) to mysql@10.0.0.247(10.0.0.247:22)..Thu Dec 20 19:47:20 2018 - [debug] ok.Thu Dec 20 19:47:20 2018 - [debug] Connecting via SSH from mysql@10.0.0.249(10.0.0.249:22) to mysql@10.0.0.248(10.0.0.248:22)..Thu Dec 20 19:47:20 2018 - [debug] ok.Thu Dec 20 19:47:20 2018 - [info] All SSH connection tests passed successfully.在 manager 节点执行 masterha_check_repl –conf=/etc/masterha/app1.cnf 检测同步状态，下面是执行结果[mysql@chengqm ~]$ masterha_check_repl –conf=/etc/masterha/app1.cnfThu Dec 20 20:05:03 2018 - [warning] Global configuration file /etc/masterha_default.cnf not found. Skipping.Thu Dec 20 20:05:03 2018 - [info] Reading application default configuration from /etc/masterha/app1.cnf..Thu Dec 20 20:05:03 2018 - [info] Reading server configuration from /etc/masterha/app1.cnf..Thu Dec 20 20:05:03 2018 - [info] MHA::MasterMonitor version 0.56.Thu Dec 20 20:05:03 2018 - [info] Multi-master configuration is detected. Current primary(writable) master is 10.0.0.247(10.0.0.247:3306)Thu Dec 20 20:05:03 2018 - [info] Master configurations are as below: Master 10.0.0.247(10.0.0.247:3306), replicating from 10.0.0.248(10.0.0.248:3306)Master 10.0.0.248(10.0.0.248:3306), replicating from 10.0.0.247(10.0.0.247:3306), read-only================ 省略 ==================Thu Dec 20 20:05:08 2018 - [info] /etc/masterha/script/master_ip_failover –command=status –ssh_user=mysql –orig_master_host=10.0.0.247 –orig_master_ip=10.0.0.247 –orig_master_port=3306 Thu Dec 20 20:05:08 2018 - [info] OK.Thu Dec 20 20:05:08 2018 - [warning] shutdown_script is not defined.Thu Dec 20 20:05:08 2018 - [info] Got exit code 0 (Not master dead).MySQL Replication Health is OK.出现 MySQL Replication Health is OK. 表示成功如果出现Failed to get master_ip_failover_script status with return code 255:0这个错误，就注释掉master_ip_failover脚本的FIXME_xxx注意：要想正常运行，系统路径必须要有 mysqlbinlog 和 mysql 命令4 启动和测试4.1 启动使用脚本管理 VIP 不会自动设置 VIP，所以先手动在 Master 设置 VIP[root@cluster01 ~]# /sbin/ifconfig eth0:1 10.0.0.237 netmask 255.255.255.255[root@cluster01 ~]# ifconfigeth0 Link encap:Ethernet HWaddr FA:16:3E:DE:80:33 inet addr:10.0.0.247 Bcast:10.0.255.255 Mask:255.255.0.0 inet6 addr: fe80::f816:3eff:fede:8033/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17333247 errors:0 dropped:0 overruns:0 frame:0 TX packets:5472004 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1476157398 (1.3 GiB) TX bytes:1064253754 (1014.9 MiB)eth0:1 Link encap:Ethernet HWaddr FA:16:3E:DE:80:33 inet addr:10.0.0.237 Bcast:10.0.0.237 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1…启动 MHA Manager[mysql@chengqm ~]$ nohup /usr/bin/masterha_manager –conf=/etc/masterha/app1.cnf –ignore_last_failover &[1] 21668–ignore_last_failover 忽略上次切换。MHA每次故障切换后都会生成一个app1.failover.complete这样的文件，如果不加这个参数，需要删除这个文件才能再次启动检查启动日志[mysql@chengqm ~]$ tail -18 /etc/masterha/manager.log Fri Dec 21 13:56:39 2018 - [info] 10.0.0.247(10.0.0.247:3306) (current master) +–10.0.0.248(10.0.0.248:3306) +–10.0.0.249(10.0.0.249:3306)Fri Dec 21 13:56:39 2018 - [info] Checking master_ip_failover_script status:Fri Dec 21 13:56:39 2018 - [info] /etc/masterha/script/master_ip_failover –command=status –ssh_user=mysql –orig_master_host=10.0.0.247 –orig_master_ip=10.0.0.247 –orig_master_port=3306 VIP Command: start=sudo /sbin/ifconfig eth0:1 10.0.0.237 netmask 255.255.255.255 stop=sudo /sbin/ifconfig eth0:1 downCheck script.. OK Fri Dec 21 13:56:39 2018 - [info] OK.Fri Dec 21 13:56:39 2018 - [warning] shutdown_script is not defined.Fri Dec 21 13:56:39 2018 - [info] Set master ping interval 1 seconds.Fri Dec 21 13:56:39 2018 - [info] Set secondary check script: /usr/bin/masterha_secondary_check -s 10.0.0.247 -s 10.0.0.248Fri Dec 21 13:56:39 2018 - [info] Starting ping health check on 10.0.0.247(10.0.0.247:3306)..Fri Dec 21 13:56:39 2018 - [info] Ping(SELECT) succeeded, waiting until MySQL doesn’t respond..日志中显示 Ping(SELECT) succeeded, waiting until MySQL doesn’t respond 表示启动成功如果查看Master的general日志，会发现MHA不断执行SELECT 1 As Value检查命令4.2 失效转移我们模拟Master数据库宕机的情况[root@cluster01 ~]# ps -ef | grep mysqlmysql 20061 1 0 11:19 pts/0 00:00:00 /bin/sh /usr/local/mysql57/bin/mysqld_safe –defaults-file=/data/mysql_db/test_db/my.cnf –datadir=/data/mysql_db/test_db –pid-file=/data/mysql_db/test_db/mysql.pidmysql 20494 20061 0 11:19 pts/0 00:00:21 /usr/local/mysql57/bin/mysqld –defaults-file=/data/mysql_db/test_db/my.cnf –basedir=/usr/local/mysql57 –datadir=/data/mysql_db/test_db –plugin-dir=/usr/local/mysql57/lib/plugin –log-error=/data/mysql_log/test_db/mysql-error.log –pid-file=/data/mysql_db/test_db/mysql.pid –socket=/data/mysql_db/test_db/mysql.sock –port=3306[root@cluster01 ~]# kill -9 20061 20494查看MHA日志可以看到整个切换过程Fri Dec 21 14:04:49 2018 - [warning] Got error on MySQL select ping: 2006 (MySQL server has gone away)Fri Dec 21 14:04:49 2018 - [info] Executing secondary network check script: /usr/bin/masterha_secondary_check -s 10.0.0.247 -s 10.0.0.248 –user=mysql –master_host=10.0.0.247 –master_ip=10.0.0.247 –master_port=3306 –master_user=mha_manager –master_password=mha_manager –ping_type=SELECTFri Dec 21 14:04:49 2018 - [info] Executing SSH check script: save_binary_logs –command=test –start_pos=4 –binlog_dir=/data/mysql_log/test_db –output_file=/tmp/save_binary_logs_test –manager_version=0.56 –binlog_prefix=mysql-binMonitoring server 10.0.0.247 is reachable, Master is not reachable from 10.0.0.247. OK.Fri Dec 21 14:04:49 2018 - [info] HealthCheck: SSH to 10.0.0.247 is reachable.Monitoring server 10.0.0.248 is reachable, Master is not reachable from 10.0.0.248. OK.Fri Dec 21 14:04:49 2018 - [info] Master is not reachable from all other monitoring servers. Failover should start.=============== 省略 ================Fri Dec 21 14:04:52 2018 - [info] Forcing shutdown so that applications never connect to the current master..Fri Dec 21 14:04:52 2018 - [info] Executing master IP deactivation script:Fri Dec 21 14:04:52 2018 - [info] /etc/masterha/script/master_ip_failover –orig_master_host=10.0.0.247 –orig_master_ip=10.0.0.247 –orig_master_port=3306 –command=stopssh –ssh_user=mysql VIP Command: start=sudo /sbin/ifconfig eth0:1 10.0.0.237 netmask 255.255.255.255 stop=sudo /sbin/ifconfig eth0:1 downDisabling the VIP on old master: 10.0.0.247 SIOCSIFFLAGS: Cannot assign requested addressFri Dec 21 14:04:52 2018 - [info] done.=============== 省略 ================Fri Dec 21 14:04:53 2018 - [info] Starting master failover..Fri Dec 21 14:04:53 2018 - [info] From:10.0.0.247(10.0.0.247:3306) (current master) +–10.0.0.248(10.0.0.248:3306) +–10.0.0.249(10.0.0.249:3306)To:10.0.0.248(10.0.0.248:3306) (new master) +–10.0.0.249(10.0.0.249:3306)Fri Dec 21 14:04:53 2018 - [info]=============== 省略 ================Fri Dec 21 14:04:53 2018 - [info] All other slaves should start replication from here. Statement should be: CHANGE MASTER TO MASTER_HOST=‘10.0.0.248’, MASTER_PORT=3306, MASTER_LOG_FILE=‘mysql-bin.000005’, MASTER_LOG_POS=154, MASTER_USER=‘repl’, MASTER_PASSWORD=‘xxx’;Fri Dec 21 14:04:53 2018 - [info] Executing master IP activate script:Fri Dec 21 14:04:53 2018 - [info] /etc/masterha/script/master_ip_failover –command=start –ssh_user=mysql –orig_master_host=10.0.0.247 –orig_master_ip=10.0.0.247 –orig_master_port=3306 –new_master_host=10.0.0.248 –new_master_ip=10.0.0.248 –new_master_port=3306 –new_master_user=‘mha_manager’ –new_master_password=‘mha_manager’ VIP Command: start=sudo /sbin/ifconfig eth0:1 10.0.0.237 netmask 255.255.255.255 stop=sudo /sbin/ifconfig eth0:1 downSet read_only=0 on the new master.Enabling the VIP - 10.0.0.237 on the new master - 10.0.0.248 =============== 省略 ================Fri Dec 21 14:04:55 2018 - [info] 10.0.0.248: Resetting slave info succeeded.Fri Dec 21 14:04:55 2018 - [info] Master failover to 10.0.0.248(10.0.0.248:3306) completed successfully.查看新Master VIP[mysql@cluster02 ]$ ifconfigeth0 Link encap:Ethernet HWaddr FA:16:3E:66:7E:E8 inet addr:10.0.0.248 Bcast:10.0.255.255 Mask:255.255.0.0 inet6 addr: fe80::f816:3eff:fe66:7ee8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:40197173 errors:0 dropped:0 overruns:0 frame:0 TX packets:10470689 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4063358126 (3.7 GiB) TX bytes:2269241789 (2.1 GiB)eth0:1 Link encap:Ethernet HWaddr FA:16:3E:66:7E:E8 inet addr:10.0.0.237 Bcast:10.0.0.237 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1可以看到VIP已经成功切换查看新Master的general日志，可以看到MHA的操作过程, 下面展示部分日志…2018-12-21T14:04:41.782336+08:00 5525 Query SHOW SLAVE STATUS2018-12-21T14:04:41.788318+08:00 5525 Query STOP SLAVE IO_THREAD2018-12-21T14:04:41.900734+08:00 5525 Query SHOW SLAVE STATUS2018-12-21T14:04:42.044801+08:00 5525 Query SHOW SLAVE STATUS2018-12-21T14:04:42.668581+08:00 5525 Query SHOW SLAVE STATUS2018-12-21T14:04:42.670336+08:00 5525 Query STOP SLAVE SQL_THREAD…2018-12-21T14:04:42.863904+08:00 5526 Query SET GLOBAL read_only=0…2018-12-21T14:04:43.950986+08:00 5527 Query SET @rpl_semi_sync_slave= 1…查看Slave的general日志，可以看到Slave会重新指向2018-12-21T14:04:04.835218+08:00 90 Query STOP SLAVE IO_THREAD2018-12-21T14:04:04.955706+08:00 90 Query SHOW SLAVE STATUS2018-12-21T14:04:05.092123+08:00 90 Query SHOW SLAVE STATUS2018-12-21T14:04:06.018838+08:00 90 Query SHOW SLAVE STATUS2018-12-21T14:04:06.034225+08:00 90 Query SHOW SLAVE STATUS2018-12-21T14:04:06.036613+08:00 90 Query SHOW SLAVE STATUS2018-12-21T14:04:06.038475+08:00 90 Query STOP SLAVE SQL_THREAD2018-12-21T14:04:06.160142+08:00 90 Query SHOW SLAVE STATUS2018-12-21T14:04:06.162224+08:00 90 Query STOP SLAVE2018-12-21T14:04:06.163171+08:00 90 Query SHOW SLAVE STATUS2018-12-21T14:04:06.164554+08:00 90 Query RESET SLAVE2018-12-21T14:04:06.825564+08:00 90 Query CHANGE MASTER TO MASTER_HOST = ‘10.0.0.248’ MASTER_USER = ‘repl’ MASTER_PASSWORD = <secret> MASTER_PORT = 3306 MASTER_LOG_FILE = ‘mysql-bin.000005’ MASTER_LOG_POS = 1542018-12-21T14:04:06.981718+08:00 90 Query SET GLOBAL relay_log_purge=02018-12-21T14:04:06.982802+08:00 90 Query START SLAVE注意: MHA在切换完成后会结束 Manager 进程4.3 手动切换切换后Master为Cluster2, 把Cluster1重新指向Cluster2，现在测试一下手动切换，把Master切回Cluster1, 命令如下masterha_master_switch –conf=/etc/masterha/app2.cnf –master_state=alive –new_master_host=10.0.0.247 –new_master_port=3306 –orig_master_is_new_slave–orig_master_is_new_slave 是将原master切换为新主的slave，默认情况下，是不添加的。下面是执行过程, 有两个地方要回答 yes/no[mysql@chengqm ]$ masterha_master_switch –conf=/etc/masterha/app2.cnf –master_state=alive –new_master_host=10.0.0.247 –new_master_port=3306 –orig_master_is_new_slave……It is better to execute FLUSH NO_WRITE_TO_BINLOG TABLES on the master before switching. Is it ok to execute on 10.0.0.248(10.0.0.248:3306)? (YES/no): yes……Sun Dec 23 16:50:48 2018 - [info] From:10.0.0.248(10.0.0.248:3306) (current master) +–10.0.0.247(10.0.0.247:3306) +–10.0.0.249(10.0.0.249:3306)To:10.0.0.247(10.0.0.247:3306) (new master) +–10.0.0.249(10.0.0.249:3306) +–10.0.0.248(10.0.0.248:3306)Starting master switch from 10.0.0.248(10.0.0.248:3306) to 10.0.0.247(10.0.0.247:3306)? (yes/NO): yes……Sun Dec 23 16:51:36 2018 - [info] 10.0.0.247: Resetting slave info succeeded.Sun Dec 23 16:51:36 2018 - [info] Switching master to 10.0.0.247(10.0.0.247:3306) completed successfully.切换成功，查看Cluster1的VIP[mysql@cluster01 ]$ ifconfigeth0 Link encap:Ethernet HWaddr FA:16:3E:DE:80:33 inet addr:10.0.0.247 Bcast:10.0.255.255 Mask:255.255.0.0 inet6 addr: fe80::f816:3eff:fede:8033/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20585872 errors:0 dropped:0 overruns:0 frame:0 TX packets:5519122 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1785787985 (1.6 GiB) TX bytes:1068115408 (1018.6 MiB)eth0:1 Link encap:Ethernet HWaddr FA:16:3E:DE:80:33 inet addr:10.0.0.237 Bcast:10.0.0.237 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1注意：手动切换的时候先把 MHA Manager 停了4.4 停止 MHA停止 MHA 的命令如下，就不演示了masterha_stop –conf=配置文件5 总结总的来说，MHA是一套非常优秀而且使用比较广的高可用程序，它可以自动补齐日志使得一致性有保证，部署的时候不需要改变原有架构就可以使用。但是使用起来还是有一点复杂的，因为MHA不接管VIP，所以要自己写脚本实现，而且只保证Master高可用，没有Slave高可用，还有就是中继日志要自己设定时任务来清理。不管怎么说，在没有更好的方案下，MHA还是值得使用的。附master_ip_failover 脚本#!/usr/bin/env perluse strict;use warnings FATAL => ‘all’;use Getopt::Long;use MHA::DBHelper;my ( $command, $ssh_user, $orig_master_host, $orig_master_ip, $orig_master_port, $new_master_host, $new_master_ip, $new_master_port, $new_master_user, $new_master_password);my $vip = ‘10.0.0.237’;my $key = ‘1’;my $ssh_start_vip = “sudo /sbin/ifconfig eth0:$key $vip netmask 255.255.255.255”;my $ssh_stop_vip = “sudo /sbin/ifconfig eth0:$key down”;GetOptions( ‘command=s’ => $command, ‘ssh_user=s’ => $ssh_user, ‘orig_master_host=s’ => $orig_master_host, ‘orig_master_ip=s’ => $orig_master_ip, ‘orig_master_port=i’ => $orig_master_port, ’new_master_host=s’ => $new_master_host, ’new_master_ip=s’ => $new_master_ip, ’new_master_port=i’ => $new_master_port, ’new_master_user=s’ => $new_master_user, ’new_master_password=s’ => $new_master_password,);exit &main();sub main { print “\n\n VIP Command: start=$ssh_start_vip stop=$ssh_stop_vip\n\n”; if ( $command eq “stop” || $command eq “stopssh” ) { # $orig_master_host, $orig_master_ip, $orig_master_port are passed. # If you manage master ip address at global catalog database, # invalidate orig_master_ip here. my $exit_code = 1; eval { print “Disabling the VIP on old master: $orig_master_host \n”; &stop_vip(); # updating global catalog, etc $exit_code = 0; }; if ($@) { warn “Got Error: $@\n”; exit $exit_code; } exit $exit_code; } elsif ( $command eq “start” ) { # all arguments are passed. # If you manage master ip address at global catalog database, # activate new_master_ip here. # You can also grant write access (create user, set read_only=0, etc) here. my $exit_code = 10; eval { my $new_master_handler = new MHA::DBHelper(); # args: hostname, port, user, password, raise_error_or_not $new_master_handler->connect( $new_master_ip, $new_master_port, $new_master_user, $new_master_password, 1 ); ## Set read_only=0 on the new master $new_master_handler->disable_log_bin_local(); print “Set read_only=0 on the new master.\n”; $new_master_handler->disable_read_only(); $new_master_handler->disconnect(); print “Enabling the VIP - $vip on the new master - $new_master_host \n”; &start_vip(); $exit_code = 0; }; if ($@) { warn $@; # If you want to continue failover, exit 10. exit $exit_code; } exit $exit_code; } elsif ( $command eq “status” ) { print “Check script.. OK \n”; # do nothing exit 0; } else { &usage(); exit 1; }}sub start_vip() { ssh $ssh_user\@$new_master_host \" $ssh_start_vip \";}sub stop_vip() { return 0 unless ($ssh_user); ssh $ssh_user\@$orig_master_host \" $ssh_stop_vip \";}sub usage { print"Usage: master_ip_failover –command=start|stop|stopssh|status –orig_master_host=host –orig_master_ip=ip –orig_master_port=port –new_master_host=host –new_master_ip=ip –new_master_port=port\n";}master_ip_online_change 脚本#!/usr/bin/env perl# Copyright (C) 2011 DeNA Co.,Ltd.## This program is free software; you can redistribute it and/or modify# it under the terms of the GNU General Public License as published by# the Free Software Foundation; either version 2 of the License, or# (at your option) any later version.## This program is distributed in the hope that it will be useful,# but WITHOUT ANY WARRANTY; without even the implied warranty of# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the# GNU General Public License for more details.## You should have received a copy of the GNU General Public License# along with this program; if not, write to the Free Software# Foundation, Inc.,# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA## Note: This is a sample script and is not complete. Modify the script based on your environment.use strict;use warnings FATAL => ‘all’;use Getopt::Long;use MHA::DBHelper;use MHA::NodeUtil;use Time::HiRes qw( sleep gettimeofday tv_interval );use Data::Dumper;my $_tstart;my $_running_interval = 0.1;my ( $command, $orig_master_is_new_slave, $orig_master_host, $orig_master_ip, $orig_master_port, $orig_master_user, $orig_master_password, $orig_master_ssh_user, $new_master_host, $new_master_ip, $new_master_port, $new_master_user, $new_master_password, $new_master_ssh_user);GetOptions( ‘command=s’ => $command, ‘orig_master_is_new_slave’ => $orig_master_is_new_slave, ‘orig_master_host=s’ => $orig_master_host, ‘orig_master_ip=s’ => $orig_master_ip, ‘orig_master_port=i’ => $orig_master_port, ‘orig_master_user=s’ => $orig_master_user, ‘orig_master_password=s’ => $orig_master_password, ‘orig_master_ssh_user=s’ => $orig_master_ssh_user, ’new_master_host=s’ => $new_master_host, ’new_master_ip=s’ => $new_master_ip, ’new_master_port=i’ => $new_master_port, ’new_master_user=s’ => $new_master_user, ’new_master_password=s’ => $new_master_password, ’new_master_ssh_user=s’ => $new_master_ssh_user,);my $vip = ‘10.0.0.237’;my $key = ‘1’;my $ssh_start_vip = “sudo /sbin/ifconfig eth0:$key $vip netmask 255.255.255.255”;my $ssh_stop_vip = “sudo /sbin/ifconfig eth0:$key down”;exit &main();sub current_time_us { my ( $sec, $microsec ) = gettimeofday(); my $curdate = localtime($sec); return $curdate . " " . sprintf( “%06d”, $microsec );}sub sleep_until { my $elapsed = tv_interval($_tstart); if ( $_running_interval > $elapsed ) { sleep( $_running_interval - $elapsed ); }}sub get_threads_util { my $dbh = shift; my $my_connection_id = shift; my $running_time_threshold = shift; my $type = shift; $running_time_threshold = 0 unless ($running_time_threshold); $type = 0 unless ($type); my @threads; my $sth = $dbh->prepare(“SHOW PROCESSLIST”); $sth->execute(); while ( my $ref = $sth->fetchrow_hashref() ) { my $id = $ref->{Id}; my $user = $ref->{User}; my $host = $ref->{Host}; my $command = $ref->{Command}; my $state = $ref->{State}; my $query_time = $ref->{Time}; my $info = $ref->{Info}; $info = s/^\s*(.?)\s$/$1/ if defined($info); next if ( $my_connection_id == $id ); next if ( defined($query_time) && $query_time < $running_time_threshold ); next if ( defined($command) && $command eq “Binlog Dump” ); next if ( defined($user) && $user eq “system user” ); next if ( defined($command) && $command eq “Sleep” && defined($query_time) && $query_time >= 1 ); if ( $type >= 1 ) { next if ( defined($command) && $command eq “Sleep” ); next if ( defined($command) && $command eq “Connect” ); } if ( $type >= 2 ) { next if ( defined($info) && $info = m/^select/i ); next if ( defined($info) && $info = m/^show/i ); } push @threads, $ref; } return @threads;}sub main { if ( $command eq “stop” ) { ## Gracefully killing connections on the current master # 1. Set read_only= 1 on the new master # 2. DROP USER so that no app user can establish new connections # 3. Set read_only= 1 on the current master # 4. Kill current queries # * Any database access failure will result in script die. my $exit_code = 1; eval { ## Setting read_only=1 on the new master (to avoid accident) my $new_master_handler = new MHA::DBHelper(); # args: hostname, port, user, password, raise_error(die_on_error)_or_not $new_master_handler->connect( $new_master_ip, $new_master_port, $new_master_user, $new_master_password, 1 ); print current_time_us() . " Set read_only on the new master.. “; $new_master_handler->enable_read_only(); if ( $new_master_handler->is_read_only() ) { print “ok.\n”; } else { die “Failed!\n”; } $new_master_handler->disconnect(); # Connecting to the orig master, die if any database error happens my $orig_master_handler = new MHA::DBHelper(); $orig_master_handler->connect( $orig_master_ip, $orig_master_port, $orig_master_user, $orig_master_password, 1 ); $orig_master_handler->disable_log_bin_local(); ## Waiting for N * 100 milliseconds so that current connections can exit my $time_until_read_only = 15; $tstart = [gettimeofday]; my @threads = get_threads_util( $orig_master_handler->{dbh}, $orig_master_handler->{connection_id} ); while ( $time_until_read_only > 0 && $#threads >= 0 ) { if ( $time_until_read_only % 5 == 0 ) { printf”%s Waiting all running %d threads are disconnected.. (max %d milliseconds)\n", current_time_us(), $#threads + 1, $time_until_read_only * 100; if ( $#threads < 5 ) { print Data::Dumper->new( [$] )->Indent(0)->Terse(1)->Dump . “\n” foreach (@threads); } } sleep_until(); $tstart = [gettimeofday]; $time_until_read_only–; @threads = get_threads_util( $orig_master_handler->{dbh}, $orig_master_handler->{connection_id} ); } ## Setting read_only=1 on the current master so that nobody(except SUPER) can write print current_time_us() . " Set read_only=1 on the orig master.. “; $orig_master_handler->enable_read_only(); if ( $orig_master_handler->is_read_only() ) { print “ok.\n”; } else { die “Failed!\n”; } ## Waiting for M * 100 milliseconds so that current update queries can complete my $time_until_kill_threads = 5; @threads = get_threads_util( $orig_master_handler->{dbh}, $orig_master_handler->{connection_id} ); while ( $time_until_kill_threads > 0 && $#threads >= 0 ) { if ( $time_until_kill_threads % 5 == 0 ) { printf”%s Waiting all running %d queries are disconnected.. (max %d milliseconds)\n", current_time_us(), $#threads + 1, $time_until_kill_threads * 100; if ( $#threads < 5 ) { print Data::Dumper->new( [$] )->Indent(0)->Terse(1)->Dump . “\n” foreach (@threads); } } sleep_until(); $_tstart = [gettimeofday]; $time_until_kill_threads–; @threads = get_threads_util( $orig_master_handler->{dbh}, $orig_master_handler->{connection_id} ); } ## Terminating all threads print current_time_us() . " Killing all application threads..\n"; $orig_master_handler->kill_threads(@threads) if ( $#threads >= 0 ); print current_time_us() . " done.\n"; $orig_master_handler->enable_log_bin_local(); $orig_master_handler->disconnect(); print “Disabling the VIP on old master: $orig_master_host \n”; &stop_vip(); ## After finishing the script, MHA executes FLUSH TABLES WITH READ LOCK $exit_code = 0; }; if ($@) { warn “Got Error: $@\n”; exit $exit_code; } exit $exit_code; } elsif ( $command eq “start” ) { ## Activating master ip on the new master # 1. Create app user with write privileges # 2. Moving backup script if needed # 3. Register new master’s ip to the catalog database# We don’t return error even though activating updatable accounts/ip failed so that we don’t interrupt slaves’ recovery.# If exit code is 0 or 10, MHA does not abort my $exit_code = 10; eval { my $new_master_handler = new MHA::DBHelper(); # args: hostname, port, user, password, raise_error_or_not $new_master_handler->connect( $new_master_ip, $new_master_port, $new_master_user, $new_master_password, 1 ); ## Set read_only=0 on the new master $new_master_handler->disable_log_bin_local(); print current_time_us() . " Set read_only=0 on the new master.\n"; $new_master_handler->disable_read_only(); $new_master_handler->enable_log_bin_local(); $new_master_handler->disconnect(); print “Enabling the VIP - $vip on the new master - $new_master_host \n”; &start_vip(); ## Update master ip on the catalog database, etc $exit_code = 0; }; if ($@) { warn “Got Error: $@\n”; exit $exit_code; } exit $exit_code; } elsif ( $command eq “status” ) { # do nothing exit 0; } else { &usage(); exit 1; }}sub start_vip() { return 0 unless ($new_master_ssh_user); ssh $new_master_ssh_user\@$new_master_host \" $ssh_start_vip \";}sub stop_vip() { return 0 unless ($orig_master_ssh_user); ssh $orig_master_ssh_user\@$orig_master_host \" $ssh_stop_vip \";}sub usage { print"Usage: master_ip_online_change –command=start|stop|status –orig_master_host=host –orig_master_ip=ip –orig_master_port=port –new_master_host=host –new_master_ip=ip –new_master_port=port\n"; die;}send_report 脚本#!/usr/bin/perluse strict;use warnings FATAL => ‘all’;use Getopt::Long;#new_master_host and new_slave_hosts are set only when recovering master succeededmy ( $dead_master_host, $new_master_host, $new_slave_hosts, $subject, $body, $title, $content);GetOptions( ‘orig_master_host=s’ => $dead_master_host, ’new_master_host=s’ => $new_master_host, ’new_slave_hosts=s’ => $new_slave_hosts, ‘subject=s’ => $subject, ‘body=s’ => $body,);# 调用外部脚本$title="[mha switch]";$content="date +'%Y-%m-%d %H:%M' old_master=".$dead_master_host." new_master=".$new_master_host;system(“sh /etc/masterha/script/send_report.sh $title $content”);exit 0;清理中继日志定时任务下面是我的定时任务，参数自行替换, workdir 需要和中继日志在同一个盘# 每小时清理一次0 * * * * (/usr/bin/purge_relay_logs –user=mha_manager –password=mha_manager –disable_relay_log_purge –port=3306 –workdir=/tmp/relaylogtmp >> /var/log/purge_relay_logs.log 2>&1)MHA Wiki: https://github.com/yoshinorim… ...

摘要： 由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目。如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。说到SRE，就需要科普一下了。SRE全拼为Site Reliability Engineer，是软件工程师和系统管理员的结合，是一种要求极高的技术工种。据说，目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服是其中之一。由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目，今天，就来起底一下这个神秘的项目。从“青铜”到强者红蓝军技术攻防演练与蚂蚁金服技术风险部的发展息息相关，而蚂蚁技术风险的演进轨迹和游戏中的不断打怪升级非常相像。早期是质量+运维+架构师三角协同，各司其职并自发性的开展一些技术风险相关的工作。2013年，蚂蚁金服技术团队提出了质量2.0战略，以统一的规章、统一的流程和统一的阵型，开始体系化地沉淀故障检测等方面的平台化能力。大概一年后，也就是2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2015年，技术质量部正式升级成为技术风险部，专注研发及架构的技术风险问题，并完成相应解决方案和落地的平台。2016年，技术风险部再次升级为SRE团队。SRE团队组建后，就开始全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中防抖这块，要保证任何的网络或基础设施抖动，用户都无感知；而精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。同时，那个热衷“找茬”的组织——技术蓝军也正式成立。这个专门的、拥有独立职能的团队不干别的，主要职责是挖掘系统的弱点并发起“真实”的攻击，红蓝军技术攻防演练也自此诞生。牛X的是，技术蓝军并不对各业务方负责，只对应用架构及防御系统的稳定性和可靠性负责。在蓝军眼中，故障的发生是必然的，只是时间早晚而已。蓝军只有想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。所以，蓝军发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。而故障防御系统及不断优化的高可用架构则是由SRE团队的红军与各业务深度合作，沉淀、构建出来的。现在，全栈级别的技术攻防演练每周都在进行，蓝军似乎对“疯起来连自己都打”很上瘾。利矛与坚盾不断升级持续不断的攻防演练，让蓝军和红军的技术能力得到了极大地提升，同时双方“武器库”也在不断升级。2017年秋天，蓝军团队在成立后的两个月内，自主研发了字节码级别的故障注入系统Awatch，这个武器的厉害之处在于可以实时地对运行中的业务系统进行任意链路的编织侵入。这对于对于技术蓝军以及整个红蓝攻防体系，具有里程碑式的意义。蓝军研发出了厉害的武器，红军也没闲着。与此同时，技术红军的防控体系建设也在如火如荼地进行着，实时核对平台横空而出。该平台能够做到稳定的分钟级核对异常发现能力，在某些场景下可以做到秒级发现，并且平台提供了业务快速接入的能力；红军还在实时核对平台的基础之上，升级演化出一套智能核对平台(内部代号四道防线)，引入AI技术自动识别业务问题，目前这套防线已经覆盖蚂蚁80%以上的业务。另外，各个业务域针对自身业务的一些特殊性，也研发了相应的核对系统。尽管蓝军制造故障的能力有很大的提高，但大部分的故障场景主要是各个业务方提供的，只有极少数是蓝军人工梳理业务或者分析代码产出。此时，蓝军团队认为，日常演练常态化，在故障场景发现方面不能再依赖业务，必须建立自主发现故障场景的能力。2018年3月，蓝军推出故障场景挖掘平台，基于Awatch探针探测应用内数据流，以此进行“弱点挖掘”。这套弱点挖掘体系，能够自动发现故障场景，最高能够在5分钟内产生500+的故障场景，红蓝攻防的日常演练的最为重要一块拼图终于完成！然而新的问题来了。蓝军的故障挖掘平台能力毋庸置疑，但有攻击就需要应急，高频攻防实施亦会给红军带来大量的人力消耗。持续应急压力驱动，红军开展““故障自愈”架构体系升级及能力建设，以效能为目标，结合仿真，红蓝军一起研发了“无损”攻防体系，并且推出与之匹配的度量平台，自动度量攻防结果，数据可视化。目前，常态红蓝技术对抗保持每周200+个故障场景的节奏在持续运作。常态化的红蓝 “互怼”在线、实时、随地、无差别……这是支付宝技术蓝军实施攻击行为的几大标签。2017年年底的红蓝技术攻防周，技术蓝军发起攻击，但由于故障组件一处隐藏bug导致故障命中数量远远大于预期，给红军增添了不少麻烦，业务线的技术同学投入大量的人力和资源进行善后。此情此景之下，红军方面不仅没有抱怨，反而给予蓝军鼓励，“这次预期外的故障攻击是最真实的应急锻炼！”2018年年中的一次红蓝技术攻防中，蓝军在周末发起突袭，而刚好红军的相关同学正在举办婚礼。于是，一群程序员赶紧拿出吃饭的家伙，噼里啪啦敲着键盘进行应急，那画面简直不要太美了。还是在2018年的一次对抗中，红军祭出了“尖端武器”——自适应防灾、防抖等，这让蓝军吃尽苦头，几乎每次攻击都无功而返。挫败感飙升的蓝军最终放出大招，让红军接受了非常猛烈的炮火洗礼。有意思的是，似乎蓝军攻击得越欢，红军的同学越高兴……虽然看上去很受虐，但却没毛病，因为蓝军攻击得越狠越深入，被挖掘和发现出来的技术风险就会越确定，防御系统的能力也会因此而得到提升。令人震惊的是，为了防止蓝军的“袭击”，红军除了在防御系统方面下十足的功夫，每年期中和期末的红蓝技术攻防演练，红军都要举办一个仪式——那就是拜关公，除了叩拜，还得给驱邪镇恶的关公献礼，礼品包括旺仔牛奶、格子衬衫、键盘、香烟等。风险防控技术全面开放蚂蚁金服技术风险部门经过不断地升级，并将红蓝技术攻防演练形成常态化。除了每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。这意味着，支付宝的风险防控体系持续地经受打磨与锤炼。目前，支付宝的“红蓝对抗”演练已经沉淀出一整套成熟的风险防控体系，通过仿真环境模拟天灾人祸，去考验技术架构的健壮性及技术人员的应急能力，从而全面地提升系统稳定，实现系统的高可靠性和高可用性。所谓的天灾和人祸。天灾指的是，当出现台风、断网、火情等极端异常情况的时候，系统如何快速应对。这有点类似于今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场演练的异常断网情况下，“三地五中心”自动切换，保证支付服务不中断。人祸则是指因技术人员操作失误引发故障后，系统如何快速应。在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，这些技术风险相关的能力已经对外开放，目前共有3款产品，包括容灾应急平台、全链路压测和资金安全监控；另外，还有3款产品，变更管控、巡检平台和黑屏运维管控即将上线对外开放。本文作者：华蒙阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 红军 VS 蓝军，谁是更强者？小蚂蚁说：自古红蓝出CP，在蚂蚁金服就有这样两支“相爱相杀”的队伍——红军和蓝军。蓝军是进攻方，主要职责是挖掘系统的弱点并发起“真实”的攻击，俗称“找茬”；红军则是防守方，其防控体系建设中的实时核对平台能够做到稳定的分钟级核对异常发现能力，并提供业务快速接入的能力。支付宝“疯起来连自己都打”的项目就是红蓝军技术攻防演练，他们不仅每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。接下来就跟着小蚂蚁一起去看看这对红蓝cp的日常“互怼”生活吧！如果一个技术团队不干别的，专门“搞破坏”，这是一种怎样的存在？这真的不是“天方夜谭”，在支付宝确实有这么一支队伍——技术蓝军。蓝军的任务就是不断地攻击和进攻，而防守方则是技术红军。在支付宝，蓝军从属于蚂蚁金服技术风险部（SRE），而红军则包括SRE及各业务部门的技术团队。说到SRE，就需要科普一下了。SRE全拼为Site Reliability Engineer，是软件工程师和系统管理员的结合，是一种要求极高的技术工种。据说，目前全球只有少数几家顶级互联网公司拥有真正意义上的SRE团队，蚂蚁金服是其中之一。由蓝军主导的技术攻防演练就是那个传说中的“疯起来连自己都打”的项目，今天，就来起底一下这个神秘的项目。从“青铜”到强者红蓝军技术攻防演练与蚂蚁金服技术风险部的发展息息相关，而蚂蚁技术风险的演进轨迹和游戏中的不断打怪升级非常相像。早期是质量+运维+架构师三角协同，各司其职并自发性的开展一些技术风险相关的工作。2013年，蚂蚁金服技术团队提出了质量2.0战略，以统一的规章、统一的流程和统一的阵型，开始体系化地沉淀故障检测等方面的平台化能力。大概一年后，也就是2014年，专门成立了技术质量部，从全域视角解决技术风险的问题。2015年，技术质量部正式升级成为技术风险部，专注研发及架构的技术风险问题，并完成相应解决方案和落地的平台。2016年，技术风险部再次升级为SRE团队。SRE团队组建后，就开始全面开展故障自动定位、自适应容灾、防抖、精细化高可用等工作。其中防抖这块，要保证任何的网络或基础设施抖动，用户都无感知；而精细化高可用，又叫单笔高可用，其颗粒度可以精准到用户的每一笔交易，远远优于行业内的机房级高可用。同时，那个热衷“找茬”的组织——技术蓝军也正式成立。这个专门的、拥有独立职能的团队不干别的，主要职责是挖掘系统的弱点并发起“真实”的攻击，红蓝军技术攻防演练也自此诞生。牛X的是，技术蓝军并不对各业务方负责，只对应用架构及防御系统的稳定性和可靠性负责。在蓝军眼中，故障的发生是必然的，只是时间早晚而已。蓝军只有想尽办法去触发这些故障，这样，在故障真实发生的时候，才有足够的应付能力。所以，蓝军发掘各类脆弱点，并通过红蓝军技术攻防演练，不断验证防御系统的可靠性。而故障防御系统及不断优化的高可用架构则是由SRE团队的红军与各业务深度合作，沉淀、构建出来的。现在，全栈级别的技术攻防演练每周都在进行，蓝军似乎对“疯起来连自己都打”很上瘾。利矛与坚盾不断升级持续不断的攻防演练，让蓝军和红军的技术能力得到了极大地提升，同时双方“武器库”也在不断升级。2017年秋天，蓝军团队在成立后的两个月内，自主研发了字节码级别的故障注入系统Awatch，这个武器的厉害之处在于可以实时地对运行中的业务系统进行任意链路的编织侵入。这对于对于技术蓝军以及整个红蓝攻防体系，具有里程碑式的意义。蓝军研发出了厉害的武器，红军也没闲着。与此同时，技术红军的防控体系建设也在如火如荼地进行着，实时核对平台横空而出。该平台能够做到稳定的分钟级核对异常发现能力，在某些场景下可以做到秒级发现，并且平台提供了业务快速接入的能力；红军还在实时核对平台的基础之上，升级演化出一套智能核对平台(内部代号四道防线)，引入AI技术自动识别业务问题，目前这套防线已经覆盖蚂蚁80%以上的业务。另外，各个业务域针对自身业务的一些特殊性，也研发了相应的核对系统。尽管蓝军制造故障的能力有很大的提高，但大部分的故障场景主要是各个业务方提供的，只有极少数是蓝军人工梳理业务或者分析代码产出。此时，蓝军团队认为，日常演练常态化，在故障场景发现方面不能再依赖业务，必须建立自主发现故障场景的能力。2018年3月，蓝军推出故障场景挖掘平台，基于Awatch探针探测应用内数据流，以此进行“弱点挖掘”。这套弱点挖掘体系，能够自动发现故障场景，最高能够在5分钟内产生500+的故障场景，红蓝攻防的日常演练的最为重要一块拼图终于完成！然而新的问题来了。蓝军的故障挖掘平台能力毋庸置疑，但有攻击就需要应急，高频攻防实施亦会给红军带来大量的人力消耗。持续应急压力驱动，红军开展““故障自愈”架构体系升级及能力建设，以效能为目标，结合仿真，红蓝军一起研发了“无损”攻防体系，并且推出与之匹配的度量平台，自动度量攻防结果，数据可视化。目前，常态红蓝技术对抗保持每周200+个故障场景的节奏在持续运作。常态化的红蓝“互怼”在线、实时、随地、无差别……这是支付宝技术蓝军实施攻击行为的几大标签。2017年年底的红蓝技术攻防周，技术蓝军发起攻击，但由于故障组件一处隐藏bug导致故障命中数量远远大于预期，给红军增添了不少麻烦，业务线的技术同学投入大量的人力和资源进行善后。此情此景之下，红军方面不仅没有抱怨，反而给予蓝军鼓励，“这次预期外的故障攻击是最真实的应急锻炼！”2018年年中的一次红蓝技术攻防中，蓝军在周末发起突袭，而刚好红军的相关同学正在举办婚礼。于是，一群程序员赶紧拿出吃饭的家伙，噼里啪啦敲着键盘进行应急，那画面简直不要太美了。还是在2018年的一次对抗中，红军祭出了“尖端武器”——自适应防灾、防抖等，这让蓝军吃尽苦头，几乎每次攻击都无功而返。挫败感飙升的蓝军最终放出大招，让红军接受了非常猛烈的炮火洗礼。有意思的是，似乎蓝军攻击得越欢，红军的同学越高兴……虽然看上去很受虐，但却没毛病，因为蓝军攻击得越狠越深入，被挖掘和发现出来的技术风险就会越确定，防御系统的能力也会因此而得到提升。令人震惊的是，为了防止蓝军的“袭击”，红军除了在防御系统方面下十足的功夫，每年期中和期末的红蓝技术攻防演练，红军都要举办一个仪式——那就是拜关公，除了叩拜，还得给驱邪镇恶的关公献礼，礼品包括旺仔牛奶、格子衬衫、键盘、香烟等。风险防控技术全面开放蚂蚁金服技术风险部门经过不断地升级，并将红蓝技术攻防演练形成常态化。除了每周进行全栈级别的演练，每年还会举行规模极大的“期中考试”和“期末考试”。这意味着，支付宝的风险防控体系持续地经受打磨与锤炼。目前，支付宝的“红蓝对抗”演练已经沉淀出一整套成熟的风险防控体系，通过仿真环境模拟天灾人祸，去考验技术架构的健壮性及技术人员的应急能力，从而全面地提升系统稳定，实现系统的高可靠性和高可用性。所谓的天灾和人祸。天灾指的是，当出现台风、断网、火情等极端异常情况的时候，系统如何快速应对。这有点类似于今年杭州云栖ATEC大会上，蚂蚁金服副CTO胡喜现场演练的异常断网情况下，“三地五中心”自动切换，保证支付服务不中断。人祸则是指因技术人员操作失误引发故障后，系统如何快速应。在蚂蚁金融科技官网（https://tech.antfin.com/）上可以看到，这些技术风险相关的能力已经对外开放，目前共有3款产品，包括容灾应急平台、全链路压测和资金安全监控；另外，还有3款产品，变更管控、巡检平台和黑屏运维管控即将上线对外开放。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

上篇文章 MySQL集群搭建(3)-MMM高可用架构 介绍了 MMM 高可用集群的搭建方法, 里面有提到 MMM 可以配置多个读 VIP， 今天这篇文章教大家怎么用 LVS 对这些读 VIP 做一个负载均衡。1 LVS 介绍1.1 简介LVS 是 Linux Virtual Server 的简写，意即 Linux 虚拟服务器，是一个虚拟的服务器集群系统。本项目在 1998 年 5 月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。LVS 集群采用 IP 负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。比如说，用 LVS 做 Web 负载均衡，那么请求 LVS 调度器的时候，请求会根据配置的算法分发给后端某台 Web 服务器，后端 Web 服务器机器对于请求者来说是透明的。1.1 LVS 工作模式LVS 包含以下三种常用工作模式1). NAT 模式NAT (Network Address Translation) 即网路地址装换，NAT 的工作原理是更改报文头（目标地址、源地址和端口等）后，转发请求都后端地址。流程如下客户端请求 LVS 的 IPLVS 更改请求的目的 IP，改为后端服务器其中一个 IP，然后转发请求后端服务器处理完，返回数据给 LVS，LVS 更改源 IP 为 LVS 机器的 IP 然后返回给请求端NAT 模式的所有数据都会经过 LVS 服务器，简单来说就是从 LVS 进，从 LVS 出，如图2). TUN 模式在 NAT 的集群系统中，请求和响应的数据报文都需要通过 LVS 服务器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数 Internet服务都有这样的特点：请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提高整个集群系统的吞吐量。IP 隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技 术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。我们利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户(要求后端真实服务器与外部网络连接)。TUN 模式工作流程如下:客户端请求数据，调度器根据各个服务器的负载情况，动态地选择一台服务器， 将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发 现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。3). DR 模式DR 模式中，负载调度器中只负责调度请求，而服务器直接将响应返回给客户, DR 模式架构图DR 模式的执行流程如下客户端请求数据，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC 地址改为选出服务器的 MAC 地址，再将修改后 的数据帧在与服务器组的局域网上发送。因为数据帧的 MAC 地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该 IP 报文。当服务器发现 报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。关于三种模式选择NAT模式下，所有流量会经过 LVS 服务器, 很容易有瓶颈；TUN 模式需要内核支持，部署成本比较高；DR模式性能高、容易部署，一般使用这种模式。本小节内容参考: LVS集群中的IP负载均衡技术1.2 LVS 调度算法这里简单介绍 LVS 的 8 种调度算法静态调度轮询调度(rr): 轮询调就是依次将请求调度不同的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优点是其简洁性，它无需记录当前所有连接的状态，所以它是一种无状态调度。加权轮询(wrr): 加权轮询算法可以解决服务器间性能不一的情况，它用相应的权值表示服务器的处理性能，服务器的缺省权值为1。假设服务器A的权值为1，B的 权值为2，则表示服务器B的处理性能是A的两倍。加权轮询调度算法是按权值的高低和轮叫方式分配请求到各服务器。源地址散列(sh): 该算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。目标地址散列(dh): 该算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，通过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。动态调度最少连接(lc): 最少连接是把新的连接请求分配到当前连接数最小的服务器。加权最少连接(wlc): 加权最少连接算法是最小连接调度的超集，各个服务器用相应的权值表示其处理性能。基于局部性的最少连接(lblc): 该算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，因为在Cache集群中 客户请求报文的目标IP地址是变化的。带复制的基于局部性最少连接(lblcr): 该算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要 维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。本小节内容参考: LVS集群的负载调度2 Keepalived 简介Keepalived 起初是为 LVS 件设计, 用来管理和监控 LVS 各个服务器节点状态的工具Keepalived 采用 Master/Slave 模式, 在 Master 上设置配置文件的 VIP，当 Master 宕机后，VIP 自动漂移到另一台 Keepalived 服务器上Keepalived 可以用来做各种软件的高可用集群，它会一直检测服务器的状态，如果有一台服务器宕机，或工作出现故障，Keepalived 将检测到，并将有故障的服务器从系统中剔除，同时使用其他服务器代替该服务器的工作，当服务器工作正常后 Keepalived 自动将服务器加入到服务器群中。简单来说，Keepalived 就是用来实现机器的高可用的，在使用 Keepalived 的情况下，只有一台服务器能够提供服务(通过 VIP 来实现)，当 Master 主机宕机后，VIP 会自动飘移到另一台服务器3 环境准备3.1 服务器与 MySQL 环境MySQL 环境采用上篇文章部署的那一套，然后新增一台服务器作为 LVS 的备用节点节点信息IP系统端口MySQL版本节点读写说明10.0.0.247Centos6.533065.7.9Master读写主节点10.0.0.248Centos6.533065.7.9Standby只读,可切换为读写备主节点10.0.0.249Centos6.533065.7.9Slave只读从节点10.0.1.24Centos6.5–MMM Monitor/LVS-MMM Monitor/LVS Keepalive Master10.0.1.85Centos6.5–LVS-LVS Keepalive SlaveVIP 信息简称VIP类型RW-VIP10.0.0.237读写VIPRO-VIP110.0.0.238读VIPRO-VIP210.0.0.239读VIPLVS-RO10.0.0.236LVS Keepalived VIP3.2 Keepalved 安装配置我们在10.0.1.24和10.0.1.85上部署 Keepalived1). yum 安装如果有对应的 yum 源，直接安装就可以了yum install -y keepalived2). 源码安装下载安装包, 下载地址 keepalived, 使用 1.2.24 版本举例# 安装依赖yum install -y gcc popt-devel openssl openssl-devel libssl-dev libnl-devel popt-devel libnfnetlink-devel# 下载包wget http://www.keepalived.org/software/keepalived-1.2.24.tar.gz# 解压安装tar -xvz -f keepalived-1.2.24.tar.gzcd keepalived-1.2.24./configure –prefix=/usr/local/keepalivedmake && make installcp /usr/local/keepalived/sbin/keepalived /usr/sbin/cp /usr/local/keepalived/etc/rc.d/init.d/keepalived /etc/init.d/cp /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/mkdir /etc/keepalived/cp /usr/local/keepalived/etc/keepalived/keepalived.conf /etc/keepalived/3). 配置 Keepalived打开 /etc/keepalived/keepalived.conf 文件, 加上上面的配置global_defs { notification_email { } router_id MYSQL_MMM}vrrp_instance MMM_TEST { state BACKUP interface eth0 virtual_router_id 24 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 10.0.0.236 }}router_id: 标识用的state: MASTER或BACKUP, 当其他节点起来的时候会重新选举，所以这里设为 BACKUP 就可以了virtual_router_id: 用来区分 VRRP 组播的标记，取值 0-255priority: 优先级advert_int: 监控检测间隔authentication: 认证相关virtual_ipaddress: 要设置的 VIP注意: 在同一个广播域内 virtual_router_id 不能重复 4). 启动由于在priority都相同，所以先启动为 Master, 我们在10.0.1.24和10.0.1.85上轮流启动Keepalived/etc/init.d/keepalived start启动后观察10.0.1.24 IP 状态[root@chengqm ~]# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:ee:ae:a1 brd ff:ff:ff:ff:ff:ff inet 10.0.1.24/16 brd 10.0.255.255 scope global eth0 inet 10.0.0.236/32 scope global eth0 inet6 fe80::f816:3eff:feee:aea1/64 scope link valid_lft forever preferred_lft forever3.3 LVS 安装配置本次测试，负载调度的算法采用 加权最少连接(wlc)，工作模式采用 DR 模式1). 安装LVS 采用 yum 安装就可以了yum install -y ipvsadm2). 增加配置文件继续打开 /etc/keepalived/keepalived.conf 文件, 在后面加上 LVS 配置, 转发VIP为10.0.0.236的3306端口到MMM的虚IPvirtual_server 10.0.0.236 3306 { delay_loop 6 # 健康检查时间，单位是秒 lb_algo wlc # 负载调度的算法 lb_kind DR # LVS 工作模式 nat_mask 255.255.255.255 # 掩码 persistence_timeout 0 protocol TCP real_server 10.0.0.237 3306 { # 指定后端真实服务器的IP地址, 这里直接指到 MMM 虚 IP 上 weight 1 # 节点权重, 数字越大, 权重越大 TCP_CHECK { # 检测参数 connect_timeout 10 nb_get_retry 3 delay_before_retry 3 connect_port 3306 } } real_server 10.0.0.238 3306 { weight 3 TCP_CHECK { connect_timeout 10 nb_get_retry 3 delay_before_retry 3 connect_port 3306 } } real_server 10.0.0.239 3306 { weight 3 TCP_CHECK { connect_timeout 10 nb_get_retry 3 delay_before_retry 3 connect_port 3306 } }} 更改完毕重启 keepalived3). 后端真实服务器抑制 ARP 广播由于 DR 模式的原理是 LVS 与后端真实服务器配置同一个 VIP，后端服务器 不允许arp广播，这样路由器接收到请求就会发给 LVS，LVS 修改请求的 MAC 地址。这样路由器和后端服务器通过 MAC 地址进行通信，达到负载均衡的目的。在 10.0.0.247, 10.0.0.248, 10.0.0.249 服务器上执行以下命令VIP=10.0.0.236ifconfig lo:0 $VIP netmask 255.255.255.255 broadcast $VIP/sbin/route add -host $VIP dev lo:0echo “1” >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho “2” >/proc/sys/net/ipv4/conf/lo/arp_announceecho “1” >/proc/sys/net/ipv4/conf/all/arp_ignoreecho “2” >/proc/sys/net/ipv4/conf/all/arp_announcesysctl -p >/dev/null 2>&1注意: 后端真实服务器的 VIP 绑在 lo 上如果想取消，可以反着操作ifconfig lo:0 downroute del VIP >/dev/null 2>&1echo “0” >/proc/sys/net/ipv4/conf/lo/arp_ignoreecho “0” >/proc/sys/net/ipv4/conf/lo/arp_announceecho “0” >/proc/sys/net/ipv4/conf/all/arp_ignoreecho “0” >/proc/sys/net/ipv4/conf/all/arp_announce4). 检查 LVS 状态[root@chengqm ~]# ipvsadm -lIP Virtual Server version 1.2.1 (size=4096)Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConnTCP 10.0.0.236:mysql wlc -> 10.0.0.237:mysql Route 1 0 0 -> 10.0.0.238:mysql Route 3 0 0 -> 10.0.0.239:mysql Route 3 0 0 LVS 负载均衡已经生效4 测试4.1 负载均衡测试LVS 配置好了，让我们测试一下效果, 目前 Keepalived Master在 10.0.1.24, 并且已经预先创建了一个测试账号，那么我们在其他机器发起请求看看[root@mysql-test-83 ~]# mysql -umytest -p -h10.0.0.236 -P3306 -e “show variables like ‘hostname’“Enter password: +—————+———–+| Variable_name | Value |+—————+———–+| hostname | cluster01 |+—————+———–+[root@mysql-test-83 ~]# mysql -umytest -p -h10.0.0.236 -P3306 -e “show variables like ‘hostname’“Enter password: +—————+———–+| Variable_name | Value |+—————+———–+| hostname | cluster02 |+—————+———–+可以看到，LVS 负载均衡已经生效4.2 高可用测试10.0.1.24 和 10.0.1.85部署了 Keepalived服务，我们停掉Master的Keepalived, VIP 会自动飘移到另一台机器现在停掉10.0.1.24的Keepalived[root@chengqm ~]# /etc/init.d/keepalived stopStopping keepalived: [ OK ]查看10.0.1.85的IP[root@yexm ~]# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:3c:81:1b brd ff:ff:ff:ff:ff:ff inet 10.0.1.85/16 brd 10.0.255.255 scope global eth0 inet6 fe80::f816:3eff:fe3c:811b/64 scope link valid_lft forever preferred_lft forever[root@yexm ~]# ip addr1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether fa:16:3e:3c:81:1b brd ff:ff:ff:ff:ff:ff inet 10.0.1.85/16 brd 10.0.255.255 scope global eth0 inet 10.0.0.236/32 scope global eth0 inet6 fe80::f816:3eff:fe3c:811b/64 scope link valid_lft forever preferred_lft forever可以看到 VIP 已经飘移到另一台 LVS 服务器5 结语LVS + MMM下既可以实现多台 MySQL 节点的负载均衡，也避免了因为同步延迟、同步失败等问题造成的数据不一致问题，是一个非常不错的架构方式。参考: http://www.linuxvirtualserver.org/zh/lvs1.html ...

一、八年双十一，造就国内最大最专业HBase技术团队阿里巴巴集团早在2010开始研究并把HBase投入生产环境使用，从最初的淘宝历史交易记录，到蚂蚁安全风控数据存储。持续8年的投入，历经8年双十一锻炼。4个PMC，6个committer，造就了国内最大最专业的HBase技术团队，其中HBase内核中超过200+重要的feature是阿里贡献。集团内部超过万台的规模，单集群超过千台，全球领先。二、HBase技术团队重磅发布X-Pack，重新赋能轻量级大数据平台阿里云自从17年8月提供HBase云服务以来，到18年12月累计服务了上千大B客户，已经有上千个在线的集群。是阿里云增长最为快速的数据库服务，也是大B客户比例最高的云服务之一。并于6月6日全球第一个推出HBase 2.0，是HBase领域当之无愧的排头兵。为了满足客户对数据库更丰富业务处理需求、更易用、强大功能的需求，我们重磅发布 X-Pack ：支持SQL、时序、时空、图、全文检索能力、及复杂分析。阿里云HBase从KV为主大数据数据库成功进化成“轻量级全托管大数据平台”数据库。全部能力计划12月底全部上线。三、深度解读 “ 轻量级全托管大数据平台 ”，云HBase能力再上新台阶通常一个大企业里面，数据和业务存在天然的多样性。真正称得上平台级的数据库，要至少要满足客户不同三个及以上层次的诉求，才能称的上平台级。阿里云HBase从成本最优化、运维便利性、业务敏捷度三个方面将HBase的能力全面提升一个高度，成就轻量级全托管大数据平台，云HBase能力再上新台阶。3.1 轻量级，满足CXO成本最优化的诉求1）起步成本低，整体成本低，扩展性强。云HBase针对企业不同的使用环境，不同的SLA诉求，云HBase一共提供3个版本，分别满足开发环境，在线业务，以及金融级业务的诉求。单节点版本，低廉的价格用于开发测试场景，集群版本，99.9%可用，满足企业在线业务诉求，支持最高5000万的QPS和10P的数据。还有支持金融级高可用的双活版本。所有版本都支持11个9的数据可靠性，无需担心数据丢失。2）支持冷存储，助你不改代码，1/3成本轻松搞定冷数据处理大数据场景下，存储成本占比往往是大头，把存储成本降下来，整体成本才能下降。一般随着业务的发展，HBase中存储的数据量会逐渐变大。在这些数据中，业务最关心的，最常访问的，往往是某些特定范围的数据，比如说最近7天的数据，业务对这类数据访问频次高，延迟要求高，即所谓的热数据。而其他的数据，一般访问量极少，性能要求不高, 但这类数据往往数据量大，即冷数据。如果能把冷热数据分离开，把热数据存储在性能更好的介质中，而把庞大的冷数据放到成本更低的介质中，从而实现把更多优质资源用来提高热数据的读写性能，同时节省存储成本的目的。阿里云HBase针对冷数据存储的场景，提供一种新的冷存储介质，其存储成本仅为高效云盘的1/3，写入性能与云盘相当，并能保证数据随时可读。冷存储的使用非常简单，用户可以在购买云HBase实例时选择冷存储作为一个附加的存储空间，并通过建表语句指定将冷数据存放在冷存储介质上面，从而降低存储成本，基本不用改代码就获得了低成本存储能力，助力企业降低整体成本。3.2 全托管，全面解放运维，为业务稳定保驾护航大数据时代，数据是企业最宝贵的资产，业务是企业赖以生存的基础。因此高可用和高可靠是最基本诉求。云HBase提供的全托管服务相比其他的半托管服务以及自建存在天然的优势。依托持续8年在内核和管控平台的研究，以及大量配套的监控工具、跨可用区，跨域容灾多活方案，云HBase提供目前业界最高的4个9的可用性（双集群），11个9的可靠性的高SLA的支持，满足众多企业客户对平台高可用、稳定性的诉求。云HBase服务定位为全托管服务，后台自动代维和保持服务稳定性，极大的降低了客户使用门槛，让无论是SME，还是巨头都能享受到HBase技术红利。选择云HBase就是选择了高可用、高可靠服务！3.3 全面能力提升，源头解决业务敏捷度，真正释放数据和业务的价值1）100%兼容原生接口和能力，开发简单，容易上手。云HBase百分百兼容开源接口，并提供一系列配套开发，数据搬迁，监控工具，全面帮助用户提高开发和管理效率。2）独家跨Region/AZ双活阿里云是云HBase首家推出跨Region/AZ双活，在一个集群出现故障的时候，迅速地将业务切换至另外一个集群从而避免故障。HBase主备之间数据的同步基于异步链路实现，遵循最终一致性协议，典型的主备同步延迟在200ms左右。满足金融、社交、电商、人工智能等关键领域对高可用的诉求。3）备份恢复量级提升百倍以上，数据库领域最大我们经常会听到“某某某DBA误操作把整张表删了”，“某某磁盘故障，造成数据库的某个库的数据全部损坏了”。这种由于外在和内在的原因造成的数据不可靠，最终会给用户带来毁灭性的灾难。所以一个企业级数据库，全量备份、全量恢复、增量备份、增量恢复，是基础能力。传统数据库备份恢复的能力都是TB级别，这在交易等场景下面是足够的，但是面向大数据场景就捉襟见肘了。云HBase通过垂直整合高压缩、内核级优化，分布式处理等能力，将备份恢复的量级成功推高百倍以上，做到百TB级别甚至更高，让客户大数据量下面也无后顾之忧。4）支持融合多模型和融合多负载、提供开箱即用的能力云HBase在KV的基础上，同时支持时序、时空、图、文档等多种数据模型，内置丰富处理能力，让业务开发效率提升百倍。在线能力的基础上，融合流处理、批处理、OLAP，OLTP、高速对象存储，全文检索等能力，提供客户融合业务开箱即用的能力。四、展望未来，持续优化服务，不负重托，成就客户历经近8年的技术沉淀，阿里巴巴大数据NoSQL数据库处理技术的精华沉淀在HBase上，后者成功支撑了成功支撑了阿里经济体中最大的NoSQL业务体量，是阿里大数据处理技术的核心组成部分，当前将这项技术应用到广大企业中，助力企业发现数据价值。短短1年间，就覆盖了社交、金融、政企、车联网、交通、物流、零售、电商等数十个个行业，帮单用户顶住千万级QPS的业务压力，以及百PB级数据高效存储和处理。本文作者：所在jason阅读原文本文为云栖社区原创内容，未经允许不得转载。

摘要： 一起来探索蚂蚁双11的神秘技术之旅吧！小蚂蚁说：你们都很关心的 “OB双11大促实战分享” 专题来啦！本系列将为你系统性的介绍OceanBase支撑蚂蚁双11背后的技术原理和实战分享。从平台到架构，再到实现，一起来探索蚂蚁双11这场神秘的技术之旅吧！2018年的双11十周年，最终成交额以2135亿元创纪录收官，支付宝系统在这场“商业奥运会”中再次经受住了考验。这也是OceanBase顺利支撑蚂蚁双11的第五年。从五年前，只有10%流量切到OceanBase上，到如今OceanBase 2.0版本成功支撑2018年双11的支付宝核心链路。每年不变的是一如既往的表现平稳，丝般顺滑，变化的是技术能力的不断升级和迭代。今年的双11，OceanBase 2.0扛起了大梁，性能比去年提升了50%，真正实现了“零成本”支撑大促。一、2018双11大促使用了哪些核心技术？今年的双11，OceanBase致力于通过底层架构及平台能力的提升，来实现双11稳定性、成本优化、性能及效率方面的全方位的提升。相较以往始终如一“丝般顺滑”的大促能力外，2018年的双11，OceanBase更加注重长久技术能力的沉淀：OceanBase2.0版本首次上线支付宝的核心链路，包括交易、支付系统，为“峰值百万支付能力”的三年战略沉淀了通用的“极致弹性”的分布式数据库能力，夯实了百万支付的底层基座。在底层存储介质方面，OceanBase 2.0核心链路首次100%运行在容器上，同时存储计算分离架构上线，大幅降低资源成本的同时夯实统一存储基座。在智能化运维的实践方面，OCP（OceanBase云平台）着眼于SQL优化诊断、故障根因分析和智能容量规划等数据库关键场景，将数据库专家的经验与AI算法/机器学习相结合，提供智能化的数据库服务。在平台能力的沉淀上，OCP引入Orchestration理念，通过编排/复用原子变更任务灵活，实现大促快速弹出/弹回的流程，同时平台内置变更免疫及变更三板斧能力（可监控/可灰度/可回滚），极大的提升了大促整体的稳定性和效率；在整个大促期间，OCP自动执行40000+变更，最终实现全程零故障。在商业产品化方面：智能化运维及平台能力抽象出大促及对外商业化场景，建设通用能力来覆盖蚂蚁内外场景。二、OceanBase 2.0 & 百万支付每年双11的压力在不断创造新高，支付系统需要具备百万每秒的支付能力，那么一个亟待解决的问题是：如何解决最小数据分片的峰值能力超过单机性能的问题。OceanBase 2.0应运而生，其目标是在应用无感知的情况下对数据分片进一步拆分，将数据sharding到无限多的机器上，实现极致弹性能力优雅支撑百万支付峰值。1.百万支付架构如下图的百万支付架构所示，传统数据库的弹性架构，将数据进行物理拆分到不同机器，业务在数据访问、研发、后期维护及数据配套设施上都非常繁琐；同时拆分后资源很难快速回收，且数据拆分及聚合无法实现业务无损。相比于传统数据库的弹性架构，OceanBase 2.0架构完全不侵入业务，内部通过分区实现数据分片的自组织及负载均衡，通过生成列及分区规则实现自动路由，通过分区聚合（partition_group）消除分布式事务性能开销以提升性能，从而实现无损线性伸缩。另外，数据分片间share_nothing及多版本的架构，实现分片故障隔离及单点故障消除的高可用架构。2.性能提升为实现“零成本大促”，OceanBase 2.0花了非常多的精力致力于性能的提升。相比OceanBase1.0，2.0在分布式架构上全面升级，如原生sharding/分布式事务优化/优化事务提交日志开销。OceanBase作为底层基础软件，任何微小的性能提升都会为业务节省大量资源，秉承持续优化的匠心，OceanBase 2.0在数据库底层架构、系统实现层面及数据库运行环境全方位进行优化。最终，OceanBase 2.0相比1.0提升了50%的性能，实现今年双11大促的零机器增加。三、OceanBase 容器化 & 存储计算分离双11峰值需要大量的资源支撑，而峰值后资源处于低水位状态，如何快速申请/释放这部分资源？双11当天非支付链路资源空闲，大促是否可以抢占这批资源？大促不同活动时间错峰，不同链路的资源可否实现快速腾挪？类似的资源问题不一而足。大家可以发现以上问题的本质在于：如何最大化程度降低双11当天的资源成本？这是大促技术要实现的一个核心价值。双11大促资源成本与两个因素相关，一个是大促资源的总数目，另一个是持有时长。我们可以通过系统优化提升单机性能，来降低大促资源的总数目（如前章节提到的OceanBase 2.0的性能优化）。那么如何降低持有时长呢？我们统一的思路是：用“高峰期抢占/低峰值释放资源”的方式来大幅降低持有时长；其两个关键前提技术就是容器化和存储计算分离。1.OceanBase容器化OceanBase容器化的核心思想是“资源调度”，大促目标就是“OceanBase能够被快速调度到各种资源载体上（如离线资源、云资源、峰值无压力的数据库其他集群）”；容器化屏蔽了底层资源载体的差异化，具备弹性部署高效的优点，是资源调度的前提条件。OceanBase打造自身调度能力，深入结合副本、租户的概念，精细化资源画像，使得OB容器化部署快速实现分时复用、资源抢占及混部。2.存储计算分离存储计算分离，顾名思义，将数据库运行依赖的计算资源和存储资源部署到不同的资源载体上，从而实现数据库的弱状态化，使得数据库可分别对存储和计算资源进行弹性伸缩。其好处是显而易见的。典型场景：大促态——CPU资源需求激增，而存储资源增幅很小，那么我们可以针对性对计算资源的机型进行扩容，从而降低资源成本且提升扩容效率；日常态——OB LSM架构将离散IO转化成顺序IO，因此存储的IO能力不是瓶颈，更多的是存储空间上的需求；存储计算分离后，多集群间可降低存储碎片，共享整体存储资源池，提升资源利用率。四、平台智能化随着业务规模的快速增长，系统稳定性SLA预发严峻和OceanBase部署的多样化，传统平台已无法满足我们的需求，可以预见不久的将来，运维将成为业务扩展的瓶颈。因此，OceanBase平台正在逐步走向智能化道路实现智能运维。OCP着眼于SQL优化诊断、故障根因分析和智能容量等大促关键场景，目标是将运维专家的技术经验和AI算法/机器学习技术相结合，分解运维关键技术，开发成一系列的智能运维模型，应用于大规模运维系统中。众所周知，SQL plan的正确性对数据库运行至关重要。OCP针对风险场景SQL，在千万峰值压力下，实时进行plan正确性比对，并对可能存在性能变坏隐患的SQL进行分钟级修正。容量水位是大促至关重要的一环，OCP通过数据建模/智能水位预测对集群/租户/docker进行容量画像，结合OceanBase内置Tenant Group能力，实现容器/集群/租户等多个维度的自动扩缩容，同时计算容量plan在集群/租户维度混部，实现最佳负载均衡部署【 深度部署资源利用率达到(n-1)/n 】，大幅节省了机器资源。OCP作为OceanBase的“智能大脑”，实时监控数据库运行状态，小至单条SQL plan，大至数千台机器容量，真正做到了生产环境智能化全覆盖。未来，OCP还将不断创新数据库智能化的运维之路，打造更加完善的数据库自治体系。五、生态与连接蚂蚁金服与金融机构最早建立的连接是基于支付业务的合作，后来又逐渐扩展了很多其他普惠金融类的业务，比如网商银行的同业合作，借呗/花呗等。如今随着在蚂蚁金服内部多年积累的技术能力与产品能力，OceanBase也将全面走向外部，对所有行业开放，通过科技作为新的连接纽带助力企业的数字化转型。过去金融业IT系统的基础架构建设基本都来自国外，如IBM、甲骨文、EMC这些公司构建底层架构，其中门槛最高的就是数据库的整体平滑替换。OceanBase团队从成立之初就肩负着使命，即我们要做一款通用数据库真正的去推动整个社会的进步，能够让整个社会的生产力发生变化。从2016年底，OceanBase就开始准备走出去，用技术改变业务形态；用技术创造新的业务模式，与更多企业建立更为紧密的连接关系。近两年对外服务的过程中，通过与ISV的深度合作与赋能，不仅提供OceanBase内核的能力，也不断丰富周边配套产品生态，涵盖使用数据库过程中的方方面面。未来，我们将继续致力于提供高可用、高性能、低成本的数据库服务，相信通过科技的连接助力更多企业，让科技的产出变成可以量化的业务价值。本文作者：平生栗子阅读原文本文为云栖社区原创内容，未经允许不得转载。

为什么需要架构可视化随着企业进行微服务架构改造，系统架构复杂度越来越高，架构变化日益频繁，微服务改造后的实际架构模型可能与预期已经产生了巨大差异，架构师或系统运维人员很难准确记忆所有资源实例的构成和交互情况；其次，系统架构在动态演化过程中可能引入了一些不可靠的因素，比如弱依赖变强依赖、局部容量不足、系统耦合过重等，给系统的稳定性带了极大的安全隐患。所以我们每次在面对系统改造、业务大促以及稳定性治理工作之前，都会通过梳理架构图的方式，呈现系统架构中个组件之间的交互方式，架构可视化能够清晰的协助我们识别架构中存在的问题以及建立高可用的系统。架构可视化后，可以给我们带来以下几点但不局限于此的优势：确定系统边界一张好的架构图，应该明确系统所包含的各个组件以及各个组件之间的核心调用关系，这些组件的集合就是系统的处理边界，系统架构的边界在一定程度上也反映了业务域的边界。架构问题识别基于高可用的架构准则，结合可视化的架构图，可以评估架构可能存在的安全风险，比如系统在容灾、隔离以及自愈维度下的健壮性。其次，一些架构链路可视化工具(比如鹰眼)在实际工作中确实大大提高了开发者排查与定位问题的效率。提高系统可用性有了系统架构的上下游依赖关系图，在故障发生时，开发人员可以借助依赖数据快速定位到问题的来源，极大缩短问题修复时间（MTTR）。借助架构图，我们还可以梳理出系统中存在的强弱依赖，在业务高峰期对弱依赖进行降级，或者针对系统依赖的各个组件进行故障模拟，以评测系统整体在面对局部故障的可靠性。常见架构可视化的做法我们熟知的架构图是静态的停留在PPT上的，很多时候我们的架构已经发生了非常大的变化，但是我们还在使用那张看上去很经典却早已过时的架构图。长时间使用与实际架构不符的架构图对线上架构的认知的危害是巨大的，我们需要在脑海中不断更新对系统架构的视图，以保持对系统架构的敏感度。每年的大促或者重大系统改造成为我们梳理系统架构、对架构进行重新认知的机会，此刻我们需要通过各种工具查看系统的各个组件分布以及不同组件的内部与外部的依赖关系，这种梳理架构图的方法是最常用的方式，权且称之为“手工绘制法”。手工经常干的事情，就有追求效率的同学使用计算机系统带来的自动化手段帮助自己做这件事情，比如我们常常看到的基于数据埋点的微服务可视化解决方案，这类架构可视化手段通常在分布式追踪、APM等监控领域使用较多，下图为某APM产品提供的应用维度架构可视化方案：我们称这种可视化方式为“埋点式感知法”，架构组件的识别是依赖关键的核心类检测与埋点，此种方案存在以下弊端：语言相关性：只要是系统埋点，与语言相关的特征基本就拜托不了，需要针对不同语言提供不同的依赖包；不易维护：因为是对核心类的检测，当组件包做了重大变更时，需要同步变更；不易扩展：因为是客户端识别方案，客户端一旦开放出去，新组件的支持只能等待用户更新组件；规模受限：客户端识别的另一个缺点是算法受限，服务端进行识别，可以借助大数据分析等手段更有效准确的识别；还有一种自动化架构感可视化方法，我们称之为“无界架构感知”，是一种语言无关性的架构识别方案，其采用采集用户主机上的进程和容器的元数据、监控数以及网路数据的最最基础的数据，在服务端构建架构图。我们设计架构可视化的理念为了最大限度上降低用户进行架构可视化的成本，我们采用了无界架构感知-应用无侵入的方式微服务进行可视化，通过采集进程数据与网络调用数据，构建进程间的网络调用关系，构建微服务的架构信息。用户只需要安装我们AHAS Agent探针，即可完成架构可视化操作；对于阿里云云原生系统，我们提供了自动化安装方式，而无需登录机器。核心本质软件架构可视化的核心点是寻找在软件体系结构中有意义和有效的元素视图以及这些元素之间的关系。我们认为一款优秀的软件架构可视化产品应该帮助用户排除掉不重要的信息，给用户呈现出对他们有价值的视图，特别是在微服务架构下庞大而复杂的调用关系链场景中。这里面的核心点是__有意义__和__有效__，要做到这两点，首先需要识别什么是有意义和有效的元素和关系，我们在此领域做的事情归纳起来就是“识别”，识别机器上的每个进程是什么，发生的网络调用远端是什么，唯有知晓了这些元素是什么我们才有理由和依据来判断是否对用户有意义以及其在用户架构中的重要程度。在梳理了大量架构图，我们发现用户关心的架构元素主要分为三类：自己的应用服务；应用对外部的资源依赖；服务器本身的信息。 应用对外部资源的依赖通常以其它应用和通用中间件或者存储服务两种形式存在。故我们将需要识别的进程分为：应用服务和常见的组件服务（比如redis、mysql等），这些组件服务又分为用户自建的服务和使用公有云提供的服务，特别是对于Cloud Native应用来说，云服务的识别显得格外重要。目前，我们提供了20种阿里云云服务的识别以及包含mysql、redis、Tomcat等常见的21种三方服务组件，此组件库还在不断扩张中，目的就是最大限度的知晓架构中的元素到底是什么。架构分层我们同样认为架构可视化的有效性跟人的认知层次有关，架构可视化的重点是确定该工具是否更好的支持自顶向下方法、自下而上方法或者两者的结合。开发者更关心应用维度上的架构，架构师或者管理者更关心整体系统架构。所以需要针对不用的使用者提供不同层次的架构可视化视角。理想的架构图需要支持宏观维度以及不断下钻下的微观视角，我们对架构进行了分层设计，目前分为进程层、容器层和主机层，后期我们可能会继续上扩或者下钻支持地域层或者服务层。架构回溯没有哪个系统的架构是一成不变的，系统架构会随着系统的版本迭代不断进行演化。所以对架构可视化操作，还需要具备随着时间的推移可对架构信息进行自动更新已经回溯的能力。在我们提供的架构感知产品中默认架构图会随着时间自动刷新，同时支持对历史的回溯，你可以选择历史中的某一刻查看架构信息，比如，重大版本的变更时，发布前与发布后的系统架构是否发生了违背一些高可用原则的问题，抑或排查是否出现了不该有的依赖问题。可见可得架构可视化解决了可见的问题，但当我们从架构图中发现了问题需要解决时，架构图还应该给我们提供便利的可交互操作入口，让我们可以完成问题发现与解决的闭环。比如通过架构感知监控到了某个应用的流量非常大，我们需要对应用进行限流或者预案，那么通过架构图，我们应该是可以完成我们期望执行的操作。在架构图中融入可以交互的运维操作，让我们从看到到操作，再到问题恢复后体现在图中，这就像计算机发展史上从命令行视图到窗口视图的转变。我们对架构可视化的定位__架构可视化不是目的，只是实现系统高可用性的手段__。借助架构感知采集到的架构数据，在识别了用户使用的组件（我们对mysql、redis、mq等的统称)后，我们借助这些组件以及与组件匹配的故障库，可以给用户自动推荐这些组件可能遇到的故障，配合我们提供的评测服务让用户更方便地对组件进行各种故障的模拟与演练，以提高系统的健壮性。其次，通过架构感知识别Java Application 应用，如果发现其负载较高，配合我们提供的限流降级（阿里巴巴开源的Sentinel商业版）功能，为服务的持续可用性保驾护航。我们对AHAS的定位是一款数据分析型的高可用保障产品，帮助云原生架构系统实现高可用能力的提升。架构可视化是我们给用户提供的高效运维和管控的窗口，我们期望通过丰富的云原生数据体系配合架构图的可视化以及可操作性，建立起以应用为中心的运维一体化平台。在未来，我们会加强与其它云服务的集成，比如监控、容器服务，以丰富架构感知的数据维度；其次，会在数据的深度挖掘和智能化消费上投入更多精力，真正让数据成为企业的核心价值，让数据成为保障业务的稳定性的利器。本文作者：心远阅读原文本文为云栖社区原创内容，未经允许不得转载。

随着移动互联网、电子商务的高速发展，被使用最多的企业级开源数据系统MySQL面临着巨大挑战——为迎接“双11"的高并发要提前做好分库分表;用户不断激增要将读写分离才能应对每天上亿次的访问，但读写分离后会导致数据同步延时严重、分布式事务复杂且效率低下、数据库可用性下降、MySQL的3T容量瓶颈等一系列问题都困扰着CTO和架构师们。“要解决这些问题，阿里巴巴2008年就开始研发自主可控的数据系统，2014年基于MySQL的国内首个云原生数据库POLARDB开始孵化，到今天已累计超过PB的数据迁移至 POLARDB”阿里云研究员吕漫漪这样告诉记者。荣耀一：超大容量 弹性扩展虽然POLARDB是基于MySQL研发的关系型数据库，但存储容量完全不受到限制，存储容量最高可达100TB，单库最多可扩展到 16 个节点，性能提升是MySQL的6倍，并且完全兼容MySQL。“由于MySQL 和POLARDB 百分之百兼容，有两种办法可以实现快速迁移，：一是直接做个备份，就可以从MySQL迁移到POLARDB,这种方式非常简单，还可以通过我们提供的DTS在线工具进行迁移。“吕漫漪表示：”对于一个完全基于云环境的数据库，利用云的弹性扩展是个基本项，用Serverless方式自动扩容，存储空间无需手动配置，根据数据量自动伸缩，用户只需为实际使用容量付费。”当应对完一次“大促“释放数据资源、节点资源非常简单，POLARDB三分钟就可生效。“不同于MySQL的‘一主多从’POLARDB则采用‘一写多读共享同一份数据’的方式，无需额外建立多个从库。在几分钟内就可以增加一个只读节点并启动服务。采用物理日志(RedoLog)代替逻辑日志(Binlog)极大程度的减少的主备延迟和磁盘IO，使得主备延迟控制在毫秒级，并可根据实际情况修改为主备强同步。”荣耀二：运维简单 安全可靠操作简单一直是降低差错、提高可用性的不二法则。吕漫漪表示：“POLARDB的大容量、高性能简化了构架师对数据库的操作，不用去做分库分表、不用做冷热分离，同时有对查询的加速接口，可以直接通过调用智能接入层的一个接口就可完成复杂的查询。”同时，数据越来越成为企业的重要资产，甚至是企业的生命线。“我们在数据库安全方面对POLARDB也做了很多改进。POLARDB共享分布式存储的设计彻底解决了MySQL Master-Slave异步复制所带来的备库数据非强一致的缺陷，使得整个数据库集群在应对任何单点故障时，可以保证数据 0 丢失。采用Active-Active的高可用集群架构，可读写的主节点和只读节点之间进行Failover切换，与传统的Active-Standby相比，用同样成本带来了更好的系统访问性能。“POLARDB也加强了数据安全方面的措施，包括采用白名单、VPC网络、SSL加密、数据多副本存储等全方位的手段，对数据库数据访问、存储、管理等各个环节提供安全保障。“在实际场景中我们发现，误删除等低级错误时有发生造成的损失巨大，为此我们未来在新版本中还会提供‘回收站’的功能，能很快地将删除的数据库表进行恢复，此外，还利用POLARDB共享分布式存储的特点，可以快速将数据库恢复到某一个指定时间点，通过快照的功能通过快照和物理日志将数据库恢复到一个指定的时间点来提高数据库的高可用性。“荣耀三：平滑演进 面向未来对于POLARDB的演进方向，吕漫漪表示，“首先就是在靠可用性上下功夫。企业及客户对高可用性和数据库的安全要求特别高，所以我们会在高可用上加大投入。此外在性能上的提高，把更多的功能下推到存储层来做。在当今大数据的时代，企业级用户在功能上也有了新的要求，要求数据库既要是事务性数据库又要是分析性数据库，我们今后把这两个需求结合在一起，今后将推出并行查询、大幅提高大表查询、复杂查询的性能，这些都是我们的前进方向。当前数据种类繁多，除了大家熟知的关系型数据库，图数据库、文件数据库、流数据库等非关系数据库也在崛起。吕漫漪认为，数据库的发展现在是百花齐放，由于应用场景的不同，用户可以选择不同的数据库，但我们可以看到MySQL数据库也发生了很多改变，它从一个纯关系型的数据库也开始支持文件存储，5.7版开始支持文件存储，关系型数据库的演变和MySQL的演变也开始支持更多的存储模式，我们可以给客户提供更多的选择。”阿里云数据库事业部总经理鸣嵩认为：“十年时间，阿里云数据库团队从技术创造新商业到推动中国数据库技术变革。”从AliSQL到RDS，再到首个自研云原生数据库POLARDB，如今，阿里巴巴数据库技术得到了极大的提升，领跑数据时代。前不久，Gartner公布了2018全球数据库魔力象限，阿里云以国内云厂商第一成为首个入选的中国企业，分析师更是认为POLARDB云原生数据库在使用场景的应用值得期待。相信作为国产数据库的领跑者，阿里云将一直在为使命而努力奋斗，让我们拭目以待。本文作者：桐碧2018阅读原文本文为云栖社区原创内容，未经允许不得转载。

破土而出的生命力，源自理想主义者心底对技术的信念。开源曾经帮助 Redhat 在传统软件市场奠定了其行业地位。无独有偶，作为云计算时代的赶超者，谷歌也拿起了开源的武器，试图打乱 AWS 和 Azure 的节奏。目前，这一策略似乎正在奏效。如今云原生技术正席卷全球，云原生基金会在去年 KubeCon +CloudNativeCon NA 的现场宣布：其正在孵化的项目已达 14 个，入驻的厂家或产品已超过 300 家，并吸引了 2.2 万开发者参与项目代码贡献，其明星产品 Kubenetes 的 GitHub 上 Authors 和 Issues 量已排行开源领域的第二名。而 Kubenetes 正是 Google 开源的一个容器编排引擎。今年，KubeCon + CloudNativeCon 首次来到中国。在2018 KubeCon + CloudNativeCon的现场，阿里云研究员伯瑜向在场的开发者们宣布，CNCF 已将阿里巴巴云原生镜像分发系统 Dragonfly 接纳为其沙箱项目（Sandbox），并有机会成为国内首个从 CNCF 毕业的开源项目。目前已经毕业的两个项目，一个是 Kubernetes，另一个是 Prometheus。据悉，目前阿里巴巴已经有 8 个项目进入 CNCF 云原生全景图，分别是分布式服务治理框架 Dubbo、分布式消息引擎 RocketMQ、流量控制组件Sentinel、企业级富容器技术 PouchContainer、服务发现和管理 Nacos、分布式消息标准 OpenMessaging、云原生镜像分发系统 Dragonfly 和高可用服务 AHAS。时间回到 2016 年2016 年的那届双11，RocketMQ 创始人冯嘉和他的团队首次将低延迟存储解决方案应用于双11的支撑，经受住了流量的大考，整个大促期间，99.996%的延迟落在了 10ms 以内，完成了保障交易稳定的既定目标。对于读写比例几乎均衡的分布式消息引擎来说，这一技术上的突破，即便是放在全球范围内，也绝对是值得称赞的。另一边，在历时3个月的开源重塑后，冯嘉和他的团队启动了 RocketMQ 向Apache 软件基金会的捐赠之路，但迈出这一步并不容易。“当时国内的开源氛围还没有现在那么活跃，开源之后，很多设计、源码和文档的维护工作还不够理想，但我们就是想证明国内的开源项目和开源社区也可以在世界的开源舞台上发挥价值。”经过近一年的努力，在2017年9月25日，Apache 软件基金会官方宣布，阿里巴巴捐赠给 Apache 社区的开源项目 RocketMQ 从 Apache 社区正式毕业，成为 Apache 顶级项目（TLP），这是国内首个非 Hadoop 生态体系的Apache 社区顶级项目。值得一提的是，根据项目毕业前的统计，RocketMQ 有百分八十的新特性与生态集成来自于社区的贡献。2017 年，消息领域出现一件里程碑事件。分布式消息领域的国际标准 OpenMessaging 开源项目正式入驻 Linux 基金会，这是国内首个在全球范围发起的分布式计算领域的国际标准。消息通讯已经成为现代数据驱动架构的关键环节，但在全球范围内，消息领域仍然存在两大问题：一是缺乏供应商中立的行业标准，导致各种消息中间件的高复杂性和不兼容性，相应地造成了公司的产品低效、混乱和供应商锁定等问题。二是目前已有的方案框架并不能很好地适配云架构，即非云原生架构，因此无法有效地对大数据、流计算和物联网等新兴业务需求提供技术支持。这也是冯嘉和他的团队在开源 RocketMQ 过程中，开发者和合作伙伴经常会提到的问题：“在消息领域，市场上出现了各类不同的开源解决方案，这导致了用户更高的接入和维护成本，为了确保各个消息引擎间能正常通信，还要投入大量的精力去做兼容。”这时候，建立一套供应商中立，和语言无关的消息领域的事实标准，成为各社区成员共同的诉求。此后，在 2017 年 9 月，阿里巴巴发起 OpenMessaging 项目，并邀请了雅虎、滴滴出行、Streamlio共同参与，一年后，参与 OpenMessaging 开源标准社区的企业达10家之多，包括阿里巴巴、Datapipeline、滴滴出行、浩鲸科技、京东商城、青云 QingCloud、Streamlio、微众银行、Yahoo、中国移动苏州研发中心（按首字母排序），此外，还获得了 RocketMQ、RabbitMQ 和 Pulsar 3 个顶级消息开源厂商的支持。相比于开源一个分布式消息项目，一套开源标准能被各家厂商所接受，对整个国内开源领域而言，是更具有里程碑意义的事件。2017 年 9 月，Dubbo 重启开源。Dubbo 是阿里巴巴于 2012 年开源的分布式服务治理框架，是国内影响力最大、使用最广泛的开源服务框架之一，在 2016 年、2017 年开源中国发起的最受欢迎的中国开源软件评选中，连续两年进入 Top10 名单。2017 年 9 月 7 日，在 Github 将版本更新至 2.5.4，重点升级所依赖的 JDK 及其组件，随后连续发布了 11 个版本。并于2018年2月捐献给 Apache 软件基金会，希望借助社区的力量来发展 Dubbo，打消大家对于 Dubbo 未来的顾虑。项目重启半年后，Dubbo 项目负责人阿里巴巴高级技术专家北纬在接受媒体采访的时候，从战略、社区、生态和回馈四个方面谈了 Dubbo 重启开源背后的原因。“集团近几年开始将开源提到了新的战略高度，这次投入资源重启开源，核心是希望让开源发挥更大的社会价值，并和广大开发者一起，建立一个繁荣的Dubbo 生态，普惠所有使用 Dubbo 的人和 Dubbo 本身。”Dubbo项目组成员朱勇在今年上海的技术沙龙上分享Dubbo未来发展的过程中提到，其后续的规划是要解决好两个问题。第一个问题是重点关注技术趋势，例如云原生对Dubbo开源现状的影响。第二个问题是 Dubbo 本身定位的问题，除了保持技术上的领先性，还需要围绕 Dubbo 核心发展生态，和社区成员一起将 Dubbo 发展成一个服务化改造的整体解决方案。2017 年 11 月，阿里自研容器技术 PouchContainer 开源。在开源不到一年的时间里，PouchContainer 1.0 GA 版本发布，达到可生产级别。今年 8 月，PouchContainer 被纳入开源社区开放容器计划 OCI；9 月，被收录进高校教材《云计算导论》；11 月，PouchContainer 团队携蚂蚁金服容器团队、阿里云 ACS 团队，与容器生态 Containerd 社区 Maintainer进行技术交流，有望发展成 Containerd 社区 Maintainer 席位，代表国内企业在世界容器技术领域发声。PouchContainer 发展速度之快，超出了宏亮的想象。宏亮是 Docker Swarm 容器集群项目的核心代码维护者（Maintainer），并于2015 年 8 月出版了《Docker 源码分析》一书，对 Docker 架构和源代码进行了深入的讲解，该书在 Docker 领域迅速成为畅销书籍。2017 年，宏亮承担起阿里自有容器技术的对内支持和对外技术布道的工作，秉承初心，希望在竞争激烈的容器开源领域能抢下属于国内容器技术的一席之地。在团队的努力下，阿里集团内部已实现 100%的容器化，并已经开始涉及离线业务，实现在、离线业务的混合调度与部署。整个集团能实现 100%的容器化，离不开阿里内部自研的 P2P 分发技术，该项目取名为 Dragonfly，寓意点与点之间的文件分发能如蜻蜓般轻盈和迅速，解决传统文件发布系统中的大规模下载、远距离传输、带宽成本和安全传输的问题。日前，Dragonfly 正式进入 CNCF， 并成为国内第三个被列为沙箱级别（Sandbox Level Project）的开源项目，可见，CNCF 在其云原生的技术版图中正希望借助Dragonfly等优秀的镜像分发技术，以提升企业微服务架构下应用的交付效率。始于阿里，回归社区。今年夏天，国内开源领域，迎来了两位新成员。作为微服务和云原生生态下的两款重要开源框架/组件，Nacos主打云原生应用中的动态服务发现、配置和服务管理，Sentinel 则是聚焦在限流和降级两个方面。Nacos 和 Sentinel 均是在阿里近 10 年的核心业务场景下沉淀所产生的，他们的开源是对微服务和元原生领域开源技术方案的有效补充，同时也非常强调融入开源生态，除了兼容 Dubbo和Sentinel，也支持对Spring Cloud 和 Kubenetes 等生态，以增强自身的生命力。“阿里巴巴早在 2007 年进行从 IOE 集中式应用架构升级为互联网分布式服务化架构的时候，就意识到在分布式环境中，诸如分布式服务治理，数据源容灾切换、异地多活、预案和限流规则等场景下的配置变更难题，因为在一个大型的分布式系统中，你没有办法把整个分布式系统停下来，去做一个软件、硬件或者系统的升级。”阿里巴巴高级技术专家坤宇在 2017 QCon 的现场分享到。在配置变更领域，我们从2008年的无 ConfigServer 时代，借用硬件负载设备 F5 提供的 VIP 功能，通过域名方式来实现服务提供方和调用方之间的通信，逐步经历了 ConfigServer 单机版、集群版的多次迭代，不断提高其稳定性。曾写下支付宝钱包服务端第一行代码的阿里高级技术专家慕义，在今年深圳的技术沙龙现场回忆了阿里注册中心自研的 10 年路：“这期间，集团业务经历了跨越式的发展，每年翻番的服务规模，不断的给 ConfigServer 的技术架构演进带来更高的要求和挑战，使得我们有更多的机会在生产环境发现和解决一个个问题的过程中，实现架构的一代代升级。Nacos 便是在这样的背景下，经过几代技术人的技术攻坚所产生的。”我们希望 Nacos 可以帮助开发者获得有别于原生或其他第三方服务发现和动态配置管理解决方案所提供的能力，满足开发者们在微服务落地过程当中对工业级注册中心的诉求，缩短想法到实现的路径。巧的是，一边是 Nacos宣布开源，另一边是 Spring Cloud 生态下的服务注册和发现组件 Netflix Eureka 宣布闭源，勇敢者的游戏充满了变数，但在坤宇和他的团队看来，这场游戏自己可以走到最后，因为我们并不是一个人在战斗，Nacos 只是阿里众多开源项目中的一员，随后还会有更多的开源项目反哺给社区，形成生态，例如轻量级限流降级组件 Sentinel。7月29日，Aliware Open Source•深圳站现场，只能容纳 400 人的场地，来了 700 多位开发者。阿里巴巴高级技术专家子矜在现场宣布了轻量级限流降级组件 Sentinel 的开源。作为阿里巴巴“大中台、小前台”架构中的基础模块，Sentinel 经历了 10 年双 11 的考验覆盖了阿里的所有核心场景，也因此积累了大量的流量归整场景以及生产实践。Sentinel 的出现，离不开阿里历届高可用架构团队的共同努力。“在双11备战中，容量规划是最重要也是最具挑战的环节之一。从第一年开始，双11的 0 点时刻就代表了我们的历史最高业务访问量，它通常是日常流量的几十倍甚至上百倍。因此，如何让一个技术和业务持续复杂的分布式站点去更平稳支撑好这突如其来的流量冲击，是我们这 10 年来一直在解的题。”阿里巴巴高可用架构团队资深技术专家游骥在今年的双11结束后分享道。这 10 年，容量规划经历了人工估算、线下压测、线上压测、全链路压测、全链路压测和隔离环境、弹性伸缩相结合的 5 个阶段。2013 年双11结束后，全链路压测的诞生解决了容量的确定性问题。作为一项划时代的技术，全链路压测的实现，对整个集团而言，都是一件里程碑事件。随后，基于全链路压测为核心，打造了一系列容量规划相关的配套生态，提升能力的同时，降低了整个环节的成本、提升效率。随着容量规划技术的不断演进，2018 年起，高可用架构团队希望可以把这些年在生成环境下的实践，贡献给社区，之后便有了 Sentinel 的开源。一边是作为发起者。将自己生产环境实践下沉淀出来的架构和技术贡献给社区。另一边是作为参与者。基于一些开源项目或云平台，输出可以解决开发者当前工作中存在的痛点的解决方案，例如近期新开源的项目 Spring Cloud Alibaba 和 开发者工具 Alibaba Cloud Toolkit。相同的是，技术理想主义者都希望技术可以为让世界变得更好，这才是技术人的兴奋点。“让世界的技术因为阿里巴巴而变得更美好一点点”。这是阿里巴巴系统软件、中间件、研发效能事业部负责人毕玄邮件签名中的一句话。他正和一群技术理想主义者，与太平洋另一边的技术高手们正面PK，在这场躲不开的战役中，一起认真一把。本文作者：amber涂南阅读原文本文为云栖社区原创内容，未经允许不得转载。 ...