微服务设计服务组合和可视化编排思考

　　今天再重新整理下我对服务组合和服务可视化编排的一些思考。
　　从整个服务分层的角度来说，微服务最底层首先提供的是原子服务，再朝上则可以提供更加粗颗粒度的组合服务能力。
　　为何要进行服务组合和编排？
　　简单来说就是进一步将共性的可复用业务能力下沉，这些共性业务能力有些是在前端开发中，开发人员自己进行组合和编排完成的。那么实际这块内容应该下沉到一个统一的领域服务能力提供层。
　　在前后端开发分离的情况下，实际上对于前端人员往往并不熟悉和精通业务，如果是简单的UI界面交互调用多个接口服务，前端来做没有问题。但是对于本身和业务场景和业务规则相关的服务组合，前端实际上很难在清楚业务情况下进行编排。
　　比如对于一个订单提交，前端来说就是准备好数据调用接口，但是实际一个订单提交涉及到订单保持，库存扣减，预算检查，支付请求生成等多个API接口能力。而这些如何组合，按什么顺序调用已经和业务规则逻辑相关，而且往往还需要事务控制。
　　类似上面事情则不适合前端来做，而应该通过服务组合来完成，即使没有可视化的服务组合编排工具，那么这部分工作也应该在微服务架构中，由一个领域服务层来进行提供。简单输入-组合输出
　　这个是在开发中经常会遇到的一个场景。比如在实现一个订单查看功能的时候，在订单详细界面里面往往涉及到订单信息，用户详细信息，订购的酒店信息，房间详细信息，付款信息多个信息展示功能。
　　如果是前端开发来做，那么往往前端开发需要调用多个后台的API接口服务来完成数据的获取和填充。而通过服务组合则可以通过一次组合服务调用来返回所有信息。
　　整个服务组合过程可以简化如下：
　　在这个图里面实际上有两个关键点。
　　其一是一个服务的输出可以选择某些数据项目信息作为下游服务的输入。其二是任何一个服务的输出信息都可以作为最终服务的输出组合。
　　那么如何来实现呢？
　　整体思路我们完全可以借鉴传统ESB里面进行服务组合设计的思路，即首先定一个新的组合服务，并确定该API接口服务的契约格式。然后基于该新服务进行服务组合和数据映射。
　　整体实现的难度实际体现在两点。
　　其一是数据映射节点的设计，该数据映射需要是一个独立的设计节点，在该节点完成上一个接口服务的输出到下一个接口服务输入之间数据格式的映射和转化操作。
　　比如前面这个例子，订单查询接口查询出来的json数据中，只获取到userid信息，即可去触发调用用户查询接口。而一个订单可以预定多个方面，那么这里就需要获取到一个roomidList的json数据作为入口传递给房间信息获取接口。
　　因此，在映射里面不是简单的数据项映射，还涉及到数据集合的映射等。
　　其二是数据组合格式的处理，要明白实际最终输出的是要给多个查询返回的组合数据集，那么数据集本身就会有结构，有层次体现。因此在最终返回数据集的数据映射中，需要处理这种组合数据格式，包括每个独立接口服务返回信息具体映射到哪层，和主节点的ID依赖关系等。串行处理中的事务
　　对于API接口服务，本身是无状态的，因此当调用多个服务进行串行编排的时候，不是简单地输入和输出的组合和数据映射。更加重要的是分布式事务处理。
　　在服务编排中的分布式事务处理实际推荐两种方式。其一是事务补偿其二是异步最终一致性
　　对于事务补偿，那需要在提供服务编排和接入的时候，基于服务幂等性提供要给逆向操作服务。而对于异步最终一致性则需要服务组合中提供底层的消息中间件来实现异步和消息重试能力。
　　举个简单的例子来进行说明。
　　对于订单提交的时候，我们需要调用订单保存服务，在订单保存成功的时候调用库存扣减服务接口扣减库存。同时给用户发送订单提交成功的邮件通知。
　　以上是一个常见的三个服务的串行编排操作。在这个过程中对于订单保存和库存扣减我们采用补偿机制，先进行库存扣减，再进行订单保存，如果订单保存失败则对库存扣减回退。
　　而对于邮件发送我们采用异步方式接口，即确保事务最终一致性即可。
　　因此在进行服务编排设计的时候，上游服务应该提供幂等的逆服务用于编排，方便下游服务调用出现异常的时候对上游服务进行回滚操作。
　　而对于类似发送消息，事件等接口服务，则建议采用消息中间件来实现异步最终一致性。在这种情况下即使调用失败也不进行上游服务回滚，而是服务编排实现中对服务进行重试处理。如果多次重试仍然失败再发送异常日志信息供人工修复处理。对传统BPEL流程编排的简化
　　在传统的SOA建设和实施项目中，如果遇到复杂的服务组合和服务编排，一般会采用类似BPEL来完成。比如在Oracle SOA建设项目中，采用Oracle BPEL流程设计器来实现服务编排和组合。
　　BPEL是Business Process Execution Language的缩写，意为业务过程执行语言，是一种基于XML的，用来描写业务过程的编程语言，被描写的业务过程的每个单一步骤则由Web服务来实现。2002年IBM、BEA和微软一起开发和引入了BPEL作为描写协调Web服务的语言。这个描写的本身也由Web服务提供，并可以当作Web服务来使用。
　　对于BPEL实际功能相当强大，类似协议转换，适配，数据映射，数据裁剪和丰富，分支判断逻辑，外部第三方接口服务调用等能力全部具备。因此也经常被认为是比较重量级的服务编排工具。
　　对于BPEL设计的结果是XML格式文件，有严格的方法步骤说明，对于接口服务本身也需要有类似WSDL和XSD等严格的接口契约说明文件。因此在当前微服务编排中很少再用类似BPEL这种服务编排工具。
　　BPEL的服务编排基本是面向设计开发人员的，而在这里需要找寻一种方法可以面向业务建模和系统分析人员使用的服务简单组装和编排的方法。对于服务的组装，和流程建模和设计的方法基本类似，服务组装的最后成果是一个组合服务或流程服务，在服务组装的过程中仍然会大量参考流程可视化建模和设计的方法，只是考虑如何尽量简化。
　　相对于传统的BPEL服务编排来讲，实际上微服务编排需要简化如下内容。仅仅编排服务，不做服务适配，协议转换等。仅做数据映射，不做复杂的业务规则逻辑处理。仅做简单数据裁剪或丰富，不做复杂逻辑分支判断
　　以上3点是在实现服务组合和服务编排的时候需要考虑的点。否则整个服务编排会越做越复杂，服务编排本身不是万能的，对于复杂的规则实现，服务组合等写代码仍然是最佳方式。编排后服务可监控
　　对于通过服务设计器编排完成的服务，本身即是一个新的API接口服务。服务编排设计和流程设计实际上有很多地方类似。即既需要提供服务设计功能，又需要提供服务运行监控功能。
　　对于组合服务运行，每次请求方对API组合服务的调用都应该产生一个接口服务实例，进入到接口服务实例后可以详细的监控到当前接口服务的运行状态，具体每个编排节点的输入输出信息，运行日志和异常信息等。
　　如果要实现整个服务编排，可以看到不仅仅是一个简单的服务设计器问题，而是需要提供要给完整的类似BPEL一样的服务编排管理系统，既包含了设计态，也包括了服务运行容器和状态监控。通过服务编排构建领域服务
　　对于后端是一个个已经拆分的微服务模块中心，那么如果出现需要整合多个微服务API接口服务的领域服务能力在哪里做？传统的做法一般两种，一种是直接在前端开发中完成，一种是单独新增一个领域服务模块来实现跨微服务中心的领域服务API能力接口。
　　如果在前端来实现服务组合存在两个问题，其一是前端开发往往并不会太关心详细业务规则和逻辑，让前端来组合往往导致关键业务实现逻辑出现差错；其次就是在前端组合后这部分内容将很难复用，比如同时存在BS端和APP端的时候，这部分内容往往需要同时实现两遍。
　　因此对于服务编排内容更适合在后端开发来做，但是传统的单体应用以及划分为了多个独立的微服务中心，开发人员往往也仅仅是对自己负责的微服务模块业务熟悉。因此即使要后端来做，也需要对整体业务和应用架构熟悉的人员才能够完成。
　　在前面谈低代码开发平台的时候也谈到，最好是通过一个统一的服务层来实现前端开发和后端能力提供之间的解耦，即前端表单设计绑定的是API接口服务能力，而不是和后台对象和数据库直接发生关系。这样对于比较复杂的业务规则实现，我们就可以编码实现API接口服务，再统一接入。
　　在整个APP应用开发过程中，通过前后端分离后，后端能力和API提供仅需要做到半自动化即可，而前端表单设计由于是通过调用API接口来实现，再增加前端一些JS脚本进行的简单规则处理完全可以实现理想的低代码开发效果。