akka设计模式系列-消息模型（续）

Posted 2021-03-25 gabry

　　在之前的akka设计模式系列-消息模型中，我们介绍了akka的消息设计方案，但随着实践的深入，发现了一些问题，这里重新梳理一下设计方法，避免之前的错误、不当的观点给大家带来误解。

---

 命令和事件

　　我们仍然把akka中的消息分为命令和事件两大类，但二者的具体含义和实现有一点变化。“命令，是指一个actor给另外一个actor发送指令做相关的业务逻辑；事件，则是actor对某个命令的响应结果，或者对其他事件的响应结果”。之前是这样定义的，但在具体的实践过程中发现了一些问题。

　　比如，命令如何归类？是根据命令的发送者归类还是根据接收者归类呢？是不是根据消息的作用对象更恰当呢？事件的定义是不是可以更加宽泛一下呢？如果某个消息是定时产生的，那它应该是一个命令还是一个消息呢？

　　当然还有一些其他的问题，认真总结后，在代码设计上我们做了一些优化。

消息

trait Message {
  /**
    * 消息发生的时间
    */
  final lazy val at: Long = System.currentTimeMillis()
}

 　　消息的定义很简单，只有一个时间字段，表示命令或事件的产生时间。但在实践过程中发现，很少使用这个字段，再加上System.currentTimeMillis()多线程调用会有性能问题，所以干脆把它定义成了lazy。关于这一点，大家可以根据各自的实际情况修改。

命令

trait Reply{
  def replyTo:ActorRef
}

trait Command extends Message with Reply

 　　命令就是含有回复对象的消息，之所以强化这一点，主要是想 用Command模拟能返回结果的函数。也就是说，actor收到Command之后必须有一个返回事件。

trait TaskCommand extends Command
object TaskCommand{
  final case class Run(jobContext: JobContext,replyTo:ActorRef) extends TaskCommand
  final case class Kill(jobId:UID, taskId:UID, executorType: ExecutorType, replyTo:ActorRef) extends TaskCommand
}

 　　上面定义两个命令：Run、Kill。很明显我们是根据命令的作用对象进行归类，也就是实现统一的trait（TaskCommand）。之所以这样做是因为我们发现很多命令被某一个actor处理之后，并不返回结果，而是发送给下一个actor处理，并由其返回结果。这种情况下无论从发送者还是接收者归类都不恰当，而用命令的作用对象进行归类则比较合适。

事件

trait SchedulerEvent extends Event
object SchedulerEvent{
  final case class ScheduleTriggered() extends SchedulerEvent
  final case class NodeDowned(nodeAnchor:String) extends SchedulerEvent
}

　　 事件的含义和实现方法跟之前基本不变，但总体来说也是围绕某个对象进行归类。比如Scheduler这个对象有两个事件：ScheduleTriggered、NodeDowned。这样事件在多个actor传递的时候不会改变其原始的含义，比较容易理解。

命令结果

　　actor处理命令的时候，需要有一个返回结果，仍然需要对如何返回进行界定。我们根据面向过程编程的一个优良习惯进行规范：对某一类Command返回结果时，只能有一个地方返回成功结果，可以有多个地方返回失败结果。这只是一个软性约束，但非常有用，这样排查问题比较方便，也有利于画系统的流程图。

总结

　　在Akka中消息设计的好坏往往决定着应用的质量，非常重要。每个人的设计理念不同，实现的方式也就不同，这里也只是抛砖引玉，如果你有更好的设计模式，欢迎留言或者加微信（HelloGrape）讨论。