反应式微服务框架Flower

Flower是一个构建在Akka上的反应式微服务框架，开发者只需要针对每一个细粒度的业务功能开发一个Service服务，并将这些Service按照业务流程进行可视化编排，即可得到一个反应式系统。

Flower既是一个反应式编程框架，又是一个分布式微服务框架。

Flower框架使得开发者无需关注反应式编程细节，即可得到一个反应式系统。

快速上手

Flower框架的主要元素包括：Flower Service（服务）、Flower 流程和Flow容器。Service实现一个细粒度的服务功能，Service之间通过Message关联，前一个Service的返回值（Message），必须是后一个Service的输入参数（Message），Service按照业务逻辑编辑成一个Flow（流程），Flower容器负责将前一个Service的返回消息，传递给后一个Service。

安装

Maven

Gradle

SBT

Ivy

Flower初始化

Flower使用前需要进行初始化，这里演示最简单的方式。

Flower初始化

定义Flower服务

开发Service类必须实现Flower框架的Service接口或者继承AbstractService基类，在process方法内完成服务业务逻辑处理。

UserServiceA

UserServiceB

UserServiceC1

服务注册

Flower提供两种服务注册方式：配置文件方式和编程方式。

服务流程编排

Flower框架提供两种服务流程编排方式：配置文件方式和编程方式。

两种编排方式的结果是一样：

调用Flower流程

前面定义了3个Flower服务，并编排了名称为flower_test的服务流程。那么怎么使用它呢？

完整示例

在Flower里面消息是一等公民，基于Flower开发的应用系统是面向消息的应用系统。 消息由Service产生，是Service的返回值；同时消息也是Service的输入。前一个Service的返回消息是下一个Service的输入消息，没有耦合的Service正是通过消息关联起来，组成一个Service流程，并最终构建出一个拥有完整处理能力的应用系统。流程举例：

术语

Flower消息处理模式

消息除了将服务串联起来，构成一个简单的串行流程，还可以组合应用，产生更强大的功能。

消息分叉

消息分叉是指，一个服务输出的消息，可能产生分叉，分发给1个或者多个其他服务。消息分叉后有两种处理方式，全部分发和条件分发。

全部分发

将输出消息分发给全部流程后续服务。后续多个服务接受到消息后，并行执行。这种模式多用于可并行执行的多个子任务，比如用户注册成功后，需要1、将用户数据写入数据库，2、给用户发送激活邮件，3、给用户发送通知短信，4、将新用户注册信息发送给关联产品，实现账户打通。上述4个服务就可以采用消息全部分发模式，接受用户注册消息，并发完成上述4个任务。

要实现消息全部分发，需要在流程中进行配置，所有需要接受前序服务的输出消息的服务都要配置在流程中，如

service1是前序服务，service2和service3是后继服务。 如果service2和service3的class定义中，实现Service接口的声明中指定了泛型，则泛型类型必须是service1的输出类型或者其父类。

Service1

Service2

Service3

条件分发

有时候，前一个服务产生的消息，根据消息内容和业务逻辑可能会交给后续的某一个服务处理，而不是全部服务处理。比如用户贷款申请，当前服务计算出用户信用等级后，需要根据信用等级判断采用何种贷款方式，或者是拒绝贷款，不同贷款方式和拒绝贷款是不同的服务，这些服务在流程配置的时候，都需要配置为前序服务的后继服务，但是在运行期根据条件决定将消息分发给具体哪个后继服务。

实现条件分发在流程配置上和全部分发一样，所有可能的后继服务都要配置在流程中。具体实现条件分发有如下三种方式。

根据泛型进行分发

后续服务实现接口的时候声明不同的泛型类型，前序服务根据业务逻辑构建不同的消息类型，Flower会根据消息类型匹配对应的服务，只有成功匹配，消息才发送给过去。比如：

构建流程

声明ServiceB接受的消息类型为MessageB

ServiceA

ServiceB是ServiceA的后续服务，ServiceA收到的消息如果是字符串“b”，就会返回消息类型B，这时候框架就会将消息发送给ServiceB，而不会发送给ServiceC。

在消息中指定后继服务的id进行分发

前序消息实现Condition接口，并指定后继服务的id，如：

一般说来，服务是可复用的，可复用于不同的流程中，但是在不同的流程中后继服务可能是不同的，后继服务的id也是不同的，在服务中写死后续服务id，显然不利于服务的复用。解决方案有两种，一种是在不同的流程中，写一个专门用于分发的服务，也就是处理业务逻辑的服务并不关心消息的分发，只管返回消息内容，但是其后继服务是一个专门用来做消息分发的服务，这个服务没有业务逻辑，仅仅实现Condition接口根据消息内容指定后继服务。

另一种是使用框架内置服务ConditionService进行消息分发

使用框架内置服务ConditionService进行消息分发

ConditionService是一个通用的消息分发服务，

服务serviceE要将消息根据条件分发给serviceF或者serviceG，流程配置如上，中间加入serviceCondition进行适配。 serviceCondition的服务注册方法为

comlytrainflowercommonserviceConditionService为框架内置服务

这种方式中，依然需要在serviceCondition的前驱服务serviceE中设置返回消息的condition，但是不必设置后续服务的id，只需要设置后续服务的顺序号即可。

几种条件分发的代码示例参考/flowersample/src/main/java/com/ly/train/flower/common/sample/condition/Samplejava

消息聚合

对于全部分发的消息分叉而言，通常目的在于使多个服务能够并行执行，加快处理速度。通常还需要得到这些并行处理的服务的全部结果，进行后续处理。 在Flower中，得到多个并行处理服务的结果消息，称为消息聚合。实现方式为，在流程中，配置需要聚合的多个消息的后续服务为comlytrainflowercommonserviceAggregateService，这是一个框架内置服务，负责聚合多个并行服务产生的消息，将其封装到一个Set对象中返回。 如流程

