JdonFramework 6.4(Disruptor)版发布

11-09-07 banq
2009年JdonFramework 6.2版本推出基于内存的异步领域事件版本,其关键点是Domain Model + In-memory + Domain Events.常驻内存In-memory的领域模型Domain Model通过领域事件Domain Events驱动技术实现各种功能,正如基因DNA是生命各种活动功能的核心一样,实现了以领域模型而不是数据表为核心的新的模型驱动开发架构MDD。

2011年Martin Fowler肯定了LMAX架构的领域模型in-memory事件架构.

JdonFramework原先Domain Events是使用JDK FutureTask实现的, 但是最快并发开源框架Disruptor的创建者LMAX团队测试发现JDK所谓带锁并发包性能不优异,他们也发现函数式语言的Actor模型是有瓶颈的,所以他们采取Disruptor这样配合多核CPU高速缓冲策略的新框架,破除了Java多核并发隐患了JVM伪共享

JdonFramework 6.4版本引入了Disruptor作为其Domain Events实现机制,如下图:

JF的领域事件是一种异步模式 + 生产者-消费者模式。分为主题topic和Queue队列两种。领域模型是生产者;JF的消费者有两种:

(1).@Send => @Consumer;可以实现1:N多个,内部机制使用号称最快的并发框架Disruptor实现。适合轻量;小任务;原子性;无状态。

(2).@Send => @Componet;只能1:1,直接使用普通组件类作为消费者,使用jdk future机制,适合大而繁重的任务,有状态,单例。

有关新的JF领域事件见该文档:JdonFramework模型驱动快速开发

JiveJdon 4.4版本是基于JdonFramework 6.4版本的Disruptor新版本,基本使用Disruptor的DomainEventHandler替代了原来的MessageListener。其最新测试结果如下,由于将数据库等操作使用异步事件实现,回帖和帖子修改等写入性操作都是基于内存领域对象实现,性能大大提高:

领域事件是一种CQRS架构,也是一种Event Sourcing模式,可扩展性极强,通过以事件函数为核心,与面向函数思维一致,符合蒯因的引用透明原则和懒惰加载特性。

JdonFramework 6.4(Disruptor)版下载地址:SourceForge code.google.com下载

English: http://www.jdon.org/

JdonFramework on GitHub: https://github.com/banq/jdonframework

                   

11
banq
2011-09-09 17:01
使用JF可以轻松实现DCI架构。事件的生产者实际是DCI中的角色,JF运行时通过将角色注入到模型中实现其角色扮演功能。

DCI:数据Data, 场景Context, 交互Interactions是由MVC发明者Trygve Reenskaug发明的。 见 DCI架构是什么? DCI让我们的核心模型更加简单,只有数据和基本行为。业务逻辑等交互行为在角色模型中 在运行时的场景,将角色的交互行为注射到数据中。

JdonFramework的Domain Events是DCI的交互行为,在实现领域事件的同时也实现了DCI。为更清楚说明DCI,下面以JdonFramework案例说明。源码见: SimpleJdonFrameworkTest.rar

领域模型是DCI的Data,只有数据和基本行为,更简单,但注意不是只有setter/getter的贫血模型。如下:

@Model
public class User Model {

     private String userId;
     private String name;

     @Inject
     private ComputerRole computerRole;

<p>

Domain Events事件或消息的生产者也就是DCI中的角色Role,比如我们有一个专门进行计数计算的角色,实际上真正计算核心因为要使用关系数据库等底层技术架构,并不真正在此实现,而是依托消息消费者@Consumer实现,那么消息生产者可以看出是一个接口,消费者看成是接口的实现:

@Introduce("message")
public class ComputerRole {

     @Send("computeCount")
     public DomainMessage computeCount(User[author]Model[/author] user) {
          return new DomainMessage(user);
     }

