背景：除去大名鼎鼎的QQ这款即时聊天工具，还有许多细分行业的IM，比如淘宝阿里旺旺、网易泡泡、YY语音......。恰巧公司产品也要开发一款基于我 们自己行业的类IM系统，很有幸我担当了这个产品的架构师，核心代码编写、实现者。下面把我近年来从技术上我对IM系统（即时消息的传输，不包括语音，视频，文件的传输）的理解和设计分享出来，浅薄之见，望大家别见笑，欢迎给出批评意见。

一.网络传输协议的选择

目前我知晓的所有IM系统传输即时消息无外乎使用UDP、TCP、基于TCP的http这几种协议中的一种或几种。比如QQ主要采用UDP协议，MSN主要采用TCP协议，而且他们也都支持HTTP协议的代理模式。更多资料，请参加这篇文章《一些常用软件的网络端口协议分类介绍》。

我们该如何选择呢？

• UDP协议实时性更好，但是如何处理安全可靠的传输并且处理不同客户端之间的消息交互是个难题，实现起来过于复杂；

• HTTP协议属于扩展支持，我们在产品的初始阶段可以不用支持；

• 那就非TCP协议莫属了，要考虑的同样也有很多，特别是如果有海量用户的需求。如何保证单机服务器高并发量，如何做到灵活，扩展的架构。

Tips: QQ 为什么采用 UDP 协议，而不采用 TCP 协议实现？

二.应该选择什么格式的数据协议

二进制格式？文本格式？这个话题转到我的这篇文章《网络传输数据格式的选择》，从我们当前的需求和产品周期上我觉得选择JSON形式的数据协议是最好的。

三.架构设计

首先我们来提炼一下一个IM系统的主要需求，包括账号，关系链，在线状态显示，消息交互......。

架构考量：

• 由于采用可靠传输协议TCP，考虑到负载问题（短连接实现账号、关系链相关业务，长连接实现上线、信息推送）；

• 后台架构的灵活性、可扩展性，支持分布式部署——把网络层、业务逻辑层、数据层分离，网络层和业务层支持负载均衡策略、数据层支持分布式存储；

• 客户端SDK的易用性：把网络层、数据层分离、业务逻辑层分离；

后台架构简化图

架构示意图

架构细化图

说明

• 从< 架构细化图>中可以看出对于上线服务由于建立的是TCP长连接，对于单台服务器往往由于硬件资源、系统资源、网络资源的限制无法做到海量用户的同时 在线，所以设计为根据服务器负载支持多服务器上线，同时由于多服务器上线造成了对整个系统交互（不同的客户端的交互，协作部门应用服务和客户的交互）的分 割，引入消息转发服务器作为粘合点。另外对于多服务器上线造成的统一账户信息（在线状态，消息）数据的分割，引入统一的数据层（内存存储 层：session、状态信息存储、消息队列存储；数据库：账号信息存储）做到业务和数据的分离，也就做到了支持分布式部署。参见我的这篇文章《构建高性能服务的考量》

• 对于部分业务服务：做到网络层、业务层、数据层的完全分离。首先对于TCP短连接来说不会如长连接那般消耗资源，即使后期遇到海量的并发访问请求依然可以从容的通过负载均衡策略和数据分布式部署策略进行解决。参见我的这篇文章《服务端架构中的“网关服务器”》

服务端平台及技术选型

• 系统开发平台： CentOS——Linux发行版的一种，稳定可靠、可定制优化、支持丰富；

• 网络支撑层： libevent——减小开发成本，增强稳定性；

• 缓存存储层： Redis——支持丰富的存储结构，支持分布式存储；

• 数据库： MySQL——最适合互联网的数据库，免授权、高效稳定、可控性高；

• 开发语言： C/C++；

部分热点问题考量

• 系统性能考量：

  • 编码角度：采用高效的网络模型，线程模型，I/O处理模型，合理的数据库设计和操作语句的优化；

  • 垂直扩展：通过提高单服务器的硬件资源或者网络资源来提高性能；

  • 水平扩展：通过合理的架构设计和运维方面的负载均衡策略将负载分担，有效提高性能；后期甚至可以考虑加入数据缓存层，突破IO瓶颈；

