0  我是谁？杜军，《Docker——容器与容器云》和《云原生分布式存储基石：etcd》这两本书的作者。现任职于华为Cloud BU PaaS服务产品部，主要负责容器与Kubernetes集群管理技术的研发。是Kubernetes核心维护者，也是CNCF TOC Contributor。在Kubernetes社区主导了Kube-proxy IPVS模式，Pod网络QoS，流图调度器Poseidon，Cluster-API-OpenStack和边缘计算KubeEdge等项目的开发。你可以在KubeCon，LinuxCon和CNUTCon等大会找到我分享的主题演讲，我也做过多次Kubernetes和CKA考试的培训。1      如何理解“云原生”这三个字？  云计算时代，企业将不再耗巨资投资自己的IT系统，而是直接使用无限制的按需付费的云服务，这无疑将显著降低IT基础设施的开销，加速软件占据世界的进程。作为程序员，我时常为自己有机会投身于这个波澜壮阔的技术变革事业而感到莫名激动。  回到正题，我理解的云原生是一种新的软件工程方法，即充分利用云计算的优势来构建（build）和运行（run）软件。“Build once, run everywhere”，当初Docker公司提出的这个口号现在喊起来是否已经朗朗上口了？  有时候我们会反思，当容器技术方兴未艾的时候，是什么促使了云原生技术如雨后春笋般在企业内萌发呢？诚然，“一次构建，到处运行”——容器良好的良好的可移植性，敏捷性和Docker革新的镜像打包方式相较云计算最初的IaaS虚拟机形态，更加容易地成为公有云全新的基础设施和交付手段。但Docker毕竟只是一个runtime，当我们需要一个编排框架作为系统核心来串联开发、测试、发布、运行和升级等整个软件生命周期时，它就略显单薄。  搞大规模的基础设施，还得看Google，毕竟人家管理大规模的容器集群已经快二十年了，哪怕是在公有云领域攻城略地、出尽风头的AWS，都没有Google在容器领域积累的深厚经验。Kubernetes就是Google照着鼎鼎大名的Borg系统开源出来的容器编排引擎。如今的Kubernetes，既是 GitHub上的明星项目，也获得了了全世界所有公有云厂商（包括AWS）的青睐，更是让当年不可一世的Docker公司低下了他那高傲的头颅。  关心容器生态圈的朋友，想必都已经接受了Kubernetes作为容器编排甚至是云原生标准的事实。2      什么样的技术才能配得上“基石”二字？  etcd的作者，李响曾“傲娇”地说，“etcd就是用来存储云上最重要的数据的”。  从技术上的角度，用户大可以放心这么做，因为etcd底层采用的Raft一致性协议保证了数据的分布式强一致性和高可用。一个etcd数据集群，即使挂掉半数节点，也不影响集群的正常工作。  李响的底气更来自于，etcd同时被经典PaaS的代表Cloud Foundry和容器云新贵Kubernetes采用，作为他们后端数据存储和协同的关键组件。毫不夸张地说，etcd就是Kubernetes和Cloud Foundry的“心脏”。更饶有趣味的是，Docker Swarm的节点管理系统也引用了etcd的Raft库，要知道Docker和CoreOS（开发etcd的公司）曾经在容器runtime战场上有过一番争夺啊！我只能感叹，etcd的代码质量之高以至于让商业竞争对手都放下了门户之见。又或许，Docker Swarm那时也找不到更稳定的Go语言版本的Raft实现了。更不用说，TiDB这类新兴的分布式NewSQL数据库基于etcd的Raft库构建分布式事务、跨数据中心数据强一致性、故障自恢复等能力。  经典PaaS我们不必再提，考虑到Kubernetes在当今云原生时代所扮演的角色，用“基石”二字形如etcd的重要性一点都不为过。事实上，etcd也不负众望，很好地扮演了“坚若磐石，稳如泰山”的云原生大厦基石的角色。etcd作为硅谷明星创业公司CoreOS最重要的项目，一开始便含着“金钥匙”出生，直接被Kubernetes指定作为其后端的存储实现。  “Kubernetes是Borg的开源实现，在Google内部，Borg使用Chubby作为分布式协同的后端，Kubernetes选择了etcd——一个Go语言的Chubby实现。”  Kubernetes的创始人如是解释道Kubernetes和etcd的结缘。相较于基于Paxos协议，并且给Google的工程师们带来无尽软件工程梦魇的Chubby，etcd底层的Raft协议容易实现太多，再加上由Go这门被Google寄托了太多云时代愿望的编程语言编写，自然能够无缝融入到Kubernetes的生态之中。  如果说当初etcd搭上Kubernetes的快车还有些“幸运”的成分，但是etcd伴随着Kubernetes共同成长，历经了从V2到V3的重大版本更新，经受住了Kubernetes大规模部署最严苛的可用性和性能考验，就是它实力的体现了。Kubernetes项目早期还预留了对接多种后端存储的接口设计，现如今再去讨论这个话题已经失去了意义，因为etcd作为Kubernetes后端唯一存储早已深入人心。诞生于云原生星火燎原之时，上天再把你派到Kubernetes这个老大哥身边，把你打造成开源的Chubby，云原生的分布式存储基石，这是一份多么让人艳羡的履历啊！什么叫天之骄子？我想这便是！3     成书缘由  笔者求学于国内云计算研究最前沿的浙大SEL实验室，从研究生开始便投身于云原生技术的探索与实践。从最开始研究KVM虚拟机，再到后来的底层基础设施CloudStack，OpenStack，也参与过经典PaaS Cloud Foundry在企业私有云的落地。  在2014年Docker和Kubernetes技术刚诞生之时，我们实验室的几位老师和博士（其中便包括后来的Kubernetes核心维护者张磊）便敏锐地意识到这将是改变未来十年基础设施的新技术，出于技术布道的目的，我们合著了并出版了国内第一本深度解析Docker和Kubernetes的书《Docker——容器与容器云》。由于我负责该书Kubernetes部分，因此在写作过程中便对etcd有过较深入的研究，但考虑到彼时etcd还是0.4版本，功能比较简单，而且和该书的主题关联不强，所以就没有花篇幅介绍etcd。但彼时便被etcd简明的架构设计和优美的Raft算法实现深深折服，从此心中埋下了一颗独立出版一本介绍etcd书籍的种子。  毕业后由于工作关系一直深耕Kubernetes，并基于Kubernetes构建华为公有云的PaaS平台。自然，etcd是整个华为PaaS平台的重中之重，我所在的技术团队也经历了从Kubernetes 1K节点到10K节点百万容器规模的艰辛蜕变，积累了不少etcd在大规模场景下的运维和性能调优经验。我想，任何基于Kubernetes构建的云平台都会碰到我们之前解决过的各种etcd相关的问题，比如：数据容灾恢复，watch缓冲区溢出，高并发带来的读写性能衰退，磁盘I/O低下导致的集群频繁选主等问题。很多情况下，这些问题并非etcd的问题，是因为我们对etcd的核心机制不理解或理解不充分导致的。     etcd的官网只有粗浅的API使用等资料，缺乏对etcd架构和原理的深度剖析——可能这个世界上最懂etcd的人太忙没时间写文档吧。市面上介绍Kubernetes的书籍多如牛毛，却“不约而同”地忽略了最关键的etcd的相关内容。按李响的原话讲，“etcd是一个需要动脑子的项目”。尽管Raft算法和Paxos相比容易理解了很多，但对初学者来说里面仍然有不少奥秘需要点破。恰逢etcd准备捐献CNCF，急需中立的项目维护者，我希望更多人了解到这个优秀的项目，壮大开源社区。  因此，本着技术分享，回馈社区的心态，我们华为云容器服务团队合著了这本《云原生分布式存储基石：etcd深入解析》，希望在探索云原生落地的道路上，有更多志同道合的朋友加入，有你从此便不再孤单。  可能有人会问，市面上不是已经有一本etcd源码解析的书了吗？但我们需要注意到，etcd项目迭代更新快，今天拉的代码过上几个月有可能就变得面目全非，纯粹的源码解析的书籍很难做到与时俱进。此外，很多etcd的运维人员可能并不关心etcd的源代码，他们更关心如何使用etcd。在我的上一本书写作过程中，我就意识到了这个问题，因此《云原生分布式存储基石：etcd深入解析》是第一本涵盖分布式基本理论，分布式一致性协议Raft，etcd使用，运维，API，源码解析等内容的书，更是第一本综合分析了etcd V2和V3差异的书。希望各个层次的读者都能够从中获益。4      谁应该看这本书？如果你正在学习或者使用Kubernetes，我建议你看下这本书，因为Kubernetes后期的坑都在etcd，这本书可以让你提前知晓并且避开那些坑。如果你是分布式系统的爱好者，你可以从这本书了解到分布式系统的基本理论，包括：CAP理论，复制状态机，拜占庭将军问题，FLP不可能性等。如果你想自学Raft协议，这本书详解了Raft一致性算法，包括：Raft选举过程，日志同步，快照，异常恢复等机制。如果你是etcd的初学者，这本书手把手教你如何部署一个etcd集群，并用相当多的篇幅解释了etcd的基本概念、常用命令和配置方法等，更有常见问题的Q&A和实践分享。如果你是Kubernets/etcd的运维人员，etcd集群的稳定性关乎线上/线下环境的平稳，我建议你的案头放一本这书，每天闲时翻一翻，集群升级，备份恢复，日志监控，性能调优，认证授权等知识点一网打尽，彻底告别临时抱佛脚。如果你是etcd的开发者，这一本不错的API参考书，里面详细罗列了etcd V2和V3的常用API调用和各个参数的含义。如果你是高阶的分布式系统开发者和架构师，这本书你没有理由错过，因为它从源码级别娓娓道来etcd的多版本并发控制（MVCC），etcd V2存储机制，etcd V3数据模型，etcd的日志和快照管理，etcd V3的事务和隔离，etcd watch机制等实现细节，你可以从中汲取分布强一致性存储系统的设计灵感。5     如何获得这本书？《云原生分布式存储基石：etcd深入解析》一书由机械工业出版社在2018年11月5日正式出版，华为云容器服务团队荣誉出品。 各大平台均有发售，新书发售期间折扣力度较大：京东（自营有电子版），淘宝，当当（自营有电子版）。欢迎大家积极勘误，找到的错误直接回帖即可，找错最多的五位同学将有机会获得作者本人给各位充值话费哦~还请各位专家不吝赐教并反馈宝贵意见帮助后续改进！

