微服务中的数据处理逻辑就用Java硬写吗?

为了保证微服务的可扩展性数据库往往主要做数据持久化,而不过多承担数据处理的工作,数据处理主要在应用端通过 Java 完成。这样可以解耦应用和数据库,数据库更换或扩容都不会对微服务产生过大影响,充分发挥微服务的效力。

那么微服务中的数据处理逻辑只能使用 Java 硬编码吗?

要回答这个问题,我们要梳理一下目前能实现微服务中数据处理工作的技术还有哪些。

数据库 SQL

强依赖数据库处理数据会影响微服务扩展。在具体实施时,如果多个微服务共享一个数据库会引发单点故障;如果采用一对一方式按业务拆分的微服务会面临分布式事务、数据分布以及跨服务请求数据计算困难等问题。这种方式严重违背了微服务的设计原则,因此很少采用。

其他开发语言

除了 Java 和 SQL 还有一些具备一定数据处理能力的开发语言,比如 Scala、Python 和 Kotlin。这些技术要么使用门槛较高(如 Scala),要么很难跟 Java 微服务框架结合(如 Python),要么实施计算不方便(如 Kotlin),要么不支持热部署(如 Scala 和 Kotlin)。这些技术与 Java 比起来并没有太多长处,反而因为目前主流的微服务框架都基于 Java 开发,使用 Java 处理数据天然适配。

那么使用 Java 处理数据有哪些优缺点呢?

显而易见的优点是与主流微服务框架的无缝结合,其次基于 Java 可以实施分步计算。不过,Java 的缺点也非常明显。Java 缺乏结构化计算类库,实现数据处理非常困难,简单的分组运算也要几十行代码,复杂计算的编码量简直难以承受,即使 Java8 以后引入 Stream 也并无明显改善。这方面就远没有 SQL 方便了。此外,Java 作为编译型语言很难热部署,对多变的微服务场景并不友好。

由此可见,其他技术无法满足微服务数据处理要求,就只能硬着头皮用 Java 硬编码了,虽然困难,但相对其他技术还是有优势的。

集算器 SPL 的出现改变了这个现状,使用集算器进行微服务数据处理可以很好地继承 Java 的优点并改善其缺点。集算器是一款开源数据处理引擎,不仅能与 Java 应用(微服务框架)无缝集成,还提供了完备的计算能力,基于集算器的 SPL 语法实施计算的简便性远超 Java(甚至 SQL),为微服务数据处理提供了新思路。

数据源方面,集算器支持多种数据源类型,RDB、NoSQL、Json、CSV、HDFS、RESTApi 等,还可以基于这些数据源混合计算。

在数据处理算法实现方面,集算器采用自有的 SPL 语法,下面的例子可以感受到 SPL 的简洁程度。

根据股票记录表查询股价连续上涨超过 5 天的股票及上涨天数(股价相等记为上涨)

A
1 =db.query@x("select * from stock_record order by   ddate")
2 =A1.group(code)
3 =A2.new(code,~.group@i(price<price[-1]).max(~.len())-1:maxrisedays) 计算每只股票的连续上涨天数
4 =A3.select(maxrisedays>=5) 选出符合条件的记录

从数据库取数后,通过 SPL 实施计算,这个例子即使使用 SQL 也要嵌套 3 层子查询才能实现,更不用说 Java(Stream,也包括 Kotlin)了。SPL 支持分步计算,这方面也要优于 SQL。

SPL 是解释执行的,支持热切换,计算脚本修改无需重启服务,这点是其他编译型语言无法比拟的。

集算器可以作为嵌入式 JDBC 与微服务框架集成使用,应用通过 JDBC 方式访问 SPL 计算结果,就像访问数据库一样。

imagepng

总体来看,集算器几乎结合了其他实现方式的所有优点,具备 all-in-one 的特征。相对 SQL,SPL 支持分步计算实现复杂计算更加简单;相对 Java 则提供了丰富的计算类库,算法更加简洁;相对 Scala 也更简单;相对 Python 除了语法简洁又可以与微服务框架无缝嵌入更易使用,是相对理想的微服务数据处理手段。