服务编排前端应用和后端服务能力间关键衔接

　　注：对于服务编排，我在前面专门有文章谈及，今天再整理一篇文章来说服务编排的一些关键设计点和实现思路。
　　首先提出一个重要观点，即在当前微服务架构转型中，服务编排将成为一个大的技术发展趋势，其主要原因展开描述如下：
　　当前在微服务架构，包括中台思想实施过程中有两个重点，其一是共性业务能力下沉并统一以API接口服务能力对上层应用提供；其二是底层共性能力构建微服务化构建。
　　在整个过程中基于上层应用构建场景出现另外一个关键点，即上层应用可能需要的是一个跨了多个微服务API能力的组合服务能力。
　　那么这个能力在哪里实现？
　　当前实际有两种常见的做法如下：其一是在前端应用里面自己实现，但是存在代码重复问题。
　　其二是抽象独立的领域服务组件，在领域服务组件里面实现。
　　不论是传统的构建服务能力共享平台，还是当前构建统一的能力中台服务层，其核心目的都是为了前端应用更加快速的构建，如果前端去做这种复杂组合显然不合适，同时也导致后端业务逻辑泄漏到前端。
　　而在后端独立一个领域组件处理，本身也很难做到足够的灵活可配置，那么新的需求来的时候领域服务开发本身又是很大的工作量和开发周期，这样很难真正敏捷做到响应业务。
　　也正是这个原因，提供灵活，可视化的服务组合，服务编排能力将成为整个微服务架构里面细分的一个技术工具发展点。
　　1.编排概述
　　编排这个概念当前出现得很多，因此还是简单再对编排做下理解。
　　简单来说，编排即是将做一件事情分解得到的操作步骤组装和连接在一起，这些步骤间有具体的执行顺序和判断逻辑，同时又进行输入和输出间的数据内部交互。但是这些内部细节对用户不可见，用户仅仅看到编排后展现的粗粒度能力接口。
　　对于编排，网上又有编制和编排两个说法，先做下引用。
　　https://www.jianshu.com/p/54e2e223dbac
　　Orchestration（编制）
　　Orchestration面向可执行的流程：通过一个可执行的流程来协同内部及外部的服务交互，通过流程来控制总体的目标、涉及的操作、服务调用顺序。Orchestration和BPM、ESB的思想很相似，首先要有一个流程控制服务，该服务接收请求，依照业务逻辑规则，依次调用各个微服务，并最终完成处理逻辑。可以把控制服务视作BPM、ESB引擎，微服务视作BPM、ESB的各种组件。Orchestration实现方案多是同步的，因此导致耦合度高。
　　Choreography（编排）
　　Choreography面向协作：通过消息的交互序列来控制各个部分资源的交互，参与交互的资源都是对等的，没有集中的控制。Choreography可以看作一种消息驱动模式，或者说是订阅发布模式，每笔业务到来后，各个监听改事件的服务，会主动获取消息，处理，并可以按需发布自己的消息。可以把不同队列看作不同种类的消息，微服务看作消息处理函数。Choreography实现方案多是异步的。耦合度低，但是难以满足一些查询类实时同步场景。
　　可以看下当前谈到编排的一些常见场景如下：
　　应用编排
　　在最终我们基于开源的Cloudify来定制PaaS平台的时候就经常提到应用编排的概念，包括当前容器云谈到Kurbernetes的时候也经常说其核心能力是实现容器编排。
　　对于应用编排简单来说就是一个完整的应用托管或部署动作往往涉及到数据库，应用中间件，缓存，消息等多个底层资源，应用部署包能力的提供，同时相互之间还有部署顺序要求。因此应用编排即提供将一个应用完整托管的所有资源安装配置，部署包部署的过程整合在一起形成一个大的流程。
　　在应用编排设计好后，以后就不用单独再去进行数据库，应用，缓存等中间件一个个的部署任务，而是直接通过应用编排模板一次执行即完成整体部署。
　　当前云应用编排的主流做法均是基于TOSCA规范。
　　云应用拓扑和编排规范（Topology and Orchestration Specification for Cloud Applications，简称TOSCA）是一种用于描述在云计算平台上的服务和应用程序以及它们之间的关系和依赖性的语言规范。TOSCA可以描述云计算服务及其组件，并记录这些组件的组织方式以及使用或修改这些组件和服务所需的编排流程。
　　BPM和BPEL流程编排
　　在SOA架构实施里面谈得比较多的是业务流程编排，即在SOA构建完成统一的服务共享层后，期望上层的业务流程能够通过可视化的流程编排来设计和实现。
　　一个业务应用可以理解为：
　　业务应用界面+业务流程（BPEL+HWF)+规则（规则引擎）
　　在流程编排中期望的就是将这些内容串接在一起，完成一个完整的流程开发。首先仍然是进行前端可视化界面设计和数据模型设计，在完成后将界面对应的事件或操作绑定到后端的API服务能力接口上。其次一个完整的业务流程除了自动化业务流，还包括了人工审批流，因此需要完全覆盖常规工作流引擎能力。
　　当前主流的流程编排基本是基于BPMN规范和模型进行设计。
　　BPMN（Business Process Modeling Notation）的主要目标是提供一些被所有业务用户容易理解的符号，从创建流程轮廓的业务分析到这些流程的实现，直到最终用户的管理监控。BPMN也支持提供一个内部的模型可以生成可执行的BPEL4WS。因此BPMN的出现，弥补了从业务流程设计到流程开发的间隙。
　　业务流程编排大厂商一般推出自己的BPEL流程设计器，比如Oracle BPEL设计器，功能相当强大，但是整体偏重量级产品，而且一般也是技术和开发人员使用。
　　ESB服务设计器编排
　　一些ESB产品本身也会提供可视化的服务设计器和服务编排功能。但是这里的服务编排仅仅只针对单个服务的设计。
　　比如当前需要提供一个API接口服务，但是需要适配到数据库，同时获取到的数据还需要进行转换映射再发布。那么将这些动作步骤可视化的组装设计在一起，最终发布一个API接口服务能力。
　　比如对应开源的Talend ESB提供的服务可视化设计。
　　通过可视化设计器可以很灵活的实现常见的数据库适配，协议转换，数据映射等常见操作。但是对应多个服务的组合，组装等能力往往并不提供。
　　微服务编排
　　如果你搜索微服务编排，往往会搜索到开源的Netflix Conductor。但是对于Conductor最重要的还是实现了基本的工作流定义，任务定义，任务的连接，整个工作流的任务调度和监控等基本能力。
　　该工具也没有看到可以进行可视化服务编排设计的地方，但是对于编排完成的模型文件可以展现为可视化的流程图展示，这个也是很多编排软件常用的做法。由于没有可视化设计，当前的输入输出数据项映射也在手工编写流程模板文件的时候完成数据映射工作。但是可以实现前面多个节点的输出朝后续节点传递的需求。
　　当然类似阿里云部分产品也提供轻量的API服务组装编排能力，如下：
　　上图是阿里云的数据服务产品里面提供的服务编排能力。该能力能够实现多个API接口服务的组合组装，实现活动节点之间输入输出数据的参数化传递。
　　虽然当前这个功能还比较简单，但是这个实际为我今天谈服务编排组合的核心应用场景点，即实现多个原子服务的组合，组装，最终提供一个粗粒度的组合服务能力暴露。
　　2.API服务编排设计
　　软件开发中经常会遇到的一个场景。比如在实现一个订单查看功能的时候，在订单详细界面里面往往涉及到订单信息，用户详细信息，订购的酒店信息，房间详细信息，付款信息多个信息展示功能。
　　如果是前端开发来做，那么往往前端开发需要调用多个后台的API接口服务来完成数据的获取和填充。而通过服务组合则可以通过一次组合服务调用来返回所有信息。
　　整个服务组合过程可以简化如下：
　　而这个就是服务组合和编排的常见场景。
　　即就前端应用开发来说并不希望去调用多个服务，而只希望调用一个粗粒度的组合服务来完成业务需求和功能实现。至于内部如何组合服务，如何控制规则，如何传递输入和输出这些都是内部规则逻辑，对前端应用来说不关心。
　　而对于服务组合设计来说，常见的即服务串行和并行场景，在这个场景实现中又增加了类似条件分支判断逻辑，数据映射逻辑等。
　　对于通过服务设计器编排完成的服务，本身即是一个新的API接口服务。服务编排设计和流程设计实际上有很多地方类似。即既需要提供服务设计功能，又需要提供服务运行监控功能。
　　对于组合服务运行，每次请求方对API组合服务的调用都应该产生一个接口服务实例，进入到接口服务实例后可以详细的监控到当前接口服务的运行状态，具体每个编排节点的输入输出信息，运行日志和异常信息等。
　　如果要实现整个服务编排，可以看到不仅仅是一个简单的服务设计器问题，而是需要提供要给完整的类似BPEL一样的服务编排管理系统，既包含了设计态，也包括了服务运行容器和状态监控。
　　3.服务编排节点设计
　　服务组合编排是服务组合，服务组装等，希望通过服务编排能够完成这些事情，而不是简单的完成单一服务的设计和开发。即将多个原子服务组合或组装在一起，最终形成一个新的服务并提供的能力。
　　今天重点思考下服务组合设计中的一些关键节点设计。
　　图片来源网络
　　a.数据Mapping能力节点
　　这个还是要参考ESB设计器的节点设计思路，即提供一个数据Mapping映射能力的节点。这个节点不仅仅可以应用到服务串行设计，也可以应用到并行设计中。
　　A服务输出经过裁剪作为B服务的输入：这个是串行服务设计里面经常遇到的场景点，采用Mapping节点即可以解决。不一定提供可视化的数据映射能力，也可以实际进行参数化的内容模板映射即可。
　　b.数据聚合和Join节点
　　该节点提供数据聚合能力。有点类似于数据库的Join类型操作将两个数据输出关联后再形成一个完整输出。聚合方式实际有两种：方式1：多个输出基于关键字抽象，聚合为一个树结构方式2：多个输出关联为一个宽表数据集
　　A服务+B服务的输出作为C服务的输入：这个场景即涉及到数据聚合和关联，该节点配置重点是确定两个输出之间的关联条件或聚合条件。
　　注：对于Mapping和聚合是作为两个独立节点设计还是合并为一个能力节点，还需要进一步思考，实际在聚合过程中也可以同时处理Mapping操作。
　　c.条件和分支判断节点
　　该节点为必须设计的节点，实际上对于条件判断存在两种主要场景。
　　一种是if-else场景，即当满足条件的时候执行A服务，否则执行B服务。另外一种场景是单纯的if场景，比如当满足条件的时候触发发送邮件服务，没满足条件不触发。
　　在条件判断阶段可以基于输入最简单的规则计算。
　　d.规则处理节点
　　规则处理节点可以基于多个编排服务的输出参数内容进行较为复杂的计算处理逻辑。在这里最好是能够支持常用的脚本计算语言进行规则计算。
　　规则处理节点最好设计为一种离散的节点类型，即规则节点进行规则计算，计算完成的结果可以存在到全局参数变量中。同时在后续服务编排节点中引用。
　　e.事务处理和补偿机制
　　图片来源网络
　　在服务编排设计的时候需要考虑事务处理和补偿机制，多个服务调用属于典型的分布式事务处理场景。因此如果需要补偿，则任何一个服务在进行编排的时候都需要提供幂等的逆向服务，如A服务编排的时候需要提供-A服务，方便在后续服务调用失败时候进行补偿。
　　f.数据映射方式
　　对于数据映射一个方式是进行可视化的数据拖拽映射，一个方面是通过参数化模板进行映射。建议在实现的时候还是考虑参数化模板映射，虽然在使用上增加一定的复杂度，但是本身数据映射的灵活度会大幅度增加。
　　g.定时任务节点
　　可以考虑增加定时任务处理节点，即某些节点需要定时执行，通过轮询的方式来确定是否满足条件，当满足条件后再继续执行下游节点。
　　特别是在服务组合中存在一些异步的导入服务接口的时候需要采用该方式，即通过调用查询接口来轮询导入数据的状态，当导入成功后再执行下游的任务处理节点。