【摘要】 分布式缓存服务（Distributed Cache Service，简称DCS），用于提供即开即用、安全可靠、弹性扩容、便捷管理的在线分布式缓存能力，兼容Redis和Memcached，提供单机、主备、集群等丰富的实例类型，满足用户高并发及快速数据访问的业务诉求。本文中模板在创建安全组的模板中引入分布式缓存Redis的内容。分布式缓存服务（Distributed Cache Service，简称DCS），用于提供即开即用、安全可靠、弹性扩容、便捷管理的在线分布式缓存能力，兼容Redis和Memcached，提供单机、主备、集群等丰富的实例类型，满足用户高并发及快速数据访问的业务诉求。下面模板在创建安全组的模板中引入分布式缓存Redis的内容。tosca_definitions_version: huaweicloud_tosca_version_1_0inputs:  myredis_password:    description: 分布式缓存实例的登录密码node_templates:  myvpc:    type: HuaweiCloud.VPC.VPC    properties:      name: my-vpc      cidr: '192.168.0.0/16'  mysubnet:    type: HuaweiCloud.VPC.Subnet    properties:      name: my-subnet      cidr: '192.168.1.0/24'      gateway: 192.168.1.1      vpcId:        get_reference: myvpc      dhcpEnable: true    requirements:      - vpcId:          node: myvpc  myecs:    type: HuaweiCloud.ECS.CloudServer    properties:      name: my-ecs      instances: 1      imageId: a3934478-bfeb-4a02-b257-9089779f0380      flavor: c1.medium      vpcId:        get_reference: myvpc      availabilityZone: cn-south-1a      nics:        - subnetId:            get_reference: mysubnet      rootVolume:        volumeType: SATA        size: 40      securityGroups:        - id:            get_reference: mysg    requirements:      - vpcId:          node: myvpc      - securityGroups.id:          node: mysg      - nics.subnetId:          node: mysubnet  mysg:    type: HuaweiCloud.VPC.SecurityGroup    properties:      name: my-sg    requirements:      - vpcId:          node: myvpc  mysgrule:    type: HuaweiCloud.VPC.SecurityGroupRule    properties:      direction: ingress      securityGroupId:        get_reference: mysg      ethertype: IPv4      maxPort: 5444      minPort: 5443      protocol: TCP    requirements:      - securityGroupId:          node: mysg  myredis:    type: HuaweiCloud.DCS.Redis    properties:      capacity: 2      securityGroupId:        get_reference: mysg      instanceMode: single      subnetId:        get_reference: mysubnet      password:        get_input: myredis_password      vpcId:        get_reference: myvpc    requirements:      - subnetId:          node: mysubnet      - securityGroupId:          node: mysg      - vpcId:          node: myvpc模板中有如下几个参数：1.         capacity：分布式缓存实例的容量，默认值为2。2.         securityGroupId：分布式缓存实例使用的安全组ID。3.         instanceMode：分布式缓存实例的类型，可填写single、HA或cluster。4.         subnetId：分布式缓存实例的子网ID。5.         password：分布式缓存实例的登录密码，建议定义为get_input方式获取，由用户在创建堆栈时输入，以保证安全性，避免明文密码。关于inputs的用法，将在后面章节介绍。6.         vpcId：分布式缓存实例所属的虚拟私有云ID。分布式缓存创建成功：

关键字：高可用、分布式、多可用区       最近公司新项目使用了华为云的DDM分布式数据库中间件服务，通过一段的时间的使用感觉还不错。近段时间发现有许多小伙伴也准备去使用这个服务，所以为大家分享一下使用 创建DDM服务的经验，帮助小伙伴们少走弯路。       首先在使用创建DDM实例的时候小伙伴们会遇到的第一个问题应该是如何选择DDM实例的规格，选小了满足不了业务量，选大了浪费多余的性能。 那么应该如何解决呢？DDM服务公布了不同规格DDM实例的性能压测数据，如下图，我们可以参考DDM的性能压测数据，再通过对公司业务发展规模的评估，选择相对应的DDM实例规格。混合读写OLTP场景sql类型DDM规格并发数QPS混合sql8C16G2564947416C32G2568730232C64G25615267164C128G512317431 简单查询场景sql类型DDM规格并发数QPS单select8C16G25610800316C32G25620522832C64G25642558564C128G512796614         选择规格之后，在创建DDM实例的界面，我们会看到有可用分区这个选项。可能有部分小伙伴不理解可用分区是什么意思，在这里也一起解释一下。      不同的可用分区在物理上分布在不同的地点，可以简单地理解为：在同一区下，电力、网络隔离的物理区域，可用区之间内网互通，不同可用区之间物理隔离（如下图所示）。针对可用区的选择上，主要从两个方面考虑：   （1）如果您需要提高应用的高可用性，建议您将云服务器创建在不同的可用区内。这样我们使用的DDM实例虚拟机的物理资源，就分布在了多个可用分区上，当其中有可用分区的物理资源出现故障时，只要有一个可用分区还正常运行我们的DDM实例就依然可以使用。   （2）如果您需要较低的网络延迟，建议您将云服务器创建在相同的可用区内。             还有一点需要注意的是，在创建DDM实例时选择的VPC与安全组必须要与你的ECS服务器使用的一致，否则会导致网络不通如下图所示（华为云出于安全上的考虑，VPC之间默认网络不互通，安全组不一致有可能导致网络访问被拦截），在华为云创建了多个VPC和安全组的同学需要注意一下。            DDM实例的使用需要关联RDS实例，因此在创建完DDM实例之后，还需要创建RDS实例才能够使用DDM实例。下面我们继续介绍RDS实例创建的注意事项。         首先需要注意的是，存储类型一定要选择超高IO类型，如下图所示，超高IO类型的最大吞吐量达到350MB/S，性能大大提高，并且价格只比普通IO贵20多块钱超值。数据库版本，优先选择最高MySQL5.7+，新版本会修复旧版本存在的漏洞，并且性能上会有所提高。           实例类型（如下图所示）如果仅仅是学生小伙伴自己玩玩，或者用于开发测试环境，则可选择单机实例即可，省点钱。但是如果是使用于公司的业务，则建议选择主备实例，预防万一，保证业务的稳定运行，提高可靠性，就相当于买个保险了，多花点钱图个安心，完全值得。            RDS实例规格可以适当选择小点，以便创建多个RDS，比如：如果需要一个2核8GB的RDS，可以换成创建两个1核4GB的RDS。这样的好处是，在使用DDM实例时，可以挂载多个RDS，提高使用DDM实例的性能。需要注意的是，创建RDS实例时，选择的VPC与安全组，也与创建DDM实例时选择的一样，必须与你的ECS服务器使用的一致。         最后在创建完RDS实例之后，如果对性能有更高要求的小伙伴，可以在RDS实例管理界面，创建只读实例，如下图所示，创建的只读实例的规格与主RDS实例的规格一致即可。创建了只读实例后，可以在DDM服务中，设置访问主RDS实例与只读RDS实例的负载均衡策略，进一步提升DDM实例的性能。                  好了，今天的分享就先到这里，后面还会继续分享DDM实例创建逻辑库、逻辑表、负载均衡策略等相关经验，小伙伴们如果有什么疑问可以随时与我交流分享吗，谢谢大家！欢迎扫码查看更多精彩：

