背景Q除d名鼎鼎的QQq款x聊天工具Q还有许多细分行业的IMQ比如淘宝阿里旺旺、网易泡、YY语音......。恰巧公品也要开发一Ƒ֟于我 们自p业的cIMpȝQ很有幸我担当了q个产品的架构师Q核心代码编写、实现者。下面把我近q来从技术上我对IMpȝQ即时消息的传输Q不包括语音Q视频,文g的传输)的理解和设计分n出来Q浅薄之见,望大家别见笑Q欢q给出批评意见?/p>
目前我知晓的所有IMpȝ传输x消息无外乎用UDP、TCP、基于TCP的httpq几U协议中的一U或几种。比如QQ主要采用UDP协议QMSN主要采用TCP协议Q而且他们也都支持HTTP协议的代理模式。更多资料,请参加这文?a target="_blank" style="color: #004276;">《一些常用Y件的|络端口协议分类介绍?/a>?/p>
我们该如何选择呢?
UDP协议实时性更好,但是如何处理安全可靠的传输ƈ且处理不同客L之间的消息交互是个难题,实现hq于复杂Q?/p>
HTTP协议属于扩展支持Q我们在产品的初始阶D可以不用支持;
那就非TCP协议莫属了,要考虑的同样也有很多,特别是如果有量用户的需求。如何保证单机服务器高ƈ发量Q如何做到灵z,扩展的架构?/p>
Tips: QQ Z么采?UDP 协议Q而不采用 TCP 协议实现Q?/a>
二进制格式?文本格式Q这个话题{到我的这文?a target="_blank" style="color: #004276;">《网l传输数据格式的选择?/a>Q从我们当前的需求和产品周期上我觉得选择JSON形式的数据协议是最好的?/p>
首先我们来提g下一个IMpȝ的主要需求,包括账号Q关p链Q在U状态显C,消息交互......?/p>
架构考量Q?/p>
׃采用可靠传输协议TCPQ考虑到负载问题(短连接实现̎受关p链相关业务Q长q接实现上线、信息推送)Q?/p>
后台架构的灵zL、可扩展性,支持分布式部|?#8212;—把网l层、业务逻辑层、数据层分离Q网l层和业务层支持负蝲均衡{略、数据层支持分布式存储;
客户端SDK的易用性:把网l层、数据层分离、业务逻辑层分;
后台架构化图
架构C意?/p>
架构l化?/p>
说明
?lt; 架构l化?gt;中可以看出对于上U服务由于徏立的是TCP长连接,对于单台服务器往往׃g资源、系l资源、网l资源的限制无法做到量用户的同?在线Q所以设计ؓҎ服务器负载支持多服务器上U,同时׃多服务器上线造成了对整个pȝ交互Q不同的客户端的交互Q协作部门应用服务和客户的交互)的分 Ԍ引入消息转发服务器作为粘合点。另外对于多服务器上UK成的统一账户信息Q在U状态,消息Q数据的分割Q引入统一的数据层Q内存存?层:session、状态信息存储、消息队列存储;数据库:账号信息存储Q做C务和数据的分,也就做到了支持分布式部v。参见我的这文?a target="_blank" style="color: #004276;">《构建高性能服务的考量?/a>
对于部分业务服务Q做到网l层、业务层、数据层的完全分R首先对于TCP短连接来说不会如长连接那般消耗资源,即后期遇到量的ƈ发访问请求依然可以从容的通过负蝲均衡{略和数据分布式部v{略q行解决。参见我的这文?a target="_blank" style="color: #004276;">《服务端架构中的“|关服务?#8221;?/a>
服务端^台及技术选型
pȝ开发^収ͼ CentOS——Linux发行版的一U,E_可靠、可定制优化、支持丰富;
|络支撑层: libevent——减小开发成本,增强E_性;
~存存储层: Redis——支持丰富的存储结构,支持分布式存储;
数据库: MySQL——最适合互联|的数据库,免授权、高效稳定、可控性高Q?/p>
开发语aQ?C/C++Q?/p>
部分热点问题考量
pȝ性能考量Q?/p>
~码角度Q采用高效的|络模型Q线E模型,I/O处理模型Q合理的数据库设计和操作语句的优化;
垂直扩展Q通过提高单服务器的硬件资源或者网l资源来提高性能Q?/p>
水^扩展Q通过合理的架构设计和q维斚w的负载均衡策略将负蝲分担Q有效提高性能Q后期甚臛_以考虑加入数据~存层,H破IO瓉Q?/p>
pȝ的高可用性:Q防止单Ҏ障)
在架构设计时做到业务处理和数据的分离Q从而依赖分布式的部|得在单点故障时能保证pȝ可用?/p>
对于关键独立节点可以采用双机热备技术进行切换?/p>
数据库数据的安全性可以通过盘阵列的冗余配|和d数据库来解决?/p>
主要学习资料Q?误行google?/p>
?.4亿在U背后的故事》;
《BasicDB的架构演变》;
《微信之道-至简》;
本文51博客 “永远的朋?/a>” Q{载请务必保留此出?a style="color: #004276;">http://yaocoder.blog.51cto.com/2668309/1412029
q几q_微服务架构迅速在整个技术社区窜U,它被认ؓ是IT软g架构的未来方向,大神Martin Fowler也给微服务极高的评h。那Z么我们需要微服务Q微服务的真正优势到底是什么,一个完整的微服务系l,应该包含哪些功能Q本文作者刘彦夫在Y件设计和开发领域有10多年工作l验Q他会从他的角度给出答案?/p>
思义Q微服务要从两个斚w来理解,一个是“?#8221;Q一个是“服务”。体型小C定程度才能叫“?#8221;Q这个程度是什么呢Q一个n?c?Q体?0斤的MMQ我们说她苗条。微服务也一PҎ亚马逊CEO Bezosl出的有定义,单个微服务的设计、开发、测试和q维的所有h加在一起吃饭,只需要两个批萨就够了Q这是就是著名的two pizza team rule?/p>
具备什么样的能力才能算?#8220;服务”Q?/span>q个话题很大Q我q里按照自己的片面理解ȝ一下,所谓服务就一定会区别于系l的功能Q服务是一个或者一l相对的较小且独立的功能单元Q是用户可以感知的功能最集Q比如:购物车,订单Q信用卡l算{都可以作ؓ单个服务独立提供?/p> q个理解昄不够深刻Qؓ了进一步理解ؓ什么微服务在近两年业界q速窜U,理解Z么微服务会被认ؓ是IT软g架构的未来方向,p理解Z么我们需要微服务Q它能给企业带来什么h倹{?/span>传统企业的IT软g大多都是各种独立pȝ的堆砌,q些pȝ的问题ȝ来说是扩展性差Q可靠性不高,l护成本高。后来有了一个叫SOA的Y件架构专门针对这些问题给Z一套解x案,很多企业也因此将自nITpȝq移到SOA架构上?/p> 但是Q由于SOA早期均用了ȝ模式Q这Uȝ模式是与某种技术栈强绑定的Q比如:J2EE。这D很多企业的遗留系l很隑֯接,切换旉太长Q成本太高,新系l稳定性的收敛也需要一些时间。最lSOA开h很美Q但却成Z企业U奢侈品Q中公叔R望而生畏?/p> 微服务,从本质意义上看,q是SOA架构。但内涵有所不同Q微服务q不l定某种Ҏ的技术,在一个微服务的系l中Q可以有Java~写的服务,也可以有Python~写的服务,他们是靠Restful架构风格l一成一个系l的?/p> 最_浅的理解就是将微服务之间的交互看作是各U字W串的传递,各种语言都可以很好的处理字符Ԍ所以微服务本n与具体技术实现无养I扩展性强。另一个不同是微服务架构本w很轻,底层也有cM于SOA的ȝQ不q非常轻薄,现在看到的就两种方式QMQ和HTTPQ而HTTP都不能完全等同于ȝQ而仅仅是个信息通道?/p> 所以,Zq种单的的协议规范,无论是兼容老旧pȝQ还是上U新业务Q都可以随着时代的步伐,滚动升。比如:你去q还在?NET技术,今年可以^滑的q度到Go了,而且pȝ已有服务不用改动。所以微服务架构Q既保护用户已有投资Q又很容易向新技术演q?/p> 人月不是银弹Q微服务更不是银弹,好像软g微服务化了,软gpȝp够应对各U问题了。其实微服务的水面下藏着巨大的冰山。下面是微服务提供的能力Q以及背后需要付出的代h?/p> 单个微服务代码量,易修改和l护。但是,pȝ复杂度的总量是不变的Q每个服务代码少了,但服务的个数肯定多了?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">p拼图游戏一P切的碎Q越难拼出整q图?/span>一个系l被拆分成零的微服务,最后要集成Z个完整的pȝQ其复杂度肯定比大块的功能集成要高很多?/p> 单个微服务数据独立,可独立部|和q行。虽然微服务本n是可以独立部|和q行的,但仍焉免不了业务上的你来我往Q这涉及到要对外通信Q当微服务的数量辑ֈ一定量U的时候,如何提供一个高效的集群通信机制成ؓ一个问题?/p> 单个微服务拥有自qq程Q进E本w就可以动态的启停Qؓ无缝升的打好了基础Q但谁来启动和停止进E,什么时机,选择在哪台设备上做这件事情才是无~升U的关键。这个能力ƈ不是微服务本w提供的Q而是需要背后强大的版本理和部|能力?/p> 多个相同的微服务可以做负载均衡,提高性能和可靠性。正是因为相同微服务可以有多个不同实例,让服务按需动态~成为可能,在高峰期可以启动更多的相同的微服务实例ؓ更多用户服务Q以此提高响应速度。同时这U机制也提供了高可靠性,在某个微服务故障后,其他相同的微服务可以接替其工作,对外表现为某个设备故障后业务不中断。同L道理Q微服务本n是不会去兛_pȝ负蝲的,那么什么时候应该启动更多的微服务,多个微服务的量应该如何调度和分发,q背后也有一套复杂的负蝲监控和均衡的pȝ在v作用?/p> 微服务可以独立部|和对外提供服务Q微服务的业务上U和下线是动态的Q当一个新的微服务上线Ӟ用户是如何访问到q种新的服务Q?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">q就需要有一个统一的入口,新的服务可以动态的注册到这个入口上Q用hơ访问时可以从这个入口拿到系l所有服务的讉K地址Q类g到餐厅吃饭,新菜要写?#8220;菜单”中,以供用户选择 q有一些企业x的系l问题,比如Q安全策略如何集中管理?pȝ故障如何快速审计和跟踪到具体服务?整个pȝ状态如何监控?服务之间的依赖关pd何管理?{等q些问题都不是单个微服务考虑的范_而需要有一个系l性的考虑和设计,让每个微服务都能够按照系l性的要求和约束提供对应的安全性,可靠性,可维护性的能力?/p> lg所qͼ微服务关键其实不仅仅是微服务本nQ而是pȝ要提供一套基的架构,q种架构使得微服务可以独立的部v、运行、升U,不仅如此Q这个系l架构还让微服务与微服务之间在结构上“松耦合”Q而在功能上则表现Z个统一的整体。这U所谓的“l一的整?#8221;表现出来的是l一风格的界面,l一的权限管理,l一的安全策略,l一的上U过E,l一的日志和审计ҎQ统一的调度方式,l一的访问入口等{?/p> q些pȝ性的功能也需要有一些服务来提供Q这些服务不会直接呈现给最l用P也就是微服务pȝ冰山下面的部分,我们可以U它为微服务pȝ?#8220;底”。所有的微服务都像一个APPQ插在这个底座的上面Qn受这个底座提供的pȝ能力比如Q元数据存放、灰度发布、蓝lK|等{?/p> 一个完整的微服务系l,它的底最要包含以下功能Q?/p> 日志和审计,主要是日志的汇总,分类和查?/p> 监控和告警,主要是监控每个服务的状态,必要时生告?/p> 消息ȝQ轻量的MQ或HTTP 注册发现 负蝲均衡 部v和升U?/p> 事g调度机制 资源理Q如Q底层的虚拟机,物理机和|络理 以下功能不是最集的一部分Q但也属于底座功能: 认证和鉴?/p> 微服务统一代码框架Q支持多U编E语a l一服务构徏和打?/p> l一服务试 微服务CI/CD水U?/p> 服务依赖关系理 l一问题跟踪调试框架Q俗U调用链 灰度发布 蓝绿部v 微服务的底是不是必ȝQ?/span> 是的Q基本上是必ȝ。你可以不用代码实现一个资源管理服务,可以手工用Excel理你的所有机器资源,但是不代表微服务pȝ没有q个功能Q只不过q个功能是h工实现的。再举个例子Q日志系l如果只是简单的打印文gQ那么多个微服务的日志就需要手工收集,人工分类和筛选。所以,微服务的底最集一定会存在Q问题是看怎样实现它?/p> q里仅仅是ȝ了对微服务系l的基本理解Q而实现这个架构有很多技术,q里不进行详l展开。实跉|面,推荐王磊的《微服务架构与实c,他描qC使用Ruby相关的技术实C一整套微服务系l,特别是书中后面的实践部分讲解了如何将已有的系l演化ؓ微服务架构,是很好的参考和指导材料?/p> 是不是所有Y仉能做微服务? q个命题有些微妙Q也很难说清楚,回答q个命题本n是一U挑战,可能最l也没有正确{案。不q,我还是把我自q理解写在q里Q让大家L砖。在我这里,{案是否定的。我只需丑և一个反例,比如Q存储系l,其架构是传统的分层架构,每一层都使用下面一层的服务QƈZ一层提供服务。虽然可以将q种架构调整为基于服务的架构Q但没办法做成微服务?/p> 区别在哪里呢Q核心的区别在于独立性上Q微服务大多是可以独立的q行和用的Q而存储这U非常底层和基础的系l,每层部g都不能单独被使用Q比如:Pool理、CHUNK理、VOL理、NFS文gpȝQ这些功能都无法d另外一些功能而独立运行,要对外提供可用的存储功能Q一大堆功能必须一起上。这U系l做到极_最多也p够光件可以独立的部v和升U,俗称打热补丁?/p> q也是Z么这U底层传l系l架构通常是单块架构的原因。由于单块架构的各个部分调用关系紧密Q做成微服务后系l集成成本会大大增加Q不仅如此,q样的架构做成微服务q不能提高交付效率,因ؓ各个部分Ҏ无法独立的q行和测试?/p> 什么样的Y件做成微服务Q?/span> 能不能做成微服务Q取决于四个要素Q?/p> :微服务体U小Q? pizza团队?/p> 独:能够独立的部|和q行?/p> 轻:使用轻量U的通信机制和架构?/p> 松:为服务之间是松耦合的?/p> 针对于小、轻、松都是可以通过某些技术手D达到目的,而独立的部v和运行,则是和业务本w有关系Q如果你q个pȝ提供的业务是贴近最l用LQƈ且这些功能之间的耦合性很,则微服务可以按照业务功能本w的独立性来划分Q则q类pȝ做成微服务是非常合适的。如果系l提供的业务是非常底层的Q如Q操作系l内核、存储系l、网l系l、数据库pȝ{等Q这cȝl都偏底层,功能和功能之间有着紧密的配合关p,如果强制拆分的服务单元Q会让集成工作量急剧上升Qƈ且这Uh为的切割无法带来业务上的真正的隔,所以无法做到独立部|和q行Q也更加无法做到真正的微服务了?/p> 感谢郭蕾Ҏ文的审校?/p> lInfoQ中文站投E或者参与内容翻译工作,请邮件至editors@cn.infoq.com。也Ƣ迎大家通过新浪微博Q?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">@InfoQQ?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">@丁晓昀Q,微信Q微信号Q?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">InfoQChinaQ关注我们?/p>依然SOA
微服务水下的冰山
。这个统一的系l入口ƈ不是微服务本w的一部分Q所以这U能力需要系l单独提供?/p>微服务系l底?/h2>
令h困惑的几个问?/h2>
from: http://wapapp.baidu.com/tianhuimin/item/6e144c362eced2ff96f88d42
1 概述1.1 研发背景
支撑互联|应用的各种服务通常都是用复杂大规模分布式集来实现的。而这些互联网应用又构建在不同的Y件模块集上,q些软g模块Q有可能是由不同的团队开 发、可能用不同的~程语言来实现、有可能布在了几千台服务器,横跨多个不同的数据中心。因此,需要一些可以帮助理解系l行为、用于分析性能问题的工 兗?/p>
hydra分布式跟t系l就Z解决以上q些问题而设计的?/p>1.2 理论依据
Google的论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》是我们设计开发的指导思想(原文和译文地址 https://github.com/bigbully/Dapper-translation)。Google针对自己的分布式跟踪pȝDapper 在生产环境下q行两年多时间积累的l验Q在论文中重ҎC分布式跟t系l对业务pȝ的零侵入q个先天优势Qƈȝ了大量的应用场景Q还提及它的不?nbsp;处。我们通过对这论文的深入研究Qƈ参考了Twitter同样依据q篇论文的scala实现ZipkinQ结合我们自w的现有架构Q我们认为分布式跟踪 pȝ在我们内部是非常适合的,而且也是急需的?/p>1.3 功能概述
hydra目前的功能ƈ不复杂,他可以接入一些基lgQ然后实现在基础lg上收集在l徏上生的行ؓ的时间消耗,q且提供跟踪查询面Q对跟踪到的数据q行查询和展C?/p>
我们会在之后的功能介l中对hydra现有功能q行说明?/p>2 领域模型
分布式跟t的领域模型其实已经很成熟,早在1997qIBM把ARM2.0(Application Response Measurement)作ؓ一个公开的标准提供给了Open GroupQ无奈当时SOA的架构还未成熟,对业务的跟踪q需要直接嵌入到业务代码中,致跟踪pȝ无法利推广?/p>
如今互联|领域大多数后台服务都已l完成了SOA化,所以对业务的跟t可以直接简化ؓҎ务调用框架的跟踪Q所以越来越多的跟踪pȝ也涌现出来?nbsp;在hydrapȝ中,我们使用的领域模型参考了Google的Dapper和Twitter的Zipkin(http://twitter.github.io/zipkin/)?/p>2.1 hydra中的跟踪数据模型
参考Dapper和Zipkin的设计,hydra也提炼出了自q领域模型Q如图所C?
Trace:一ơ服务调用追t链路?/p>
Span:q踪服务调基本结构,多span形成树Şl构l合成一ơTraceq踪记录?/p>
Annotation:在span中的标注点,记录整个span旉D内发生的事件?/p>
BinaryAnnotation:属于Annotation一U类型和普通Annotation区别Q这键值对形式标注在span中发生的事gQ和一些其他相关的信息?/p>
Annotation在整个跟t数据模型中最灉|的,灉|q用annotation基本能表达你所惛_的跟t场景。在hydra?参考了zipkin)定义4U不同value的annotation用来表达记录span 4个最基本的事件。通过q?个annotation能计出链\中业务消耗和|络消耗时间?/p>2.2 dubbo服务调用框架的模?p style="margin: 10px 0px; padding: 0px; font-family: arial, sans-serif, verdana, helvetica; color: #404040; line-height: 25px; background-color: #fafafa;">公司内部Q尤其是我们部门有很多业务系l用dubbo作ؓ服务调用框,所以我们的分布式跟t系l第一个接入组件就是dubbo?nbsp;另一个原因也是因为我们团队对dubbo有着非常深入的理解,加之dubbo本n的架构本w十分适合扩展Q作为服务调用框架而言Q跟t的效果会非常明显, 比如Twitter的Zipkin也是植入到内部的Finagle服务调用框架上来q行跟踪的?/p>
׃现阶Dhydra主要接入了dubbo服务调用框架,所以在q必M解dubbo的几个模型,如下图所C?
Application:一cM务类型的服务Q下面可能包含多个接口服务,可能出现多种cd业务跟踪链\?/p>
InterfaceService:接口服务Q一个服务接口提供多U业务处理方法?/p>
Method:接口服务中具体处理业务的Ҏ?/p>
如图所C的应用场景对A服务的调用。A服务在被调用的过E中会l调用服务B和服务C,而服务C被调用之后又会l调用服务D和服 务E。在我们的领域模型中Q服务A被调用到调用完成的过E,是一ơtrace。而每一个服务被调用q返回的q程Q一M回的头Qؓ一个span。可?nbsp;看到q个CZ中包?个spanQclient-AQA-BQA-CQC-DQC-E。span本n以树形结构展开QA-C是C-D和C-E的父 spanQ而client-A是整个树形结构的root span。之后要提到的一个概念就是annotationQannotation代表在服务调用过E中发生的一些我们感兴趣的事情,如图所CC-E上标?nbsp;来的那四个点Q就是四个annotationQ来记录事g旉戻I分别是C服务的csQclient sendQ,E服务的ssQserver receiveQ?E服务的ssQserver sendQ? C服务的crQclient receiveQ。如果有一些自定义的annotation我们会把它作为BinaryAnnotationQ其实就是一个k-v对,记录M跟踪pȝ?nbsp;记录的信息,比如服务调用中的异常信息Q重要的业务信息{等?/p>3 功能介绍
当前hydra1.0版的功能主要分ؓ两个部分Q跟t查询和跟踪展示?/p>
如图所CZؓ查询面Q?/p>
在hydra针对业务提出两个相关的概念:应用和服务。不同的业务的所属不同的应用(相当于dubbo中的Application)Q服务(相当于dubbo中的interfaceQ挂在应用之下?/p>
在hydra的查询界面中首先要选择惌x的应用名Q然后通过自动完成的方式输入应用下的服务。选择服务的开始时间和需要查看的跟踪ơ数。另外hydra需要确定返回数据的总量Q防止查询出大数据量D面失去响应?/p>
另外我们提供寚w外的{选条Ӟ调用响应旉、是否发生异常。调用响应时间指的是q一ơ服务调用从调用开始到调用l束的时_是否发生异常则包括一ơ服务调用中所有历l的服务抛出的异帔R会捕获到?/p>
对于查询之后的数据,hydra提供在前台进行排序的功能?/p>
对于每一ơ跟t,我们可以q一步展CZ的服务调用层U与响应旉的时序图。如下图所C:
我们参考Dapper中论q的场景Q在时序图中用绿色代表服务调用时_蓝色代表网l耗时Q另外如果服务调用抛出异常被 hydra捕捉到的话,会用U色表示。鼠标移动到时序图中的每一个对象上Q会Tip展现详细信息Q包括服务名、方法名、调用时ѝEndpoint、异?nbsp;信息{?/p>
左侧的树形结构图可以收v和展开Q同时右侧的时序图生联动,利于调整x点在不同的服务上?/p>4 整体架构4.1 完整?img width="640" height="445" src="http://g.hiphotos.baidu.com/album/pic/item/ac6eddc451da81cb77043c715366d016082431af.jpg" alt="Hydra - 京东开源的ZDubbo的调用分布跟t系l? style="border: 0px; margin-bottom: 8px; clear: both; max-width: 758px; vertical-align: top;" />
对于分布式跟t系l而言Q必d接入的基lgq行攚w,我们对dubbo的改造很单,只是在过滤器链上增加一个过滤器Q我们将其封装成一个hydra-dubbo的jar包,由dubbo直接依赖?/p>
所有跟t所需的通用性的API我们装在hydra-client中,遍于接入各种lg?nbsp;hydra-manager用来完成每个服务的注册、采L的调成、发送seed生成全局唯一的traceId{通用性的功能。所有hydra-manager数据l一用mysqlq行存储?/p>
我们使用hydra-collector和hydra-collector-serviceq行跟踪数据的异步存储,中间使用metaQq行~冲?/p>
hydra-manager和hydra-collector使用dobbo提供服务?/p>4.2 _?p style="margin: 10px 0px; padding: 0px; font-family: arial, sans-serif, verdana, helvetica; color: #404040; line-height: 25px; background-color: #fafafa;">考虑到数据量不大的情况,以及部v的复杂度。我们提供了两种更简便的架构
如果考虑到数据量没有那么大,可以不用hbaseQ用mysql代替Q即_?。因为毕竟hadoop集群和hbase集群的部|和l护工作量很大?/p>
如果q发量也不是很大的话Q可以不使用消息中间Ӟ也就是精?Q如图所C。在hydra-collector端直接进行数据落圎ͼ当然仍然是异步的?/p>
在用mysqlq行存储的时候我们ƈ未进行分库分表,因ؓ考虑到存储的是监控数据,时效性较高,而长期的监控数据的保留意义ƈ不大。所以我们在主表上有明确的时间戳字段Q用者可以自行决定何时对保存的历史数据进行迁UR?/p>5 Quick Start5.1 部v?p style="margin: 10px 0px; padding: 0px; font-family: arial, sans-serif, verdana, helvetica; color: #404040; line-height: 25px; background-color: #fafafa;">Hydra分布式跟t系l可以跟t环境的数据量大选择上文所q的三种部v方式
高ƈ发,大数据量Qhydra-client | Queue | hbase
高ƈ发,数据量Qhydra-client | Queue | mysql
低ƈ发,数据量Qhydra-client | mysql
因ؓ是quick startQ这里只介绍低ƈ发和数据量的情c不q这里会详细介绍如何通过配置文g的修Ҏ切换q三U部|方式?/p>5.2 g要求
1或多C务系l集机
1套zookeeper单点或集机
1台机器部|Hydra-manager
1或多台机器部|Hydra-Collector
1台机器部|Hydra-web
1台数据库服务?/p>
Dubbo:Hydra是基于alibaba的dubbo框架基准上做的服务跟t系l,理论上原有的Dubbo框架服务中所有应用不需要额外的配置Q皆可以qx的接入Hydrapȝ?/p>
Zookeeper:各个服务点依赖于zookeeper来读取Hydra-manager和Hydra-collector获取数据交互路由点,来完成跟t数据的推送和跟踪的控制?/p>
Mysql:跟踪数据的持久化存储?/p>
Tomcat:前端web应用容器
可以暂时使用masterQ后l版本会归ƈ到dubbo理?/p>5.5 目构徏打包
maven目不用多说。mvn clean install。不q不得不说的是,hydra目中包含一些涉及数据库d的单元测?mysqlQhbaseQ,配置文g分别?
modules/hydra-manager-db/src/test/resources/mysql.properties
modules/hydra-store/hydra-mysql/src/test/resources/mysql.properties
modules/hydra-store/hydra-hbase/src/test/resources/hbase-site.xml
modules/hydra-store/hydra-hbase/src/test/resources/hydra-hbase-test.xml
mysql需要创建测试用数据库和试用表Qhbase需要创建测试用?/p>
docs/table-hbase/initTable
(hbase时可以根据hbase集群的具体情况调整域分区Q涉及到table-mysql中对TB_PARA_SERVICE_ID_GEN初始化数据的设计)
docs/table-mysql
当然对于不需要用hbase的同学也可以自行U除modules/hydar-store/hydra-hbase?/p>
当然用maven构徏跌试也是可以的。用mvn clean install -Dmaven.test.skip=true
需要打包的子项目会通过maven:assemblly插g打成tar.gz包在各自的target目录下?/p>5.6 安装部v5.6.1 Hydra-client
hydra-client中包含hydra与dubbo的集成,以及hydra跟踪攉的相兛_能。如果需要进行dubbo服务的跟t,只需要把q个jar包放在dubbo服务的classpath下,׃自动开启跟t功能!
5.6.2 Hydra-manager部vQscp -r target/*.tar.gz username@ip:dirname
配置Qcd basedir/conf Q需要修攚w|)
启动Qcd basedir/bin
sh manager.sh start
停止Qcd basedir/bin
sh manager.sh stop
输入Qcd basedir/log
tail -f manager.log
部vQscp -r target/*.tar.gz username@ip:dirname
配置Qcd basedir/conf Q需要修攚w|)
启动Qcd basedir/bin
sh collector-mysql.sh start
(q里注意一下,如果在hydra-collector中需要发送到Queue中,则需要启动collector.sh,jar包会加蝲不同的配|文件?
停止Qcd basedir/bin
sh collector-mysql.sh stop
输入Qcd basedir/log
tail -f *.log
需要在web.xml中修改引入的配置文g为hydra-mysql.xmlQ注掉hydra-hbase.xml
部vQscp -r target/*.war username@ip:$TOMCAT_WEBAPPS
我们模拟了两个测试场景,均是Zdubbo服务调用
场景exp1:
A --> B --> C
x务A调用服务B,服务B调用服务C。测试用例在modules/hydra-example/hydra-exmple-exp1/。熟悉dubbo的同学一定不会陌生?/p>
场景exp2:
A --> B --> C1 --> E --> C2 --> D1 --> C1 --> E --> D2
场景2很复杂,基本늛了对同步调用跟踪的大多数可能遇到的场景。测试用例在modules/hydra-example/hydra-exmple-exp2/?/p>6.2 模拟场景dubbo服务的部|?p style="margin: 10px 0px; padding: 0px; font-family: arial, sans-serif, verdana, helvetica; color: #404040; line-height: 25px; background-color: #fafafa;">Hydra默认使用了hydra-exmple中的两个应用场景来做Q你可以在hydra-test/hydra-test-integration打包中获得应用场景?/p>
获得tar.gz包或者zip包后Q将服务分布式部|到不同的机器上Q以模拟应用场景,一下介l场景一的部|方法,场景二的部vҎcM?/p>
hydra-test-intergration 分ؓwindows版和linux?默认)Q见如下打包Ҏ?/p>
打包Qlinux: mvn package -Pruntime-env-linux
window: mvn package -Pruntime-env-windows
部v: scp -r target/*.tar.gz username@ip:dirname
配置: cd basedir/conf
修改 *exp1.properties
启动Q?nbsp;cd basedir/bin
cd exp1
sh startA.sh
cd ..
sh startTrigger-exp1.sh start
停止: cd basedir/bin
sh startTrigger-exp1.sh stop
All.sh stop
输出: cd basedir/log
tail -f *.log
以下演示安装样例Q?/p>
部vzookeeper单点或集环境,以保证获得最佳SOAQzookeeper的部|请参照官方文?/p>
部v实验场景exp1Q只需要部|hydra-test-integration模块打包的tar.gz包,拯三䆾分布式部|Ӏ?/p>
部v一个触发器TriggerQ以ȀzL务的调用?/p>
部v一个ManagerQ以理各个跟踪点的跟踪上下文?/p>
部v一个或者多个Collector消费机集,以搜集来自Hydra-client推送过来的跟踪数据?/p>
部v一个web应用Q已提供l前端展现应用系l服务上下文?/p>
exp1场景说明Q?/p>
有三个服务应用A、B、C和一个触发RPC调用的应用TriggerQ服务调用关pMؓA-B-CQ?nbsp;每隔500s触发一个调用,持箋旉?天?/p>
部v地址举例Q?/p>角色ipportZK192.168.200.110-1122181~A192.168.200.11020990B192.168.200.11120991C192.168.200.11220992Trigger192.168.200.113-Manager192.168.228.8120890Collector192.168.228.81-8220889Web192.168.228.818080MySql-DB192.168.228.8133067 试相关7.1 试说明
本测试针对Hydra-Client模块q行功能试和压力测试,以便在Hydra开发的q程中及时发现重要bug和帮助优化Hydrapȝ性能?/p>
本测试目前只针对Hydra-client的测试,重点x业务pȝ接入Hydra和不接入Hydra前后性能影响Q以保证Hydrapȝ接入端的低R入性和E_性?/p>
针对Hydra-Client的测试,在部|上Q只用部|应用场景(带Hydra_clientQ和Benchmark触发点,然后在应用Benchmark和应用场景上埋点分析Hydra性能?br />
资料来源Q?a target="_blank" style="color: #4bc1c1;">http://www.open-open.com/lib/view/open1370253915148.html