微服务设计中关于服务组合和可视化编排的思考

这篇文章重新整理下我对服务组合和服务可视化编排的一些思考。

从整个服务分层的角度来说，微服务最底层首先提供的是原子服务，再朝上则可以提供更加粗颗粒度的组合服务能力。

为何要进行服务组合和编排？

简单来说就是进一步将共性的可复用业务能力下沉，这些共性业务能力有些是在前端开发中，开发人员自己进行组合和编排完成的。那么实际这块内容应该下沉到一个统一的领域服务能力提供层。

在前后端开发分离的情况下，实际上对于前端人员往往并不熟悉和精通业务，如果是简单的UI界面交互调用多个接口服务，前端来做没有问题。但是对于本身和业务场景和业务规则相关的服务组合，前端实际上很难在清楚业务情况下进行编排。

比如对于一个订单提交，前端来说就是准备好数据调用接口，但是实际一个订单提交涉及到订单保持，库存扣减，预算检查，支付请求生成等多个API接口能力。而这些如何组合，按什么顺序调用已经和业务规则逻辑相关，而且往往还需要事务控制。

类似上面事情则不适合前端来做，而应该通过服务组合来完成，即使没有可视化的服务组合编排工具，那么这部分工作也应该在微服务架构中，由一个领域服务层来进行提供。

简单输入-组合输出

这个是在开发中经常会遇到的一个场景。比如在实现一个订单查看功能的时候，在订单详细界面里面往往涉及到订单信息，用户详细信息，订购的酒店信息，房间详细信息，付款信息多个信息展示功能。

如果是前端开发来做，那么往往前端开发需要调用多个后台的API接口服务来完成数据的获取和填充。而通过服务组合则可以通过一次组合服务调用来返回所有信息。

整个服务组合过程可以简化如下：

在这个图里面实际上有两个关键点。

其一是一个服务的输出可以选择某些数据项目信息作为下游服务的输入。其二是任何一个服务的输出信息都可以作为最终服务的输出组合。

那么如何来实现呢？

整体思路我们完全可以借鉴传统ESB里面进行服务组合设计的思路，即首先定一个新的组合服务，并确定该API接口服务的契约格式。然后基于该新服务进行服务组合和数据映射。