普惠AI视频调研活动，高校开发者体验福利包，点击对应类目领取使用云资源。Part1：PaaS服务体验包1、分布式消息服务（DMS）限时体验2、分布式缓存Redis限时体验3、分布式数据库中间件（DDM）限时体验Part2：趣味在线实践课，真实案例，0基础也能学1、人机对战五子棋APP开发2、趣味社交App开发3、人脸识别Android应用开发Part3：Demo体验，0基础入门1、API网关API调试demo体验2、函数工作流控制台demo应用体验

【摘要】 华为云分布式缓存服务Redis提供即开即用、安全可靠、弹性扩容、便捷管理的在线分布式缓存能力，且实例类型丰富，可满足用户高并发及快速数据访问的业务诉求。新一代分布式缓存服务Redis可实现实例8秒创建、单节点性能提升300%、可以G单位进行弹性扩展、提供可视化WebCli访问Redis。

南哥本文内容速览：1 什么是事务2 ACID   2.1 原子性   2.2 一致性   2.3 隔离性   2.4 持久性3 分布式事务   3.1 基于XA协议的2pc   3.2 TCC   3.3 SAGA   3.4 基于消息队列   3.5 最大努力提交4 DDM分布式事务解决方案   4.1 单机   4.2 最大努力提交   4.3 最终一致性   4.4 强一致性分布式事务是个业界难题，在看分布式事务方案之前，先从单机数据库事务开始看起。1 什么是事务事务（Transaction）是数据库系统中一系列操作的一个逻辑单元，所有操作要么全部成功要么全部失败。可以看一个经典的转账事务示例，小哥哥转账100元给小姐姐：         begin;      操作1：查询小哥哥账号余额，确保余额充足      操作2：从小哥哥账号扣除100元      操作3：往小姐姐账号增加100元         commit;转账的一系列操作就是一个事务，事务会确保这一系列操作要么全部成功，要么全部失败。2 ACID谈起事务就不得不谈事务的四大特性ACID2.1 原子性（Atomicity）一个事务（transaction）中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。还拿之前的转账案例来理解，原子性就是要求转账的一系列操作（操作1、操作2、操作3）要么全部完成，要么全部失败。不能出现钱转了一半的情况，比如小哥哥的账号钱扣除成功了，但是小姐姐账号加钱的操作失败了，这种属于不满足原子性。2.2 一致性（Consistency）一致性这个词总是一个让人困惑话题，有时不同语境下说的都不是同一个事情。我们先看看维基百科定义：Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof。我们看看关键点，事务确保数据从一个valid状态转换到另外一个valid状态。什么样才算是valid呢，符合all defined rules。all defined rules包括了constraints、 cascades、triggers等。所以这里的一致性强调的是事务操作使得数据一直处于符合预定规则（约束、触发器等）。This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct。但是我们通常讨论的一致性的含义往往比较广，并不局限于ACID的C。看看转账案例，怎么样才算符合一致性呢，账户余额不能为负数可以算，而两者账户余额相加=200则属于应用语义层面的一致性，由原子性来保证。2.3 隔离性（Isolation）事务通常是并发执行的，同时对数据进行读写和修改的，隔离性强调的多个事务并发执行对数据的影响看起来跟串行一样。通常为了提高并发度，弱化了事务并发时对数据一致性的要求，允许若干种数据异常现象，从而定义了不同的事务隔离分为不同级别，包括读未提交（Read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（Serializable）。严格来说只有最高隔离的串行化隔离级别才是符合隔离性的。在转账案例中，如果在转账事务执行过程中，能读取到事务中间状态，比如转了一半然后出错事务进行了回滚，读到了“转一半”的不一致的数据状态，属于脏读。为了提高并发度，在最低的读未提交隔离级别是允许这种脏读，其他几种不会出现此种脏读。2.4 持久性（Durability）事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。持久性其实好理解，事务做完了要保证持久不丢失，比如转账已经转成功了，不能这笔事务丢失掉。从某种意义来说，ACID都是为了保障数据的一致性，不满足ACID则会有数据的不一致。 3 分布式事务互联网时代，业务发展迅猛，数据往往超出单机数据库所能处理的极限，遇到性能的瓶颈。应用层面微服务架构越来越流行，从原来的单体应用拆分成一个个独立的微服务，当应用通过一组微服务来协助完成时，对数据的一致性就需要分布式事务来保证。对数据库通常采用垂直拆分和水平数据分片，将数据拆分到多个不同的数据节点上。如果一个事务里的操作涉及了多个不同分片节点则产生了分布式事务。我们来看看业界常见的几种分布式事务实现：3.1 基于XA协议的2pc两阶段提交（2pc）大概属于被提的最多的分布式事务实现方案了。XA协议是 X/Open DTP Group提出的定义的两段提交（2PC - Two-Phase-Commit）协议，主要用于分布式数据库事务管理。XA规范主要定义了（全局）事务管理器（Transaction Manager）和（局部）资源管理器（Resource Manager）之间的接口。两阶段提交将提交过程分为两个阶段，在第一阶段，协调者询问所有的参与者是否可以提交事务（请参与者投票），所有参与者向协调者投票。在第二阶段，协调者根据所有参与者的投票结果做出是否事务可以全局提交的决定，并通知所有的参与者执行该决定。3.1.1 2PC的缺点2PC虽然保证了提交的原子性，但缺点也很明显，先从协议本身来看看两阶段提交的缺点：同步阻塞。执行过程中，所有参与节点都是事务阻塞型的。当参与者占有资源时，其他第三方节点访问资源不得不处于阻塞状态。单点故障。由于协调者的重要性，一旦协调者发生故障。参与者会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。从性能来看，2PC中协调者与每个参与者至少有2轮消息交互、多次写日志，过程又是同步阻塞，性能十分低下。3.1.2 2PC是强一致吗经常听到一些人说2PC是强一致的，真的是吗？我们先从隔离性的角度来看看，比如有两个节点a和b,一个事务已经到第二阶段准备提交，在某个时间点上，a节点已经提交，但b节点还未提交，这时另一个事务就能看到a节点提交后的值以及b节点提交前的值。还以之前转账为例，转入分支事务已经成功，转出分支事务还未提交成功，这个时候就看到不一致，两个账号总额度是300，属于脏读，能看到不一致还能算强一致么。从隔离性角度来说，2PC的分布式事务只能算最终一致，算不得强一致。一般人说的强一致只是说的原子性，事务要么全成功要么全失败。所以一致性这个词已经被玩坏了。 3.1.3 MySQL对XA支持的坑另外我们可以看看MySQL对XA的支持，在MySQL5.7之前一直有2个缺陷多年未修复。 prepare未写入binlog，若主库宕机切换后则丢失prepare客户端退出或者服务宕机，MySQL会自动回滚MySQL对外部xa的支持还有其他不少bug，这里不一一赘述。3.2 TCC关于TCC（Try-Confirm-Cancel）的概念，最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions: an Apostate's Opinion》的论文提出。TCC事务机制相对于XA的2PC相比，其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。TCC型事务（Trying/Confirming/Canceling）。Ø  TRYING 阶段主要是对业务系统做检测及资源预留Ø  CONFIRMING 阶段主要是对业务系统做确认提交，TRYING阶段执行成功并开始执行CONFIRMING阶段时，默认CONFIRMING阶段是不会出错的。即：只要TRYING成功，CONFIRMING一定成功。Ø  CANCELING 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。3.2.1 TCC与2PC区别当讨论2PC时，只专注于事务处理阶段，因而只讨论prepare和commit，往往忽略了业务逻辑执行阶段，或者默认为prepare包括了业务逻辑执行。可以看下MySQL的XA的一个示例就比较好理解。 2PC的一个完整的事务生命周期是：begin -> 业务逻辑 -> prepare -> commit。再看TCC的一个完整的事务生命周期是：begin -> 业务逻辑(try业务) -> commit(comfirm业务)。虽然TCC的confirm阶段也会包含部分业务逻辑，当然从事务执行角度可以简化来看将commit与confirm类比，所以TCC并不是两阶段提交。 TCC的Trying/Confirming/Canceling三个接口针对每个事务都需要用户自己来实现，其实对用户不太友好，增加用户开发工作量，另外不能保证所有人实现的接口一定能符合一致性要求，如果接口实现的有漏洞很可能会造成不一致。 3.3 SAGASaga是由普林斯顿大学的H.Garcia-Molina等人提出。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调。每个Saga由一系列本地分支事务组成，每个分支事务有对应一个补偿事务。如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作SAGA事务模型，是牺牲了一定的隔离性的，但是提高了long-running事务的可用性。除了隔离性的问题，SAGA跟TCC一样对于补偿的动作也是需要用户自己实现。 3.4 基于消息队列这种思路最早来自于ebay，核心思想将分布式事务分成多个本地事务，这里称之为主事务与从事务。主事务本地先行提交，然后通过消息通知从事务，从事务从消息中获取信息进行本地提交。可以看出这是一种异步事务机制、只能保证最终一致性；但可用性非常高，不会因为故障而发生阻塞。上述解决方案看似完美，实际上还没有解决分布式问题。为了使第一个事务不涉及分布式操作，消息队列必须与主事务使用同一套存储资源，但为了使第二个事务是本地的，消息队列存储又必须与第二事务的存储在一起。这两者是不可能同时满足的。本质上并没有规避分布式事务。如果消息具有操作幂等性，也就是一个消息被应用多次与应用一次产生的效果是一样的话，上述问题是很好解决的。但实际情况下，有些消息很难具有幂等性，比如转账中的扣款操作，执行一次和执行多次的结束显然是不一样的，因此需要做很多额外处理，一般通过状态表或者事务消息来解决。 3.5 最大努力提交最大努力提交（Best Efforts）的关键点在于： 与2PC相比，省去了prepare，本质上属于1PCcommit推迟到最后一起执行最大努力提交最早在spring中事务管理中广泛流传，感兴趣的可以参考https://www.javaworld.com/article/2077963/open-source-tools/distributed-transactions-in-spring--with-and-without-xa.html在分布式数据库中间件的场景也广泛应用，我们来看看MyCAT的事务模型，有时也被称为弱XA。 最大努力提交优点是性能非常好且对用户透明，缺点是可能存在部分提交成功部分失败的场景（Partial commits），而对于已经commit成功的场景无法rollback。但是由于将容易出错的sql执行阶段先执行，commit推迟到最后一起执行，相当于可能出错的危险窗口期缩短到只有最后的commit阶段，实际出错概率很低。而commit开始之前出错时可以正常回滚，不会有不一致。如果是在应用层采用该事务模型可以将分支事务设计成幂等性，这样在commit出错时可以对出错分支进行重试。在分布式数据库中间件的场景，则很难具备幂等性。 4 DDM分布式事务解决方案各种分布式事务的方案都各有优缺点，而业务场景又是复杂多样的，对一致性的要求也各不一样，很难有一种方案包打天下。所以我们DDM（https://www.huaweicloud.com/product/ddm.html）在设计分布式事务方案时，充分考虑和权衡了各种方案的优缺点，提供了四种分布式事务模型，可以由用户自由选择。TCC等模型使用起来需要用户自己实现相应的接口，对用户非常不友好。因此DDM提供了全透明模型的分布式事务，使用接口与原来单机一致。4.1 单机适合业务拆分比较合理，在应用层有自己的完善的事务处理框架，到DDM的事务都是单分片事务，单分片事务由底层数据库提供强一致性的保证。单机事务模型下，如果出现跨分片的事务，会报错进行提示，避免达不到预期目的。 4.2 最大努力提交该事务模型前文有描述，在此不再赘述。该模型适合绝大部分不涉及金钱往来的业务，在性能和一致性之间比较好的一个平衡。事务中commit时因为是往多个节点发送执行，有部分commit成功部分commit失败的可能性，但是可能性比较低，只有在commit的时间窗内出现异常才有可能出现此种情况。4.3 最终一致性最大努力提交模型的问题（Partial commits）本质是不满足ACID中的A原子性  ，针对该问题 做了改进，针对Partial commits中已经提交成功的分支事务进行自动的事务补偿，保证了原子性，由于从Partial commits到补偿成功会有比较短的时间窗口，该时间窗口内数据处于不一致状态但最终会达到一致状态，所以称之为最终一致性。当出现Partial commits异常情况是，是允许应用支持读取，所以可能会有脏读，如果业务场景对脏读比较敏感，比如之前转账事务中的查询余额，可以通过对该select加for update或者lock in share mode来解决，相当于针对该语句了保证了读已提交。从Partial commits到补偿成功时间窗内，业界有选择不加锁的则会出现回滚覆盖，造成数据错误回补不成功，而DDM采用了高效的加锁避免了该问题。强一致性强一致性模型既解决了分布式事务的原子性，又可避免脏读，确保了读取到的都是commit成功的数据，从隔离级别上来属于读已提交。适合对一致性有极端要求的场景。但是一致性级别越高，付出性能代价会越大，所以请根据业务需要选择合适的模型。最后DDM对分布式事务支持这么优秀的分布式数据库中间件，还不赶紧申请一个把玩一下，猛戳https://www.huaweicloud.com/product/ddm.html，更多惊喜等着你。欢迎扫码查看更多精彩：

