消息系统与轻量化计算

消息系统作为一个核心的基础架构组件由来已久，而且运用广泛。整个消息系统的演化进程，大致可以分为三个阶段：

首先是各类MQ的时代以实现组件之家的解耦合为目的；

然后是现阶段以构建实施消息管道为目的，以kafka为代表；

随着今年（2018年）Pulsar的获奖，流数据平台时代恐怕要到来了。

流数据平台有两个关键词，一是流数据，也是就是活数据，我个人是数据域未来的趋势和方向；二是平台化，之前消息系统只是一个组件，采用分区的方式解决消息的生产和消费的问题，消息的持久化也只是简单的采用文件系统进行落盘，没有真正实现计算和存储分离，未来流数据平台化必要要考虑这些。

一、批流一体化框架

传统的Lambda架构下的数据域平台，基本采用批处理和流处理分别处理的思路，同时实现兼容。无论是 Flink 还是 Spark（streaming），流计算还是批计算的边界已经变得模糊。用户真正关心的是如何更好更快地使用数据，如何从数据中更快地挖掘出其中的价值。而这其中最核心的思维转变是，流数据和静态数据不再是不同的数据，它们其实是同一份数据的两种不同表征方式。

二、问题在哪儿

传统消息系统（比如kafka）以分区为中心的架构设计是面向物理机时代的架构设计，基本上是紧耦合了消息服务和消息存储。降低了系统的可扩展性和服务可用性。传统消息系统的持久化普遍考虑比较简单，没有跟云平台整体进行统筹考虑，存储设计过于简单，导致其进行多租户管理、IO 隔离以及平台化转型过程中，需要解决架构上的很多缺陷。

三、江山代有才人出

今年InfoWorld最佳开源数据平台奖公布，连续两年入选的 Kafka 这次意外失手，pulsar取而代之。这说明了什么，趋势。Apache Pulsar 在架构上最明显的优势是采用了消息服务和消息存储分层的策略。它包括了无状态的消息服务层和消息存储层。这为系统带来了极好的扩展性和健壮性。而且pulsar支持多租户， 重要问题说三遍，多租户、多租户、多租户！！！ 下面是从网上抄的pulsar对比kafka的关键特性：

1、broker与日志存储分离，而kafka的broker则依赖节点上的文件系统，pagecache与本地磁盘

2、多租户的功能，权限，配额，流控等，而kafka前期并没有这些特性，后续才慢慢增加这些功能

3、运维更简单，尤其在broker扩展时候，kafka需要将分区的数据迁移到新的broker上，而purlsa并不需要

四、流数据的轻量计算

随着微服务的兴起，以及事件驱动架构的流行，有一种趋势是在消息系统上添加轻量化计算。比如Kafka 引入了 KStreams，使用了传统的流计算的概念，只是将计算变得轻量化，不再依赖于某个计算平台，用户可以选择自己最适合的部署方式；而 Pulsar 则走了截然不同的一条路径，它跳脱出了传统流计算的模型，而借鉴了 Serverless 的概念，将 Serverless Function 引入了消息系统内部。用户可以通过编写原生的 Function 来进行任意逻辑的计算。以 Function 为主导的轻量化计算让用户更加关注于计算逻辑本身，适用于一些简单计算，比如 Filtering、Aggregation、Routing 等。

如此一来，数据的计算势必会分成在前端的消息阶段的轻量化简单计算还有平台侧的通用计算，消息的轻量计算由新的消息平台处理，更厚重的通用计算自然还是批流一体化框架负责。