Akka入门系列(三):远程Actor

虽然Akka在单机上可以运行上百万的Actor,但出于容错、负载均衡、灰度发布、提高并行度等等原因,我们仍然需要能在多个不同的服务器上运行Actor。所以Akka提供了akka-remoting的扩展包,屏蔽底层网络传输的细节,让上层以及其简单的方式使用远程的Actor调度。

官方文档:https://doc.akka.io/docs/akka/current/remoting.html

适用场景

Akka入门系列(二):Actor

Actor模型

由于AKka的核心是Actor,而Actor是按照Actor模型进行实现的,所以在使用Akka之前,有必要弄清楚什么是Actor模型
Actor模型最早是1973年Carl Hewitt、Peter Bishop和Richard Seiger的论文中出现的,受物理学中的广义相对论(general relativity)和量子力学(quantum mechanics)所启发,为解决并发计算的一个数学模型。

Actor模型所推崇的哲学是”一切皆是Actor“,这与面向对象编程的”一切皆是对象“类似。
但不同的是,在模型中,Actor是一个运算实体,它遵循以下规则:

Akka入门系列(一):基本介绍

什么是Akka,它能干什么?

互联网系统的发展,大多数情况下都是业务倒逼的。发展过程不外乎以下几步:

  1. 最开始时,一个简单的MVC程序就可以,甚至是早期的J2EE也能得到很好的性能。
  2. 忽然某一天,系统压力大了,一些功能变得比较慢,这时会尝试去做代码重构优化,必要的地方开始使用进程内MQ以及线程池,开启异步及多线程
  3. 再往后,单台也不能满足系统的吞吐了,这时就得上集群,前面一个负载均衡,后面部署多台相同的服务器,将压力均衡到若干服务器上,甚至数据库都开始做切片。
  4. 再往后,继续优化,将一些压力大的功能单独提出来,做成一个Service,对外部提供服务,可以是REST,也可以是RPC,用这种方式来提高服务器利用率,毕竟有些业务只需要IO,而有些业务需要很强的CPU,根据实现逻辑不同,需要的物理资源也不同。而这时,简单的负载均衡也无法适用了,需要功能相对复杂的网关总线,并且各种分布式下的难点都出来了——调度、分布式容错熔断弹性扩容、分布式事务、灰度发布、压力调整等等。

JHipster快速开发Web应用

在基于Spring的Web项目开发中,通常存在两个问题:

  1. 普通CRUD的代码基本重复,完全是体力活;
  2. Controller层和持久层之间的数据传递,存在不规范。有人喜欢直接返回JSON,有人喜欢用DTO,有人喜欢直接Entity。

那如何解决这个问题呢?自动生成呗。一群喜欢动脑筋(懒)的人,发明了JHipster。

JHipster是一个基于SpringBoot和Angular的快速Web应用和SpringCloud微服务的脚手架。本文将介绍如何利用JHipster快速开发Web应用。

Axon入门系列(八):AxonFramework与SpringCloud的整合

上一篇里,我们在利用Axon3的DistributeCommand的JGroup支持,和DistributedEvent对AMQP的支持,实现了分布式环境下的CQRS和EventSourcing。
在这一篇中,我们将把Axon3与当下比较火热的微服务框架——SpringCloud进行整合,并将其微服务化。

写在前面的话

AxonFramework对SpringCloud的支持,是从3.0.2才开始的,但是在3.0.2和3.0.3两个版本,均存在blocking bug,所以要想与SpringCloud完成整合,版本必须大于等于3.0.4
PS:连续跳坑,debug读代码,帮Axon找BUG,血泪换来的结论……好在社区足够活跃,作者也比较给力,连续更新。

Axon入门系列(七):DistributeCommand和DistributeEvent

上一篇我们才算真正实现了一个基于Axon3的例子,本篇我们来尝试实现在分布式环境下利用Axon3做CQRS,即把CommandSide和QuerySide变成两个独立应用,分别可以启多份实例。

首先,我们回顾一下CQRS&EventSourcing模式下,整个架构的关键点,或者说最大的特点:

  • CommandSide和QuerySide的持久层分离;
  • 保存对Aggregate状态造成变化的Event,而不是状态本身;
  • Aggregate的状态全局原子化操作;
  • 适用于读大于写的场景;
    我们前面的例子,是在一个应用里面实现了CQRS模式,而在分布式场景下,有如下要求:
  • CommandSide和QuerySide可以不在同一个节点(甚至不在同一个应用)下;
  • CommandSide不同的CommandHandler、EventHandler可以不在同一个节点;
  • 不同CommandSide对同一个Aggregate的操作应具有原子性;
    我们来一步步满足这三个要求。

Axon入门系列(六):Saga的使用

在上一篇里面,我们正式的使用了CQRS模式完成了AXON的第一个真正的例子,但是细心的朋友会发现一个问题,创建订单时并没有检查商品库存。
库存是否足够直接回导致订单状态的成功与否,在并发时可能还会出现超卖。当库存不足时还需要回滚订单,所以这里出现了复杂的跨Aggregate事务问题。
Saga就是为解决这里复杂流程而生的。

Saga

Saga 这个名词最早是由Hector Garcia-Molina和Kenneth Salem写的Sagas这篇论文里提出来的,但其实Saga并不是什么新事物,在我们传统的系统设计中,它有个更熟悉的名字——“ProcessManager”,只是换了个马甲,还是干同样的事——组合一组逻辑处理复杂流程。
但它与我们平常理解的“ProgressManager”又有不同,它的提出,最早是是为了解决分布式系统中长时间运行事务(long-running business process)的问题,把单一的transaction按照步骤分成一组若干子transaction,通过补偿机制实现最终一致性。
举个例子,在一个交易环节中有下单支付两个步骤,如果是传统方式,两个步骤在一个事务里,统一成功或回滚,然而如果支付时间很长,那么就会导致第一步,即下单这里所占用的资源被长时间锁定,可能会对系统可用性造成影响。如果用Saga来实现,那么下单是一个独立事务,下单的事务先提交,提交成功后开始支付的事务,如果支付成功,则支付的事务也提交,整个流程就算完成,但是如果支付事务执行失败,那么支付需要回滚,因为这时下单事务已经提交,则需要对下单操作进行补偿操作(可能是回滚,也可能是变成新状态)。
可以看到Saga是牺牲了数据的强一致性,实现最终一致性。

Axon入门系列(五):第一个正式Axon例子

前面对Axon的基本概念和基本操作做了简介,从本章开始,我们将一步步使用AxonFramework完成一个真正CQRS&EventSourcing的例子。

设计

回顾一下使用AxonFramework应用的架构

Axon入门系列(四):Axon使用EventSourcing和AutoConfigure

继上一篇集成SpringBoot后,本篇将继续完成小目标:

  1. 使用EventSourcing
  2. 使用AutoConfigure配置Axon

前一篇中看到配置Axon即便在Spring中也是比较麻烦的,好在Axon提供了spring-boot-autoconfigure,提供了Spring下的一些默认配置,极大地方便了我们的工作。
启用也是非常方便的,在上一篇的基础上,我们只需要干三件事即可达成目标:

  1. 引入spring-boot-autoconfigure
  2. 删除JpaConfig类
  3. 去除BankAccount中的Entity声明

Axon入门系列(三):Axon使用Jpa存储Aggregate状态

上一篇里,介绍了Axon的基本概念,并且做了一个最简单的hello例子。本篇将更进一步,完成两个小目标:

  1. 集成SpringBoot;
  2. 使用Standard Repository来存储Aggregate的最新状态。

1. 更新Maven依赖

干几件事:

%>