陆小曼|从ESB服务组合编排到NetflixConductor微服务编排( 二 )


比如存在A , B , C三个原子服务 , 我们通过服务编排形成一个新的D服务 。
三个原子服务全部是查询服务 , 希望组装一个新服务 , 一次返回A , B , C三个服务查询结果
这个即我们说的服务组合能力 , 比如我们可以对合同基本信息查询 , 合同条款信息查询 , 合同执行信息查询三个基本原子服务进行组合 , 最终返回一个服务综合信息查询的服务 , 一次返回三个查询结果 。
在这种场景下我们需要考虑查询结果是并行返回还是按层次返回即可 。
二个查询类的原子服务 , 最终需要返回两个数据集关联查询的结果集
这个在微服务架构做了底层数据库拆分后经常会遇到 , 比如对于物料基本信息查询 , 和采购订单明细查询是在两个独立的数据库独立服务提供 。 而我们希望返回的查询结果集是物料编码 , 名称 , 型号 , 单位 , 价格 , 采购数量的复合结果集 。
这种场景下往往一般都是在前端功能开发的时候进行组装 , 而实际上可以考虑是否可以在服务编排层解决这个问题 , 该问题写代码来解决容易 , 但是要做为可视化服务编排组态方式来做实际上有一定的难度 。
对单个已有服务进行裁剪和丰富并形成一个新服务输出
这个暂时也将其纳入到服务编排的范畴 , 即仍然是输入服务 , 但是输出是提供了一个新服务 。
即对单个已有的服务进行服务裁剪和丰富 , 比如对于输出结果过滤掉一些数据项 , 对于输入固定输入一些数据项等 。 这些简单的服务裁剪 , 丰富 , 或简单的数据转换可以在服务编排的时候完成 , 并提供一个新服务 。
对多个原子服务进行流程式的前后串接并形成服务提供
这个是我们经常看到的一种服务编排场景 , 即A , B , C三个服务直接进行编排 , 即A服务的输出直接变为B服务的输入 , B服务的输出又变为C服务的输出 。 如果仅仅是上面假设的这样 , 那么这种流程式的服务编排仍然很简单 , 也很容易去实现 。
但是实际上的难点在于A服务的输出本身也需要作为C服务的输出 , 同时A , B服务的输出也可能是整体输出的一部分 , 这本身就加大了服务编排可视化设计的难度 。
单一业务服务为主体服务 , 但是编排多个业务规则逻辑处理类服务
这也是经常会遇到的场景 , 比如我们在进行合同信息导入的时候 , 首先要调用合同有效性校验服务 , 同时还有调用预算信息检查和扣减服务进行相关的完整性和业务规则校验 。 在这些校验完成后再调用实际的合同信息导入服务 , 如果校验失败则直接返回失败结果 。
这类服务编排往往也正是我们实际在进行前端功能开发时候服务进行组装的逻辑 。
多个导入服务组装为一个导入服务合并导入并形成一个新服务
这个场景实际上和场景1是对应的 , 既然多个服务可以组合后形成组合结果返回 , 那么自然可以将多个导入服务合并为一个导入服务 , 一次性的完成数据导入 。
比如有项目信息导入和项目WBS信息导入两个原子服务 , 那么我们就可以提供一个新的项目信息导入服务 , 一次完成项目基本信息和项目WBS信息的导入 。
陆小曼|从ESB服务组合编排到NetflixConductor微服务编排在这些场景里面可以看到 , 实际上服务编排就是服务串联 , 服务并联下的输入和输出合并 , 服务内容丰富和裁剪等常见场景 。 在一个理想的场景下 , 我们最希望实现的就是一个业务功能点的实现完全能够通过服务编排可视化设计方式来完成 。
下面我们来分析和讨论下服务编排的可视化设计 。
a. 定义一个新服务 , 需要提前考虑新服务输入和输出结构设计
要进行服务编排 , 实际上编排完成后是新产生一个新服务 , 那么新服务一定有输入和输出结构 , 那么就需要对新服务的输入和输出结构进行设计 。 一种方法是在服务编排的时候再对输入和输出结构进行定义 , 一种方法是提前对新服务的服务契约进行定义 , 服务契约定义好后就形成了标准的服务输入和输出结构 。


推荐阅读