今天我们来谈一下akka的序列化框架，其实序列化、反序列化是一个老生常谈的问题，那么我们为什么还要研究一下akka的序列化框架呢？不就是使用哪种序列化、反序列化方法的区别么？其实刚开始的时候我也是这么想的，但是针对性、系统性的分析一下akka的序列化、反序列化过程，就会发现这个问题其实还是挺有意思的。
我们首先来看下什么是序列化、反序列化。序列化 (Serialization)将对象的状态信息转换为可以存储或传输的形式的过程；反序列化，就是通过从存储区中读取或反序列化对象的状态，重新创建该对象。举个栗子，在跨网络传输的过程中，传输的都是二进制数，是无法直接传输对象的。对象是什么呢？数据和算法，状态和方法。数据就是对象的状态，比如一个整型字段的值，字符串的具体内容；算法就是对象所属的方法，简单来说就是二进制可执行代码。统一来看，他们都可以是二进制数据。那么为啥在序列化的定义中，没有说算法的。想想都知道，当然是为了减少传输的数据量啊。而且代码这部分不传输也是可以的，毕竟网络的两端代码这部分是需要预先协商好的。
那既然序列化就是用来保存、传输对象的状态的，那为啥还要单独研究akka的序列化框架呢？因为我喜欢！啊哈哈，其实也不是。主要是akka的序列化是一个框架，而不是只单独的某个算法或jar包。因为在这个框架内，你可以单独制定每个class的序列化、反序列化对应的实现。
记得之前在分析remote的时候，我们有谈到过序列化，下面还从这部分开始分析，因为这比较直接。如果上来就分析整个框架，比较容易迷失。
上面是跨网咯传输数据的相关代码，很明显，这里调用了codec.constructMessage，生成了pdu，然后调用handle.write把数据发送出去了。
def constructMessage(
localAddress: Address,
recipient: ActorRef,
serializedMessage: SerializedMessage,
senderOption: OptionVal[ActorRef],
seqOption: Option[SeqNo] = None,
ackOption: Option[Ack] = None): ByteString
也就是说constructMessage把待发送的消息转化成了ByteString，这就是可以跨网络传输的二进制数据流。不过还调用了serializeMessage这个方法，把用户待发送的消息序列化了。其实我们应该特别注意这一点，为啥呢？因为这意味着用户待发送数据的序列化和系统消息的序列化分开了，或者说是两个层面的东西。啥意思呢？简单来说就是，akka先调用序列化方法（可以是任意自定义）把用户待发送数据转成ByteString，然后把这个数据设置成系统消息的某个字段，再调用系统序列化器把系统消息序列化。
override def constructMessage(
localAddress: Address,
recipient: ActorRef,
serializedMessage: SerializedMessage,
senderOption: OptionVal[ActorRef],
seqOption: Option[SeqNo] = None,
ackOption: Option[Ack] = None): ByteString = {
val ackAndEnvelopeBuilder = AckAndEnvelopeContainer.newBuilder
val envelopeBuilder = RemoteEnvelope.newBuilder
envelopeBuilder.setRecipient(serializeActorRef(recipient.path.address, recipient))
senderOption match {
case OptionVal.Some(sender) ⇒ envelopeBuilder.setSender(serializeActorRef(localAddress, sender))
case OptionVal.None ⇒
}
seqOption foreach { seq ⇒ envelopeBuilder.setSeq(seq.rawValue) }
ackOption foreach { ack ⇒ ackAndEnvelopeBuilder.setAck(ackBuilder(ack)) }
envelopeBuilder.setMessage(serializedMessage)
ackAndEnvelopeBuilder.setEnvelope(envelopeBuilder)
ByteString.ByteString1C(ackAndEnvelopeBuilder.build.toByteArray) //Reuse Byte Array (naughty!)
}
上面是constructMessage的具体实现，可看到envelopeBuilder.setMessage(serializedMessage)这行代码确实把序列化后的数据赋值给了某个字段。
public Builder setMessage(akka.remote.WireFormats.SerializedMessage value) {
if (messageBuilder_ == null) {
if (value == null) {
throw new NullPointerException();
}
message_ = value;
onChanged();
} else {
messageBuilder_.setMessage(value);
}
bitField0_ |= 0x00000002;
return this;
}
这是setMessage的代码。需要特别注意的是它的参数是SerializedMessage类型，而不是ByteString。这意味着什么呢？这意味着，还有一层。
目前来看，序列化的过程大概是上面这个样子。那上面的系统消息又是啥呢？我们来分析ackAndEnvelopeBuilder.build.toByteArray这段代码。首先来看build返回了什么。
public akka.remote.WireFormats.AckAndEnvelopeContainer build() {
akka.remote.WireFormats.AckAndEnvelopeContainer result = buildPartial();
if (!result.isInitialized()) {
throw newUninitializedMessageException(result);
}
return result;
}
它返回了一个AckAndEnvelopeContainer，那就可以再补充一下上面的图。
下面是AckAndEnvelopeContainer的继承关系。
其实AckAndEnvelopeContainer内部还有其他的对象，但也不需要再过多深入分析，因为他们的序列化方法都是一样的。
从上面红框开始，相关的序列化好像都是akka框架自定义的，那么它又是如何支持用户自定义序列化方法的呢？答案就在前面的serializeMessage方法中。
private def serializeMessage(msg: Any): SerializedMessage = handle match {
case Some(h) ⇒
Serialization.currentTransportInformation.withValue(Serialization.Information(h.localAddress, extendedSystem)) {
MessageSerializer.serialize(extendedSystem, msg.asInstanceOf[AnyRef])
}
case None ⇒
throw new EndpointException("Internal error: No handle was present during serialization of outbound message.")
}
很明显，最终调用了MessageSerializer.serialize把用户自定义消息转化成了SerializedMessage。那SerializedMessage是用来干啥的呢？其实直观上来说，它还是用来保存用户序列化后的数据的，跟前面的伎俩一样，把ByteString赋值给某个字段。目前猜测来看，的确是这样的，但又感觉那里不对。4
从SerializedMessage的继承关系和字段来看，好像确实是这样的。但需要注意这个类又两个ByteString的字段，分别是message_ 和 messageManifest_。一个是序列化后的消息，一个是序列化后消息的声明。
/**
* Uses Akka Serialization for the specified ActorSystem to transform the given message to a MessageProtocol
* Throws `NotSerializableException` if serializer was not configured for the message type.
* Throws `MessageSerializer.SerializationException` if exception was thrown from `toBinary` of the
* serializer.
*/
def serialize(system: ExtendedActorSystem, message: AnyRef): SerializedMessage = {
val s = SerializationExtension(system)
val serializer = s.findSerializerFor(message)
val builder = SerializedMessage.newBuilder
val oldInfo = Serialization.currentTransportInformation.value
try {
if (oldInfo eq null)
Serialization.currentTransportInformation.value = system.provider.serializationInformation
builder.setMessage(ByteString.copyFrom(serializer.toBinary(message)))
builder.setSerializerId(serializer.identifier)
val ms = Serializers.manifestFor(serializer, message)
if (ms.nonEmpty) builder.setMessageManifest(ByteString.copyFromUtf8(ms))
builder.build
} catch {
case NonFatal(e) ⇒
throw new SerializationException(s"Failed to serialize remote message [${message.getClass}] " +
s"using serializer [${serializer.getClass}].", e)
} finally Serialization.currentTransportInformation.value = oldInfo
}
这两个字段先忽略，先来看serialize这个方法。需要注意这段代码builder对象的三个set方法。它分别设置了序列化后的消息、消息的声明，还有一个是序列化器的identifier。
上面是Serializer的trait。抛开与序列化、反序列化相关的方法定义，第一个字段是一个identifier。从中文释义和官方注释来看，这是一个序列化器的数字标志，用以区分不同的序列化器。0~40是官方预留值，标志内部序列化用途，那为啥是40呢？你猜，哈哈哈，我也不知道，大概是官方觉得预留40个内部序列化器应该够用了吧。啥？如果不够用？鬼知道。
那为什么每个序列化器都需要一个identifier呢？后面再说吧。
/** * Returns whether this serializer needs a manifest in the fromBinary method */ def includeManifest: Boolean
其实Serializer还有一个非常重要的方法：includeManifest。它标志当前序列化器是否包含消息声明。那这个消息声明具体有啥用呢？
def manifestFor(s: Serializer, message: AnyRef): String = s match {
case s2: SerializerWithStringManifest ⇒ s2.manifest(message)
case _ ⇒ if (s.includeManifest) message.getClass.getName else ""
}
从获取消息声明的代码来看，它首先判断是否为SerializerWithStringManifest类型，如果是就调用manifest返回消息声明；否则就判断是否需要消息声明，如果需要则获取当前class的名称，否则返回空字符串。目前我们知道当前class的名称可以是消息的声明。那我们应该能大胆的猜测这个字段的意义了。
它是用来给反序列化提供相关的参数或信息的。因为序列化后的对象都是二进制数据，在接收端怎么知道该用哪个序列化器进行反序列化呢？如果有这部分二进制数据对应的类名，那就可以从配置里面查找到了！！！这有什么意义呢？其实我们在开发系统的时候，一般都非常具有针对性，或者说不会考虑通用性。比如会在系统设计阶段，使用固定的序列化器，比如kryo，或Hessian。这就意味着我们已经提前知道了该用哪种序列化框架，不需要进行选择。拿过来的数据，用对应的序列化器反序列化就好了，不用担心格式不兼容！！！所以一般是没有manifest的。所以我觉得manifest是通用序列化框架的关键。
其实SerializerWithStringManifest继承了Serializer，就是多提供了一个manifest方法。
/** * Return the manifest (type hint) that will be provided in the fromBinary method. * Use `""` if manifest is not needed. */ def manifest(o: AnyRef): String
就是返回给定消息的类型提示字符串。
那么在序列化之前是如何知道改用那个序列化器呢？答案就在SerializationExtension.findSerializerFor这个方法上。
/**
* Returns the Serializer configured for the given object, returns the NullSerializer if it's null.
*
* Throws akka.ConfigurationException if no `serialization-bindings` is configured for the
* class of the object.
*/
def findSerializerFor(o: AnyRef): Serializer =
if (o eq null) NullSerializer else serializerFor(o.getClass)
/**
* Returns the configured Serializer for the given Class. The configured Serializer
* is used if the configured class `isAssignableFrom` from the `clazz`, i.e.
* the configured class is a super class or implemented interface. In case of
* ambiguity it is primarily using the most specific configured class,
* and secondly the entry configured first.
*
* Throws java.io.NotSerializableException if no `serialization-bindings` is configured for the class.
*/
@throws(classOf[NotSerializableException])
def serializerFor(clazz: Class[_]): Serializer =
serializerMap.get(clazz) match {
case null ⇒ // bindings are ordered from most specific to least specific
def unique(possibilities: immutable.Seq[(Class[_], Serializer)]): Boolean =
possibilities.size == 1 ||
(possibilities forall (_._1 isAssignableFrom possibilities(0)._1)) ||
(possibilities forall (_._2 == possibilities(0)._2))
val ser = {
bindings.filter {
case (c, _) ⇒ c isAssignableFrom clazz
} match {
case immutable.Seq() ⇒
throw new NotSerializableException(s"No configured serialization-bindings for class [${clazz.getName}]")
case possibilities ⇒
if (unique(possibilities))
possibilities.head._2
else {
// give JavaSerializer lower priority if multiple serializers found
val possibilitiesWithoutJavaSerializer = possibilities.filter {
case (_, _: JavaSerializer) ⇒ false
case (_, _: DisabledJavaSerializer) ⇒ false
case _ ⇒ true
}
if (possibilitiesWithoutJavaSerializer.isEmpty) {
// shouldn't happen
throw new NotSerializableException(s"More than one JavaSerializer configured for class [${clazz.getName}]")
}
if (!unique(possibilitiesWithoutJavaSerializer)) {
_log.warning(LogMarker.Security, "Multiple serializers found for [{}], choosing first of: [{}]",
clazz.getName,
possibilitiesWithoutJavaSerializer.map { case (_, s) ⇒ s.getClass.getName }.mkString(", "))
}
possibilitiesWithoutJavaSerializer.head._2
}
}
}
serializerMap.putIfAbsent(clazz, ser) match {
case null ⇒
if (shouldWarnAboutJavaSerializer(clazz, ser)) {
_log.warning(LogMarker.Security, "Using the default Java serializer for class [{}] which is not recommended because of " +
"performance implications. Use another serializer or disable this warning using the setting " +
"'akka.actor.warn-about-java-serializer-usage'", clazz.getName)
}
log.debug("Using serializer [{}] for message [{}]", ser.getClass.getName, clazz.getName)
ser
case some ⇒ some
}
case ser ⇒ ser
}
简单来说这个方法就是从SerializationExtension这个扩展配置的序列化器中根据类的claz信息找到一个序列化器，如果找不到就招父类对应的序列化器，如果还找不到那就用Java默认的序列化器。
其实序列化的过程可以简单总结为上面这样的流程图。下面我们简要分析一下反序列化的过程。
上面是收到消息时的处理过程，很显然调用了tryDecodeMessageAndAck方法。
private def tryDecodeMessageAndAck(pdu: ByteString): (Option[Ack], Option[Message]) = try {
codec.decodeMessage(pdu, provider, localAddress)
} catch {
case NonFatal(e) ⇒ throw new EndpointException("Error while decoding incoming Akka PDU", e)
}
这个方法输入是一个ByteString，返回一个Tuple，第二个类型是Message。
override def decodeMessage(
raw: ByteString,
provider: RemoteActorRefProvider,
localAddress: Address): (Option[Ack], Option[Message]) = {
val ackAndEnvelope = AckAndEnvelopeContainer.parseFrom(raw.toArray)
val ackOption = if (ackAndEnvelope.hasAck) {
import scala.collection.JavaConverters._
Some(Ack(SeqNo(ackAndEnvelope.getAck.getCumulativeAck), ackAndEnvelope.getAck.getNacksList.asScala.map(SeqNo(_)).toSet))
} else None
val messageOption = if (ackAndEnvelope.hasEnvelope) {
val msgPdu = ackAndEnvelope.getEnvelope
Some(Message(
recipient = provider.resolveActorRefWithLocalAddress(msgPdu.getRecipient.getPath, localAddress),
recipientAddress = AddressFromURIString(msgPdu.getRecipient.getPath),
serializedMessage = msgPdu.getMessage,
senderOption =
if (msgPdu.hasSender) OptionVal(provider.resolveActorRefWithLocalAddress(msgPdu.getSender.getPath, localAddress))
else OptionVal.None,
seqOption =
if (msgPdu.hasSeq) Some(SeqNo(msgPdu.getSeq)) else None))
} else None
(ackOption, messageOption)
}
上面是decodeMessage的源码，第一行是用来反序列化的。
public static akka.remote.WireFormats.AckAndEnvelopeContainer parseFrom(byte[] data)
throws akka.protobuf.InvalidProtocolBufferException {
return PARSER.parseFrom(data);
}
它返回一个AckAndEnvelopeContainer对象。怎么样这个类型是不是比较熟悉？没错，在序列化的过程中，用户消息的最终序列化数据传给了这个对象，然后序列化发送出去的。
后面的代码就是在解析AckAndEnvelopeContainer的其他字段了，比如Recipient/Sender/Seq等。其中我们最关心的是Message。还记得这个Message的类型是什么吗？没错就是SerializedMessage。
不过上面的代码并没有对用户消息进行反序列化，而是调用msgDispatch.dispatch(msg.recipient, msg.recipientAddress, msg.serializedMessage, msg.senderOption)对消息进行处理。
很显然，用户消息最终调用了MessageSerializer.deserialize进行反序列化。
/**
* Uses Akka Serialization for the specified ActorSystem to transform the given MessageProtocol to a message
*/
def deserialize(system: ExtendedActorSystem, messageProtocol: SerializedMessage): AnyRef = {
SerializationExtension(system).deserialize(
messageProtocol.getMessage.toByteArray,
messageProtocol.getSerializerId,
if (messageProtocol.hasMessageManifest) messageProtocol.getMessageManifest.toStringUtf8 else "").get
}
它还是通过SerializationExtension这个扩展来反序列化的。同样有三个参数：message，serializerID，Manifest。
/**
* Deserializes the given array of bytes using the specified serializer id,
* using the optional type hint to the Serializer.
* Returns either the resulting object or an Exception if one was thrown.
*/
def deserialize(bytes: Array[Byte], serializerId: Int, manifest: String): Try[AnyRef] =
Try {
val serializer = try getSerializerById(serializerId) catch {
case _: NoSuchElementException ⇒ throw new NotSerializableException(
s"Cannot find serializer with id [$serializerId]. The most probable reason is that the configuration entry " +
"akka.actor.serializers is not in synch between the two systems.")
}
deserializeByteArray(bytes, serializer, manifest)
}
首先根据serializerId找到本节点对应的序列化器，这意味着什么呢？这意味着所有的节点，相同的序列化器都必须具有相同的serializerId。这就是serializerId的意义。
private def deserializeByteArray(bytes: Array[Byte], serializer: Serializer, manifest: String): AnyRef = {
@tailrec def updateCache(cache: Map[String, Option[Class[_]]], key: String, value: Option[Class[_]]): Boolean = {
manifestCache.compareAndSet(cache, cache.updated(key, value)) ||
updateCache(manifestCache.get, key, value) // recursive, try again
}
withTransportInformation { () ⇒
serializer match {
case s2: SerializerWithStringManifest ⇒ s2.fromBinary(bytes, manifest)
case s1 ⇒
if (manifest == "")
s1.fromBinary(bytes, None)
else {
val cache = manifestCache.get
cache.get(manifest) match {
case Some(cachedClassManifest) ⇒ s1.fromBinary(bytes, cachedClassManifest)
case None ⇒
system.dynamicAccess.getClassFor[AnyRef](manifest) match {
case Success(classManifest) ⇒
val classManifestOption: Option[Class[_]] = Some(classManifest)
updateCache(cache, manifest, classManifestOption)
s1.fromBinary(bytes, classManifestOption)
case Failure(e) ⇒
throw new NotSerializableException(
s"Cannot find manifest class [$manifest] for serializer with id [${serializer.identifier}].")
}
}
}
}
}
}
很明显，首先判断Serializer是不是SerializerWithStringManifest，如果是就传入发送过来的manifest；如果不是且manifest是空字符串，则调用fromBinary时，第二个参数为空（也就是manifest）；如果manifest不为空，则从manifestCache中找到对应的manifest信息，传入fromBinary；如果manifestCache没找到，则动态加载manifest信息，更新manifestCache后再传入fromBinary。
至此，反序列化过程结束。
上面是我们总结的akka的序列化框架。消息的序列化可以分为三层：用户消息、用户消息序列化后对应的SerializedMessage、SerializedMessage对应的AckAndEnvelopeContainer。其中AckAndEnvelopeContainer的序列化是系统提供的，用户无法自定义；SerializedMessage是系统序列化和用户自定义序列化的中间层，提供一个适配的功能，比如提供序列化器的ID以及消息的声明信息；用户消息是基础层，可以使用自定义序列化器进行序列化。在反序列化时先反序列化城AckAndEnvelopeContainer，进行一些系统级的操作，然后根据SerializedMessage的序列化器ID查找对应的序列化器，反序列化用户消息。至此一个通用的序列化、反序列化流程设计完毕，而且还很通用的额。其实简单来说就是，解耦了“变”和“不变”。“变”是指用户的序列化器可能不变通，而且支持自定义；“不变”是指系统级消息的序列化过程不变，所有节点都一样。
怎么样，你对akka设计的这个通用的序列化框架怎么看？是不是觉得挺好用的？我觉得这个分层设计的概念大家应该学会，这有助于我们照葫芦画瓢也设计一个类似的序列化框架。啥？你的序列化不需要通用？那你总会遇到schema变迁、升级的问题的。