精华内容
下载资源
问答
  • 服务编排 框架
    千次阅读
    2022-03-25 23:33:24

    写在前面。低代码最近被炒的火热,各种争议不断,我们且不去添油加醋,仔细想来,在一些特定的场景,在整体架构的特定层面,低代码平台确实是可以发挥其长处的,足矣。

    一.微服务编排的必要性

    微服务是当前流行的软件架构风格,在底层共性技术服务和中台业务服务能力具备后,上层应用应基于这些服务快速地构建,但不可能所有场景都简单调用一个服务就能实现。当存在一定业务规则需要处理的时候,往往都涉及到多个服务调用,中间还涉及到基础的数据处理,逻辑判断才能够完成。

    如果让前端应用来处理这种组合,需要大量编写脚本代码,还不时需要调整,而且存在共性领域服务逻辑对外泄露的问题。其二在前后端分离的场景下,前端并不关心复杂的后端逻辑。

    服务编排是对基础的业务服务按照一定的业务规则进行逻辑组合,提供一个封装后的组合服务接口给前端的过程。

    服务编排引擎可以进行可视化的业务流程编排来降低这些大量重复且没有技术含量的前端脚本、提升服务调用逻辑的可视化。

    二.服务编排的方式及开源产品

          当前服务编排主要是Orchestration和Choreography两种模式。

    1、Orchestration(编制)

    Orchestration模式面向流程:通过一个可执行的流程来协同内部及外部的服务交互,通过流程来控制总体的目标、涉及的操作、服务调用顺序。Orchestration和BPM、ESB的思想很相似,首先要有一个流程控制服务,该服务接收请求,依照业务逻辑规则,依次调用各个微服务,并最终完成处理逻辑。

    2、Choreography(编排)

    Choreography模式面向协作:通过消息的交互序列来控制各个部分资源的交互,参与交互的资源都是对等的,没有集中的控制。Choreography可以看作一种消息驱动模式,或者说是订阅发布模式,每笔业务到来后,各个监听该事件的服务,会主动获取消息,处理,并可以按需发布自己的消息。可以把不同队列看作不同种类的消息,微服务看作消息处理函数。

    当前主流的微服务编排引擎包括:zeebe-io/zeebe, netflix/conductor, uber/cadence,其适用场景功能特性以及优缺点读者可自行去查阅了解,也有不少布道者写了相关的介绍文章。

    三.Commander的主要功能

    Commander 是一个Orchestration模式的服务编排框架库,可以嵌入式使用,也提供独立运行的服务端。由IDE和运行时两部分构成。IDE提供所见即所得的服务定义(接入接出通讯配置,接口配置)和处理流程,是一个基于Eclipse的低代码开发平台。主要功能如下:

    • 可视化组合服务定义,包括服务Url,流控标识,熔断标识,请求接口,响应接口,处理流程等;

     

    • 可视化流程编排:对于服务处理流程的节点组件,控制模型的属性进行可视化设置;

     

    • 流程控制模型(顺序、分支、循环、异常抛出、并行);
    • 丰富的业务流程处理组件。包括接口解析拼装组件,变量处理脚本组件,服务调用组件等;提供自定义组件接口可方便自行扩展;
    • 支持分布式事务能力,在服务调用失败时可以进行重试或冲正操作
    • JSON报文的拆分,合并,数据映射
    • 微服务链路追踪;
    • 熔断限流,流量控制;
    • 可作为存量业务系统的边车,进行通讯方式(TCP长连接,TCP短连接,Http,MQ),报文接口(XML,JSON,SOAP,定长报文,分隔符报文,块报文)的转换,将存量系统的服务注册,访问其他微服务功能。

    欢迎对Commander感兴趣的朋友访问Commander: Commander 是一个服务编排框架库。由IDE和运行时两部分构成。IDE提供所见即所得的组合服务配置,接口配置,及处理流程,是一个低代码开发平台。

    联系方式 meta_soft@163.com

    更多相关内容
  • 面向普适计算环境的Android平台服务编排框架.pdf
  • Kstry能做什么?...某业务链路由一系列子任务组成,其中需要并行处理一些耗时长且数据间没有依赖的子任务,但苦于没有精简且无代码侵入的并发框架 维护平台型产品,为众多上游业务线提供着基础服务

    Kstry能做什么?

    如果您遇到了以下问题:

    • 代码复杂、模型文档更新不及时,致使新同学和非技术同学不能短时间内了解业务现状。技术和非技术间对同一业务理解存在分歧而不自知。甚至业务Owner也不能很流畅的描述出自己所负责的业务
    • 项目中涉及到许多领域对象,对象间不仅存在复杂的前后依赖关系还相互掺杂没有明显边界,代码多次迭代后更是混乱不堪难以维护
    • 某业务链路由一系列子任务组成,其中需要并行处理一些耗时长且数据间没有依赖的子任务,但苦于没有精简且无代码侵入的并发框架
    • 维护平台型产品,为众多上游业务线提供着基础服务,但在短时间内应对各个业务方的定制化需求捉襟见肘,更不知如何做好平台与业务、业务与业务之间的隔离
    • 业务流转数据状态追踪困难,只存在于线上环境的偶现问题更是难以排查。需要一种可以通过简单操作就能将重要节点数据都保存下来的能力,此能力堪比对链路精细化梳理后的系统性日志打印
    • 业务场景多样,不乏一些复杂的链路难以被测试覆盖。或者三方数据Mock困难,测试成本居高不下

    那么可以尝试一下Kstry框架,因为其具备:

    可视化

    • 框架引入了业界通用的BPMN流程编排语言
    • 使用事件节点、任务节点、网关节点等组件来描述业务动作和执行线路
    • 编排好的图示模型即为代码真实的执行链路,通过所见( 图示模型 )即所得( 代码执行 )的方式在技术和业务之间架起一道通用语言的桥梁,使彼此之间沟通更加顺畅

    image-20211219163429668.png

    服务编排

    • 框架通过定义任务节点来划分领域边界并实现业务功能,任务节点对应代码中Class的某个方法
    • 一个独立的任务节点理论上只承担着一种业务动作或领域能力
    • 输入完成任务所需参数的最小集,输出任务完成的结果或处理后的领域对象
    • 节点间使用箭头符号这种可视化编排手段来保证彼此间的相互作用有序,通过并行网关、包含网关、排他网关等来丰富节点间的执行依赖关系

    image-20211219163540179

    支持并发

    • 无需改动代码,仅仅在并行网关或包含网关上配置 open-async=true,即可将其后的子链路并行化
      image-20211213145202846

    RBAC( Role-based access control )模式

    • 针对平台型服务,首先可以定义编排出通用的链路模型
    • 模型中的某个任务节点,应对不同业务场景或需求方的诉求时,可以扩展不同的服务能力( 比如A、B两个业务方都需要抽佣的服务,那么就可以定义一个抽佣的任务节点,然后A业务需要比例抽佣,而B业务需要阶梯式抽佣,这时就可以在抽佣的任务节点上再扩展两个不同的抽佣能力
    • 扩展出来的能力可视作资源,所有的资源都有着独一无二的资源名称,携带着包含某个资源名称的权限对象即可访问与之对应的资源( 资源也可称为:扩展出来的服务能力
    • 一批独立的权限对象有着较高的维护成本,所以可依次将某一业务场景所需的全部权限聚合起来组成角色对象
    • 提供平台能力时,根据参数标识判断出具体的业务场景或需求方,并找到与之对应的角色,携带该角色执行预设的链路模型,即可完成定制化的业务诉求

    在这里插入图片描述

    详见:RBAC模式

    流程回溯

    流程回溯可以在链路执行完之后,拿到结果或者异常之前,打印节点执行日志或执行自定义回调方法,可以应对如下问题:

    • 查看运行过节点的信息如:执行顺序、节点耗时、入参、出参、异常信息等重要数据
    • 自定义流程回溯日志,或者可以在出现异常时才打印详情日志
    • 检查节点执行、参数设置等是否符合预期。因为有时结果确实没有报错,但并不代表过程一定没有问题
    • 如果链路中有自定义角色的操作,检查最终角色是否符合预期

    简化测试

    • 不依赖业务方入参,而是通过Mock业务角色的方式。之后请求携带该角色即可完成对包含有待测试服务节点或者能力扩展点的个性化业务链路的测试

    Kstry如何使用?

    下面步骤仅为简单介绍,具体细节请参考使用文档

    1、配置引入

    <dependency>
        <groupId>cn.kstry.framework</groupId>
        <artifactId>kstry-core</artifactId>
        <version>1.0.5</version>
    </dependency>
    

    2、项目引入

    @EnableKstry(bpmnPath = "./bpmn/*.bpmn")
    @SpringBootApplication
    public class KstryDemoApplication {
    
        public static void main(String[] args) {
            SpringApplication.run(KstryDemoApplication.class, args);
        }
    }
    

    3、编写组件代码

    @TaskComponent(name = "goods")
    public class GoodsService {
        
        @NoticeResult
        @TaskService(name = "init-base-info")
        public GoodsDetail initBaseInfo(@ReqTaskParam(reqSelf = true) GoodsDetailRequest request) {
            return GoodsDetail.builder().id(request.getId()).name("商品").build();
        }
    }
    

    4、定义bpmn配置文件

    image-20211211151733111

    5、调用执行

    @RestController
    @RequestMapping("/goods")
    public class GoodsController {
    
        @Resource
        private StoryEngine storyEngine;
    
        @PostMapping("/show")
        public GoodsDetail showGoods(@RequestBody GoodsDetailRequest request) {
    
            StoryRequest<GoodsDetail> req = ReqBuilder.returnType(GoodsDetail.class)
                                                      .startId("kstry-demo-goods-show").request(request).build();
            TaskResponse<GoodsDetail> fire = storyEngine.fire(req);
            if (fire.isSuccess()) {
                return fire.getResult();
            }
            return null;
        }
    }
    

    6、请求测试

    image-20211211145528118
    展开全文
  • 谈谈服务编排

    千次阅读 2021-08-02 18:54:08
    同事Spring微服务技术架构网上应用出现了服务堵塞,监控不到服务运行(业务进展情况),以及需求变更困难、维护成本高等情况,再回顾以前数据不一致等情况,通过讨论分析发现系统架构中没有使用流程方法的服务编排

    最近,同事Spring微服务技术架构网上应用出现了服务堵塞,监控不到服务运行(业务进展情况),以及需求变更困难、维护成本高等情况,再回顾以前数据不一致等情况,通过讨论分析发现系统架构中没有使用流程方法的服务编排。

    1. 什么是微服务?

    维基上对其定义为:一种软件开发技术- 面向服务的体系结构(SOA)架构样式的一种变体,将应用程序构造为一组松散耦合的服务。在微服务体系结构中,服务是细粒度的,协议是轻量级的。
    微服务(或微服务架构)是一种云原生架构方法,其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。

    微服务架构继承了服务架构,是与单体应用(monolith application)相对的,其构成主要是通过多层架构完成业务,如下图所示典型微服务技术架构。
    在这里插入图片描述
    这种架构支撑完成某些具体业务还是很方便的,如果遇到企业内部全生产流程、信息孤岛、数据治理等需求时,就显得力不从心了,需要大量、复杂的开发工作。因此,又回到企业级服务体系架构。

    2. 流程编排与服务编排

    对于服务编排和流程编排这两个概念,很多时候我们并没有刻意的去区分,但是还是结合具体的使用场景做下个人的一些理解。严格来将服务编排应该是属于流程编排的一个子集,同时服务编排更多的有点类似于组合服务的设计。而流程编排则面向一个完整业务流程的自动化实现。

    那么可以看到一个完整的流程里面涉及的节点要素就比服务编排要多的多。比如人工处理节点,通知类节点,规则处理或规则引擎,流程的串行并行回退等处理等,这些往往在简单的服务编排里面并不会出现。而服务编排更多就是多个服务的组合,可以是串行组合,也可以是并行组合,然后形成一个新的组合服务能力。

    当说到流程编排的时候,一般都会说到BPM业务流程管理和BPEL业务流程执行语言和建模设计器,同时也可以看到流程编排往往最终完成的是一个流程,为了最终实现的流程可用,往往就还涉及到具体的业务对象单据的的设计,前端界面展现层设计等一系列的工作。只有这样才能够完成一个完整的业务人员可用的流程。流程编排完成的结果可以是一个API服务接口,也可以就是一个流程模版ID,而服务编排则最终形成的一定是一个新的API服务接口,最终的使用方也不是用户而是开发人员。

    不论是流程编排还是服务编排可以看到,都具备了基本的流程定义,任务定义,连接定义,流程启动和任务调度监控等基础能力。以实现对于编排完成的服务或流程能够在运行的时候能够实现动态,端到端可视化监控能力。在一个流程启动后,我们就可以进入到监控界面对流程执行进行监控和调度控制。

    还有一类就是纯粹的任务编排或调度系统,即我们希望将做的多项工作任务连接起来形成一个任务链条有序的执行,不管是DevOps里面的部署流水线,还是运维工作里面的多步骤自动化运维都符合上面的特征,这种任务调度系统的实现也具备了流程定义,任务定义,任务调度监控等能力。但是实际上的任务活动节点仅仅是触发外部的脚本或接口,其本身并不是一个原子服务节点,也谈不上编排服务间的时间映射等复杂功能。

    3. 微服务编排方式

    目前有3种常见的微服务编排方式,实现微服务的组合与协调,可根据开发项目的实际情况进行选择。

    3.1. Orchestration(编制)

    Orchestration面向可执行的流程:通过一个可执行的流程来协同内部及外部的服务交互,通过流程来控制总体的目标、涉及的操作、服务调用顺序。

    Orchestration和BPM、ESB的思想很相似,首先要有一个流程控制服务,该服务接收请求,依照业务逻辑规则,依次调用各个微服务,并最终完成处理逻辑。可以把控制服务视作BPM、ESB引擎,微服务视作BPM、ESB的各种组件。

    Orchestration实现方案多是同步的。

    优点:
    流程控制服务时时刻刻都知道每一笔业务究竟进行到了什么地步,监控业务成了相对简单的事情。
    缺点:
    1)流程控制服务很容易控制了太多的业务逻辑,耦合度过高,变得臃肿。
    2)各个微服务退化为单纯的增删改查,失去自身价值。

    在这里插入图片描述
    如上图所示的某商用微服务平台,以流程服务方式编制服务,以及提供服务运行监控能力。

    3.2. Choreography(编排)

    Choreography面向协作:通过消息的交互序列来控制各个部分资源的交互,参与交互的资源都是对等的,没有集中的控制。

    Choreography可以看作一种消息驱动模式,或者说是订阅发布模式,每笔业务到来后,各个监听改事件的服务,会主动获取消息,处理,并可以按需发布自己的消息。可以把不同队列看作不同种类的消息,微服务看作消息处理函数。

    Choreography实现方案多是异步的。

    优点:
    耦合度低,每个服务都可以各司其职。
    缺点:
    1)业务流程是通过订阅的方式来体现的,很难直接监控每笔业务的处理,因此难于调试。
    2)由于没有预定义流程,所以很难在事前保证流程正确性,基本靠事后分析数据来判断。
    3)当一个业务流程会嵌入到多个服务中时,维护会很困难。
    建议:
    1)小粒度的服务需要组合,服务的粒度越小,越需要组合。
    2)增加相应的监控系统,来保证业务顺畅进行。

    3.3. API网关

    API网关可以看作一种简单的接口聚合/拆分的方式:每笔业务到来后先到达网关,网关调用各微服务,并最终聚合/拆分需反馈的结果。

    API网关其实就是一个适配网关,比如对于Web端,可以一个页面同时发起几十个请求,而对于移动端,最好是一个页面就几个请求。而采用API网关,后面的微服务可以是相同的。

    优点:
    对外接口相对稳定。
    缺点:
    只适合业务逻辑较为简单的场景,业务逻辑过于复杂时,网关接口耦合度及复杂度会急剧升高,变得臃肿。

    4. 案例分析

    4.1. 京东商城技术架构总览

    1、基本平台。数据存取方面的技术组件包括:缓存服务有JFS/Jimstore、图片服务JSS、即时服务JDW、索引服务Search、数据库服务DBS。

    2、集成层。服务流程引擎PAF、服务中间件SAF、MQ服务JDMQ、数据库中间件JDAL、调度服务JDWorker、业务规则服务JDRules、配置服务JDCenter、推送服务JMP。

    3、质量层。监控服务UMP、日志服务Loghub、风控系统JDriskM、应用管理jdcenter。

    其它还包括治理层、虚拟平台、运营管理等等。
    在这里插入图片描述

    4.2. 阿里业务中台技术架构

    所谓的业务中台就是:通过制定标准和机制,把不确定的业务规则和流程通过工业化和市场化的手段确定下来,以减少人与人之间的沟通成本,同时还能最大程度地提升协作效率。

    集中管控,分布式执行,构建业务中台的基共享服务体系:

    • 回归SOA的本质一服务重用
    • 服务需要不断的业务滋养
    • 共享服务体系是培育业务创新的土壤
    • 赋予业务快速创新和试错能力
    • 为真正发挥大数据威力做好储备
    • 改变组织阵型会带来组织效能的提升

    在这里插入图片描述

    4.3. 人工智能中台

    我们可以把人工智能中台看成是基于 IaaS 基础上的人工智能 PaaS 平台。在人工智能中台上灵活搭建各种人工智能基础服务,如人脸识别算法能力、语义识别算法能力、语音合成算法能力、布局决策能力等。然后在这些基础人工智能能力之上,进行服务编排和组织,就可以形成语音转文本、文本转语音、智能推荐等带有业务色彩的人工智能服务。包装和组织这些带有业务色彩的人工智能服务,最后就能包装出各种垂直的人工智能解决方案。从 IaaS 到人工智能统一门户这几个层次,我们统称为人工智能中台。
    在这里插入图片描述

    5. 微服务编排组件

    1、zeebe-io/zeebe

    Zeebe是一个用于微服务编排的工作流引擎。Zeebe是一个免费的、源代码可用的微服务编制工作流引擎,它提供:

    • 对公司端到端的工作流状态的可见性,包括正在运行的工作流的数量、平均工作流持续时间、工作流中的当前错误,等等。
    • 根据工作流的当前状态编制工作流;Zeebe将“命令”作为事件发布,可以由一个或多个微服务使用,确保工作流按照其定义进行。
    • 监视超时或其他流程错误,以及配置错误处理路径的能力,例如有状态重试或向能够手动解决问题的团队升级,确保工作流始终按计划完成。

    Zeebe被设计用来解决非常大规模的微服务编排问题,为了实现这一点,它提供:

    • 横向可伸缩性,不依赖于外部数据库;相反,Zeebe直接将数据写入部署它的服务器上的文件系统,并且可以轻松地跨计算机集群分发处理,从而提供高吞吐量。
    • 通过易于配置的复制机制实现容错,确保Zeebe可以从机器或软件故障中恢复,而不会造成数据丢失和最小的停机时间。
    • 一种消息驱动的体系结构,其中所有与工作流相关的事件都被写入仅用于追加的日志。这些事件可以导出到外部系统进行长期存储,以提供一个完整的工作流审计日志。
    • 发布-订阅交互模型,它允许连接到Zeebe的微服务在提供处理反压力机制的同时保持高度的控制。
      在iso标准BPMN 2.0中建模的可视化工作流,使得技术和非技术涉众可以用一种公共语言协作进行工作流设计。
    • 与语言无关的客户机模型,使得用组织用来构建微服务的几乎任何编程语言构建Zeebe客户机成为可能。
      在这里插入图片描述
      2、netflix/conductor

    来自netflix 的为微服务编排引擎,支持的功能很丰富,同时文档也比较全
    在这里插入图片描述
    Netflix Conductor开源微服务编排框架并不满足我们前面描述的微服务编排场景,如果要实现服务和服务之间的编排,实际上对该开源软件的定制和改造工作量相当大。因此在我们实现微服务编排的时候并不建议选择该开源软件。其次,在整个微服务架构体系中,也不建议采用Netflix Conductor,至少在前期的改造过程中使用的场景很小,完全可以用其他方式来替代。【12】

    3、uber/cadence

    Cadence 是 Uber 开发的一个分布式,可扩展,持久且高度可用的编排引擎,以可扩展和弹性的方式执行异步长期运行的业务逻辑。

    业务逻辑被建模为工作流和活动。工作流程是协调逻辑的实现。其唯一目的是协调活动执行。活动是业务逻辑中特定任务的实现。工作流和活动实现在工作进程中托管和执行。这些工作人员长期轮询Cadence服务器以执行任务,通过调用工作流或活动实现来执行任务,并将任务结果返回给Cadence服务器。此外,工作人员可以实现为完全无状态的服务,这反过来允许无限制的水平扩展。

    Cadence服务器代理并持久保存在工作流执行期间生成的任务和事件,这为工作流执行提供了某些可伸缩性和可靠性保证。单个活动执行不具有容错能力,因为它可能由于各种原因而失败。但是,确定在哪种顺序以及如何(位置,输入参数,超时等)活动被执行的工作流程保证在各种故障条件下继续执行。

    其他还有Activiti、JBPM等,以及很多商用工作流或BPM标准的业务流程工具。

    6. 总结

    微服务做为服务架构家族的一员,是构建服务架构中一种方法,服务的粒度不仅仅是技术的问题,更多的是业务问题,我们需要把服务粒度放到全业务流程环境中去解耦,按业务流程解耦服务、编排服务,在数据隔离、服务隔离的条件下,还要避免产生新的信息孤岛,共享是未来的主题。

    参考:

    【1】ccww,微服务中的编排,具体指的是什么? ,知乎,2019.11
    【2】人月神话的博客,服务编排和流程编排(7.5),新浪博客,2019.07
    【3】沉落的星星,微服务核心研究之–编排 ,简书,2019.07
    【4】rongfengliang-荣锋亮,几个微服务编排工具,博客园, 2019.02
    【5】intelligentx,【BPM技术】Zeebe是一个用于微服务编排的工作流引擎,首席架构师,2020.06
    【6】纯洁的微笑,一文读懂 Spring Boot、微服务架构和大数据治理三者之间的故事,2018.05
    【7】鹿鸣天涯,淘宝技术架构变迁,CSDN博客,2019.07
    【8】nicholas.wu,京东架构专家分享京东架构之路,CSDN博客,2018.04
    【9】技术领导力,京东商城,超大型电商系统架构设计原则与实践!8页ppt详解,CSDN博客,2020.03
    【10】火雨_Nick,淘宝网技术架构介绍,CSDN博客,2015.12
    【11】博文视点Broadview,人工智能工程化丨中小企业AI中台落地指南,知乎,2020.10
    【12】人月神话的博客,微服务编排NetflixConductor(7.4),新浪博客,2019.07
    【13】java圈,微服务编排引擎Cadence简介,CSDN博客,2020.11

    展开全文
  • Camel服务集成,服务编排操作文档
  • 导体一个小小的 Golang 服务/程序框架使用 Conductor 编排异步功能/可关闭服务 cond := conductor . NewConductor ( func ( err error ) { log . Error ( err ) }) fi , _ ioutil. ReadFile (“ path / to / ...
  • 效率 Eficy是一个前端编排框架,可以通过JSON配置来编排任何React组件库,简单的配置就可以生成完整的页面。 推荐与组件库一起使用: English | :sparkles: 特征使用JSON编排任何React组件库以快速形成可用页面内置...
  • 由Yaml配置文件驱动的简单任务编排框架 安装 将此行添加到您的应用程序的Gemfile中: gem 'task-orchestrator' 然后执行: $ bundle 或将其自己安装为: $ gem install task-orchestrator 用法 $ orchestrator ...
  • rocs-zeebe-demo Zeebe 入门实战 项目背景介绍 启动该项目希望可以帮助更多社区Zeebe初学者能够快速入门,并以模拟电商在线交易系统中顾客购买商品的...分布式工作流引擎与编排框架:Zeebe 0.26.1 事件驱动架构(EDA)
  • Halo框架是基于CQRS+扩展点+流程编排的应用框架,致力于采用领域驱动的设计思想,规范控制程序员的随心所欲,从而解决软件的复杂性问题。架构原则很简单,即在高内聚,低耦合,可扩展,易理解大的指导思想下,尽可能...
  • 微服务编排

    万次阅读 2019-03-19 10:35:10
    但是,编排涉及到RPC、分布式事务等等,编排的质量不能仅仅取决于老师傅的手艺,需要有完善的编排框架来支撑。首先作一点说明,我们认为流程有长流程和短流程之分,长流程是指包含人工活动的流程,流...

    相对于传统架构,微服务架构下更需要通过各微服务之间的协作来实现一个完整的业务流程,可以说服务编排是微服务架构下的必备技能。但是,编排涉及到RPC、分布式事务等等,编排的质量不能仅仅取决于老师傅的手艺,需要有完善的编排框架来支撑。

    首先作一点说明,我们认为流程有长流程和短流程之分,长流程是指包含人工活动的流程,流程的完成时间因为人的因素会在一个较大范围内波动;短流程指的是不包含人工活动的流程,在流程启动后会在一个较短的预期时间内完成。

    相对于长流程,短流程会更关注与响应时间和tps等指标,也更关注自动保证事务一致性的能力。所以在技术设计上长流程和短流程会有较大的区别,今天本文主要介绍的是短流程相关的那些事儿。

    一、编制、编排傻傻分不清楚

    说到编排,不得不提两个概念:编制和编排。
    图片描述
    编制的英文是Orchestration,本意是乐队指挥,在演出的时候,乐队由指挥来统一的进行指挥和控制。

    编排的英文是Choreography,本意是舞蹈编舞,舞蹈表演通常是舞蹈演员对外部感应作出响应,比如音乐的响应,并且需要与舞伴的行动和表情进行配合。

    这两个词用在微服务下,也有类似的含义:
    图片描述
    微服务的编制强调的是通过一个可执行的中心流程来协同内部及外部的服务交互。通过中心流程来控制总体的目标,涉及的操作,服务调用顺序。

    微服务的编排强调的是协作,通过消息的交互序列来控制各个部分资源的交互。参与交互的资源都是对等的,没有集中的控制。

    可能还是不太好理解,借一个现成的例子:
    图片描述
    编制(Orchestration)就好像交通信号灯,控制着车辆什么时候可以通行。而编排(Choreography)就好像是环岛,没有集中的控制,只有一系列的规则来指明车辆在接近十字路口的时候必须要等待,直到有空间进入环岛环绕系统,然后寻找适当的时候离开。

    编制初看起来好像没有编排自由,灵活。但是编排也有不完美的地方:

    编排使一个业务流程会嵌入到多个服务中,维护会困难重重。

    编排的对等特点,使得两端的服务强耦合,将表现为很难适应需求的变化。

    在扩展性上和工程化上编制在一定程度上更优于编排,在一个业务域内编制更适用,而编排更适用跨业务域的流程。

    后面要分享的内容,实际上是编制的模式,所以在小节标题上甚至都加了引号。仍然使用编排是因为:第一,他已经太深入人心了,几乎没有听到服务编制的说法。第二,我认为刻意的区分“编制”与“编排”并没有多大价值,重要的是保证各参与方对所用的术语有共同的理解。

    二、“编排”的关键在于流程+适配

    前段时间我参加了一个devops的项目,其中有一部分是这样子的:
    图片描述
    在这短短的120行代码中,有25行注释,12行空行,83行功能,包括12次参数校验,18此Rpc(包括14次写操作),包括6大业务步骤,主要功能是实现添加一个用户。但是啊但是,这里面绝大部分是没有事务控制的,可想而知,当真的出现数据不一致的时候我们修复的过程是有多头疼。

    我们不能把代码质量完全寄托于老师傅的手艺,编排完全是有章可循的。结合我们自己的产品经验,来说一说要构建一个编排框架要做些什么事儿,这里不可能覆盖所有的细节,所讲的都是个人认为比较重要的。
    图片描述
    编排包含3个基本的活动模型(赋值、invoke(调用)、空)和5个基本的控制模型(顺序、分支、异常抛出、异常捕获、并行)。

    当然很多编排框架提供了更多方便的活动,比如普元的编排框架提供了本地调用、rest调用、webservice调用等活动,从而在使用上更加的方便。

    有了这些基本的模型,我们就能方便的编排出复杂的业务流程。

    作为一个老师傅,在invoke的时候我们知道有同步和异步的区别,同步实现起来简单,但是在多级级联编排的时候要避免因为某个服务的长响应时间导致雪崩效应,一般可以通过设置合理的超时事件和服务熔断策略来避免;同样在异步调用的时候,应该能自动缓存上下文和避免缓存爆掉,能自动建立异步响应和请求之间的关联。

    同样提到并行也必须考虑不同的聚合方式,部分聚合?全部聚合?

    流程编排完成之后也仅仅是走完了第一步,我们还需要给每个被编的服务提供正确的参数,是一个适配的过程。
    图片描述
    一个编排服务(abcd)由a、b、c、d服务编排而成,每个服务都会有自己的出参入参。适配的过程就是从上下文中给入参赋值以及将出参的结果写入到上下文中。
    图片描述
    编排服务执行到不同阶段,组成上下文的模型也是不一样的。从最初服务的开始执行的时候,上下文中只有系统级的参数和入参(请求报文)。到执行完一个被编服务后上下问就会增加这个被编服务的出参(响应报文),执行上下文是一个不断增大的过程。

    所以适配不仅仅存在与编排服务的入参和被编服务的入参之间,还存在于被编服务和在其之前的服务出参之间。
    图片描述
    最直接的莫过于依靠我们勤劳的双手,完成点到点的映射赋值。只是吧,“勤劳”完了也是没有什么成就感的。

    当然,我们作为老师傅还是有一些过人之处的,我们有一种解放双手的武器。
    图片描述
    这个武器就是元数据,我们通过使用元数据对所有的出参和入参标记着色,然后就可以自动完成同样颜色之间的自动映射。
    图片描述
    之前说到执行上下文的组成模型的时候还包括一个框架产生的部分,这一部分数据主要是流水号(id)和安全方面的考量。按照《基于微服务的企业应用架构设计范式》流水号的生成应该遵循GAIR模式。

    globalId: 全局流水号,如果请求中的globalId为空,则编排服务生成;否则保持不变。

    answerId: 响应流水号,服务提供者生成;可以作为提供者受理的凭证

    inRequestId: 前台流水号,由前台生成

    requestId: 请求流水号,编排服务的协调器生成;生成规则由服务提供者定义

    能编排流程,能适配参数,这个编排框架已经具备运行的能力,后面我们要考虑的就是事务的一致性问题。

    三、“编排”中的分布式事务应满足最终一致性

    依据CAP理论,必须在可用性(availability)和一致性(consistency)之间做出选择。如果选择提供一致性需要付出在满足一致性之前阻塞其他并发访问的代价。这可能持续一个不确定的时间,尤其是在系统已经表现出高延迟时或者网络故障导致失去连接时。

    依据目前的成功经验,可用性一般是更好的选择,但是在服务和数据库之间维护数据一致性是非常根本的需求,我们的编排框架应该选择满足最终一致性。补偿模式就是就是一种很好的实现最终一致性的途径。
    图片描述
    我们通过一个实例来说明补偿模式,一家旅行公司提供预订行程的业务,可以通过公司的网站提前预订飞机票、火车票、酒店等。

    假设一位客户规划的行程是,(1)上海-北京6月19日9点的某某航班,(2)某某酒店住宿3晚,(3)北京-上海6月22日17点火车。在客户提交行程后,旅行公司的预订行程业务按顺序串行的调用航班预订服务、酒店预订服务、火车预订服务。最后的火车预订服务成功后整个预订业务才算完成。

    如果火车票预订服务没有调用成功,那么之前预订的航班、酒店都得取消。取消之前预订的酒店、航班即为补偿过程。

    在补偿模式中,我们要求参与补偿的微服务必须提供补偿操作,并且补偿操作必须是幂等的。补偿框架可以在异常时自动调用补偿操作完成补偿。

    现在restful作为一个轻量级的rpc协议已经被广泛采用,能不能很好的支持restful服务的事务一致性也是衡量一个编排框架的是否成熟的一个标准。我们公司的王博士设计了一套restful扩展规范来支持补偿模式的事务一致性。
    图片描述
    通过PATCH的HTTP Method来表示compensation操作,并且支持通过服务来查询编排服务执行的状态。

    再说一个常见的坑:
    图片描述
    由于是通过rpc的调用,因为网络和调度的关系,可能出现补偿请求比原交易先到达的情况。这会导致补偿操作直接会失败,因为此时原交易尚未发生;最终原交易到达时会被成功的执行,最终就导致了事务不一致。

    填这个坑的办法就是在编排框架发现补偿操作补偿的原交易不存在时,补记录一条原交易的流水,从而保证原交易晚到时会因为记录流水失败而不会成功。

    关于事务一致性的更多内容可以参考之前的关于数据一致性的分享:
    《微服务架构下的数据一致性保证(一)》
    《微服务架构下的数据一致性保证(二)》
    《微服务架构下的数据一致性保证(三)》

    四、“编排”需要更友好的运维工具支撑

    在生产环境中,我们需要通过查看日志来排除故障,应该有支持日志全路径回放的工具,来帮助我们快速定位故障。

    另外我所讲的编排实际是编制,是一种集中式的控制,也就意味着如果被编排的服务有响应缓慢的情况,可能会影响到其他服务。这时候我们需要更快的监控来帮助我们发现这类服务,从而尽早优化。

    五、总结

    最后,总结一下,服务编排有两种:编排和编制。编制是集中式控制,编排强调的是协作。在扩展性上和工程化上编制在一定程度上更优于编排,在一个业务域内编制更适用,而编排更适用跨业务域的流程。

    考虑到服务编排的复杂性,我们不能完全依靠经验丰富的老师傅,使用编排框架能大大提供生产力。构造一个编排框架至少要支持3+5模型,应该采用元数据着色来自动适配服务参数的方法,更进一步要考虑事务(分布式)一致性,补偿模式通常是一种很好的保证事务一致性的方法。

    展开全文
  • 基于DAG的任务编排框架/平台

    千次阅读 2021-08-02 22:50:27
    一、任务编排工作流 任务编排是什么意思呢,顾名思义就是可以把"任务"这个原子单位按照自己的方式进行编排,任务之间可能互相依赖。复杂一点的编排之后就能形成一个 workflow 工作流了。我们希望这个工作流按照我们...
  • API服务编排是指把微服务发布的API或业务系统的API服务接口,按照一定的业务逻辑和流程进行可视化编排的功能,编排后的API流程再重新发布成为一个新的API并可以直接打包成为一个新的微服务单元进行部署和运行。...
  • 上两篇文章主要讲了《[实战项目:设计实现一个流程编排框架(分析)(https://mp.weixin.qq.com/s/veLQZJqYNKbYvuCi7Pf_nA)]》《实战项目:设计...
  • 上一篇文章我们讲了《实战项目:设计实现一个流程编排框架(分析)》主要对流程编排框架产生的背景,并做了需求分析,这其中包含功能性需求和非功能性需求,算是在正式开始设计之前做一个铺垫。前面提...
  • 为什么不进行点对点编排? 基本概念 工作流定义 任务定义 系统任务 工人任务 工作流任务的生命周期 元数据定义 任务定义 重试逻辑 超时政策 工作流定义 工作流程中的任务 连接输入和输出 $ {SOURCE.input / ...
  • 流程编排框架LiteFlow详解

    千次阅读 2021-11-15 19:14:50
    流程编排框架LiteFlow详解1. 前言2. 概述3. LiteFlow框架的作用4. LiteFlow的设计原则5. LiteFlow不适用于场景6. LiteFlow适用场景7. LiteFlow相比于Flowable和Activiti8. 实现验证 1. 前言 在每个公司的系统中,总...
  • 最近几篇文章,我会带大家一起设计一个流程编排框架,从项目的分析、设计、实现、重构、测试方面去了解整个编排框架,也会用到一些设计开发原则及设计模式,话不多说,我们先来看下编排框架的一个背景...
  • 通过微服务编排可以把已经开发好的API服务无需任何代码就可以进行业务逻辑的重组与重构,可以提升API服务的复用效率实现前台业务或业务系统集成的的敏捷交付,通过微服务编排平台也能把业务系统、数据、业务逻辑进行...
  • 基于JSON DSL 创建工作流,对任务的执行进行编排。 工作流在执行的过程中可见、可追溯。 提供暂停、恢复、重启等多种控制模型。 提供一种简单的方式来最大限度重用微服务。 拥有扩展到百万流程并发运行的服务...
  • 上几篇文章主要讲了《实战项目:设计实现一个流程编排框架(分析)》《实战项目:设计实现一个流程编排框架(设计》《实战项目:设计实现一个流程编排框架(实现)》,我们今天主要讲一下基于分析、设...
  • Decker-渗透测试编排框架 目的 Decker是一个渗透测试业务流程框架。 它利用 (与相同的配置语言)来允许声明性penetration testing as code ,因此您的测试可以进行版本控制,共享,重用以及与您的团队或社区进行...
  • 服务编排/数据聚合指的是可以通过一个请求来依次调用多个微服务,并对每个服务的返回结果做数据处理,最终整合成一个大的结果返回给前端。 例如一个服务是“查询用户预定的酒店”,前端仅需要传一个订单ID,...
  • 最近在做的工作比较需要一个支持任务编排工作流的框架或者平台,这里记录下实现上的一些思路。任务编排工作流任务编排是什么意思呢,顾名思义就是可以把"任务"这个原子单位按照自己的方式进行编排,任务之间可能互相...
  • 上一篇文章我们讲了《》主要对流程编排框架产生的背景,并做了需求分析,这其中包含功能性需求和非功能性需求,算是在正式开始设计之前做一个铺垫。 前面提到,项目实战分为分析、设计、实现、测试几个部分讲解,...
  • 触地得分:适用于python的云服务编排框架
  • 最近在做的工作比较需要一个支持任务编排工作流的框架或者平台,这里记录下实现上的一些思路。任务编排工作流任务编排是什么意思呢,顾名思义就是可以把 "任务" 这个原子单位按照...
  • 轻量级流程编排框架liteFlow

    千次阅读 多人点赞 2021-01-23 19:43:52
    但今天我要介绍的,是一款轻量级的流程编排框架——Liteflow。 Liteflow主要致力于逻辑驱动的编排。可以满足于大部分的生产业务场景。和以上著名的开源流程引擎相比,虽然不如他们那么全面,但是胜在轻量,高性能和...
  • liteFlow是一个轻量,快速的组件式流程引擎框架,组件编排,帮助解耦业务代码,让每一个业务片段都是一个组件,并支持热加载规则配置,实现即时修改。 项目主页请点击: 示例工程请点击: 特性 复杂业务的解耦编排...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 35,656
精华内容 14,262
关键字:

服务编排 框架