• 系统的高可用性：（防止单点故障）

  • 在架构设计时做到业务处理和数据的分离，从而依赖分布式的部署使得在单点故障时能保证系统可用。

  • 对于关键独立节点可以采用双机热备技术进行切换。

  • 数据库数据的安全性可以通过磁盘阵列的冗余配置和主备数据库来解决。

主要学习资料： 请自行google。

• 《1.4亿在线背后的故事》；

• 《BasicDB的架构演变》；

• 《微信之道－至简》；

本文出自51博客 “永远的朋友” ，转载请务必保留此出处http://yaocoder.blog.51cto.com/2668309/1412029

近几年，微服务架构迅速在整个技术社区窜红，它被认为是IT软件架构的未来方向，大神Martin Fowler也给微服务极高的评价。那为什么我们需要微服务，微服务的真正优势到底是什么，一个完整的微服务系统，应该包含哪些功能，本文作者刘彦夫在软件设计和开发领域有10多年工作经验，他将会从他的角度给出答案。

对微服务的基本理解

顾名思义，微服务要从两个方面来理解，一个是“微”，一个是“服务”。体型小到一定程度才能叫“微”，这个程度是什么呢？一个身高1米6，体重90斤的MM，我们说她苗条。微服务也一样，根据亚马逊CEO Bezos给出的有趣定义，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两个批萨就够了，这是就是著名的two pizza team rule。

具备什么样的能力才能算是“服务”？这个话题很大，我这里按照自己的片面理解总结一下，所谓服务就一定会区别于系统的功能，服务是一个或者一组相对的较小且独立的功能单元，是用户可以感知的功能最小集，比如：购物车，订单，信用卡结算等都可以作为单个服务独立提供。

这个理解显然不够深刻，为了进一步理解为什么微服务在近两年业界迅速窜红，理解为什么微服务会被认为是IT软件架构的未来方向，就要理解为什么我们需要微服务？它能给企业带来什么价值。传统企业的IT软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。后来有了一个叫SOA的软件架构专门针对这些问题给出了一套解决方案，很多企业也因此将自身IT系统迁移到SOA架构上。

但是，由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA开起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

依然SOA

微服务，从本质意义上看，还是SOA架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有Java编写的服务，也可以有Python编写的服务，他们是靠Restful架构风格统一成一个系统的。

最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性强。另一个不同是微服务架构本身很轻，底层也有类似于SOA的总线，不过非常轻薄，现在看到的就两种方式：MQ和HTTP，而HTTP都不能完全等同于总线，而仅仅是个信息通道。

所以，基于这种简单的的协议规范，无论是兼容老旧系统，还是上线新业务，都可以随着时代的步伐，滚动升级。比如：你去年还在使用.NET技术，今年就可以平滑的过度到Go了，而且系统已有服务不用改动。所以微服务架构，既保护用户已有投资，又很容易向新技术演进。

微服务水下的冰山

人月不是银弹，微服务更不是银弹，好像软件微服务化了，软件系统就能够应对各种问题了。其实微服务的水面下藏着巨大的冰山。下面是微服务提供的能力，以及背后需要付出的代价。

1. 单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。

2. 单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。

3. 单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。

4. 多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。

5. 微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址，类似于到餐厅吃饭，新菜要写到“菜单”中，以供用户选择。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。

6. 还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。

综上所述，微服务关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。

这些系统性的功能也需要有一些服务来提供，这些服务不会直接呈现给最终用户，也就是微服务系统冰山下面的部分，我们可以简称它为微服务系统的“底座”。所有的微服务都像一个APP，插在这个底座的上面，享受这个底座提供的系统能力比如：元数据存放、灰度发布、蓝绿部署等等。

微服务系统底座

一个完整的微服务系统，它的底座最少要包含以下功能：

• 日志和审计，主要是日志的汇总，分类和查询

• 监控和告警，主要是监控每个服务的状态，必要时产生告警

• 消息总线，轻量级的MQ或HTTP

• 注册发现

