精华内容
下载资源
问答
  • 淘宝OceanBase系统负载均衡案例

    千次阅读 2013-03-03 21:53:17
    Heroku因“随机调度+Rails单线程处理导致延迟增加的负载均衡失败”的案例之后,我们在思考:在负载均衡测试时发现问题并妥善解决的成功经验有没有?于是,挖掘出“淘宝在双十一压测OB时发现存在严重的随机访问导致...
    Heroku因“随机调度+Rails单线程处理导致延迟增加的负载均衡失败”的案例之后,我们在思考:在负载均衡测试时发现问题并妥善解决的成功经验有没有?于是,挖掘出“淘宝在双十一压测OB时发现存在严重的随机访问导致负载不均问题,并通过加权算法妥善解决”的成功案例,也就是本文。

    编者按:

    在CSDN云计算频道日前所做的文章《响应高达6秒 用户揭露Heroku私自修改路由造成高支出》中,网友们认为这是“因随机调度+Rails的单线程处理导致延迟增加的负载均衡失败的案例”。但在负载均衡测试时就能发现问题并妥善解决的成功经验有没有?在随后的微博中,支付宝的@Leverly评论:“去年双11前的压测OB就发现了存在严重的随机访问导致负载不均问题,还好通过加权算法很好的解决了。” 引发了我们的关注,于是有了本文。重点是淘宝在“双十一”背后,OceanBase分布式系统负载均衡的经验分享。

    以下为正文:

    云计算所具备的低成本、高性能、高可用性、高可扩展性等特点与互联网应用日益面临的挑战不谋而合,成为近年来互联网领域的热门话题。作为一名技术人员不难理解在云计算的底层架构中,分布式存储是不可或缺的重要组成部分。国外知名的互联网公司如Google、Amazon、Facebook、Microsoft、Yahoo等都推出了各自的分布式存储系统,在国内OceanBase是淘宝自主研发的一个支持海量数据的高性能分布式数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务[1]。

    在分布式系统中存在着著名的“短板理论”[2],一个集群如果出现了负载不均衡问题,那么负载最大的机器往往将成为影响系统整体表现的瓶颈和短板。为了避免这种情况的发生,需要动态负载均衡机制,以达到实时的最大化资源利用率,从而提升系统整体的吞吐

    本文将结合OceanBase的实际应用和大家分享一个去年淘宝双十一前期的准备工作中遇到负载均衡相关案例,抛砖引玉,期望对大家的工作有所启发。

    OceanBase架构介绍

    OceanBase是一个具有自治功能的分布式存储系统,由中心节点RootServer、静态数据节点ChunkServer、动态数据节点UpdateServer以及数据合并节点MergeServer四个Server构成[1],如图1所示。


    图1 OceanBase 架构图

    • Tablet:分片数据,最基本的存储单元,一般会存储多份,一个Table由多个tablet构成;
    • RootServer:负责集群机器的管理、Tablet定位、数据负载均衡、Schema等元数据管理等。
    • UpdateServer:负责存储动态更新数据,存储介质为内存和SSD,对外提供写服务;
    • ChunkServer:负责存储静态Tablet数据,存储介质为普通磁盘或者SSD。
    • MergeServer:负责对查询中涉及多个Tablet数据进行合并,对外提供读服务;

    在一个集群中,Tablet的多个副本分别存储在不同的ChunkServer,每个ChunkServer负责一部分Tablet分片数据,MergeServer和ChunkServer一般会一起部署。

    双十一前期准备

    对于淘宝的大部分应用而言,“双十一”就是一年一度的一次线上压测。伴随流量不断刷新着历史新高,对每个系统的可扩展性提出了很大的挑战。为了迎战双十一各产品线对有可能成为瓶颈部分的流量进行预估和扩容成为刻不容缓的任务。在本文要分享的案例中,应用方根据历史数据预估读请求的访问峰值为7w QPS,约为平时的5-6倍,合计每天支持56亿次的读请求。当时OceanBase集群部署规模是36台服务器,存储总数据量为200亿行记录,每天支持24亿次的读请求。

    当前集群的读取性能远不能满足需求,我们首先进行了一次扩容,上线了10台Chunkserver/Mergeserver服务器。由于OceanBase本身具有比较强的可扩展性,为集群加机器是一件非常简单的操作。中心节点Rootserver在新机器注册上线后,会启动Rebalance功能以Tablet为单位对静态数据进行数据迁移,见下图的示意,最终达到所有ChunkServer上数据分片的均衡分布。 

    表 1. 某Table的Tablet列表


    图2.1 Tablet在三台ChunkServer上的分布


    图2.2加入一台机器Tablet迁移后的分布

    扩容完成后引入线上流量回放机制进行压力测试,以验证当前集群的性能是否可以满足应用的双十一需求。我们使用了10台服务器共2000-4000个线程并发回放线上读流量对集群进行压测,很快发现集群整体的QPS在达到4万左右后,压测客户端出现大量超时现象,平均响应延迟已经超过阈值100ms,即使不断调整压力,系统的整体QPS也没有任何增大。此时观察整个集群机器的负载状态发现只有极个别服务器的负载超高,是其他机器的4倍左右,其他机器基本处于空闲状态,CPU、网络、磁盘IO都凸现了严重的不均衡问题

    负载不均衡导致了整体的吞吐取决于负载最高的那台Server,这正是前文提到的典型 “短板理论”问题。

    负载不均问题跟踪

    客户端连接到OceanBase之后一次读请求的读流程如下图所示:


    图3 客户端到OceanBase的读流程图

    1. Client 从RootServer获取到MergeServer 列表;
    2. Client将请求发送到某一台MergeServer;
    3. MergeServer从RootServer获取请求对应的ChunkServer位置信息;
    4. MergeServer将请求按照Tablet拆分成多个子请求发送到对应的ChunkServer;
    5. ChunkServer向UpdateServer请求最新的动态数据,与静态数据进行合并;
    6. MergeServer合并所有子请求的数据,返回给Client;

    OceanBase的读请求流程看起来如此复杂,实际上第1步和第3步中Client与RootServer以及MergeServer与RootServer的两次交互会利用缓存机制来避免,即提高了效率,同时也极大降低了RootServer的负载。

    分析以上的流程可知,在第2步客户端选择MergeServer时如果调度不均衡会导致某台MergeServer机器过载;在第4步MergeServer把子请求发送到数据所在的ChunkServer时,由于每个tablet会有多个副本,选择副本的策略如果不均衡也会造成ChunkServer机器过载。由于集群部署会在同一台机器会同时启动ChunkServer和MergeServer,无法简单区分过载的模块。通过查看OceanBase内部各模块的提供的监控信息比如QPS、Cache命中率、磁盘IO数量等,发现负载不均问题是由第二个调度问题引发,即MergeServer对ChunkServer的访问出现了不均衡导致了部分ChunkServer的过载。

    ChunkServer是存储静态Tablet分片数据的节点,分析其负载不均的原因包含如下可能:

    1. 数据不均衡: ChunkServer上数据大小的分布是不均衡的,比如某些节点因为存储Tablet分片数据量多少的差异性而造成的不均衡;
    2. 流量不均衡:数据即使是基本均衡的情况下,仍然会因为某些节点存在数据热点等原因而造成流量是不均衡的。

    通过对RootServer管理的所有tablet数据分片所在位置信息Metadata进行统计,我们发现各个ChunkServer上的tablet数据量差异不大,这同时也说明扩容加入新的Server之后,集群的Rebalance是有效的(后来我们在其他应用的集群也发现了存在数据不均衡问题,本文暂不解释)。

    尽管排除了数据不均衡问题,流量不均衡又存在如下的几种可能性:

    1. 存在访问热点:比如热销的商品,这些热点数据会导致ChunkServer成为访问热点,造成了负载不均;
    2. 请求差异性较大:系统负载和处理请求所耗费的CPU\Memory\磁盘IO资源成正比,而资源的耗费一般又和处理的数据量是成正比的,即可能是因为存在某些大用户而导致没有数据访问热点的情况下,负载仍然是不均衡的。

    经过如上的分析至少已经确定ChunkServer流量不均衡问题和步骤4紧密相关的,而目前所采用的tablet副本选择的策略是随机法。一般而言随机化的负载均衡策略简单、高效、无状态,结合业务场景的特点进行分析,热点数据所占的比例并不会太高,把ChunkServer上的Tablet按照访问次数进行统计也发现并没有超乎想象的“大热点”,基本服从正太分布

    可见热点Tablet虽访问频率稍高对负载的贡献率相对较大,但是热点tablet的占比很低,相反所有非热点tablet对负载的贡献率总和还是很高的,这种情况就好比“长尾效应”[3]。

    负载均衡算法设计

    如果把热点ChunkServer上非热点Tablet的访问调度到其他Server,是可以缓解流量不均问题的,因此我们设计了新的负载均衡算法为以实时统计的ChunkServer上所有tablet的访问次数为Ticket,每次对Tablet的读请求会选择副本中得票率最低的ChunkServer。

    同时考虑到流量不均衡的第二个原因是请求的差异较大问题,ChunkServer对外提供的接口分为Get和Scan两种,Scan是扫描一个范围的所有行数据,Get是获取指定一行数据,因此两种访问方式的次数需要划分赋予不同的权重(α,β)参与最终Ticket的运算:


    除此之外,简单的区分两种访问模式还是远远不够的,不同的Scan占用的资源也是存在较大差异的,引入平均响应时间(avg_time)这个重要因素也是十分必要的:


    负载均衡算法要求具有自适应性和强的实时性,一方面新的访问要实时累积参与下次的负载均衡的调度,另一方面历史权重数据则需要根据统计周期进行非线性的衰减(y 衰减因子),减少对实时性的影响:


    采用新的算法后,很好的缓解了负载不均衡的问题,整体负载提升了1倍,整体QPS吞吐提升到了8w。

    小结

    负载均衡问题是老生常谈的问题,解决不好就会出现“短板效应”,更甚至引发分布式系统中的连锁反应即“雪崩”,从而演化成系统的灾难。负载均衡的算法也层出不穷,有的出于成本最优,有的是为了最小延迟,有的则是最大化系统吞吐,目的不同算法自然各异,不存在包治百病的良方,并不是越复杂的算法越有效[4],要综合考虑算法所需数据获取的Overhead,更多的是遵循“简单实用”的法则,根据业务场景进行分析和尝试。

    正是这种灵活性的策略,对我们的系统设计提出了新的需求,要有一定的机制来监控和验证问题:比如可以实时获取系统运行的各种内部状态和数据,允许选择不同负载均衡算法进行试验等。

    Update1:看到楼下网友专业方面的提问,@Leverly 已经进行了回复。有更多交流,不妨直接讨论。共享:)!

    3月2日Update2:图2.2已更换(原图右边显示不完全,应为“A,E,G,H,I")。

    参考文献

    1.OceanBase : http://oceanbase.taobao.org/

    2.Buckets effect: http://www.baike.com/wiki/%E6%9C%A8%E6%A1%B6%E7%90%86%E8%AE%BA

    3.Long Tail: http://en.wikipedia.org/wiki/The_long_tail

    4.http://www.cs.usask.ca/faculty/eager/loadsharing.pdf

    欢迎 @CSDN云计算微博参与讨论,了解更多云信息。

    展开全文
  • 这段时间一直在忙工作,已经有一个月没更新博客了。从现在开始,我将继续讨论Microsoft NLayerApp案例,希望各位爱好Microsoft NLayerApp案例、架构设计以及...所谓“复杂的业务系统应用程序”是指这样一类业务系统

    这段时间一直在忙工作,已经有一个月没更新博客了。从现在开始,我将继续讨论Microsoft NLayerApp案例,希望各位爱好Microsoft NLayerApp案例、架构设计以及DDD的朋友们能够继续关注。

    从架构上看,Microsoft NLayerApp对“复杂的业务系统应用程序”这样一种应用程序的架构设计提供了一系列的设计准则。所谓“复杂的业务系统应用程序”是指这样一类业务系统应用程序,这类应用程序具有相对较长的生命周期,在其生命周期中,将发生一些可预期的“革命性变更”(比如,所使用的技术/框架的版本升级甚至替换),因此后期维护会变得非常重要。于是,针对这种类型应用程序的设计,我们应该做到,当“革命性变更”来临时,将这种变更对应用程序其他部分的影响减少到最小程度,例如,我们要确保基于基础结构层的设施变更不会影响到其上层的各个部分。更确切地说,应用程序的领域模型部分应该只关注领域本身,变更应用程序的其它部分,不会影响到领域模型。在“复杂的业务系统应用程序”中,业务规则的行为方式(也就是“领域逻辑”)将会是经常变化的,因此,使其具有很好的可修改性和可测试性将会非常重要。要达到这样的效果,就需要实现领域模型部分与系统其它部分的解耦。作为领域驱动设计(DDD)的一部分的面向领域的多层分布式架构,关注的就是这样的问题。

    还是那句话,DDD不仅仅只是架构+模式。DDD是开发应用程序的一种方式,是团队在项目中工作的一种方式。根据DDD,项目团队需要以一种特殊的方式进行合作,应该能够直接与领域专家(通常就是客户)进行沟通。整个团队需要使用“通用语言”这一能够被所有人接受的语言,等等。然而,本案例没有包含这些内容,因为这是一种“过程”,一种ALM。所以,如果你真的希望100%实践DDD,你需要阅读Eric Evans写的《领域驱动设计-软件核心复杂性应对之道》一书,或者其它的一些讨论DDD过程的书籍,这些书籍会对DDD过程、项目和团队做比较详细的介绍,而不仅仅是谈论架构和模式。架构和模式仅仅是DDD中很小的一部分,而我们在这里展示的就恰好是这一部分。总之,我们必须强调,DDD不仅仅是架构+模式。

    在社区中,不少朋友觉得DDD风格的架构模式(经典的也好,CQRS也好)在实际项目的应用与推广中存在一定的问题,比如从老系统向新系统的过渡过程中,DDD风格架构很难找到切入点,再比如,基于CQRS架构的应用系统难度较大,复杂度高,普通的开发人员很难在短期内掌握相关知识,一旦出现团队人员流动,新加入的团队成员将在短期内无法胜任开发职位,对项目本身造成影响。不少朋友都在关注领域驱动设计以及CQRS架构,或许也从我的博客系列文章中受到了启发,于是希望能够在实际工作和项目中能够应用DDD的理念和技术进行开发,但却在应用的过程中遇到了重重阻碍,最后不得不放弃。对于我来说,我专注于.NET技术以及DDD,我只不过是一直在探索某一种类型的应用程序的架构方式,并试图将这种设计思想和架构风格展示给大家。注意这里“某一种”的措辞,DDD风格架构并不适用于所有的实际项目和应用系统,就软件团队本身而言,推行DDD的开发过程也非一朝一夕之事。架构师们需要对项目实际情况进行分析,这包括应用系统的架构本身,以及团队建设的各方面因素(比如,团队是否能够首先引入Agile开发过程,进而去适应DDD的开发模式,等等)。DDD过程以及DDD风格的架构模式只不过是摆在您面前的又一个选项。接下来的介绍或许能够帮助您更准确地做出抉择。

    不选用面向领域的多层分布式架构(DDD风格架构)的理由

    如果应用程序相对简单,而且在其生命周期的整个过程中,基础结构所使用的技术和框架以及业务逻辑层等各方面都不会有太大的变更,那么你就不需要选用基于DDD的多层分布式架构。你可以选择一些RAD(Rapid Application Development)的技术,比如WCF RIA Services或者Visual Studio Lightswitch等,它能使得开发简单的应用程序变得非常高效。这些简单的应用程序关注的是Time to Market(TTM),而对于合理的结构、分层解耦等概念却并不是很关注。通常,我们把这样的应用程序成为“数据驱动的应用程序”。

    选用面向领域的多层分布式架构(DDD风格架构)的理由

    如果你希望你的应用程序在较长的一段时间内都能够适应业务逻辑的变化,那么,强烈建议你选用面向领域的多层分布式架构。在这种情况下,领域模型将降低由业务逻辑变化而引起的高额代价,组件之间、层与层之间低耦合的结构,使得在每次出现业务逻辑变更的时候,你都能够将领域模型隔离出来进行调整和测试,而不需要更改应用程序的其它部分,这样有效地降低了需求变更带来的开发风险,并节省了项目开支。

    分布式DDD(Distributed DDD, DDDD)

    这个概念是Microsoft NLayerApp在其Guide Book中提及的,就是在DDD风格架构的基础上,将分布式的特性包含进来。在Eric Evans的《领域驱动设计-软件核心复杂性应对之道》一书中,他并没有提及太多的有关分布式技术的内容(比如Web Service技术等),主要也是因为针对DDD的讨论本身也是立足于Domain的。然而,在实际的应用程序实现和部署过程中,分布式技术是必不可少的。事实上,Microsoft NLayerApp是面向分布式DDD的,在实现“分布式”的过程中,采用了微软特有的技术,比如WCF等。DDDD也使得应用程序能够更好地适应分布式场景,甚至可以使应用程序更方便地部署到云计算的环境中。

    面向领域的多层架构

    早在EntityFramework之领域驱动设计实践【分层架构】一文中,我就对基于DDD风格的分层架构做了介绍。现在回顾一下,DDD风格架构主要分为四层:表现层、应用层、领域层和基础结构层:

    现在让我们来对比一下Microsoft NLayerApp的架构分层方式。在Microsoft NLayerApp的Guide Book中提供了下面的分层架构图,其分层方式在大体上与上文所述基本相同,同时,下图还对各个层的内部做了细化描述,便于读者能够更清楚地了解到每个层所包含的组件及其之间的协作方式。

    image

    了解整个项目的整体架构对于理解整个系统的运作方式有着很大的帮助。下面,我将对上述架构中的每个层进行介绍,让我们看看这些层都包含了哪些组件,以及这些组件是如何协作的。

    • 表现层(Presentation):该层的主要职责是通过用户界面向用户展示必要的数据信息,同时接收用户的反馈。该层中的组件主要实现了与图形界面、用户操作捕获、数据转发等用户界面功能。建议根据项目的实际情况,选用相关的模式(比如MVC、MVP或者MVVM等)将这些组件细分到更小的层中。
    • 分布式服务层(Distributed Service Layer):当应用程序以服务提供商(Service Provider)的方式向其它远程应用程序提供业务功能时,或者应用程序的客户端本身是被部署在另一个远程位置时,其业务逻辑就必须通过分布式服务层向外界发布。分布式服务层(通常被实现为Web Service)可以根据可配置的通信通道与数据消息格式,为应用程序提供远程访问的功能。需要注意的是,分布式服务层中不应该包含任何业务逻辑的实现。
    • 应用层(Application Layer):应用层用于协调领域模型与其它应用组件的工作,以完成一个特定的、明确的系统任务。这种协调可以包括:事务调度、UoW(Unit Of Work,PoEAA)的执行,以及调用一些系统必须的处理任务等。应用层同时还可以包括应用程序的优化、数据的转发和格式转换等工作,当然,我们将这些工作统称为“任务调度”,至于每个任务的核心部分,应用层都会将其转发到下层去处理。应用层通常会被看做是一种“业务层外观(Business Facade)”,但它却不仅仅是转发领域模型层的处理请求/反馈那么简单。它通常可以包含下面这些内容:
      • 通过仓储契约(Repository Contract)来访问持久层机制,以读取或保存领域对象。注意这里访问的是仓储契约,而并非仓储的具体实现。仓储的具体实现是基础结构层的内容
      • 对来自于不同领域对象的数据进行组织和整理,以便能够让分布式服务层更有效地传递这些数据。通常,我们会将数据整理在数据传输对象(Data Transfer Object,PoEAA)中,例如WCF的Data Contracts
      • 管理和维护应用程序的状态(而不是领域模型中领域对象的状态)
      • 协调领域对象之间、领域模型与基础结构层组件之间的协作关系。比如在银行转账系统中,资金从一个账户转移到另一个账户,首先需要通过仓储读取“账户”领域对象,然后在领域对象上进行转账操作(可以是“账户”本身的行为,也可以是,按Evans的举例,使用领域服务(Domain Service))。或许在完成转账后,无论成功与否,都需要向外发送电子邮件,这就需要基础结构层的电子邮件组件协作完成
      • 应用服务(Application Services):首先需要注意,DDD中提到的服务与平时所说的Web Service等并不是一个概念,它可以存在于应用层、领域模型层甚至基础结构层。DDD中Service所表述的概念,其实是“无法归结到任何一个对象”的一系列操作的集合,因此,Service通常是在协调不同对象之间的工作。应用服务也是如此,它会对其它下层组件(比如领域模型层与基础结构层)进行协调
      • 业务工作流(Business Workflow):业务工作流并非必须的,对于某些由特定步骤组成的业务过程,引入业务工作流会使问题变得简单
    • 领域模型层(Domain Model Layer):该层的主要职责是展现业务/领域逻辑、业务处理状态,以及实现业务规则,它同时也包含了领域对象的状态信息。这一层是整个应用程序的核心部分,它可以包含下面这些概念和内容:
      • 实体(Entities)
      • 值对象(Value Objects)
      • 领域服务(Domain Services)
      • 仓储契约/接口(Repository Contracts/Interfaces)
      • 聚合及其工厂(Aggregates and Factories)
      • 聚合根(Aggregate Roots)
      • 规约对象(Specifications)
    • 基础结构层(数据持久化部分)(Data Persistence Infrastructure Layer):该层为应用程序的数据存取提供服务,它可以是应用程序本身的持久化机制,也可以是外部系统提供的数据访问的Web Service等。根据分层架构的设计原则,该层应该以“低耦合”的方式向上层提供数据持久化服务。因此,该层可以包含如下这些内容:
      • 仓储的具体实现:从概念上看,“仓储”意味着对一组相同类型对象的集中管理,就好像是存取同一类型对象的仓库。然而在实践中,仓储主要用来在特定的持久化机制/技术上执行对象的读取和保存操作。这些持久化机制/技术可以是Entity Framework、NHibernate或者是针对某一数据库引擎的ADO.NET组件。为了简单起见,我们将数据访问操作集中到仓储中,并针对不同的持久化机制/技术开发一个仓储的具体实现,这将会对应用程序的维护和部署带来便捷。在设计仓储时,通常的做法是,首先对领域模型划分聚合并区分聚合根,然后针对每一个聚合设计一个仓储,仓储通过聚合根对聚合进行管理。在领域模型层中,各组件是通过仓储契约(接口)来实现对仓储的访问的,这样做就使得领域模型层无需了解任何仓储的具体实现和持久化细节(Persistence Ignorance),读者可以参考我前面写的EntityFramework之领域驱动设计实践【仓储基本实现】一文。此外,我们通常所讲的“数据访问对象(Data Access Object)”并不是仓储,首先,仓储通过聚合根,负责整个聚合的读取和存储,它是一个领域概念,而数据访问对象则是对单个对象(更确切地说应该是单个数据结构)直接进行数据库操作;其次,操作方式也不同,仓储会在提交前先对内存中的对象进行标记,最后的一次提交过程(Unit Of Work,PoEAA)则是在上层组件(比如在应用层)中完成的
      • 层超类型(Layer Supertype,PoEAA):通常,在实现某层的特定功能时,我们会将一系列对象的公共逻辑提取出来,然后将这些逻辑置于一个抽象类型中,同时使得其它类型都继承于该抽象类型以避免逻辑重复。这样的抽象类型被称为层超类型。大多数数据访问任务可以使用层超类型以简化开发,减少代码维护成本。例如,在实现面向ADO.NET的数据库访问组件时,我们可以在层超类型中使用DbConnection、DbCommand等对象实现公用逻辑,然后在子类中继承这些逻辑并提供具体的SqlConnection、SqlCommand或者OleDbConnection、OleDbCommand实例
      • 数据模型(Data Model):如果使用ORM来实现仓储,那么通常情况下ORM都会使用一个数据模型(比如Entity Framework)来实现需要的功能,这样的数据模型有点像实体模型,但它与数据传输对象一样,跟领域模型层的实体模型是完全不同的。数据模型甚至是一种可视化的图形描述,由专门的可视化设计工具负责维护
      • 远程/外部服务代理:当采用外部系统来实现数据持久化机制时,远程/外部服务代理负责连接外部系统并转发数据操作请求及响应信息
    • 基础结构层(Cross-Cutting):该层提供了能被其它各层访问的通用技术框架,比如异常捕获与处理、日志、认证、授权、验证、跟踪、监视、缓存等等。这些操作通常会横向散布在应用程序的各个层面,我们平时讨论的面向方面编程(AOP)关注的就是如何在不影响对象本身处理逻辑的基础上来实现这些横切的却又必不可少的功能点。在实践中,通过使用一些流行的Interception框架(例如Microsoft Unity、Castle DynamicProxy等)可以帮助我们方便地实现AOP

    总结

    本文以文字描述为主,结合Microsoft NLayerApp项目,更详细地对DDD及其分层架构做了介绍,文中也引入了不少来自于Martin Fowler《企业应用架构模式(PoEAA)》一书中所介绍的概念与模式名称,帮助读者朋友更好地理解DDD分层架构中各层的主要职责。与Microsoft NLayerApp案例理论与实践【多层架构与应用系统设计原则】一文一起,通过这两篇文章的学习,我们已经对应用程序的设计与架构,以及DDD风格架构及其分层有了一定的了解。从下章节开始,我们会把本文所描述的分层架构与Microsoft NLayerApp项目结合起来,进一步学习Microsoft NLayerApp项目的具体实现。

    展开全文
  • 淘宝:OceanBase分布式系统负载均衡案例分享 摘要:Heroku的问题让我们意识到,在负载均衡测试时发现问题并妥善解决的成功经验有没有?于是,挖掘出“淘宝在双十一压测OB时发现存在严重的随机访问导致负载不均...

    淘宝:OceanBase分布式系统负载均衡案例分享

    摘要:Heroku的问题让我们意识到,在负载均衡测试时发现问题并妥善解决的成功经验有没有?于是,挖掘出“淘宝在双十一压测OB时发现存在严重的随机访问导致负载不均问题,并通过加权算法妥善解决”的成功案例,也就是本文。

    编者按:在CSDN云计算频道日前所做的文章《响应高达6秒 用户揭露Heroku私自修改路由造成高支出》中,网友们认为这是“因随机调度+Rails的单线程处理导致延迟增加的负载均衡失败的案例”。但在负载均衡测试时就能发现问题并妥善解决的成功经验有没有?在随后的微博中,支付宝的@Leverly评论:“去年双11前的压测OB就发现了存在严重的随机访问导致负载不均问题,还好通过加权算法很好的解决了。” 引发了我们的关注,于是有了本文。重点是淘宝在“双十一”背后,OceanBase分布式系统负载均衡的经验分享。

    以下为正文:

    云计算所具备的低成本、高性能、高可用性、高可扩展性等特点与互联网应用日益面临的挑战不谋而合,成为近年来互联网领域的热门话题。作为一名技术人员不难理解在云计算的底层架构中,分布式存储是不可或缺的重要组成部分。国外知名的互联网公司如Google、Amazon、Facebook、Microsoft、Yahoo等都推出了各自的分布式存储系统,在国内OceanBase是淘宝自主研发的一个支持海量数据的高性能分布式数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务[1]。

    在分布式系统中存在着著名的“短板理论”[2],一个集群如果出现了负载不均衡问题,那么负载最大的机器往往将成为影响系统整体表现的瓶颈和短板。为了避免这种情况的发生,需要动态负载均衡机制,以达到实时的最大化资源利用率,从而提升系统整体的吞吐

    本文将结合OceanBase的实际应用和大家分享一个去年淘宝双十一前期的准备工作中遇到负载均衡相关案例,抛砖引玉,期望对大家的工作有所启发。

    OceanBase架构介绍

    OceanBase是一个具有自治功能的分布式存储系统,由中心节点RootServer、静态数据节点ChunkServer、动态数据节点UpdateServer以及数据合并节点MergeServer四个Server构成[1],如图1所示。


    图1 OceanBase 架构图

    • Tablet:分片数据,最基本的存储单元,一般会存储多份,一个Table由多个tablet构成;
    • RootServer:负责集群机器的管理、Tablet定位、数据负载均衡、Schema等元数据管理等。
    • UpdateServer:负责存储动态更新数据,存储介质为内存和SSD,对外提供写服务;
    • ChunkServer:负责存储静态Tablet数据,存储介质为普通磁盘或者SSD。
    • MergeServer:负责对查询中涉及多个Tablet数据进行合并,对外提供读服务;

    在一个集群中,Tablet的多个副本分别存储在不同的ChunkServer,每个ChunkServer负责一部分Tablet分片数据,MergeServer和ChunkServer一般会一起部署。

    双十一前期准备

    对于淘宝的大部分应用而言,“双十一”就是一年一度的一次线上压测。伴随流量不断刷新着历史新高,对每个系统的可扩展性提出了很大的挑战。为了迎战双十一各产品线对有可能成为瓶颈部分的流量进行预估和扩容成为刻不容缓的任务。在本文要分享的案例中,应用方根据历史数据预估读请求的访问峰值为7w QPS,约为平时的5-6倍,合计每天支持56亿次的读请求。当时OceanBase集群部署规模是36台服务器,存储总数据量为200亿行记录,每天支持24亿次的读请求。

    当前集群的读取性能远不能满足需求,我们首先进行了一次扩容,上线了10台Chunkserver/Mergeserver服务器。由于OceanBase本身具有比较强的可扩展性,为集群加机器是一件非常简单的操作。中心节点Rootserver在新机器注册上线后,会启动Rebalance功能以Tablet为单位对静态数据进行数据迁移,见下图的示意,最终达到所有ChunkServer上数据分片的均衡分布。 

    表 1. 某Table的Tablet列表


    图2.1 Tablet在三台ChunkServer上的分布


    图2.2加入一台机器Tablet迁移后的分布

    扩容完成后引入线上流量回放机制进行压力测试,以验证当前集群的性能是否可以满足应用的双十一需求。我们使用了10台服务器共2000-4000个线程并发回放线上读流量对集群进行压测,很快发现集群整体的QPS在达到4万左右后,压测客户端出现大量超时现象,平均响应延迟已经超过阈值100ms,即使不断调整压力,系统的整体QPS也没有任何增大。此时观察整个集群机器的负载状态发现只有极个别服务器的负载超高,是其他机器的4倍左右,其他机器基本处于空闲状态,CPU、网络、磁盘IO都凸现了严重的不均衡问题

    负载不均衡导致了整体的吞吐取决于负载最高的那台Server,这正是前文提到的典型 “短板理论”问题。

    负载不均问题跟踪

    客户端连接到OceanBase之后一次读请求的读流程如下图所示:


    图3 客户端到OceanBase的读流程图

    1. Client 从RootServer获取到MergeServer 列表;
    2. Client将请求发送到某一台MergeServer;
    3. MergeServer从RootServer获取请求对应的ChunkServer位置信息;
    4. MergeServer将请求按照Tablet拆分成多个子请求发送到对应的ChunkServer;
    5. ChunkServer向UpdateServer请求最新的动态数据,与静态数据进行合并;
    6. MergeServer合并所有子请求的数据,返回给Client;

    OceanBase的读请求流程看起来如此复杂,实际上第1步和第3步中Client与RootServer以及MergeServer与RootServer的两次交互会利用缓存机制来避免,即提高了效率,同时也极大降低了RootServer的负载。

    分析以上的流程可知,在第2步客户端选择MergeServer时如果调度不均衡会导致某台MergeServer机器过载;在第4步MergeServer把子请求发送到数据所在的ChunkServer时,由于每个tablet会有多个副本,选择副本的策略如果不均衡也会造成ChunkServer机器过载。由于集群部署会在同一台机器会同时启动ChunkServer和MergeServer,无法简单区分过载的模块。通过查看OceanBase内部各模块的提供的监控信息比如QPS、Cache命中率、磁盘IO数量等,发现负载不均问题是由第二个调度问题引发,即MergeServer对ChunkServer的访问出现了不均衡导致了部分ChunkServer的过载。

    ChunkServer是存储静态Tablet分片数据的节点,分析其负载不均的原因包含如下可能:

    1. 数据不均衡: ChunkServer上数据大小的分布是不均衡的,比如某些节点因为存储Tablet分片数据量多少的差异性而造成的不均衡;
    2. 流量不均衡:数据即使是基本均衡的情况下,仍然会因为某些节点存在数据热点等原因而造成流量是不均衡的。

    通过对RootServer管理的所有tablet数据分片所在位置信息Metadata进行统计,我们发现各个ChunkServer上的tablet数据量差异不大,这同时也说明扩容加入新的Server之后,集群的Rebalance是有效的(后来我们在其他应用的集群也发现了存在数据不均衡问题,本文暂不解释)。

    尽管排除了数据不均衡问题,流量不均衡又存在如下的几种可能性:

    1. 存在访问热点:比如热销的商品,这些热点数据会导致ChunkServer成为访问热点,造成了负载不均;
    2. 请求差异性较大:系统负载和处理请求所耗费的CPU\Memory\磁盘IO资源成正比,而资源的耗费一般又和处理的数据量是成正比的,即可能是因为存在某些大用户而导致没有数据访问热点的情况下,负载仍然是不均衡的。

    经过如上的分析至少已经确定ChunkServer流量不均衡问题和步骤4紧密相关的,而目前所采用的tablet副本选择的策略是随机法。一般而言随机化的负载均衡策略简单、高效、无状态,结合业务场景的特点进行分析,热点数据所占的比例并不会太高,把ChunkServer上的Tablet按照访问次数进行统计也发现并没有超乎想象的“大热点”,基本服从正太分布

    可见热点Tablet虽访问频率稍高对负载的贡献率相对较大,但是热点tablet的占比很低,相反所有非热点tablet对负载的贡献率总和还是很高的,这种情况就好比“长尾效应”[3]。

    负载均衡算法设计

    如果把热点ChunkServer上非热点Tablet的访问调度到其他Server,是可以缓解流量不均问题的,因此我们设计了新的负载均衡算法为以实时统计的ChunkServer上所有tablet的访问次数为Ticket,每次对Tablet的读请求会选择副本中得票率最低的ChunkServer。

    同时考虑到流量不均衡的第二个原因是请求的差异较大问题,ChunkServer对外提供的接口分为Get和Scan两种,Scan是扫描一个范围的所有行数据,Get是获取指定一行数据,因此两种访问方式的次数需要划分赋予不同的权重(α,β)参与最终Ticket的运算:


    除此之外,简单的区分两种访问模式还是远远不够的,不同的Scan占用的资源也是存在较大差异的,引入平均响应时间(avg_time)这个重要因素也是十分必要的:


    负载均衡算法要求具有自适应性和强的实时性,一方面新的访问要实时累积参与下次的负载均衡的调度,另一方面历史权重数据则需要根据统计周期进行非线性的衰减(y 衰减因子),减少对实时性的影响:


    采用新的算法后,很好的缓解了负载不均衡的问题,整体负载提升了1倍,整体QPS吞吐提升到了8w。

    小结

    负载均衡问题是老生常谈的问题,解决不好就会出现“短板效应”,更甚至引发分布式系统中的连锁反应即“雪崩”,从而演化成系统的灾难。负载均衡的算法也层出不穷,有的出于成本最优,有的是为了最小延迟,有的则是最大化系统吞吐,目的不同算法自然各异,不存在包治百病的良方,并不是越复杂的算法越有效[4],要综合考虑算法所需数据获取的Overhead,更多的是遵循“简单实用”的法则,根据业务场景进行分析和尝试。

    正是这种灵活性的策略,对我们的系统设计提出了新的需求,要有一定的机制来监控和验证问题:比如可以实时获取系统运行的各种内部状态和数据,允许选择不同负载均衡算法进行试验等。

    Update1:看到楼下网友专业方面的提问,@Leverly 已经进行了回复。有更多交流,不妨直接讨论。共享:)!

    3月2日Update2:图2.2已更换(原图右边显示不完全,应为“A,E,G,H,I")。

    参考文献

    1.OceanBase : http://oceanbase.taobao.org/

    2.Buckets effect:http://www.baike.com/wiki/%E6%9C%A8%E6%A1%B6%E7%90%86%E8%AE%BA

    3.Long Tail: http://en.wikipedia.org/wiki/The_long_tail

    4.http://www.cs.usask.ca/faculty/eager/loadsharing.pdf

    欢迎 @CSDN云计算微博参与讨论,了解更多云信息。

    本文为CSDN原创内容,未经允许不得转载。如需转载请联系 market@csdn.net 

    展开全文
  • 复杂性研究从20世纪末叶兴起,目前在国内外已成为许多学科领域内研究的前沿和热点。它涉及又一个新型的跨学科的方法论。虽然人们对“复杂性”概念还缺乏严格一致的定义,但大家都意...
        

    复杂性研究从20世纪末叶兴起,目前在国内外已成为许多学科领域内研究的前沿和热点。它涉及又一个新型的跨学科的方法论。虽然人们对“复杂性”概念还缺乏严格一致的定义,但大家都意识到复杂性方法是为弥补长期占统治地位的经典科学的简化方法的不足而产生的。下面我结合分析国际上复杂性研究的主流的三个阶段或流派的学说的内容来探讨一下复杂性方法的基本内涵。

    法国哲学家埃德加·莫兰是当代系统地提出复杂性方法的第一人,他追求在人类思想领域里实现一个关于“复杂性范式”的革命。他的复杂性方法主要是用“多样性统一”的概念模式来纠正经典科学的还原论的认识方法,用关于世界基本性质是有序性和无序性统一的观念来批判机械决定论,提出把认识对象加以背景化来反对在封闭系统中追求完满认识,主张整体和部分共同决定系统来修正传统系统观的单纯整体性原则,等等。莫兰提出复杂性思想的标志时间可以定在他发表《迷失的范式:人性研究》一书的1973年。1979年,比利时著名科学家普利高津首次提出了“复杂性科学”的概念。普利高津实质上是把复杂性科学作为经典科学的对立物和超越者提出来的。他说:“在经典物理学中,基本的过程被认为是决定论的和可逆的。”(普里戈金、斯唐热《从混沌到有序》,上海译文出版社,1987年,第42页)而今天,“物理科学正在从决定论的可逆过程走向随机的和不可逆的过程。”(同上书,第224页)普利高津紧紧抓住的核心问题就是经典物理学在它的静态的、简化的研究方式中从不考虑“时间”这个参量的作用和无视自然变化的“历史”性。他所提出的关于复杂性的理论就是不可逆过程的物理学的理论,主要是揭示物质进化机制的耗散结构理论。普利高津说这个理论研究了物理、化学中的“导致复杂过程的自组织现象”。因此我们可以认为普利高津所说的“复杂性”意味着不可逆的进化的物理过程所包含的那些现象的总体:在热力学分岔点出现的多种发展可能性和不确定性,动态有序结构的不断增长和多样化等等。1984年美国的圣菲研究所成立,它接过了“复杂性科学”的口号,由于它实力雄厚,现在被视为世界复杂性问题研究的中枢。圣菲研究所的学术领头人、诺贝尔物理奖获得者盖尔曼如此提及圣菲研究所的研究宗旨:“现代科学的一个重大挑战是沿着阶梯从基本粒子物理学和宇宙学到复杂系统领域,探索兼具简单性与复杂性、规律性与随机性、有序与无序的混合性事件。”(盖尔曼《夸克与美洲豹》,湖南科学技术出版社,1999年,第119页)圣菲研究所的研究对象是复杂适应系统,它提出“适应性造就复杂性”,表明它主要研究能够学习的系统在适应环境的过程中于自身中发生的结构和行为方式从简单到复杂的演变。复杂适应系统的共同特征是,它们能够通过处理信息从经验中提取有关客观世界的规律性的东西作为自己行为的参照,并通过实践活动中的反馈来改进对世界规律性的认识从而改善自己的行为方式。这反映了生物、社会等高级系统的能动的自组织的机制。

    有人因为复杂性理论研究复杂系统的问题,就认为它还是属于系统论范畴的一种方法。其实莫兰认为系统论超越了还原论,复杂性理论又超越了系统论,它们代表着科学方法论依次达到的三个梯级。贝塔朗菲在20世纪4 0年代提出的系统论思想从批判还原论出发,过分强调了整体性原则,以致忽略了系统构成要素的积极作用,提出系统通过“中心化”而形成一个“愈来愈统一”的“个体”(贝塔朗菲《一般系统论》,清华大学出版社,1987年,第66页)。与此相联,他主张越是功能强的系统必须越有序。但是现在圣菲研究所提出了“混沌的边缘”的原理,指出“复杂适应系统在有序与无序之间的一个中间状态运作得最好”(盖尔曼《夸克与美洲豹》,第364页)。复杂适应系统是一些多元的或多主体的系统,它们的大量的具有主动性的个体积极地相互竞争和合作,在没有中央指挥的情况下,通过彼此相互作用和相互适应也能形成整体的有序状态。圣菲研究所采取的研究思路是“多主体建模”,“非中心化思维”,由于它主要是从个体出发,采取自下而上的研究策略,所以又被称为“基于个体的思维范式”。举例来说,计划经济体现了自上而下的“中心控制的思维方式”,而市场经济则建立在“基于个体的思维范式”的基础上,商品生产者根据价值规律的指示相互作用也能自发地形成宏观经济秩序。由此观之, 贝塔朗菲式的系统只是一种简单系统,复杂性观在它的视域内对经典系统论加以改造才达致复杂系统论。复杂性理论把被经典科学的简化理性所排除的多样性、无序性、个体性因素引进科学的视野,借以研究能动系统的复杂的自组织问题。当然我们认为也应有某种宏观调控机制来控制市场经济的自流性,莫兰也提到生物组织和社会组织的“高度复杂性表现在它们同时是无中心的(也就是说以无政府的方式通过自发的相互作用运转)、多中心的(即拥有几个控制和组织的中心)和一中心的(即同时还有一个最高的决策中心)。”(莫兰《复杂思想:自觉的科学》,北京大学出版社, 2001年,第141页)


    展开全文
  • 10月27日,由子衿技术团队首席架构师白鳝(徐戟)老师在“DBA+南京群”进行了一次关于“从一个案例系统优化”的线上主题分享。小编特别整理出其中精华内容,供大家学习交流。 嘉宾简介 白鳝(徐戟),国内最早的...
  • 统计挖掘那些事(五)--(理论+案例)如何通俗地理解极大似然估计? 在上期,浩彬老撕给大家介绍了非线性回归模型,解决了在现实环境中,非线性形式的问题。但是进一步地,我们的因变量也并不总是数值型变量,有可能...
  • 2019年9月20日,经过为期一个多月的紧张测试,北京润科通用技术有限公司为中车某机车单位倾力打造的“机车运用数据智能诊断系统”正式上线运行,标志着润科通用在轨道交通智慧运维领域的又一案例成功落地。...
  • 摘要:Heroku因“随机调度+Rails单线程处理导致延迟增加的负载均衡失败”的案例之后,我们在思考:在负载均衡测试时发现问题并妥善解决的成功经验有没有?于是,挖掘出“淘宝在双十一压测OB时发现存在严重的随机访问...
  • 【年度案例】小米抢购限流峰值系统「大秒」架构解密 原创2015-12-04马利超高可用架构 编者按:高可用架构推出2015年度案例系列文章,分享在架构领域具有典型意义的年度案例,本文根据小米工程师马利超的分享记录...
  • AI,大数据,复杂系统 最精 40本大书单 原创 2017-10-30 Peter 混沌巡洋舰 如果这篇文的题目变成最全书单,那么这篇文会变得又臭又长,这个年代,关于人工智能和大数据的书,没有一万本也有一千本,而这里...
  • 原文链接:mp.weixin.qq.com 作者 | HCY崇远01 前言本文源自于前阵子连续更新的推荐系统系列,前段时间给朋友整理一个关于推荐系统相关的知识教学体系,...整个文章的结构逻辑,先从推荐系统的基础知识结构讲起,...
  • 6G 即第六代移动通信,6G 将在5G 的基础上,把陆地移动通信网扩展至天空,构建一个天地互联、陆海空一体、全空间覆盖的超宽带移动通信系统,包括卫星通信网络、无人机通信网络、陆地超密集网络、地下通信网络、海洋...
  • 操作系统系统概述——云计算

    千次阅读 2017-01-13 12:58:20
    摘要:系统地分析和总结云计算的研究现状,划分云计算体系架构为核心服务、服务管理、用户访问接口等3个层次。围绕低成本、高可靠、高可用、规模可伸缩性等研究目标,深入全面地介绍了云计算的关键技术及最新研究...
  • 电磁波传播的复杂性是需要深入研究的 从战术上避开雷达探测区域是理论可行的 本文为荷兰代尔夫特理工大学(作者:Joris Derksen)的硕士论文,共251页。 无线电探测和测距系统(雷达)是海军用于探测...
  •  遗传算法提供了一种求解复杂系统优化问题的通用框架。它不依赖于问题的具体领域,对问题的种类有很强的鲁棒性,所以广泛应用于很多学科。遗传算法的主要应用领域有:函数优化、组合优化、生产调度问题、自动控制、...
  • ML之RL:强化学习Reinforcement Learning的简介、应用、经典案例、学习资源之详细攻略 目录 强化学习的简介 0、强化学习相关论文 1、强化学习的常用算法 1.1、策略学习 1.2、Q-Learning 2、强化学习...
  • SLAM:SLAM(即时定位与地图构建)的简介、发展、案例应用之详细攻略 目录 SLAM的简介 SLAM的发展 SLAM的案例应用 1、AR/VR设备 2、室内机器人 3、无人车 SLAM的简介 SLAM (simultaneous ...
  • GlusterFS集群文件系统研究

    万次阅读 热门讨论 2011-03-28 21:01:00
    GlusterFS是Scale-Out存储解决方案Gluster的核心,它是一个开源的分布式文件系统,具有强大的横向扩展能力,通过扩展能够支持数PB存储容量和处理数千客户端。GlusterFS借助TCP/IP或InfiniBand RDMA网络将物理分布的...
  • 大型电商网站架构案例和技术架构【推荐】

    万次阅读 多人点赞 2018-05-17 10:14:24
    大型网站架构是一个系列文档,欢迎大家关注。本次分享主题:电商网站架构案例。...本次分享大纲电商案例的原因电商网站需求网站初级架构系统容量估算网站架构分析网站架构优化架构总结电商网站案...
  • 测试理论基础

    千次阅读 2019-11-19 19:20:49
    简介:在软件开发的几十年实践中,人们总结了很多软件开发模型用来描述和表示一个复杂的开发过程,如: 1.瀑布模型 2.快速原型模型 3.螺旋模型 软件测试与软件的开发有这紧密的联系,作为一名测试人员,应该充分理解...
  • 常见的各种人提出的理论

    千次阅读 2012-11-19 09:38:19
    1、威廉·大内的Z理论(1981)   Z理论( Theory Z)是由美国日裔学者威廉·大内(一译乌契,William Ouchi)在1981年出版的《Z理论》一书中提出来的,其研究的内容为人与企业、人与工作的关系。  威廉·...
  • 大家好,我是小林。 昨天有位关注我一年的读者找我,他去年关注我公众后,开始...这里先给大家分享些计算机必读书籍,获取方式:计算机必读书籍(含下载方式),包含数据结构与算法、操作系统、计算机网络、数据库、L
  • 系统学习机器学习之系统认识

    千次阅读 2015-12-07 16:31:35
    机器学习(MachineLearning, ML)是一门多领域交叉学科,涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为,以获取新的知识或技能,重新组织已有的知识...
  • Database:Database数据库的简介、类型及其区别(关系数据库VS非关系型数据库)、案例应用之详细攻略 目录 Database数据库的简介 1、数据库的发展历史:80年代以来的关系型数据库→基于分布式技术云计算和...
  • [管理]案例剖析企业ERP失利原因

    千次阅读 2008-10-12 00:14:00
     从采购开始,生产、财务、服务等部门的同事纷纷对这套ERP系统提出质疑,一位销售部的同事更是直言:“这个系统的业务流程设计与我们以往的工作习惯大相径庭,我们根本无法适应。”  面对此起彼伏的反对之声,...
  • DL之BN-Inception:BN-Inception算法的简介(论文介绍)、架构详解、案例应用等配图集合之详细攻略 目录 BN-Inception算法的简介(论文介绍) BN-Inception算法的架构详解 1、BN-Inception网络—核心组件 5、...
  • 中国知名企业ERP失败案例分析

    千次阅读 2009-07-25 09:35:00
    中国已经有很多企业开始实施ERP了,有成功的案例,但是更多是失败的案例,这些企业实施ERP失败的教训在哪里呢?还是ERP真的不适合中国的国情吗?尽管ERP的高失败率已经成为不争的事实,诸如成功概率为0说、80亿投资...
  • 因为系统需要适应不同种类的数据格式和数据源,不能预先严格定义模式 )。 Spark Spark是由伯克利大学开发的分布式计算引擎,解决了海量数据流式分析的问题。Spark首先将数据导入Spark集群,然后再通过...
  • 2.5混合架构 上述架构各有其适应场景,有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求,有所取舍。在一般大多数场景下,是可以使用单一架构解决问题。现在很多产品...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,505
精华内容 5,002
关键字:

复杂适应系统理论案例