如题？

尊敬的华为云客户：华为云计划于2018/08/15 00:00:00将分布式消息服务Kafka专享版、RabbitMQ队列正式商用。商用后，Kafka专享版和RabbitMQ队列支持按需和包周期计费，具体价格请届时参考该服务的计费详情页。公测期间体验服务的用户，商用后将会按需计费，为保证业务的连续性，请您及时关注账户，确保账户余额充足；如您体验结束，不再需要使用该服务，建议您尽快删除队列，以免账户扣款。Kafka专享版和RabbitMQ队列商用版本采用更高性能主机，性能强劲。具有多种规格实例供选择，满足用户不同场景需要；提供SSL能力，具备更高的安全性。更多关于分布式消息服务的产品介绍，请您点击了解。如您在使用过程中有宝贵意见，欢迎您拨打华为云服务热线:4000-955-988与我们联系。感谢您对华为云的支持！

一、云时代的应用性能测试挑战二、华为云性能测试实践方案如何更加系统的开展性能测试活动被测对象分析测试场景分析建模测试需求分析工具选型与搭建测试执行性能测试分析与调优1.    被测对象分析（某社交类APP）从系统架构分析可能出现的瓶颈点，作为重点测试场景Feed流会频繁操作后台的Redis等服务，每次操作会产生100+次网络操作，200+次key/Value运算，因此会成为系统的主要性能瓶颈备注：Feed是将用户主动订阅的消息源组合在一起形成内容聚合器，帮助用户持续地获取最新的订阅源内容，在社交类应用中被广泛使用若干2.    测试场景分析建模业务特点：用户增长迅速、突发事件高流量并发Step1：以使用场景为主线，构建性能模型（使用角色、使用阶段等）Step2：分析每个操作场景的影响因子，如好友、关注数量等，建立每个场景的测试模型 单场景一级接口测试单场景二级接口测试如需测试某个对性能的影响，可递增方式改变因子值进行测试 按照页面权重分配压力模型，实际在生产环境比例会不断变化，因此在性能摸底过程中需要不断调整摸底示例：全页面混合压测模型3.    测试工具需求分析识别关键场景测试需求1)      HTTP协议/Rest接口  2)      用户登陆认证 ，模拟多用户操作 3)      支持接口串联场景，需要上下文关联4)      性能暂无基线，需要支持递增模式快速摸底 5)      各页面用户量未知，需要灵活调整混合模型配比 6)      由于社交类应用业务增长迅速，因此需要支持按需使用，随时扩大工具的并发量7)      需要支持10万以上的并发8)      测试结果易于观察、保存9)      提供监控能力，便于快速定位 4.  测试服务选型与搭建测试服务选项原则：功能满足、效率高（即开即用）、成本低云服务更适合测试高扩展性的大规模分布式系统 5. 测试执行分层开展性能测试，在集成阶段确保性能测试活动可开展 测试执行的一些典型问题性能是一个逐步提升的过程，测试过程中需要找到扩容的模型，从不足50的TPS提升至万级 6.  测试结果分析1.1  如何从测试工具侧快速分析被测对象可能存在的问题·         存在部分响应超时：a)       服务器繁忙,如某个服务节点CPU利用率高b)      网络IO超过VM/EIP带宽c)       等待后端微服务、数据库的超时时间设置过长·         运行一段时间后全部响应超时或者检查点校验不通过：a)       大压力导致系统中某个微服务奔溃b)      后端数据库无响应·         TPS未随着并发数增长而上升：a)       系统性能到达瓶颈，持续并发加压过程中响应时延增加（可观察响应区间统计）b)      可通过进一步加压是否会出现非正常响应验证·         TP90响应时延较短，TP99时延高：a)       系统性能接近瓶颈b)      可通过进一步加压是否会出现非正常响应验证 1.2  一些通用优化建议1)      扩容，链路中的某一应用可能出现cpu使用率较高或者连接池资源不够用(rpc、jdbc、redis连接池等)但本身对于拿到连接的请求处理又很快，这一类需要横向扩展资源。2)      应用逻辑优化，比如存在慢sql、 逻辑的不合理如调用db或者redis次数过多、没有做读写分离造成写库压力过大。3)      超时时间的合理设置，对于应用之间的rpc调用或者应用与其他基础组件之间的调用，均需要设置合理的超时时间，否则过长的等待将造成整个链路的故障。4)      缓存的应用，请求尽可能从前端返回，而不是每一个都要让后端应用处理后再返回，减轻后端应用及数据库压力，提高系统吞吐能力。5)      限流，对于超出承载能力的QPS或并发，可以进行拦截并直接返回提示页面。6)      降级，对于非核心链路上的应用，允许故障关闭而不影响核心链路7)      扩容和优化也是有限度的，在评估容量内，保障核心交易链路正常是重中之重，对于非核心功能模块考虑降级场景 三、某互联网平台案例业务特点：突发事件高流量突发，如瞬间由百级用户增长到万级对于网络架构复杂的应用，可以通过网络架构上的分段验证，如分别从最外端的CDN入口（1）中间的ELB（2）业务层（3）分别做测试，验证网络架构上的瓶颈和影响应用内部的性能瓶颈如何提升定位效率？ 四、性能测试的最后一公里集成APM，解决性能问题定位最后一公里问题，大幅提升性能测试效率如：xxx并发情况下，服务A调用服务B的事务1出现问题，并直接定位至出错函数在上线和活动前期通过云性能测试服务进行压力测试，发现部分接口的响应时间比较长，会出现比对失败和响应超时，通过APM的调用链分析，发现有部分SQL语句比较耗时，针对这些SQL查询语句，建立了索引，快速定位问题并迅速解决。最终经过两轮测试优化后，官网首页访问响应超时与正常返回比提升了43.3%，预约试驾场景响应超时与正常返回比降低到0，提升了100%。性能瓶颈定位时间，从官网未使用APM时需要1周，缩短到俱乐部使用APM后的0.5天，效率提升90%应用拓扑事务监控调用链跟踪 五、性能测试服务关键能力要求华为云性能测试服务CPTS官网：https://www.huaweicloud.com/product/cpts.html