• 负载均衡

• 部署和升级

• 事件调度机制

• 资源管理，如：底层的虚拟机，物理机和网络管理

以下功能不是最小集的一部分，但也属于底座功能：

• 认证和鉴权

• 微服务统一代码框架，支持多种编程语言

• 统一服务构建和打包

• 统一服务测试

• 微服务CI/CD流水线

• 服务依赖关系管理

• 统一问题跟踪调试框架，俗称调用链

• 灰度发布

• 蓝绿部署

令人困惑的几个问题

微服务的底座是不是必须的？

是的，基本上是必须的。你可以不用代码实现一个资源管理服务，可以手工用Excel管理你的所有机器资源，但是不代表微服务系统没有这个功能，只不过这个功能是人工实现的。再举个例子，日志系统如果只是简单的打印文件，那么多个微服务的日志就需要手工收集，人工分类和筛选。所以，微服务的底座最小集一定会存在，问题是看怎样实现它。

这里仅仅是总结了对微服务系统的基本理解，而实现这个架构有很多技术，这里不进行详细展开。实践方面，推荐王磊的《微服务架构与实践》，他描述了使用Ruby相关的技术实现了一整套微服务系统，特别是书中后面的实践部分讲解了如何将已有的系统演化为微服务架构，是很好的参考和指导材料。

是不是所有软件都能做微服务？

这个命题有些微妙，也很难说清楚，回答这个命题本身就是一种挑战，可能最终也没有正确答案。不过，我还是把我自己的理解写在这里，让大家去拍砖。在我这里，答案是否定的。我只需举出一个反例，比如：存储系统，其架构是传统的分层架构，每一层都使用下面一层的服务，并为上一层提供服务。虽然可以将这种架构调整为基于服务的架构，但没办法做成微服务。

区别在哪里呢？核心的区别在于独立性上，微服务大多是可以独立的运行和使用的，而存储这种非常底层和基础的系统，每层部件都不能单独被使用，比如：Pool管理、CHUNK管理、VOL管理、NFS文件系统，这些功能都无法离开另外一些功能而独立运行，要对外提供可用的存储功能，一大堆功能必须一起上。这种系统做到极致，最多也就能够使其部件可以独立的部署和升级，俗称打热补丁。

这也就是为什么这种底层传统系统架构通常是单块架构的原因。由于单块架构的各个部分调用关系紧密，做成微服务后系统集成成本会大大增加，不仅如此，这样的架构做成微服务并不能提高交付效率，因为各个部分根本就无法独立的运行和测试。

什么样的软件做成微服务？

能不能做成微服务，取决于四个要素：

• 小：微服务体积小，2 pizza团队。

• 独：能够独立的部署和运行。

• 轻：使用轻量级的通信机制和架构。

• 松：为服务之间是松耦合的。

针对于小、轻、松都是可以通过某些技术手段达到目的，而独立的部署和运行，则是和业务本身有关系，如果你这个系统提供的业务是贴近最终用户的，并且这些功能之间的耦合性很小，则微服务就可以按照业务功能本身的独立性来划分，则这类系统做成微服务是非常合适的。如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就更加无法做到真正的微服务了。

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。

from: http://wapapp.baidu.com/tianhuimin/item/6e144c362eced2ff96f88d42

1 概述1.1 研发背景

支撑互联网应用的各种服务通常都是用复杂大规模分布式集群来实现的。而这些互联网应用又构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开 发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工 具。

hydra分布式跟踪系统就为了解决以上这些问题而设计的。