这里的service5就是一个消息聚合服务，负责聚合并行的service2和service3产生的消息，并把聚合后的Set消息发送给service4 服务配置如下，service5配置为框架内置服务AggregateService。

service4负责接收处理聚合后的消息，从Set中取出各个消息，分别处理。

消息回复

Flower中的消息全部都是异步处理，也就是服务之间不会互相阻塞等待，以实现低耦合、无阻塞、高并发的响应式系统。Flower流程调用者发送出请求消息以后，消息在流程中处理，调用者无需阻塞等待处理结果，可以继续去执行其他的计算任务。

和传统的命令式编程不同，通常流程的发起调用者并不是流程处理结果的最终接受者，比如对于web开发，流程的发起者通常是一个servlet，但是真正接受处理结果的是用户端浏览器或者App，流程中的服务可以直接发送处理结果给用户端，而不必通过servlet。也就是调用发起者servlet无需等待流程服务的最终处理结果，将用户请求发送到流程中后，不必阻塞等待处理，可以立即获取另一个用户的请求继续进行处理。

但是Flower也支持调用者阻塞等待消息处理结果，消息回复模式可以使流程调用者得到流程处理的最终结果消息。可参考代码示例 /flowersample/src/main/java/com/ly/train/flower/common/sample/textflow/Samplejava

Flower web开发模式

Flower集成Servlet3的web开发模式

Flower支持Servlet3的异步模式，请求处理线程在调用Flower流程，并传入AsyncContext对象后立即释放。 代码示例参考/flowersample/src/main/java/com/ly/train/flower/common/sample/web/async/AsyncServletjava

开发支持Servlet3的Flower服务，需要实现框架的Service接口，在方法 Object process(T message, ServiceContext context) throws Exception;中，Flower框架会传入一个Web对象，通过contextgetWeb()得到Web对象，用以获得请求参数和输出处理响应结果。

Flower集成Spring boot的web开发模式

Flower支持Spring boot开发，在项目中依赖flowerweb，实现框架中的Service接口和InitController接口。 初始化@BindController注解需要的参数，在编译过程中自动由flowerweb枚举@BindController注解, 生成Spring boot需要的Controller。

注意： flowerweb利用annotation为Service生成spring boot所需的Controller类。这个生成过程在程序编译的时候完成，如果IDE环境不支持热编译，需要在命令行执行mvn install生成代码。

代码示例参考/flowersample/src/main/java/com/ly/train/flower/common/sample/springboot

使用Flower框架的开发建议

Flower分布式部署架构

开发流程

一 启动Flowercenter注册中心

二 开发Flower Service，启动业务服务Flower容器，自动向注册中心注册服务

三 开发Flower web网关，启动Flower网关服务，编排流程

一 注册中心

Flowercenter基于spring-boot开发，通过打包成fat-jar后通过命令行启动即可。

Flower注册中心启动入口/flowercenter/src/main/java/com/ly/train/flower/center/CenterApplicationjava Flower注册中心启动命令java -jar flowercenter-012jar

二 启动业务Flower容器

Flower部署支持Flower容器和Spring容器，下面的例子基于spring-boot演示

21 创建配置文件floweryml

22 配置FlowerFactory

23 开发flower服务

24 创建启动类

三 启动网关服务器，编排流程

31 创建floweryml

32 配置FlowerFactory

33 开发Flower服务

34 开发网关Controller

35 启动类

实例项目细节

flower分布式实例 >

微服务架构的系统是一个分布式的系统，按业务进行划分为独立的服务单元，解决单体系统的不足，同时也满足越来越复杂的业务需求。

一单体架构

11什么是单体架构

在软件设计的时候经常提到和使用经典的3层模型，即表现层，业务逻辑层，数据访问层。虽然在软件设计中划分了3层模型，但是对业务场景没有划分，一个典型的单体架构就是将所有的业务场景的表现层，业务逻辑层，数据访问层放在一个工程中最终经过编译，打包，部署在一台服务器上。此时服务架构如图：

12单体架构存在的不足

在小型应用的初期，访问量小的时候这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码得可读性和可维护性越来越低。用户的增加，访问量越来越多单体架构的应用并发能力十分有限。可能会有人想到将单体应用进行集群部署，并增加负载均衡服务器，再来个缓存服务器和文件服务器，数据库再搞个读写分离。这种架构如图：

这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。基于以上单体架构系统的不足，提出了微服务架构。

二微服务

21什么是微服务

说了这么多现在来看看到底什么是微服务。微服务最初是由Martin Fowler提出来的他的理解如下：

   微服务架构就是将单一程序开发成一个微服务，每个微服务运行在自己的进程中，并使用轻量级的机制通信，通常是>

1

总结起来微服务就是将一个单体架构的应用按业务划分为一个个的独立运行的程序即服务，它们之间通过>

22微服务的优势

1）将复杂的业务拆分成多个小的业务，每个业务拆分成一个服务，将复杂的问题简单化。利于分工，降低新人的学习成本。

2）微服务系统是分布式系统，业务与业务之间完全解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。面对搞并发的场景可以将服务集群化部署，加强系统负载能力。

3）服务间采用>

4）微服务每个服务都是独立部署的，每个服务的修改和部署对其他服务没有影响。

23微服务和SOA的关系

SOA即面向服务的架构，SOA是根据企业服务总线（ESB）模式来整合集成大量单一庞大的系统，微服务可以说是SOA的一种实现，将复杂的业务组件化。但它比ESB实现的SOA更加的轻便敏捷和简单。

以上就是关于反应式微服务框架Flower全部的内容，包括:反应式微服务框架Flower、什么是微服务、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！