     @Send("saveUser")
     public DomainMessage save(User[author]Model[/author] user) {
          return new DomainMessage(user);
     }

}
<p>

DCI第三个元素是场景上下文Context,在这个场景下,ComputeRole将被注入到模型UserModel中,实现计数计算的业务功能:

public class ComputeContext {

    private DomainMessage ageAsyncResult;

     public void preloadData(User[author]Model[/author] user) {
          if (ageAsyncResult == null)
               ageAsyncResult = user.getUserDomainEvents().computeCount(user);
     }

     public int loadCountNow(User[author]Model[/author] user) {
          preloadData(user);
          return (Integer) ageAsyncResult.getEventResult();
     }

     public int loadCountByAsync(User[author]Model[/author] user) {
          if (ageAsyncResult == null)
               ageAsyncResult = user.getUserDomainEvents().computeCount(user);
          else if (ageAsyncResult != null)
               return (Integer) ageAsyncResult.getEventResult();
          return -1;

     }
}
<p>

DCI应用源码下载:SimpleJdonFrameworkTest.rar

开发文档:JdonFramework模型驱动快速开发

更多文档:http://www.jdon.com/jdonframework/manual.htm

关于领域事件和DCI纠结讨论见:

DCI,领域模型,领域事件的一些想法,该文讨论场景和事件到底应该如何结合?怎么结合?

DCI并不反对继承 一文认为DCI目前最大的不确定性或者说问题是何时以及如何定义一个Context上下文场景?我个人认为通过领域事件实际上巧妙回避了这个问题,因为事件隐含了场景。

[该贴被banq于2011-09-10 17:09修改过]

[该贴被banq于2011-09-13 12:14修改过]

flyzb
2011-09-11 13:54
感谢banq的不懈努力。

  对于DCI,banq的提供思路在大多数场景下没问题。不过在我遇到的实际应用发现,在更复杂的场景中,领域对象的事件响应可能还会因场景不同而不同。这也就是说,大多数情况下主要由场景触发不同的领域对象事件,但领域对象的事件响应还可能进一步细分为不同的场景。

  所以领域对象事件和场景可能是相互交织的。不知道banq有没有更好的思路。

xuyifeng
2011-09-12 01:06
不知道jdon还记得我不,很久以前发你一个邮件,现在我也在java的领域中遨游了!最近的几篇主题LMAX和disrutor,让我非常刚兴趣。貌似我在多线程并发领域总是很有兴趣。

废话不多说。我看了disruptor的主题文章,如果真如文章所说,这个是目前最快的并非处理,那么在我一直在想,这个技术是否可以用到我们公司的系统中去。因为我们公司目前的系统虽然完整,但是咋性能上没有下很多时间,因为需要追求稳定。(插播下广告:我在职的公司是深圳的安捷信联,深圳的手机深圳通就是我们的产品)。而我们公司的系统驱动就是使用open mq的队列消息。我对disruptor的唯一担心是,他稳定吗?可以在并发情况下,保证数据的完整性等一系列问题(问题提的不好,见谅!)。

希望可以有更多的相关的文章,我很希望能够学习下这个技术。

banq
2011-09-12 07:41
2011年09月12日 01:06 "@flyzb "的内容
领域对象事件和场景可能是相互交织的。不知道banq有没有更好的思路。 ...

目前我也比较纠结..这个问题需要详细讨论才可能有好的思路,如果说场景或上下文是一个“面”,那么事件是“面”里那个点。场景在技术还要实现混合Assigned注入等作用。

2011年09月12日 01:06 "@xuyifeng "的内容

我对disruptor的唯一担心是,他稳定吗?可以在并发情况下,保证数据的完整性等一系列问题(问题提的不好,见谅!)。

这个问题Martin Fowler的LMAX架构已经回答了,LMAX团队在2010的Qcon大会汇报了他们这个技术,直至2011年老马写这篇文章,至少已经已经稳定运行一年,LMAX他们有专门的博客http://blogs.lmax.com/

猜你喜欢
4Go 1 2 3 4 下一页