近日，猿与狗之间爆发了一场不大不小的争吵，起因是猿说自己整天累得跟狗一样。狗听到不乐意了，说偶们汪汪根本不是你们想象的那样。于是，一场猿狗PK赛就此展开…… 回合一：吃饭 回合二：工作 回合三：作息 回合四：外貌 四个回合下来，结果不言而喻，真相也是十分扎心了——如果一个程序猿觉得自己整天累得跟狗一样，那他真是误会大了，因为狗真的没有这么累！那么问题来了，程序猿要怎样才能惬意地像汪汪们一样嗨皮地生活呢？ 敲黑板！都看过来了喂~首先，累了要学会休息。多抬抬头、转转脖子、伸伸懒腰啥的，起身倒杯热水，电脑崩溃了就重启试试。毕竟，这个世界上不仅有修不好的电脑，还有做不完的工作。 其次，如果boss问道为啥网页打开速度还是那么慢，并让你重构代码的时候，你一定要冷静，微笑，心平气和地对老板大大说：TMD老子不干了！ 这当然是胡扯。 正确的做法应该是：你战战兢兢地给老板大大递上一杯热茶，小心翼翼地问道：“老板，听说华为云数据库有一个年中钜惠活动，分布式缓存服务Redis现在低至5.8折！您看我们是不是可以考虑……” “还在磨叽啥呀，赶紧了解去啊！” 华为云分布式缓存服务Redis提供单机、主备、集群等实例类型，完美兼容原生开源协议，30+项监控指标自主运维，能满足用户高性能读写的业务诉求。一键扩容，立等可用，数据库运维更省心，就选华为云分布式缓存服务Redis！点击查看详情：https://activity.huaweicloud.com/dcs_midyear/index.html?forum

