Akka in 2 weeks

11:07下午 八月 23, 2011 in category Java by ingramchen

简而言之 Akka，是一个 inter-server computation framework。它的官网列出一堆有的没的 "功能" (但能做什麽应用没说)，一付好像要改变整个开发生态一样。

但 Akka 只适合拿来做 server 间的运算，因为它没有用户的 client (mobile/flash/web....etc)，所以使用上其实很局限的。好了，下一个问题来了：

你的需求是自己写 server cluster 吗？

    自己写 server 和 cluster
    自己写 server，但是不是 cluster
    不自己写 server 也自己不写 cluster。

我想第一种需求少的可怜，但这是唯一比较适合 Akka 的系统，第二种则是少数，而且通常都是写个 socket server 就好了，也没多大，这样的需求只需要 JBoss netty，而不是 Akka。第三种应该是最多的，大家都是拿现成的 apache / tomcat / RDBMS / NoSQL / hadoop / rabbitmq / jabber / solr .... 等等来兜，很少有需求需要自己苦干实干打造 cluster，尤其现在几乎是 web 服务的天下，更是如此。

Akka 的另一个面向是 Actor，event driven 式的开发。我自己写游戏写了两三年了，每天与 event 为伍，反到是没什麽特别的感觉。不用写 synchronize 和 java.util.concurrent 还蛮不错的，你可以用 single thread 的思考方式来写你的应用，唯一的要求是传递的讯息都是要 immutable 的。另外，用 event 的方式开发时，程式码会朝另一种複杂度走：

    在结构上会偏 pattern match 而不是 polymorphism (所以 Java 上比较惨)
    在相依性上则可以减到很低，但这也意味你很难看出整个流程
    最后，能用 single thread 的方式思考也代表你直接写出来的程式码其实是处处 synchronized，你必需自行找出几个瓶颈处，使用 router/load balancer 等技巧解开。

总之使用 Actor 后，思考的方式会变。这有比较好吗？我持保留态度。因为即使 Actor 包装过了，concurrent 的程式也不是一般人能碰的，而且你还是得懂 multi-thread 的概念才行。这就像是 ORM 可以爽爽用，但你不懂 SQL 迟早还是会撞牆，你还是得深入了解 SQL 才行。

话说回来，又有多少人的需求是 concurrent 的？大多数的 server 需求多是 stateless web server，concurrency 都交给 web server / db 做完了，不用自己写。最近到有个新趋势是 async web server，这个需求就很适合 Akka 来做。不过还是一样，大家只会选做好的 server，而不会自己用 Akka 刻。

前面提到 Akka 适合 inter-server 的运算。这是因为 Akka 提供超便利的 Remote Actor。要叫远端 server 做事吗？跟写 local actor 一样，开了就连上，直接开始传讯息，什麽繁杂事都不用做。不过 Remote Actor 的好处也到此为止了，其他写 cluster 时最需要的 Fail over, Replicate, Load balance, High Availability 一样也没有，你通通得自己写 (那特地选 Akka 的用意是....? 我干嘛不一开始就用 Netty 自己写？)。没这些高级功能就算了，最惨的是 Remote Actor crash 时不会通知! ，远端断了线或出错，本机端通通不知道，这种仅支援单向的联结，多了很多麻烦的事要处理....

讲 Akka 就一定会提到 Let it crash，这是 Akka CTO Jboner 每次演讲都会一提再提的概念。Let it crash 在实作上就是 -- Actor 出了 exception，它马上 crash，重建一个新的，让所有的 state 归零，重新开始。对于这样处处可以砍掉重练的思考方式我目前还不能体会。而且我也是有点怀疑砍掉重练的做法，有很多时候是一小部份的资料造成错误的，但却要捨弃所有做过的东西全部重来 (就像是用户开了三层的视窗、或逛到第五层迷宫，只因为小错误就要一切从头，用户不晕倒才怪)。

Let it crash，我目前可以 想像 的架构是，将一个功能切碎成一大堆的子功能，每个子功能交给不同的 Actor 执行，这样如果 crash 时损失就比较少了，不过程式码的複杂性/负载平白无故的增加 (本来一行 method call，变成要建立一个专用的 actor...)，这实在很难说是一个更好的架构。

其他的很时氅的什麽 Software Transactional Memory 的功能我还没碰过，不过我很怀疑 STM 的实用性。通常记忆体内的 state 坏了整个丢掉，重新再来就好，只有像 persistence 会留下半毁的资料才需要考虑 transaction。STM 个人认为像是耍花腔，重看不重用。

Akka 虽然已经 1.0 了，但是 API 变动的幅度还是很大，1.1 到 1.2 又 deprecate 一狗票 API，所以还不是很成熟，而 Akka 大概会在年底推出 2.0 ，那时候 Remote Actor 就会有 Fail over, Replicate, Load balance 等等梦幻的功能。还没出手的玩的，建议等到 2.0 再开始玩吧，反正 1.x 的 API 到时又会丢掉一大堆。当然如果你跟我一样现在就要写 cluster，那就硬着头皮直接冲吧。

ps. 我使用 Akka Java API 开发，不是用 Scala