Akka-CQRS（0）- 基于akka-cluster的读写分离框架，构建gRPC移动应用后端架构

上一篇我们讨论了akka-cluster的分片（sharding）技术。在提供的例子中感觉到akka这样的分布式系统工具特别适合支持大量的带有内置状态的，相对独立完整的程序在集群节点上分布运算。这里重点要关注这些程序的内部状态，它们会占用系统资源包括内存。把状态保存在内存里相对存放在数据库里能显著提高程序运算效率。在系统出现各种情况下对这些非持久化的程序状态的管理自然就成为了需要考虑的问题，此其一。在一个多用户、高并发的大型分布式系统里往往数据库数据使用会产生大量的冲突影响系统性能。如果能够把数据库的写入和读取分成互不关联的操作就可以避免很多资源占用的冲突。

CQRS(Command Query Responsibility Segregation 读写责任分离)就是解决读写分离问题的一个很好的框架。CQRS实际上应该是一种大量数据并发录入的解决方案。通过读写分离降低数据录入过程对系统响应的影响。

akka-CQRS大约是由event-sourcing、persistenceActor、persistenceQuery三个部分组成。event-sourcing+persistenceActor是一种数据库存写模式。传统数据库的数据更新一般直接更改数据表里的数据值。而event-sourcing模式是把所有更该数据的事件（events）或者说是动作都存放在一个log（journal）表里。如果把这个journal表里的所有记录都重新演算一下，任何时间都可以得出数据库表里当前的状态值。当然，这个journal表可能会存放大量的数据，但在大数据时代的分布式系统里这也算不了什么。由于journal表的写入永远是从后附加的，是一种不可变模式（immutable）,所以效率很高，可以支持大数据表的写入。再就是journal表里记录的事件是严格按发生时间顺序的，所以在重新运算更新状态时发生冲突机会甚微，而且一旦真的发生异常还可以再重新演算journal里的记录恢复正确的状态。

persistenceQuery则是一套与事件存写完全分离代表CQRS Q的读取部分，主要工作是定时按批量从journal里读取记录再把event还原成为数据库更新语句然后对系统业务数据库进行更新。而业务应用软件的数据操作，如业务查询、处理、分析等都是针对业务数据库的。

最近在考虑搞一套主要以移动设备为业务工具的信息系统框架。由于移动OS相对功能较弱，加上编程困难等，最好只负责应用的前端录入和表达部分。所有业务逻辑就只能放在后端了。打比方说如果开发一套基于android的POS收银系统，所有收银操作指令都在后端执行，然后向前端返回结果。这样的POS前端只负责采集指令输入然后显示后端处理结果。根据上篇对akka-cluster-sharding应用场景分析，我们可以用一个分片shard来负责一台POS机后端。考虑到akka-cluster集群分布式运算可扩展能力特性，处理万级POS同时在线应该不成问题。当然，每个POS开单销售的过程都存放在内存作为每单销售的状态。这种资源分享的模式恰恰是akka-cluster-sharding的强项。剩下海量并发的数据库操作，就可以通过akka-CQRS框架来应对了。

另外，由于移动前端和后台系统都是企业内部应用系统，可以用gRPC模式替代传统主流的HTTP/1.0协议作为系统主要集成方式。gRPC方式是基于HTTP/2.0协议上的，可以实现点对点的持续连接，支持双向数据流操作，有效解决了request/response模式带来的效率问题。我们在前面的博客里已经构建了基于gRPC，多分布式数据库的数据流编程框架，可以直接采用。google的移动应用编程语言dart2也是支持gRPC的，从整体系统实现的可行性方面应该不会有什么问题了。

在下面跟着的几篇博客里我们会分别讨论event-sourcing,persistenceActor,persistenceQuery和gRPC。