随着虚拟化、云化技术越来越成熟，分布式系统的成本和架构优势日渐凸显，特别是微服务等设计理念在业务系统尤其是大型的互联网公司中越来越流行，业务的调用关系越来越复杂。而随着业务的膨胀、服务的拆分，系统的模块变得越来越多，不同的模块可能由不同的团队/程序员来维护。一次客户的业务请求，可能会涉及数个乃至数十个服务的协同处理，牵扯到多个团队/程序员的维护模块，不同的缓存、数据库、消息队列等中间件。在这样的云化应用架构下，请求链路的任何一条请求出现故障或性能问题，都将严重影响服务的用户体验。如何能够快速准确的定位到线上故障根因？如何捕捉请求中的性能瓶颈并实施优化？如何将离散的业务请求数据关联在一起进行有效的用户体验分析？对于大型的、访问量大的网站、社交、电商、游戏应用，这类问题尤其突出，直接影响最终用户对系统的感知和留存率。传统的应用运维问题定位以日志为主，通过对告警、系统资源、日志的逐一分析，定位故障根因或性能瓶颈。但是由于云化架构的复杂性，业务请求链路的多样性，传统的应用运维模式已经无法继续支撑故障定位与性能分析的诉求。这个时候就需要APM系统来大展身手了。APM (Application Performance Management) 即应用性能管理，属于IT运维管理（ITOM)范畴。主要是针对企业关键业务的IT应用性能和用户体验的监测、优化，提高企业IT应用的可靠性和质量，保证用户得到良好的服务，降低IT总拥有成本(TCO)。APM随着互联网的发展，经历了以下三个阶段：第一阶段的APM出现在互联网兴起的初期，由于网络基础设施的水平普遍较差，使应用速度对网络速度与基础资源的性能非常敏感。这个阶段的APM以网络为中心，认为网络速度既应用速度，APM主要监控主机的CPU、I/O、内存、网络吞吐等为主。第二阶段的APM以监控各种基础组件为主，随着互联网的发展，网络应用变得越来越复杂，各种基础组件越来越多，促使APM进入以IT组件的健康状态、可用性、性能监控为中心第二个阶段。近几年移动互联网、云计算、大数据、物联网等技术的迅猛发展，各种业务应用不断出现，IT应用复杂度呈现爆炸式增长，而互联网产品本身“用户至上”的属性决定用户体验成为各互联网产品生存发展的关键因素。如何提升用户体验，保证服务和产品的可靠性、稳定性、优化服务等问题，对应用性能管理提出了新的需求，应用性能管理进入以用户体验为核心、专注业务交易与应用架构高度复杂性的第三阶段。基于APM 市场分析，Gardern对APM进行了新的定义描述：在新的标准下，APM市场发展迅速。APM通过对应用服务的性能和可用性进行监控管理，帮助应用/服务开发者发现和定位性能瓶颈和故障，保证应用达到预期的服务水平及最终用户体验。现代的APM基本都是参考Google的Dapper体系来实现的。Dapper通过跟踪请求的处理过程，来对应用系统在前后端处理、服务端调用的性能消耗进行跟踪。Google基于Dapper的实现发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，给行业内分布式跟踪的实现提供了非常有价值的参考，该论文也成为了当前分布式跟踪系统的理论基础。大家可以参考Dapper论文原版，进行详细了解，本文只对原理做简单介绍。如上图所示，对于业务链条中的每一次请求调用，划分为clientSend（客户端发送请求）、clientRecv（客户端收到响应）、serverRecv（服务端收到请求）、serverSend（服务端发送响应）等四个事件，并由这四个事件组织为一个称作Span的数据结构。通过定义Span之间的调用（父子）关系，可以对离散的Span数据进行重组，以还原完整的调用链条。Span间的关系通过traceId、parentId、spanId来标识。traceId是一次完整调用链路的唯一标识，parentId标识当前Span的前一个调用Span，spanId用来唯一的标识某一次调用。Span在跟踪链路中的关联关系可以用下图表示：基于Google Dapper这种通过traceid、parentid、spanid还原原始链路的思路，众多大型互联网公司都开发了自己的调用跟踪系统，如Twitter的Zipkin、淘宝的鹰眼、京东的Hydra、开源的PinPoint，总体思路虽然一致，但是植入点选择上却有一些分歧。应用性能管理系统主要由数据源、采集传输、分析计算、可视化查询几部分组成，其中最核心的部分就是数据源。通过从客户端和服务端进行数据采集，其中客户端的数据采集技术主要包括主动式拨测与被动式埋点探测，在此不再展开详细描述，本文主要对服务端的数据采集技术进行简单介绍。服务端的数据采集主要分为两大类：· 网络旁路监听，通过在应用或服务部署的生产网络的交换机或网络接口抓取应用访问流量进行应用性能分析。这种方式对于应用或者服务的侵入性小，性能影响小。然而此方式采集粒度较大，无法提供代码级的问题定位，且在安全传输协议下，无法针对请求或事物进行分析。· 探针埋点，通过在生产服务器上的应用部署或者嵌入探针的方式进行应用性能数据采集。这种方式能够提供非常完整与细粒度的监控数据采集，提供代码级的问题定位。但此方式对于应用来说是侵入性的，如果埋点代码异常，会对应用本身的性能和稳定性产生一定影响。在针对应用与服务的埋点数据采集中，主要使用了探针埋点的方式。探针埋点的方式主要分为两类，以Zipkin为代表的代码侵入式埋点与以PinPoint为代表的字节码增强式埋点。Zipkin是Twitter开源的分布式追踪系统，用户帮助微服务收集排查潜在问题的时序数据，提供调用跟踪数据的收集、存储、查询以及依赖分析的能力。Zipkin是一个分布式跟踪系统，不具备用户体验分析、应用监控统计等特性。Zipkin使用代码侵入埋点的方式，官方提供基于Finagle框架的埋点方案，其他语言和框架的支持主要依赖社区贡献。当前支持包括Java、Scala、Node、Go、Python、Ruby、C#等主流语言和框架。代码侵入式埋点指通过提供应用开发的SDK，或者提供集成埋点代码的框架的方式供应用开发者调用。部分具备框架研发能力的企业像Google一样将植入点选在开发框架或通信框架中，确保基于统一框架开发或通信的应用天然具备埋点能力，除框架开发团队外无需关注埋点实现、调用方式。这种埋点方式优势在于使用框架后无需额外关注埋点能力，变相降低了埋点的成本。Twitter的Zipkin、淘宝的鹰眼选择了这种埋点方式。同时，业界也有非常多的埋点装备库，支持使用埋点组件的方式实现调用链数据埋点。这种埋点方式，通过提供标准的服务框架，如：Servlet、Spring MVC、Http Client以及通用的中间件，如MySQL、Kafka等的装备类的方式，通过编写简单代码和配置，让基于这些标准框架构建的应用可以输出调用链报告数据。Brave为这种埋点方式提供了大量的标准框架实现。也提供了非常简单且标准化的接口，支持在以上的封装实现无法满足业务要求时，进行定制与扩展。代码侵入式埋点具有较好的扩展性，方便用户自定义采集的数据类型与层次。但是，不论提供框架埋点的方式还是提供装备库、SDK的方式，都需要代码侵入，在应用开发以及框架等升级场景下，应用需要重新修改代码。同时，对于应用开发人员来说，精准的识别需要埋点的地方也具有一定难度，而且基于代码侵入的埋点跟踪级别较低，无法获取足够详细的运行态信息。与Zipkin不同，PinPoint是一款开源的应用程序性能管理（Application Performance Management）工具，使用字节码增强的方式进行数据源收集，目前只有官方提供的Java Agent探针。字节码增强式埋点方式，提倡代码的非侵入性，不同的编程语言，通过不同的技术在语言运行环境或基础库上植入。对于Java应用，利用字节码增强技术，在启动JVM时通过不同的埋点插件覆盖不同的通信协议、中间件、开发框架，对Java基础调用代码进行函数级埋点。这种埋点方式优势在于能够拿到堆栈级的调用信息与其他更多运行态信息，帮助使用者无需日志等辅助手段即可快速完成问题定位。PinPoint使用字节码增强技术进行APM数据采集，通过在应用启动时配置java agent探针的方式，主动干预应用代码行为，应用开发者无需进行代码修改，由PinPoint来决定在哪些API进行数据埋点。相比较PinPoint的字节码增强技术与其他APM系统的代码侵入式埋点来说，字节码增强技术从理论上来说能够在任何地方进行埋点，而类似Brave装备库等侵入式埋点的方式本身依赖中间件的实现方式，其提供的应用层面的 API 还需要框架底层驱动的支持，才能实现拦截。PinPoint 在实现之初就考虑到了性能优化，如采用 Thrift 的二进制变长编码格式、使用 UDP 作为传输链路、在传递常量的时候使用数据参考字典、使用异步传输方式等。但任然存在一些性能问题与使用的约束，并且由于字节码增强技术对开发人员有较高的要求，其在扩展性和社区生态方面具有一定的劣势。华为APM结合PinPoint与Zipkin两种典型系统的优点，提供更便捷、更高效、性价比更高的解决方案。1. 非侵入式数据采集：一键式采集部署，更高效与健壮的数据采集能力华为APM探针借鉴PinPoint采集探针优势，在采集数据模型、输出组件性能、可靠性等方面进行优化，并统计业界各框架与中间件的使用广泛性基础上，增加插件支持能力。以保证在最小的资源占用下，为用户提供最为有用的性能分析数据。· 探针自动部署：华为APM支持与华为云容器引擎、云应用编排等服务配合使用，可以在应用部署时通过简单勾选，实现采集探针的自动部署。· 支持Zipkin模型：虽然PinPoint与Zipkin均基于Google Dapper的论文，理论基础大致相同。但是在调用链的数据模型上还是有很大的差异性。在开放性以及社区活跃度等方面，Zipkin更具有优势。为支持Zipkin用户接入，华为APM探针支持按照Zipkin的数据模型进行调用链数据输出。· 数据分类优化：对于APM调用性能统计分析（吞吐量、平均时延、TPN等），业界通用的方式为使用调用链数据进行二次抽取汇聚。该方式下需要尽量多的调用链数据样本，以使统计数据尽可能准确，势必消耗更多的应用资源。为解决这个问题，华为APM探针对采集数据源进行了分类：调用链数据与KPI数据。KPI数据针对每个业务请求按照周期进行汇聚，输出包含请求发起方、请求服务方、调用事务、调用状态（耗时、成功或失败等）等信息。由于KPI数据周期性输出，且相比较调用链数据小得多，因此能够在很小的资源负载下实现全量请求采集与统计。· 数据精准采集：调用链数据更多的关注调用超时（阈值支持自定义）或调用异常的调用链条。华为APM在基础采样率的基础上，从客户的实际运维场景触发，提供精准采集动态配置能力。精准采集支持客户针对应用或交易事务设置超时阈值、周期采集异常调用样本个数、周期内正常调用样本，以减少资源消耗的同时保证异常或超时请求的数据样本满足性能分析要求。· 数据传输优化：针对大数据量下数据输出对资源的消耗较高的问题，对输出组件进行优化，通过异步文件输出与异步Pipe输出、输出数据Cache，减少数据类型等方式，优化应用资源占用。· 采集逃生机制：在高并发峰值场景下，应用业务请求多，资源消耗大。此时，为保证业务正常运行，华为APM支持用户自定义配置逃生资源阈值。在应用资源消耗达到阈值后，华为APM探针主动停止所有运维数据采集，在资源消耗下降至阈值以下时自动恢复数据采集。逃生机制支持动态配置。2. 数字化运营：提供业务运营体验管理与性能分析实时跟踪每条业务交易，快速分析交易的运行状态并提供诊断能力· 自定义事务：用户可根据每条URL定义事务名称，方便理解。· 健康规则配置：可以对每条事务配置健康规则，如超过1s提示异常。· 性能追踪：精确采集异常性能数据，可对比历史基线数据，也能找到应用的异常方法，提升运维效率。3. 应用程序分析：应用关系与异常一目了然、故障下钻· 应用发现与依赖关系：精确采集异常性能数据，可对比历史基线数据，也能找到应用的异常方法，提升运维效率。· 应用KPI汇聚：微服务实例汇聚到应用，KPI数据自动汇聚到应用。4. 应用程序跟踪：对异常业务调用链追踪，快速问题定界支持平台、资源、应用的监控和微服务调用链分析：· 海量数据规模支撑：支持百万容器监控，秒级查询响应。· 故障下钻：通过单击故障节点可自动下钻到故障的微服务实例、也可以关联到失败的调用链和调用栈，查看失败函数的入参和返回值。现在就使用APM服务：体验馆免费体验——使用您自己的账号登录APM，通过体验馆免费体验APM功能。demo免费体验——使用应用性能管理提供的免费账号登录并了解应用性能管理服务功能。使用——使用您自己的账号登录APM，进一步了解APM服务功能或将APM服务接入您自己的应用。更多关怀：

又到了一周一次的华为云视界直播~ 本期华为云视界直播将邀请到华为云分布式数据库中间件的专家为您详细阐述华为云分布式数据库中间件的前世今生，干货满满的技术揭秘，期待您的现场参与体验！ 直播链接：http://zhibo.huaweicloud.com/watch/1971154 或扫描二维码手机观看 17297 随着互联网时代的到来，数据量呈指数级别地飞速上涨。我们的系统所需要支持的用户数，很可能在短短的一个月内突然爆发式地增长几千倍，MySQL等数据库从GB级飞速上涨到了TB级。伴随业务的信息化发展、海量并发、海量存储等现象使得传统的数据库方案面临新的困境： ● 单机数据库容易产生容量与性能瓶颈● 传统的分区分表或分库方案限制太多● 单机数据库服务器成本高昂 如果在这爆发的关键时刻，系统不稳定或无法访问，那么对于业务将会是毁灭性的打击。面对海量数据洪流，华为云推出了分布式数据库中间件服务DDM，DDM是专注于解决数据库容量、性能瓶颈和分布式扩展问题的中间件服务，提供分库分表、读写分离、弹性扩容等能力，应对海量数据的高并发访问场景，有效提升数据库读写性能。 DDM的核心优势如下： 自动数据分片：将数据自动按规则拆分数据到指定的分片中，并提供路由分发和自动聚合能力。 透明读写分离：自动完成透明读写分离，提高读操作的并发性能，支持一键添加只读实例轻松提升读性能。 卓越并发性能：提供 PB 级数据量访问，十倍于单机数据库连接数，支持百万级高并发。 平滑弹性伸缩：一键添加 RDS 实例，DDM 自动完成数据的重新分布。 本期直播议程：2018年6月14日16:00-16:45 深度解析华为云分布式数据库中间件16:45-17:00 线上互动问答