Google的论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》是我们设计开发的指导思想(原文和译文地址 https://github.com/bigbully/Dapper-translation)。Google针对自己的分布式跟踪系统Dapper 在生产环境下运行两年多时间积累的经验，在论文中重点提到了分布式跟踪系统对业务系统的零侵入这个先天优势，并总结了大量的应用场景，还提及它的不足之 处。我们通过对这篇论文的深入研究，并参考了Twitter同样依据这篇论文的scala实现Zipkin，结合我们自身的现有架构，我们认为分布式跟踪 系统在我们内部是非常适合的，而且也是急需的。

hydra目前的功能并不复杂，他可以接入一些基础组件，然后实现在基础组件上收集在组建上产生的行为的时间消耗，并且提供跟踪查询页面，对跟踪到的数据进行查询和展示。

我们会在之后的功能介绍中对hydra现有功能进行说明。

分布式跟踪的领域模型其实已经很成熟，早在1997年IBM就把ARM2.0(Application Response Measurement)作为一个公开的标准提供给了Open Group，无奈当时SOA的架构还未成熟，对业务的跟踪还需要直接嵌入到业务代码中，致使跟踪系统无法顺利推广。

如今互联网领域大多数后台服务都已经完成了SOA化，所以对业务的跟踪可以直接简化为对服务调用框架的跟踪，所以越来越多的跟踪系统也涌现出来。 在hydra系统中，我们使用的领域模型参考了Google的Dapper和Twitter的Zipkin(http://twitter.github.io/zipkin/)。

参考Dapper和Zipkin的设计，hydra也提炼出了自己的领域模型，如图所示:

• Trace:一次服务调用追踪链路。

• Span:追踪服务调基本结构，多span形成树形结构组合成一次Trace追踪记录。

• Annotation:在span中的标注点，记录整个span时间段内发生的事件。

• BinaryAnnotation:属于Annotation一种类型和普通Annotation区别，这键值对形式标注在span中发生的事件，和一些其他相关的信息。

Annotation在整个跟踪数据模型中最灵活的，灵活运用annotation基本能表达你所想到的跟踪场景。在hydra中(参考了zipkin)定义4种不同value的annotation用来表达记录span 4个最基本的事件。通过这4个annotation能计算出链路中业务消耗和网络消耗时间。

公司内部，尤其是我们部门有很多业务系统使用dubbo作为服务调用框，所以我们的分布式跟踪系统第一个接入组件就是dubbo。 另一个原因也是因为我们团队对dubbo有着非常深入的理解，加之dubbo本身的架构本身十分适合扩展，作为服务调用框架而言，跟踪的效果会非常明显， 比如Twitter的Zipkin也是植入到内部的Finagle服务调用框架上来进行跟踪的。

由于现阶段hydra主要接入了dubbo服务调用框架,所以在这必须了解dubbo的几个模型，如下图所示:

• Application:一类业务类型的服务，下面可能包含多个接口服务，可能出现多种类型业务跟踪链路。

• InterfaceService:接口服务，一个服务接口提供多种业务处理方法。

• Method:接口服务中具体处理业务的方法。

如图所示的应用场景对A服务的调用。A服务在被调用的过程中会继续调用服务B和服务C,而服务C被调用之后又会继续调用服务D和服 务E。在我们的领域模型中，服务A被调用到调用完成的过程，就是一次trace。而每一个服务被调用并返回的过程（一去一回的箭头）为一个span。可以 看到这个示例中包含5个span，client-A，A-B，A-C，C-D，C-E。span本身以树形结构展开，A-C是C-D和C-E的父 span，而client-A是整个树形结构的root span。之后要提到的一个概念就是annotation，annotation代表在服务调用过程中发生的一些我们感兴趣的事情，如图所示C-E上标出 来的那四个点，就是四个annotation，来记录事件时间戳，分别是C服务的cs（client send），E服务的ss（server receive）,E服务的ss（server send）, C服务的cr（client receive）。如果有一些自定义的annotation我们会把它作为BinaryAnnotation，其实就是一个k-v对，记录任何跟踪系统想 记录的信息，比如服务调用中的异常信息，重要的业务信息等等。

当前hydra1.0版的功能主要分为两个部分，跟踪查询和跟踪展示。

如图所示为查询页面：

在hydra针对业务提出两个相关的概念：应用和服务。不同的业务的所属不同的应用(相当于dubbo中的Application)，服务（相当于dubbo中的interface）挂在应用之下。

在hydra的查询界面中首先要选择想要关注的应用名，然后通过自动完成的方式输入应用下的服务。选择服务的开始时间和需要查看的跟踪次数。另外hydra需要确定返回数据的总量，防止查询出大数据量导致页面失去响应。

另外我们提供对额外的筛选条件：调用响应时间、是否发生异常。调用响应时间指的是这一次服务调用从调用开始到调用结束的时间，是否发生异常则包括一次服务调用中所有历经的服务抛出的异常都会捕获到。

对于查询之后的数据，hydra提供在前台进行排序的功能。

对于每一次跟踪，我们可以进一步展示他的服务调用层级与响应时间的时序图。如下图所示：

我们参考Dapper中论述的场景，在时序图中用绿色代表服务调用时间，浅蓝色代表网络耗时，另外如果服务调用抛出异常被 hydra捕捉到的话，会用红色表示。鼠标移动到时序图中的每一个对象上，会Tip展现详细信息，包括服务名、方法名、调用时长、Endpoint、异常 信息等。

左侧的树形结构图可以收起和展开，同时右侧的时序图产生联动，利于调整关注点在不同的服务上。

对于分布式跟踪系统而言，必须对接入的基础组件进行改造，我们对dubbo的改造很简单，只是在过滤器链上增加一个过滤器，我们将其封装成一个hydra-dubbo的jar包，由dubbo直接依赖。

所有跟踪所需的通用性的API我们封装在hydra-client中，遍于接入各种组件。 hydra-manager用来完成每个服务的注册、采样率的调成、发送seed生成全局唯一的traceId等通用性的功能。所有hydra-manager数据统一用mysql进行存储。

我们使用hydra-collector和hydra-collector-service进行跟踪数据的异步存储，中间使用metaQ进行缓冲。

hydra-manager和hydra-collector使用dobbo提供服务。

考虑到数据量不大的情况，以及部署的复杂度。我们提供了两种更简便的架构

• 如果考虑到数据量没有那么大，可以不使用hbase，用mysql代替，即精简版1。因为毕竟hadoop集群和hbase集群的部署和维护工作量很大。

• 如果并发量也不是很大的话，可以不使用消息中间件，也就是精简版2，如图所示。在hydra-collector端直接进行数据落地，当然仍然是异步的。

在使用mysql进行存储的时候我们并未进行分库分表，因为考虑到存储的是监控数据，时效性较高，而长期的监控数据的保留意义并不大。所以我们在主表上有明确的时间戳字段，使用者可以自行决定何时对保存的历史数据进行迁移。

Hydra分布式跟踪系统可以跟踪环境的数据量大小选择上文所述的三种部署方式

• 高并发，大数据量：hydra-client | Queue | hbase

• 高并发，小数据量：hydra-client | Queue | mysql

• 低并发，小数据量：hydra-client | mysql

因为是quick start，这里只介绍低并发和小数据量的情况。不过这里会详细介绍如何通过配置文件的修改来切换这三种部署方式。

• 1或多台业务系统集群机

• 1套zookeeper单点或集群机

• 1台机器部署Hydra-manager

• 1或多台机器部署Hydra-Collector

• 1台机器部署Hydra-web

• 1台数据库服务器

• Dubbo:Hydra是基于alibaba的dubbo框架基准上做的服务跟踪系统，理论上原有的Dubbo框架服务群中所有应用不需要额外的配置，皆可以平滑的接入Hydra系统。

• Zookeeper:各个服务点依赖于zookeeper来读取Hydra-manager和Hydra-collector获取数据交互路由点，来完成跟踪数据的推送和跟踪的控制。

• Mysql:跟踪数据的持久化存储。

• Tomcat:前端web应用容器

可以暂时使用master，后续版本会归并到dubbo管理端

maven项目不用多说。mvn clean install。不过不得不说的是，hydra项目中包含一些涉及数据库读写的单元测试(mysql，hbase），配置文件分别在:

• 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需要创建测试用数据库和测试用表，hbase需要创建测试用表

• docs/table-hbase/initTable
  (hbase建表时可以根据hbase集群的具体情况调整域分区，涉及到table-mysql中对TB_PARA_SERVICE_ID_GEN初始化数据的设计)

• docs/table-mysql

当然对于不需要使用hbase的同学也可以自行移除modules/hydar-store/hydra-hbase。

当然用maven构建跳过测试也是可以的。使用mvn clean install -Dmaven.test.skip=true

需要打包的子项目会通过maven:assemblly插件打成tar.gz包在各自的target目录下。

hydra-client中包含hydra与dubbo的集成，以及hydra跟踪收集的相关功能。如果需要进行dubbo服务的跟踪，只需要把这个jar包放在dubbo服务的classpath下，就会自动开启跟踪功能！

1. 部署：scp -r target/*.tar.gz username@ip:dirname

2. 配置：cd basedir/conf （需要修改配置）

3. 启动：cd basedir/bin
   sh manager.sh start

4. 停止：cd basedir/bin
   sh manager.sh stop

5. 输入：cd basedir/log
   tail -f manager.log

1. 部署：scp -r target/*.tar.gz username@ip:dirname

2. 配置：cd basedir/conf （需要修改配置）

3. 启动：cd basedir/bin
   sh collector-mysql.sh start 
   (这里注意一下，如果在hydra-collector中需要发送到Queue中，则需要启动collector.sh,jar包会加载不同的配置文件。)

4. 停止：cd basedir/bin
   sh collector-mysql.sh stop

5. 输入：cd basedir/log
   tail -f *.log

1. 需要在web.xml中修改引入的配置文件为hydra-mysql.xml，注掉hydra-hbase.xml

2. 部署：scp -r target/*.war username@ip:$TOMCAT_WEBAPPS

我们模拟了两个测试场景，均是基于dubbo服务调用

场景exp1:

A --> B --> C         

即服务A调用服务B,服务B调用服务C。测试用例在modules/hydra-example/hydra-exmple-exp1/。熟悉dubbo的同学一定不会陌生。

场景exp2:

A --> B --> C1 --> E                     --> C2 --> D1 --> C1 --> E                            --> D2         

场景2很复杂，基本涵盖了对同步调用跟踪的大多数可能遇到的场景。测试用例在modules/hydra-example/hydra-exmple-exp2/。

Hydra默认使用了hydra-exmple中的两个应用场景来做，你可以在hydra-test/hydra-test-integration打包中获得应用场景。

获得tar.gz包或者zip包后，将服务分布式部署到不同的机器上，以模拟应用场景,一下介绍场景一的部署方法，场景二的部署方法类似。

hydra-test-intergration 分为windows版和linux版(默认)，见如下打包方法。

• 打包：linux: mvn package -Pruntime-env-linux
  window: mvn package -Pruntime-env-windows

• 部署: scp -r target/*.tar.gz username@ip:dirname

• 配置: cd basedir/conf
  修改 *exp1.properties

• 启动： 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

以下演示安装样例：

1. 部署zookeeper单点或集群环境，以保证获得最佳SOA，zookeeper的部署请参照官方文档。

2. 部署实验场景exp1，只需要部署hydra-test-integration模块打包的tar.gz包，拷贝三份分布式部署。

3. 部署一个触发器Trigger，以激活服务的调用。

4. 部署一个Manager，以管理各个跟踪点的跟踪上下文。

5. 部署一个或者多个Collector消费机集群，以搜集来自Hydra-client推送过来的跟踪数据。

6. 部署一个web应用，已提供给前端展现应用系统服务上下文。

exp1场景说明：

有三个服务应用A、B、C和一个触发RPC调用的应用Trigger，服务调用关系为A-B-C， 每隔500s触发一个调用，持续时间为1天。

部署地址举例：

本测试针对Hydra-Client模块进行功能测试和压力测试，以便在Hydra开发的过程中及时发现重要bug和帮助优化Hydra系统性能。

本测试目前只针对Hydra-client的测试，重点关注业务系统接入Hydra和不接入Hydra前后性能影响，以保证Hydra系统接入端的低侵入性和稳定性。

针对Hydra-Client的测试，在部署上，只用部署应用场景（带Hydra_client）和Benchmark触发点，然后在应用Benchmark和应用场景上埋点分析Hydra性能。

资料来源：http://www.open-open.com/lib/view/open1370253915148.html