接手akka-typed这个系列之后后台收到不少私信问得最多的一个问题就是类型化actor和经典actor写起来到底有什么不一样很多人卡在“Behavior[T]”这个门槛上觉得不过就是把Receive换了个写法。但实际上真正让typed actor产生质变的是它把“交流方式”和“交流协议”这两件事从约定变成了契约。这篇我专门把这两件事拆开讲透。交流方式解决的是“消息怎么发出去、怎么收回来”交流协议解决的是“谁能接收什么消息、这个消息长什么样”。两者合在一起才是你写任何一个actor系统时真正的设计图纸。看完这篇你应该能回答自己几个问题tell和ask到底怎么选协议怎么定义才不容易改崩未来要加消息类型时怎么不把整个actor的代码翻个底朝天1. 为什么Typed Actor的交流方式值得单独拿出来讲1.1 从无类型Actor切到typed Actor第一关就是消息类型很多人觉得从经典actor切到typed actor不过是把Actor.Receive换成Behavior[T]换个写法而已。我一开始也是这么想的直到接到一个需求两个actor之间原来靠tell发送一个字符串消息再在接收方用match去解析。切到typed actor之后第一个编译错误就是字符串找不到了——因为现在你必须告诉编译器你的actor到底接收什么类型的消息。这个变化远不止是“编译安全”这么简单。在经典actor里消息的“协议”是隐性的你靠写文档、靠看代码、靠猜才能知道一个actor能处理哪些消息。而typed actor把协议直接写在了类型上Behavior[Counter.Command]就明确告诉你这个actor只接收Counter.Command类型的消息别的类型根本编译不过去。我管这个叫“协议感知”它是typed actor所有交流方式设计的地基。守住这个类型你再去看actor之间的交流会发现它本质上就是在类型约束下做消息路由。发送方手里的ActorRef[T]决定了它只能给这个actor发T类型的消息接收方的Behavior[S]决定了它只能处理S类型的消息。类型不匹配编译器直接拦下而不是等到运行时再扔一个ClassCastException。1.2 类型带来的“协议感知”协议感知的价值在系统复杂到一定程度后会特别明显。我参与过一个订单系统里面有十几个actor分别负责订单聚合、库存扣减、支付网关对接、物流通知。在经典actor版本里订单actor收到的消息有十来种有OrderCreated、PaymentReceived、InventoryDeducted、ShipmentScheduled后来接手的人包括我自己每次都要翻代码看这些消息的父类到底是什么。切到typed actor之后Behavior[OrderCommand]直接把所有订单消息封在了一个命令接口里你看一眼类型就知道这个actor的职责边界。协议感知还有一个容易被忽略的好处重构时特别安全。你改一个消息的字段编译器会告诉你有多少个actor引用到了这个类型改漏了跑不掉的。这在经典actor里是做不到的字符串消息满天飞的时候改一个关键字只能靠全局搜索碰运气。1.3 交流对象谁跟谁在说话讲交流方式之前我觉得有必要先理清楚一个基本问题一个actor到底和谁在交流。首先是actor与actor之间这是最典型的场景。发送方通过ActorRef[T]给目标的邮箱投递消息目标异步处理处理完如果有结果得通过消息回传。其次是actor与外部系统调用方之间。外部系统可能是HTTP服务、消息队列的消费者、定时任务调度器。这种场景通常是外部系统发起请求需要actor给一个响应。这时候你要么拿到临时ActorRef来接收回调消息要么用ask模式直接在调用方等一个Future[U]。最后是actor与自身子actor之间的交流。父actor创建子actor然后通过ctx.spawn返回的ActorRef来下发指令。这个场景下父actor往往扮演“监督者路由者”的角色协议设计上要考虑的是“子actor处理不了的情况怎么向上反馈”。搞清楚这三类场景我们再来选择合适的交流方式就不会只是套模板了。2. 三种基础交流方式tell、ask、pipeTo2.1 tell不是“发消息”那么简单tell在typed actor里写成actorRef.tell(msg)在经典actor里是actorRef.tell(msg, self)。它本质上是异步的单向消息投递发送方发完就不管了不需要也不等待对方的回复。具体实现上消息被放入对方的邮箱队列由目标actor的调度机制取出来处理。tell有一个不起眼但很关键的细节发送方不会因为接收方正在处理某条消息而阻塞。也就是说即使目标actor正在处理上一条消息你此刻发出去的消息也会被存进邮箱排着队等它处理完。这个机制决定了tell适合做“命令”command而不是“查询”query——你告诉对方“去执行某个动作”至于结果如何你用其他渠道去获取。我在订单聚合根里经常用tell下发命令比如DeductInventory、MarkOrderPaid。这些命令执行完毕后会产生领域事件事件再通过其他actor订阅处理。整个过程是异步的事件流没有人同步等待某个结果。这就是tell的典型用法把动作发出去不关心它何时完成关心的是事件最终能落到正确的订阅者手里。tell还有一个细节actorRef.tell本身没有回执机制。如果目标actor不存在或者邮箱已终止消息会被投递到deadLetters。很多新手用tell之后发现消息丢了十有八九是目标引用过期了或actor已经stop了。所以凡是需要确认“消息已经到了”的场景就不要用裸tell至少加一个确认消息ack机制或者直接用ask。2.2 ask必须配超时它本质上是一次“远程调用”ask的写法是actorRef.ask[T](makeMessage)它返回Future[T]。这里的T是你期望接收到的响应类型不是actor接收的命令类型。也就是说ask的核心机制是你构造一条消息这条消息一般会携带一个临时创建的ActorRef[Response]目标actor收到消息后会向这个引用回发消息ask框架把这个回发消息包装成Future返回给你。ask在使用的便利性上确实比tell高出一截但代价是它引进了超时机制。因为你不能再像tell那样“发完就不管”你得等着结果回来所以你必须给ask设置一个超时时间。超过这个时间没有等到响应Future会以AskTimeoutException失败。关于超时时间的设置我踩过几次坑。太短比如1秒actor稍微忙一下就超时太长比如30秒不仅会积压大量挂起的Future还容易掩盖上游性能问题。我的经验是如果actor的平均响应时间在几十毫秒内那么2~3秒是合理区间如果是带IO操作比如数据库查询、外部接口调用5~10秒更稳妥。但不管设多少你都要在代码里处理超时分支否则线上会出现一堆AskTimeoutException没人接。还有一个需要区分清楚的点ask不等于同步阻塞。它返回的是Future你可以理解成一个“尚未填值的盒子”。在调用方内部你还是要通过onComplete、map、或者放入某个actor的消息循环里处理它。不要在actor的Behavior构造函数里干等Future的结果那会阻塞整个actor的调度等于把异步模型做成了伪同步。2.3 pipeTo把异步结果安全地送回既然说ask返回Future那就一定会遇到一个问题这个Future在哪个上下文里完成如果在一个actor的Behavior里处理Future回调稍不留意就会把“发送方是谁”和“当前actor是谁”这两件事搞混。经典actor里是用pipe模式解决这个问题的typed actor里对应的就是pipeTo。pipeTo的核心思想是Future完成之后把结果作为一条消息发给某个目标actor。这个目标actor可以是你自己也可以是别的actor。关键是它绕开了“回调线程直接操作actor状态”的坑——在Akka里回调线程不是当前actor的调度线程直接在里面修改actor内部状态是线程不安全的。我举个典型场景一个订单actor调用外部支付服务支付结果以Future[PaymentResult]返回。这时候我不要在回调里尝试去改订单状态而是用pipeTo把PaymentResult包装成一条消息发回给自己或者发给一个专门的“支付结果处理actor”。顺序大概是paymentService.pay(orderId, amount).pipeTo(context.self)然后在你的Behavior里多定义一种消息类型比如PaymentResultReceived在消息处理逻辑里再更新状态。这样既避免了回调阻塞也保证了actor内部状态只在单线程的消息处理逻辑中被修改。关于pipeTo还有一个进阶用法把结果发给发送方而不是当前actor。比如一个CustomerActor向OrderActor发起了askOrderActor内部又需要使用外部服务那OrderActor可以这样写context.ask(orderJdbcRepository) { dao FetchOrder(dao, orderId) } .mapTo[OrderFetched] .pipeTo(sender)这样CustomerActor收到的响应是OrderFetched而不是收到一个中间状态。这是ask和pipeTo联动时非常顺手的一个写法可以保证调用链上的消息类型始终一致。2.4 我对三种方式的选型建议简单总结一下我的经验tell适合纯粹的异步命令不需要立即响应结果通过事件或其他消息路径传导。ask适合一次性的“请求-响应”交互尤其是外部系统同步等待结果的场景。pipeTo是辅助工具用来处理Future完成后的消息路由避免回调破坏actor的线程模型。还有一个习惯是强烈建议的一个actor对外暴露的接口不要全是ask。如果一个actor内部逻辑比较重每次都会被外部系统ask进来然后内部再ask其他actor这会出现嵌套ask超时设置会变得极度复杂。我现在的做法是对外边界HTTP、消息队列用ask内部actor之间尽量用tell事件推进这样内部链路不容易被超时问题缠住。3. 交流协议类型系统当契约3.1 协议就是Behavior[T]里的T交流方式解决“消息怎么传”交流协议解决“传的是什么”。在typed actor里协议和类型是绑定的。你定义一个actor时写的是Behavior[OrderCommand]那么OrderCommand就是你这门交流语言的全部词汇表。这个actor的指令、事件、响应都必须落在OrderCommand这个类型树里。所以定协议的第一件事是想清楚这个actor对外能接收哪些消息。这个设计一定要贴合领域模型不能图省事把协议做成一个大而全的“菜篮子”。我见过有人把OrderCommand定义成一堆字段的平铺大接口里面既有CreateOrder又有CustomerInfoQuery结果一个actor里塞了完全无关的职责。正确的做法是每一个命令类型都要对应一条明确的业务意图命令命名用祈使句CreateOrder、CancelOrder、ConfirmPayment事件命名用过去时OrderCreated、OrderCancelled、PaymentConfirmed响应类型尽量窄OrderCreatedAck、PaymentConfirmedAck。还有一个细节协议类型最好设计为不可变immutable。Akka是异步并发模型消息在多个actor之间传递如果消息对象可变等于你把共享可变状态穿过了邮箱。我习惯把所有命令类型定义成case class字段全部val再用final case class做响应类型这样编译期就能挡掉大部分可变状态的隐患。3.2 协议设计的第一原则把命令和事件分开命令command是你发给actor让它执行的动作事件event是这个actor做完事情后对外宣布的事实。很多初学者会把两者混在一起。比如订单actor接收CreateOrder命令内部处理完又要通知其他actor“订单已创建”很多人的第一反应是直接把OrderCreated也定义为OrderCommand的子类让所有actor都自己接收OrderCreated。这个设计想简单了。协议设计的核心价值是封装性。OrderCreated事件应该是订单actor内部的“私有语言”它要发布给谁、订阅方如何处理那是事件流或者pub/sub的范畴不应该反过来污染OrderCommand这个命令协议。否则你每增加一个订阅方所有命令类型的继承体系就会膨胀一分最终变成“一改协议十个actor跟着改”。我在实际项目中使用的模式是命令协议和事件协议分开继承树。订单actor的Behavior[OrderCommand]只接收命令事件通过context.system.eventStream或者项目内的事件总线发布。订阅事件的actor用Behavior[OrderEvent]接收事件两者互不混用。当然不是所有场景都适合“命令和事件解耦”。如果你的项目很小事件订阅方就一个那硬拆成两套协议反而麻烦。我在小型demo里会把命令和事件定义在一个sealed trait下用Command和Event两个子接口隔开。这样编译依然安全代码也不散。但凡是面向未来会有多个监听方的系统我还是建议命令和事件分层放到不同的包和类型树里越早拆越省心。3.3 协议演进的一个实用思路协议最怕的是“加字段”。一旦你确定了一个消息类型线上可能有几十个actor在处理它。这时候你想给OrderCreated加一个sourceChannel字段类型系统会帮你把所有引用点全部标红。看起来是麻烦但其实是好事——它逼着你评估这次改动的影响范围。对于这种演进我的经验是尽量不修改已有消息类型而是新增消息类型或者用“适配器模式”做转换。比如原来OrderCreated没有sourceChannel字段我不会在已有类型上加一个可空字段而是定义一个新的OrderCreatedV2让源头actor发出新版本事件订阅端各取所需。过两个版本再把旧的OrderCreated删掉。这个做法听上去有点笨但它有两个实打实的好处第一老版本代码不用立刻全量迁移可以灰度切换第二避免“可空字段”在代码里到处判空。我在这块吃过亏——曾经为了图省事在一个消息里加了一个可空字段结果后面有六处地方都在if (msg.sourceChannel ! null)看着就想重构。3.4 适配器与消息翻译别让协议污染到家门口在实际项目中两个系统之间的协议几乎不可能天然一致。比如订单actor内部用的是OrderCommand但外部HTTP接口的入参是某种特定格式。如果直接把HTTP的DTO类型塞进OrderCommand你的actor系统就被外部协议绑架了。typed actor里有一个专门解决这个问题的机制messageAdapter。它可以把一种消息类型转换成当前actor能处理的类型。举个例子你给某个第三方服务actor发了一个委托请求第三方返回的是它自己定义的GatewayResponse而你的订单actor里不打算处理这种类型。这时候可以在订单actor里注册一个转换器把GatewayResponse包装成OrderCommand.GatewayResponseReceived这样订单actor的协议树保持干净你只需要在适配器函数里做映射。再一个问题前提同一进程内的ActorRef是不能跨进程直接发送的。如果你的系统要做远程节点通信协议就需要序列化字段增删会影响序列化兼容性。我建议一旦剧透到序列化就要尽早考虑协议里类型的版本字段否则今后升级协议时老节点收到的消息可能会反序列化失败。这也是协议设计的“进阶必修课”。4. 我在用typed交流时踩过的坑4.1 ask超时到底设置多少开头说过超时时间不能一刀切但这里我专门把它列成一个坑是因为太多人在这上面栽跟头。有一次我在一个用户服务里调用用户actor查询用户详情ask设置了2秒超时。正常时没问题但有一次数据库连接池阻塞用户actor处理查询整整等了5秒结果ask已经超时了。超时抛异常后调用方对用户展示的是“系统繁忙”而用户actor那边实际是查询成功的只是响应回来的时候已经晚了。这个问题的本质是ask的超时是调用方的等待上限不是目标actor的执行上限。你设了2秒目标actor硬是要花5秒处理完之后它往临时引用里回发的消息根本没人接收。所以调大超时是一方面更重要的是要在目标actor内部做“快速失败”或者“熔断”确保它能做到超时返回错误而不是让调用方干等。我的经验是对内部actor超时设置2~3倍于“P99响应时间”对外部边界超时设置5~10秒并且配合重试策略但前提是目标操作是可重放的幂等。如果你连平均响应时间都不知道先压测再说别凭感觉设一个数。4.2 ClassCastException协议转型失败的典型案例typed actor在编译期能挡掉大部分类型问题但运行时依然可能遇到ClassCastException最常见的原因是你给一个ActorRef[GatewayResponse]发送了OrderCommand然后接收方用case command: OrderCommand去匹配结果发现这个类型根本不在它的协议里。还有一种隐蔽情况同一个类名在不同业务模块里各自定义了一份。比如订单模块和支付模块都定义了PaymentResult但它们结构不一样序列化之后反序列化回来时接错了类型版本。这个问题在单JVM内不明显一旦分布式部署就会冒出离奇的ClassCastException。针对这种问题我的建议是第一所有跨actor传递的消息类名一定带业务模块前缀避免不同模块出现同名的case class第二消息类型定义放到公共协议包而不是散落在各模块内部第三如果是序列化相关一定要用带类型的序列化格式比如Protobuf或Kryo并且做兼容性测试。4.3 dead letters消息发给了谁用过Akka的人对dead letters应该不陌生。它本质上是一个特殊的actor专门接收“无法投递”的消息。常见的触发场景包括消息发送时目标actor已经stop、发送的ActorRef是过期的actor重启后引用变了、或者目标actor正处在暂停状态。我早期排查一个“订单状态不更新”的bug时花了很长时间查逻辑最后在日志里发现了dead letters的警告——原来是一个子actor在某次异常重启后父actor里保存的ActorRef还是旧的继续往旧引用发消息当然全进了死信队列。在typed actor里这个问题依然存在。ActorRef的生命周期和使用者之间是有绑定的你一旦spawn了一个子actor并在父actor里持有它的引用就要在子actor restart或者stop时妥善地替换这个引用。或者你使用context.watch监听子actor的结束信号确保自己持有的引用不会陈腐。还有一点如果系统正常运行时频繁出现dead letters那多半不是bug就是资源泄漏。我建议把它作为重要监控指标一旦增长速度明显就得排查是否有actor被重复stop或者某个ActorRef被长时间缓存未刷新。4.4 协议膨胀一个Actor的T越写越大如果说上面几个坑是有明确报错的那么协议膨胀就是一个默默腐烂的坑。现象是某个actor的Behavior[T]里T的继承树越来越大消息类型几十个字段越来越长接收方match语句越写越长而实际上很多消息一年到头都不会触发一次。造成这个问题的原因是“把所有消息都堆在一个actor里”。我在项目里接手过一个“超级审计actor”它既处理日志写入、又处理用户操作记录、还处理告警推送协议自然膨胀。解决办法是拆分每个职责一个actor父actor只负责消息路由具体业务由专门的子actor处理。父actor的协议收敛为“路由指令”子actor各自维护自己的领域协议。所以定义协议时有一个我特别有心得的原则协议不是越全越好而是越“窄”越好。一个actor只处理它必须处理的那些消息其余的全部路由出去。这不会增加多少代码量但会让系统的边界极其清晰。我宁可拆出十个各司其职的小actor也不愿意写一个处理百种消息的大actor。5. 一点个人体会写在最后的建议这个系列写到第二篇我想说一个很主观、但大概率你也认同的感受typed actor的学习曲线不是“会用API”而是“愿意被类型约束”。很多从经典actor过来的人最不适应的是不能随心所欲地发消息不能把任何对象扔给某个actor让它自己处理。但恰恰是这种约束逼着你在设计阶段就把协议想清楚、把交流方式定妥而不是等项目上线后再靠人肉约定去维护。如果你现在正在把一套经典actor系统切到typed actor我的建议是不要一个大版本一次性切完。挑一个边界清晰的业务模块比如订单或库存先从Behavior[T]和协议定义开始改写跑通一条完整的tell/ask/pipeTo链路再逐步扩大范围。这个过程中你会发现类型系统替你做掉的遗漏比你想象的要多。另外最后分享一个实操小技巧定义协议时哪怕最开始只有两个消息类型我也习惯把它们都放进一个sealed trait或者一个封闭的接口体系里。这样后续扩展协议时所有分支都可以被强制检查是否穷尽编译器能帮你在所有处理逻辑里标注“还差哪些case没处理”。这个习惯不花什么成本却能在协议演进时避免很多“漏分支”的低级错误。