2018年4月，华为云DevCloud分布式追踪技术专家吴晟受邀参加2018 QCon全球软件开发大会，就《从无名小卒到拥抱全球——Apache SkyWalking (incubating) 的发展之路》做主题演讲，分享SkyWalking的发展、4次代码重构与技术升级以及社区发展之路。 吴晟进行专题演讲技术瞬息万变，云计算和云服务器目前已经逐步的成为计算机网络中基本资源，微服务的概念也随之再一次进入开发者的视野中。通俗来说，微服务的本质就是将复杂的服务拆分成单独的个体，个体之间通过统一的协议相互沟通的一个过程，这也决定了微服务的部署应该是分布式的。许多国外大型企业已经在内部生产系统中实践了分布式理念，例如google公司为了解决监控问题，研发了Dapper分布式跟踪系统，国内类似的便是开源系统SkyWalking。SkyWalking 2017 年全票通过加入了 Apache 孵化器，作为中国首个个人发起，进入Apache的孵化项目，也是唯一一个OSS项目， SkyWalking发展到这一阶段并不容易。中国开源项目的起步较晚，而且苦难重重，在OSS这个领域，国内更是很少涉猎。SkyWalking 是由开源社区推动的项目，依赖大量的基础社区反馈，国外社区的模型和理论共享，用户压力测试回馈。从2015年起，SkyWalking经历了4次代码重构与技术升级，从开始敲入第一行代码到参与W3C trace context 标准制定，从寻找第一个对SkyWalking感兴趣的人到获得Google、Micosoft、Zipkin、AppDynamic、New Relic、DynaTrace、Instana等一系列世界等级公司的尊重与重视，SkyWalking证明自己的实力、造就如今的设计和性能用了3年的时间。SkyWalking是针对分布式系统的 APM 系统，也被称为分布式追踪系统。V5版本的SkyWalking支持： [*]高性能纯流式分析 [*]高性能自动探针 [*]良好的手动探针接口 [*]分析、告警能力 [*]接入安全控制 [*]现代化UI [*]多语言社区整合 SkyWalking V5架构图除此之外，在SkyWalking的生态方面，吴晟介绍到：“目前有很多公司和个人在参加SkyWalking这一项目，4 位 PMC 成员，6 位 Committer Team 成员，总贡献者超过30位，很多贡献者目前或曾经都是APM 公司的架构或者核心研发工程师，所以SkyWalking能够提供很多商业产品或者国外产品的能力。”据了解，目前已有多家企业包括华为、当当、小米、海尔消费金融、易企秀、商云、随行付等都开始应用SkyWalking支撑企业内部研发。例如，目前SkyWalking已经作为运维监控与诊断工具对华为云DevCloud产品服务提供全流程追踪。华为云DevCloud是作为华为云的组成部分, 是华为30余年研发实践和前沿理念的结晶，为开发者提供一站式、轻量级的DevOps工具服务，支撑企业DevOps落地，实现项目的高效、高质量迭代。有了SkyWalking的应用，华为云DevCloud将进一步增强故障诊断能力与性能监控能力，也能更好的为广大开发者提供稳定可靠的云上服务。

本帖最后由 大脸猫爱吃鱼 于 2018-4-12 19:47 编辑转自CSDN 原作发于2018年04月08日 15:19:59传统的单体应用的微服务化改造过程中大多会面临数据库拆分，故而原来由数据库保证的数据一致性也一定面临重新设计和实现，此时需要引入分布式数据一致性方案来解决。常见的解决方案主要有2PC，TCC，事件驱动等，而在微服务开源项目 ServiceComb中提出并实现了使用Saga[1]来解决微服务的数据一致性难题，不同方案的对比可参考《ServiceComb中的数据最终一致性方案》[2]一文。Saga是一个数据最终一致性的解决方案，它允许我们成功地执行所有事务，或在任何事务失败的情况下，补偿已成功的事务，并提供了ACID[3]中ACD的保证（由于事务是交错执行的，可能会看到其他事务的部分结果，因此不能满足隔离性要求）。因此，Saga适用于以下跨服务的事务场景：[*]嵌套调用。如网上购物时，会依次经过下单、支付服务和第三方支付这几个子事务，其中，下单依赖于支付服务的返回状态，而支付服务也包含了多种可选的支付方式，并依赖于具体支付方式返回的结果。通过Saga，可以清晰地看到一个完整事务中各个服务之间的关系，在异常时也能快速定位出现问题的子事务。[*]高并发。如秒杀场景下，在成功扣除库存和完成支付后方可认为秒杀成功，若成功扣除库存但支付失败则自动进行补偿（即恢复库存）。鉴于Saga只有提交和补偿两种状态，成功场景下只需对每个子事务进行一次调用即可，因此可以在高并发下保持高性能。[*]调用时间长。如线上购买电影票，选好座位后一般会有15分钟的支付时间。Saga仅在子事务的提交阶段对资源进行短暂的锁定，且通过超时机制确保事务超时后能自动补偿，即在规定时间内没有支付成功的话就自动释放锁定的座位，极大地简化了业务出现异常时的处理逻辑。Saga新版本演进新年新气象，Apache ServiceComb(incubating) Saga[4]（以下简称Saga）进行了演进。相对于上一版[2]，新演进的设计主要有以下优势：[*]极大提升易用性。开发者只需使用2-3个注解（即启用事务服务：EnableOmega、全局事务标记：SagaStart和子事务标记：Compensable）。[*]更方便扩展。对微服务框架的支持更友好。[*]数据一致性与业务逻辑解耦。在演进后的设计中，通过服务侧omega的引入，saga协调器的职责更为单一（只需负责协调事务的完整性），与具体业务无关，因此，开发人员可以聚焦在具体业务的开发。Saga演进后的架构，如下图所示，主要包含两个组件，即alpha和omega，其中：[*]alpha充当协调者的角色，主要负责对事务的事件进行持久化存储以及协调子事务的状态，使其最终得以与全局事务的状态保持一致，即保证事务中的子事务要么全执行，要么全不执行。[*]omega是微服务中内嵌的一个agent，负责对网络请求进行拦截并向alpha上报事务事件，并在异常情况下根据alpha下发的指令执行相应的补偿或重试操作。omega内部运行机制omega是微服务中内嵌的一个agent，负责向alpha上报事务状态并与其它omega直接传递事务上下文信息。其中，每个服务的事务上下文包括：[*]全局事务id(Global Tx Id)：用于唯一标识全局事务，一般在全局事务入口生成，并在整个事务过程中传递。 [*]本地事务id(Local Tx Id)：用于唯一标识本地事务，一般由本地事务生成。 [*]父事务id(Parent Tx Id)：用于构建子事务间的关系，可由请求上下文中构建。如下图所示，分布式事务与用于分布式调用链追踪的zipkin[5]的处理流程很类似，在服务提供方，omega会将请求拦截并从中提取请求信息中的全局事务id作为其自身的全局事务id（即Saga事件id），并将请求中的本地事务id作为其父事务id，且使用新生成的id作为本地事务id；在服务消费方，omega会将请求拦截并往其中添加当前的全局事务id和本地事务id。通过服务提供方和服务消费方的这种协作处理，子事务能连接起来形成一个完整的全局事务。omega在预处理阶段会先向alpha发送事务开始的事件，在后处理阶段会再向alpha发送事务结束的事件。alpha在收到事件后会进行持久化的存储。因此，每个成功的子事务都有一一对应的开始及结束事件。在omega启动时会向alpha注册，使得异常或者超时场景下，alpha能通过回调向omega发送重试或补偿的命令和相应的调用参数，从而确保全局事务的一致性。具体处理流程成功场景全局事务开始前omega会先向alpha发送全局事务开始的事件，并在所有子事务完成时向alpha发送全局事务结束的事件。而每个子事务在执行前也会向alpha发送事务开始的事件，在成功执行后，会向alpha发送事务结束的事件。子事务间通过全局事务id连接在一起，但也因本地事务id而有所区分。因此，在成功场景下，每个开始的事件都会有对应的结束事件。异常场景在子事务执行期间抛出异常时，omega会向alpha上报aborted事件，然后alpha会向该全局事务的其它已完成的子事务发送补偿指令，确保最终同一全局事务下的所有子事务要么都成功，要么都回滚。由于事务中没有明确指定全局事务中的参与者，因此，alpha的扫描器会定期查询事件表并找出已完成所有补偿子事务的全局事务，然后对这些全局事务添加全局事务结束事件以保证事务的完整性。超时场景alpha的扫描器会定期扫描正在处理的事件状态，若发现事件超时，则会记录相应的aborted事件，然后alpha会向该全局事务的其它已完成的子事务发送补偿指令来恢复至事务开始前的状态。如何使用？Saga的使用主要涵盖两方面，alpha的启动及omega的使用。alpha的启动alpha启动前需要先运行数据库PostgreSQL：[code]docker run -d -e "POSTGRES_DB=saga" -e "POSTGRES_USER=saga" -e "POSTGRES_PASSWORD=password" -p 5432:5432 postgres[/code]在确保数据库正常启动后，即可运行alpha：[code]docker run -d -p 8090:8090 \ -e "JAVA_OPTS=-Dspring.profiles.active=prd" \ -e "spring.datasource.url=jdbc:postgresql://{docker.host.address}:5432/saga?useSSL=false" \ alpha-server:0.1.0[/code]omega的使用omega的使用很简单，以一个简化的转账业务为例，同一笔转账要么转入和转出都成功，要么都失败。在这样一个业务中引入Saga，只需简单几步即可：1. 引入依赖[code] org.apache.servicecomb.saga omega-spring-starter 0.1.0 org.apache.servicecomb.saga omega-transport-resttemplate 0.1.0 [/code]2. 添加Saga的注解及相应的补偿方法2.1 在应用入口添加 @EnableOmega的注解来初始化omega的配置并与alpha建立连接。[code]@SpringBootApplication @EnableOmega public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); } }[/code]2.2 在全局事务的起点添加 @SagaStart 的注解。[code]@SagaStart(timeout=10) public boolean transferMoney(String from, String to, int amount) { transferOut(from, amount); transferIn(to, amount); }[/code]2.3 在子事务处添加 @Compensable 的注解并指明其对应的补偿方法。其中，补偿方法的形参列表需与子事务方法的形参列表保持一致。[code]@Compensable(timeout=5, compensationMethod="cancel") public boolean transferOut(String from, int amount) { repo.reduceBalanceByUsername(from, amount); } public boolean cancel(String from, int amount) { repo.addBalanceByUsername(from, amount); }[/code]2.4 对转入服务重复第2.3步即可。2.5 在每个服务的application.yaml中添加配置项，指明服务信息和alpha的地址信息：[code]spring: application: name: {application.name} alpha: cluster: address: {alpha.cluster.addresses}[/code]目前Saga的实现还存在着很多有意思且有挑战性的课题，如alpha的协调调度实现、幂等的实现及自动补偿的实现等，欢迎有志之士与我们携手一起解决数据一致性的难题，共同为完善微服务生态贡献自己的力量。参考文献[1] Sagas, Hector Garcia-Molina & Kenneth Salem, https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf[2] ServiceComb中的数据最终一致性方案，殷湘，http://blog.csdn.net/fl63zv9zou86950w/article/details/78393439[3] ACID, Wikipedia, https://en.wikipedia.org/wiki/ACID[4] Apache ServiceComb(incubating) Saga, Apache, https://github.com/apache/incubator-servicecomb-saga[5] zipkin, zipkin, https://github.com/openzipkin/zipkin

