转载

事件链和服务链(2.12)

在谈EDA事件驱动架构的时候曾经谈到过事件链，即多个独立事件之间通过事件驱动规则，按照事件触发的先后关系串联在一起。单一的一个事件仅仅是一个业务活动的最终状态，本身并不会起到太大的作用，但是当事件串接为事件链后则完全可以重现相应的端到端流程。

即：事件链可以将端到端流程以另外一种方式描述出来，正如在UML建模中，对于动态部分建模可以采用时序图或活动图，也可以采用状态图一样，而事件链本身则类似状态图。

任何事件发生都会有触发规则，当规则条件满足的时候事件即会触发。而事件链本身的复杂性则在于事件链本身可能不是简单的串联结构，也可能是并联结构；其次对于规则的定义和描述也可能很复杂。例如：

事件A触发 + 规则1满足 =》触发事件B

如果进一步的抽象描述则可能是：

｛事件1,事件2, ... 事件N ｝+｛规则1,规则2, ... 规则N｝=》｛事件A,事件B,... 事件Z ｝

我们可以看下ifttt网站的思路基本则是上面的模型方式，那实际真正难的不是单个独立事件，而是规则的定义和灵活配置。如果一个EDA架构要足够灵活，则必须具备规则引擎来灵活定义规则。

事件即消息，即 通过EDA架构可以将原来长同步流程转化为彻底解耦和异步的端消息和事件处理过程 。在这种情况下消息中间件本身就会发挥巨大的作用。我们可以看到在现在大的开源云平台软件中，例如openstack , cloudstack , cloudfoundry, cloudify等都采用了消息中间件和事件驱动模式，以实现内部多个组件之间的完全解耦。

消息是事件链，而同步服务接口则形成服务链

把事件链搞清楚后再来思考下服务链。对于服务链管理和跟踪个人认为将随着微服务架构的不断推广而得到大范围的关注和应用。在微服务架构里面如果是采用Http Rest服务接口服务，那么对于这类同步类型的服务调用接口如何管理和跟踪就必须要考虑。

在传统的ESB产品中有服务编排功能，因此可以通过ESB本身的监控和管理平台来跟踪和监控组合服务和编排后的流程服务等。而在微服务架构里面我们一般不会引入过重的服务组合和编排工具，那么这些实际的服务组合往往是在代码里面完成掉的。

任何一个业务功能或操作的完成，往往就需要调用多个不同的原子服务加上代码的业务规则和逻辑判断才能完成。那么当业务功能或操作出现性能问题或异常调用的时候如何监控和分析？如何能够快速的找到服务调用链条并找到问题所在？

当前有不少的APM类产品，通过在原有的软件代码中植入探针的方式进行应用性能分析和监控，这种探针的实现类似AOP编程横切的方式来完成，通过这种方式可以监控到应用调用的完整过程，但是仍然对原有的应用具有一定的侵入性。

对于服务链监控，实际可以借鉴原有事件链处理的一些方法，即我可以定义一个服务会话ID，每次业务操作或请求都生成独立的会话ID， 在业务操作实际按步骤调用的多个服务中我们都传递该会话ID参数 ，通过这种方式只要我们提前定义清楚服务调用链和依赖关系，再加上服务调用实例产生的会话ID就很容易复原和监控整个服务链调用过程。

可以看到上面讲的方法完全可以用到微服务架构场景下的服务运行分析监控，服务链调用跟踪等。当然也可以进一步思考这种方式如何和当前已有的类似Sprind Cloud结合来实现完整的服务链监控和管理。

在2016年我们团队已经积累了对OpenStack， Hadoop的开源产品本身的事件和服务链监控和性能分析功能，在今年准备对于微服务架构下的服务链监控管理进行初步预研。

原文 http://blog.sina.com.cn/s/blog_493a84550102wpw9.html

正文到此结束