再有两天就进入2018了,想想还是要准备一下明年的工作方向。回想当初开始学习函数式编程时的主要目的是想设计一套标准API給那些习惯了OOP方式开发商业应用软件的程序员们,使他们能用一种接近传统数据库软件编程的方式来实现多线程,并行运算,分布式的数据处理应用程序,前提是这种编程方式不需要对函数式编程语言、多线程软件编程以及集群环境下的分布式软件编程方式有很高的经验要求。前面试着发布了一个基于scalaz-stream-fs2的数据处理工具开源项目。该项目基本实现了多线程的数据库数据并行处理,能充分利用域内服务器的多核CPU环境以streaming,non-blocking方式提高数据处理效率。最近刚完成了对整个akka套装(suite)的了解,感觉akka是一套理想的分布式编程工具:一是actor模式提供了多种多线程编程方式,再就是akka-cluster能轻松地实现集群式的分布式编程,而集群环境变化只需要调整配置文件,无需改变代码。akka-stream是一套功能更加完整和强大的streaming工具库,那么如果以akka-stream为基础,设计一套能在集群环境里进行分布式多线程并行数据处理的开源编程工具应该可以是2018的首要任务。同样,用户还是能够按照他们熟悉的数据库应用编程方式轻松实现分布式多线程并行数据处理程序的开发。
原文地址:https://dzone.com/articles/building-microservices-with-akka-http-a-cdc-approa
基于Actor的响应式编程计划分为三部分,第一部分剖析响应式编程的本质思想,为大家介绍何谓响应式编程(Reactive Programming)。第二部分则结合两个案例来讲解如何在AKKA中实现响应式编程。第三部分则是这个主题的扩展,在介绍Reactive Manifesto的同时,介绍进行响应式编程更为主流的ReactiveX框架。 响应式编程(Reactive Programming)到底是什么?从名词定义来讲,中文的响应式并没有很好地展现Reactive的本意。响应这个词语是一个中性词,本身没有任何倾
前面几篇讨论了关于gRPC方式的前后端连接集成方式。gRPC也是一个开放的标准,但讲到普及性就远远不及基于http/1.1协议的web-service了。特别是gRPC的前端编程还是有一定的门槛,所以作为一种开放的网络大平台还是必须考虑用web-service方式的集成。平台服务api可以有两样选择:一种是传统web-service方式,新的一种是rest api款式。rest api比较适合数据库表的crud操作。在2017年我曾经写了一系列博客介绍akka-http,这里就不再叙述它的细节了。这篇我们只聚焦在解决当前问题上。在POS控制平台例子里不会涉及到POST操作,应该全部是GET类型的,如:
该文介绍了如何使用Akka HTTP和Slick在Scala中实现基于HTTP的流式数据传输。通过使用Akka HTTP和Slick,可以方便地处理HTTP请求和响应,以及从数据库中获取数据并将其传输到客户端。该文还介绍了如何使用Akka流式处理技术来实现HTTP服务,并处理响应数据。
akka-stream原则上是一种推式(push-model)的数据流。push-model和pull-model的区别在于它们解决问题倾向性:push模式面向高效的数据流下游(fast-dow
在大数据程序流行的今天,许多程序都面临着共同的难题:程序输入数据趋于无限大,抵达时间又不确定。一般的解决方法是采用回调函数(callback-function)来实现的,但这样的解决方案很容易
在前面几篇讨论里我们介绍了scala-gRPC的基本功能和使用方法,我们基本确定了选择gRPC作为一种有效的内部系统集成工具,主要因为下面gRPC支持的几种服务模式: 1、Unary-Call:独立的一对client-request/server-response,是我们常用的http交互模式 2、Server-Streaming:client发出一个request后从server端接收一串多个response 3、Client-Streaming:client向server发送一串多个reques
该文介绍了如何利用Akka HTTP构建一个基于HTTP的分布式文件系统。主要包括了Akka HTTP的入门介绍、基于HTTP的文件上传和下载功能实现,以及如何使用Akka Stream来处理文件上传和下载中的流式数据。此外,还提供了一个基于HTTP的分布式文件系统的示例代码。
在现实应用中akka-stream往往需要集成其它的外部系统形成完整的应用。这些外部系统可能是akka系列系统或者其它类型的系统。所以,akka-stream必须提供一些函数和方法来实现与各种不
在以前的博文中我们介绍了Slick,它是一种FRM(Functional Relation Mapper)。有别于ORM,FRM的特点是函数式的语法可以支持灵活的对象组合(Query Compos
该文章介绍了在 AKKA 中,如何使用 Stream 进行高性能的 HTTP 文件上传/下载功能。首先,介绍了基于 Stream 的 HTTP 文件上传功能,它通过 chunk 进行小数据传输,能够充分利用网络带宽,提高上传速度。然后,介绍了基于 Stream 的 HTTP 文件下载功能,它通过将文件分块传输,能够充分利用网络带宽,提高下载速度。最后,总结了基于 Stream 的 HTTP 文件上传/下载功能在 AKKA 中的重要性,它能够提高系统的性能和可扩展性,同时能够降低系统的资源消耗,提高系统的效率。
关于grpc,在前面的scalaPB讨论里已经做了详细的介绍:google gRPC是一种全新的RPC框架,在开源前一直是google内部使用的集成工具。gRPC支持通过http/2实现protobuf格式数据交换。protobuf即protocol buffer,是google发明的一套全新的序列化传输协议serialization-protocol,是二进制编码binary-encoded的,相对java-object,XML,Json等在空间上占有优势,所以数据传输效率更高。由于gRPC支持http/2协议,可以实现双向通讯duplex-communication,解决了独立request/response交互模式在软件编程中的诸多局限。这是在系统集成编程方面相对akka-http占优的一个亮点。protobuf格式数据可以很方便的转换成 json格式数据,支持对外部系统的的开放协议数据交换。这也是一些人决定选择gRPC作为大型系统微服务集成开发工具的主要原因。更重要的是:用protobuf和gRPC进行client/server交互不涉及任何http对象包括httprequest,httpresponse,很容易上手使用,而且又有在google等大公司内部的成功使用经验,用起来会更加放心。
上次对restapi开了个头,设计了一个包括了身份验证和使用权限的restful服务开发框架。这是一个通用框架,开发人员只要直接往里面加新功能就行了。虽然这次的restapi是围绕着数据库表的CRUD操作设计的,但文件类数据在服务端与客户端之间的交换其实也很常用,特别是多媒体类如图片等文件类型。那我们就试着设计一个文件交换服务功能然后看看能不能很方便的加入到restapi框架内。
在前面一篇讨论里我们介绍了通过http进行文件的交换。因为文件内容是以一堆bytes来表示的,而http消息的数据部分也是byte类型的,所以我们可以直接用Source[ByteString,_]
该文介绍了如何利用Akka HTTP构建一个基于HTTP的RESTful API,该API使用Akka Streams来处理流式数据,并使用Akka HTTP来处理HTTP请求。同时,该文还介绍了如何使用Akka HTTP构建一个简单的Web服务器,并使用它来处理HTTP请求。
当我初接触akka-cluster的时候,我有一个梦想,希望能充分利用actor自由分布、独立运行的特性实现某种分布式程序。这种程序的计算任务可以进行人为的分割后再把细分的任务分派给分布在多个服务器上的actor上去运算。这些服务器都处于同一集群环境里,它们都是akka-cluster中的节点(node)。akka-cluster的节点数量只需要通过系统配置方式按照计算能力要求随意增减,在集群上运行的分布式程序可以在不修改软件的情况下自动调整actors在各节点上的分布,重新平衡程序运算负载,不受任何影响继续运行。
实际上很早就写了一系列关于akka-streams的博客。但那个时候纯粹是为了了解akka而去学习的,主要是从了解akka-streams的原理为出发点。因为akka-streams是akka系列工具的基础,如:akka-http, persistence-query等都是基于akka-streams的,其实没有真正把akka-streams用起来。这段时间所遇到的一些需求也是通过集合来解决的。不过,现在所处的环境还是逼迫着去真正了解akka-streams的应用场景。现状是这样的:跨入大数据时代,已经有大量的现代IT系统从传统关系数据库转到分布式数据库(非关系数据库)了。不难想象,这些应用的数据操作编程不说截然不同吧,肯定也会有巨大改变。特别是在传统SQL编程中依赖数据关系的join已经不复存在了,groupby、disctict等操作方法也不是所有的分布式数据库都能支持的。而这些操作在具体的数据呈现和数据处理中又是不可缺少的。当然,有很多需求可以通过集合来满足,但涉及到大数据处理我想最好还是通过流处理来实现,因为流处理stream-processing的其中一项特点就是能够在有限的内存空间里处理无限量的数据。所以流处理应该是分布式数据处理的理想方式了。这是这次写akka-streams的初衷:希望能通过akka-streams来实现分布式数据处理编程。
使用gRPC作为云平台和移动前端的连接方式,网络安全应该是必须考虑的一个重点。gRPC是支持ssl/tls安全通讯机制的。用了一个周末来研究具体使用方法,实际上是一个周末的挖坑填坑过程。把这次经历记录下来与各位分享。
前面我们全面介绍了在akka-cluster环境下实现的CQRS写端write-side。简单来说就是把发生事件描述作为对象严格按发生时间顺序写入数据库。这些事件对象一般是按照二进制binary方式如blob存入数据库的。cassandra-plugin的表结构如下:
alpakka项目是一个基于akka-streams流处理编程工具的scala/java开源项目,通过提供connector连接各种数据源并在akka-streams里进行数据处理。alpakka-kafka就是alpakka项目里的kafka-connector。对于我们来说:可以用alpakka-kafka来对接kafka,使用kafka提供的功能。或者从另外一个角度讲:alpakka-kafka就是一个用akka-streams实现kafka功能的scala开发工具。
前面我们完成了一个CQRS模式的数据采集(录入)平台。可以预见:数据的产生是在线下各式各样的终端系统中,包括web、桌面、移动终端。那么,为了实现一个完整的系统,必须把前端设备通过某种网络连接形式与数据采集平台集成为一体。有两种方式可以实现需要的网络连接:Restful-api, gRPC。由于gRPC支持http/2通讯协议,支持持久连接方式及双向数据流。所以对于POS设备这样的前端选择gRPC作为网络连接方式来实现实时的操作控制应该是正确的选择,毕竟采用恒久连接和双向数据流效率会高很多。gRPC是google公司的标准,基于protobuffer消息:一种二进制序列化数据交换机制。gRPC的优势在这里就不再细说,读者可以参考前面有关gRPC的讨论博文。
akka-stream的数据流可以由一些组件组合而成。这些组件统称数据流图Graph,它描述了数据流向和处理环节。Source,Flow,Sink是最基础的Graph。用基础Graph又可以组合
上篇描述的kafka案例是个库存管理平台。是一个公共服务平台,为其它软件模块或第三方软件提供库存状态管理服务。当然,平台管理的目标必须是共享的,即库存是作为公共资源开放的。这个库存管理平台是一个Kafka消费端独立运行的软件。kafka的生产方即平台的服务对象通过kafka生产端producer从四面八方同时、集中将消息写入kafka。库存管理平台在kafka消费端不间断监控kafka里新的未读过的消息并及时读取,解析消息获取发布者对库存管理的指令,然后按指令更新库存状态。
该文介绍了如何使用Akka HTTP和SSE实现服务端推送文件给客户端的功能。首先介绍了SSE的概念和Akka HTTP的SSE库,然后通过一个具体的应用场景和代码示例详细讲解了如何实现该功能。
KillSwitch是Akka中用于实现多播和流处理的工具。它通过将多个数据流共享一个单一的KillSwitch来控制多个数据流的终止。使用KillSwitch时,多个数据流可以共享一个单一的KillSwitch,并通过调用KillSwitch的shutdown()方法来同时终止所有数据流的执行。此外,KillSwitch还可以通过调用abort()方法来终止数据流的执行,并抛出异常。在Akka中,使用KillSwitch可以有效地管理多个数据流,并确保所有数据流都按照预期执行。
当我们把Akka-http作为数据库数据交换工具时,数据是以Source[ROW,_]形式存放在Entity里的。很多时候除数据之外我们可能需要进行一些附加的信息传递如对数据的具体处理方式等。我
gRPC Streaming的操作对象由服务端和客户端组成。在一个包含了多个不同服务的集群环境中可能需要从一个服务里调用另一个服务端提供的服务。这时调用服务端又成为了提供服务端的客户端了(服务消费端)。那么如果我们用streaming形式来提交服务需求及获取计算结果就是以一个服务端为Source另一个服务端为通过式passthrough Flow的stream运算了。讲详细点就是请求方用需求构建Source,以连接Flow的方式把需求传递给服务提供方。服务提供方在Flow内部对需求进行处理后再把结果返回来,请求方run这个连接的stream应该就可以得到需要的结果了。下面我们就针对以上场景在一个由JDBC,Cassandra,MongoDB几种gRPC服务组成的集群环境里示范在这几个服务之间的stream连接和运算。
akka-stream的Graph是一种运算方案,它可能代表某种简单的线性数据流图如:Source/Flow/Sink,也可能是由更基础的流图组合而成相对复杂点的某种复合流图,而这个复合流图本身
众所周知,Akka系统是基于Actor模式的分布式运算系统,非常适合构建大数据平台。所以,无可避免地会出现独立系统之间、与异类系统、与移动系统集成的需求。由于涉及到异类和移动系统,系统对接的方式必
Akka 帮助你构建可靠的应用程序,这些应用程序可以在一台机器中使用多个处理器核心(scaling up,纵向扩展)或分布在计算机网络中(scaling out,横向扩展)。实现这一点的关键抽象是,代码单元 Actor 之间的所有交互都是通过消息传递进行的,这就是为什么 Actor 之间传递消息的精确语义应该有自己的章节。
Akka-http的客户端Api应该是以HttpRequest操作为主轴的网上消息交换模式编程工具。我们知道:Akka-http是搭建在Akka-stream之上的。所以,Akka-http在客
在前面的主题中,我们解释了如何在大范围(in the large)内查看 Actor 系统,也就是说,如何表示组件,如何在层次结构中排列 Actor。在这一部分中,我们将通过实现设备 Actor 来在小范围(in the small)内观察 Actor。
介绍 从Play2.5.x开始,Play使用Akka Streams实现流处理,废弃了之前的Enumerator/Iteratee Api。根据官方文档描述,迁移至Akka Streams之后,Play2.5.x的整体性能提升了20%,性能提升相当可观。虽然官方已经更新了JavaStream的文档,但是ScalaStream的文档仍然没有更新,已经提了issue,希望能尽快得到反馈。 ReactiveMongo是一个基于Scala开发的完全异步非阻塞、并且提供流处理功能的MongoDB驱动。该项目目前的流处
上篇我们讨论了Akka-http的文件交换。由于文件内容编码和传输线上数据表达型式皆为bytes,所以可以直接把文件内容存进HttpEntity中进行传递。那么对于在内存里自定义的高级数据类型则
从总体上看:akka-stream是由数据源头Source,流通节点Flow和数据流终点Sink三个框架性的流构件(stream components)组成的。这其中:Source和Sink是
在数据流应用的现实场景中常常会遇到与外界系统对接的需求。这些外部系统可能是Actor系统又或者是一些其它类型的系统。与这些外界系统对接的意思是在另一个线程中运行的数据流可以接收外部系统推送的事件
akka-stream是基于Actor模式的,所以也继承了Actor模式的“坚韧性(resilient)”特点,在任何异常情况下都有某种整体统一的异常处理策略和具体实施方式。在akka-stre
我们在这篇通过一个具体CQRS-Reader-Actor的例子来示范akka-persistence的query端编程和应用。在前面的博客里我们设计了一个CQRS模式POS机程序的操作动作录入过程,并示范了如何实现CQRS的写端编程。现在我们可以根据这个例子来示范如何通过CQRS的读端reader-actor读取由writer-actor所写入的操作事件并将二进制格式的事件恢复成数据库表的行数据。
淘宝从2018年开始对整体架构进行反应式升级, 取得了非常好的成绩。其中『猜你喜欢』应用上限 QPS 提升了 96%,同时机器数量缩减了一半;另一核心应用『我的淘宝』实际线上响应时间下降了 40% 以上。PayPal凭借其基于Akka构建的反应式平台squbs,仅使用8台2vCPU虚拟机,每天可以处理超过10亿笔交易,与基于Spring实现的老系统相比,代码量降低了80%,而性能却提升了10倍。能够取得如此好的成绩,人们不禁要问反应式到底是什么? 其实反应式并不是一个新鲜的概念,它的灵感来源最早可以追溯到90年代,但是直到2013年,Roland Kuhn等人发布了《反应式宣言》后才慢慢被人熟知,继而在2014年迎来爆发式增长,比较有意思的是,同时迎来爆发式增长的还有领域驱动设计(DDD),原因是2014年3月25日,Martin Fowler和James Lewis向大众介绍了微服务架构,而反应式和领域驱动是微服务架构得以落地的有力保障。紧接着各种反应式编程框架相继进入大家视野,如RxJava、Akka、Spring Reactor/WebFlux、Play Framework和未来的Dubbo3等,阿里内部在做反应式改造时也孵化了一些反应式项目,包括AliRxObjC、RxAOP和AliRxUtil等。 从目前的趋势看来,反应式概念将会逐渐深入人心, 并且将引领下一代技术变革。
Unmarshalling是Akka-http内把网上可传输格式的数据转变成程序高级结构话数据的过程,比如把Json数据转换成某个自定义类型的实例。按具体流程来说就是先把Json转换成可传输格式数
HelloGitHub 推出的《讲解开源项目》[1]系列。从本章开始,就正式进入 PowerJob 框架的技术剖析环节了。作为技术系列文章开篇的第一章,本文会讲述 PowerJob 整体的架构设计,同时介绍相关的技术,以便于后面的讲解。
在云计算的推动下,软件系统发展趋于平台化。云平台系统一般都是分布式的集群系统,采用大数据技术。在这方面akka提供了比较完整的开发技术支持。我在上一个系列有关CQRS的博客中按照实际应用的要求对akka的一些开发技术进行了介绍。CQRS模式着重操作流程控制,主要涉及交易数据的管理。那么,作为交易数据产生过程中发挥验证作用的一系列基础数据如用户信息、商品信息、支付类型信息等又应该怎样维护呢?首先基础数据也应该是在平台水平上的,但数据的采集、维护是在系统前端的,比如一些web界面。所以平台基础数据维护系统是一套前后台结合的系统。对于一个开放的平台系统来说,应该能够适应各式各样的前端系统。一般来讲,平台通过定义一套api与前端系统集成是通用的方法。这套api必须遵循行业标准,技术要普及通用,这样才能支持各种异类前端系统功能开发。在这些要求背景下,相对gRPC, GraphQL来说,REST风格的http集成模式能得到更多开发人员的接受。
研究关于restapi的初衷是想搞一套通用的平台数据表维护http工具。前面谈过身份验证和使用权限、文件的上传下载,这次来到具体的数据库表维护。我们在这篇示范里设计一套通用的对平台每一个数据表的标准维护方式。http服务端数据表维护CRUD有几个标准的部分组成:Model,Repository,Route。我们先看看这几个类型的基类:
最近有同事提起想把网页上的图片存在MongoDB里,我十分赞同。比起把图片以文件形式存放在硬盘子目录的方式,MongoDB有太多的优势。首先,MongoDB是分布式数据库,图片可以跨服务器存储。在一个集群环境里通过复制集、分片等技术可以提高图片读取速度、实现数据的高可用和安全性。再就是对大量的图片可用规范的记录管理方式来进行处理,甚至在一个大流量环境里还可以用集群节点负载平衡方式来助力图片的存取。
作者 | 张逸 特别说明:本文包含大量代码片段,若要获得更好阅读观感,请点击文末“阅读原文”或访问我的博客。 响应式编程在前端开发以及Android开发中有颇多运用,然而它的非阻塞异步编程模型以及对消息流的处理模式也在后端得到越来越多的应用。除了Netflix的OSS中大量使用了响应式编程之外,最近阿里也提出Dubbo 3.0版本将全面拥抱响应式编程。 我之前针对某些项目需求也给出了响应式编程的方案,较好地解决了并行编程与异步编程的问题。不过在深入了解响应式编程之后,我也给出了自己的一些实践总结。 响应式编
首先声明:标题上的所谓编程模式是我个人考虑在集群环境下跨节点(jvm)的流程控制编程模式,纯粹按实际需要构想,没什么理论支持。在5月份的深圳scala meetup上我分享了有关集群环境下的编程模式思路。我提供了下面这个示意图:
在现实中我们会经常遇到这样的场景:有一个固定的数据源Source,我们希望按照程序运行状态来接驳任意数量的下游接收方subscriber、又或者我需要在程序运行时(runtime)把多个数据流向某
Akka 集群的核心是集群成员(cluster membership),以跟踪哪些节点是集群的一部分以及它们的健康状况。
领取专属 10元无门槛券
手把手带您无忧上云