本帖最后由 Sabrina 于 2018-4-4 14:59 编辑 13625 【下午茶时光——云存储知识点陪你喝咖啡】 分布式存储中的元数据管理 [indent]元数据被定义为：描述数据的数据，对数据及信息资源的描述性信息。 [/indent]元数据（Metadata）是描述其它数据的数据（data about other data），或者说是用于提供某种资源的有关信息的结构数据（structured data）。元数据是描述信息资源或数据等对象的数据，其使用目的在于：识别资源；评价资源；追踪资源在使用过程中的变化；实现简单高效地管理大量网络化数据；实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。对于元数据的管理目前有几种常用的解决方案：中心节点管理元数据，分布式管理元数据，无元数据设计；本文谈谈三种方案的特点:136261、中心节点管理元数据在设计分布式(存储)系统时，使用中心节点是非常简洁、清晰地一种方案，中心节点通常兼具元数据存储与查询、集群节点状态管理、决策制定与任务下发等功能。优点：A.由于其元数据集中式管理的特点，可以方便的处理集群运维管理的统计分析类需求；B. 中心节点记录了用户数据的状态信息(即元数据)，在扩容时，可以选择不做rebalance操作(rebalance引起的数据迁移可能带来巨大的性能开销)，且仍能正常寻址。缺点及解决方案：a.单点故障是设计分布式系统最忌讳的问题之一，中心节点简洁的设计也带来了此问题，如何实现HA呢？；解决方案：(1)使用主备模型，主备之间使用同步或异步的方式进行增量或全量的数据同步(如TFS,mfs，HDFS2.0等)，或者主备之间使用远端共享存储(如HDFS2.0，远端存储需要高可用)；b.存在性能和容量扩展上限，集中式中心节点自身硬件设施存在扩展(scale up)上限及查询式寻址方式，导致此问题；即使client缓存元数据或使用缓存集群，也不能在根本上消除上限，在某些场景下(如海量小文件)，此问题仍然存在；解决方案：(1)优化升级硬件，如使用SSD，大内存等机器；(2)当面临此问题时，考虑使用分布式管理元数据方案。2、分布式管理元数据和中心节点的方案相似，只是将元数据分片并使用分布式节点管理存储，在保有中心节点方案优点的同时，解决了性能和容量扩展上限的问题，同时，多个节点同时提供元数据查询服务，系统性能得到提升。缺点:此类系统较为少见，系统本身结构复杂，实现也有一定难度;a.系统包含两种相对独立的分布式节点：元数据节点，数据节点，它们均是带状态节点，每种节点组成的分布式模块都要面临分布式CAP原则的取舍，都要做到可扩展，尤其是元数据对一致性有着更高要求；b.元数据节点需要共同维护数据节点的状态，并在状态变化时作出一致性的决策；这些都对系统的设计和实现构成了很大挑战；c.另外，大量元数据所需的存储设备也是一笔不可忽略的成本开销；上面两种方案有着共同思想：记录并维护数据的状态(即元数据)，数据寻址时先向元数据服务器查询，再存取实际数据。3、无元数据设计主要以ceph为例，有别于上述二者的思想，此类系统的主要思想：使用算法计算寻址，寻址算法的输入参数之一为集群状态(如数据节点分布拓扑，权重，进程状态等)的某种形式描述，此类常见算法有consistent hashing，Ceph RADOS系统的CRUSH算法，这类算法通常不直接管理用户数据，而是引入中间一层逻辑分片结构(如consistent hashing的环片段，ceph的placement group)，其粒度更大，其数量有限且相对固定，用户存取的数据隶属于其中唯一一个分片中，系统通过管理维护这些分片进而管理维护用户数据；此类系统有的也有中心配置管理节点(如ceph rados的monitor)，只提供集群和分片等重要状态的管理维护，不提供元数据的存储查询。优点：A.如前所述，系统只需管理维护逻辑分片与集群状态等信息，不存储管理用户数据的元数据，系统的可扩展性大大增强，这在大量元数据场景时尤为明显；B.寻址算法所需的参数数据量小且相对固定，client可以通过缓存的方式，达到若干client并行寻址的目的，避免了寻址性能瓶颈；缺点分析：a.集群扩容时(甚至权重改变时)，需要做rebalance，尤其是数据规模很大(PB级以上)的集群，由此带来的大量数据迁移使集群一直处于高负载的状态，进而使得正常业务请求的延时、iops等性能指标下降；但有些场景做集群扩容时，并不希望做rebalance(如集群容量不足)；对此，常见策略是每个集群预先做好性能、容量评估，需要扩容时，直接新建集群；如果单个集群必须做rebalance，通过人工干预限流降低集群负载；至于需要做rebalance的根本原因，本人认为扩容导致集群状态改变，进而导致寻址算法结果改变，最终数据分布也需随之改变；b.数据的副本分布位置通过寻址算法计算得出，位置相对固定，几乎不可人为调整；但通常可以通过改变权重的方式改变数据总体分布情况；c.中心配置管理节点只管理分片信息，不知道单个用户数据的信息，统计分析类的需求需要通过定期地收集数据节点信息等方式实现，并存储维护。总结：通过以上比较分析，三类系统的寻址策略，使系统本身均有自己相应的优缺点，它们都不是完美的，但都有其适宜的场景和业务，在系统设计与选型时，需要做全面的考量。来源：量财经区块链学堂