再谈服务编排(5.22)

在原来的文章里面曾经谈到过，对于Oracle OSB或开源的ESB产品比如Mule或Talend都会提供轻量的服务编排能力，但是要注意这个服务编排往往是针对单个服务设计用的，即通过服务编排的方式将单个服务的设计过程本身可视化。

比如将单个服务设计过程分解为了适配，协议转换，输入，输出，数据映射，异常处理，路由等各种标准的动作并形成标准的组态式的组件模式。那么在服务设计的时候，我们就可以选择这种组件模块来完成服务的设计和开发工作，而基本不用再进行服务开发层面的硬编码。

而今天要谈的服务编排是两一个场景，即在原来的文章里面谈到过的服务组合，服务组装等，希望通过服务编排能够完成这些事情，而不是简单的完成单一服务的设计和开发。

即将多个原子服务组合或组装在一起，最终形成一个新的服务并提供的能力。

我们举例来说明下，比如存在A，B，C三个原子服务，我们通过服务编排形成一个新的D服务。

1：三个原子服务全部是查询服务，我们希望组装一个新服务，一次返回A，B，C三个服务查询结果

这个即我们说的服务组合能力，比如我们可以对合同基本信息查询，合同条款信息查询，合同执行信息查询三个基本原子服务进行组合，最终返回一个服务综合信息查询的服务，一次返回三个查询结果。

在这种场景下我们需要考虑查询结果是并行返回还是按层次返回即可。

2：二个查询类的原子服务，最终需要返回两个数据集关联查询的结果集

这个在微服务架构做了底层数据库拆分后经常会遇到，比如对于物料基本信息查询，和采购订单明细查询是在两个独立的数据库独立服务提供。而我们希望返回的查询结果集是物料编码，名称，型号，单位，价格，采购数量的复合结果集。

这种场景下往往一般都是在前端功能开发的时候进行组装，而实际上可以考虑是否可以在服务编排层解决这个问题，该问题写代码来解决容易，但是要做为可视化服务编排组态方式来做实际上有一定的难度。

3. 对单个已有服务进行裁剪和丰富并形成一个新服务输出

这个暂时也将其纳入到服务编排的范畴，即仍然是输入是服务，但是输出是提供了一个新服务。

即对单个已有的服务进行服务裁剪和丰富，比如对于输出结果过滤掉一些数据项，对于输入固定输入一些数据项等。这些简单的服务裁剪，丰富，或简单的数据转换可以在服务编排的时候完成，并提供一个新服务。

4. 对多个原子服务进行流程式的前后串接并形成服务提供

这个是我们经常看到的一种服务编排场景，即A，B，C三个服务直接进行编排，即A服务的输出直接变为B服务的输入，B服务的输出又变为C服务的输出。如果仅仅是上面假设的这样，那么这种流程式的服务编排仍然很简单，也很容易去实现。

但是实际上的难点在于A服务的输出本身也需要做为C服务的输出，同时A，B服务的输出也可能是整体输出的一部分，这本身就加大了服务编排可视化设计的难度。

5. 单一业务服务为主体服务，但是编排多个业务规则逻辑处理类服务

这也是经常会遇到的场景，比如我们在进行合同信息导入的时候，首先要调用合同有效性校验服务，同时还有调用预算信息检查和扣减服务进行相关的完整性和业务规则校验。在这些校验完成后再调用实际的合同信息导入服务，如果校验失败则直接返回失败结果。

这类服务编排往往也正是我们实际在进行前端功能开发时候服务进行组装的逻辑。

6. 多个导入服务组装为一个导入服务合并导入并形成一个新服务

这个场景实际上和场景1是对应的，既然多个服务可以组合后形成组合结果返回，那么自然可以将多个导入服务合并为一个导入服务，一次性的完成数据导入。

比如有项目信息导入和项目WBS信息导入两个原子服务，那么我们就可以提供一个新的项目信息导入服务，一次完成项目基本信息和项目WBS信息的导入。