低代码平台--基于surging开发微服务编排流程引擎构思

前言

微服务对于各位并不陌生，在互联网浪潮下不是在学习微服务的路上，就是在使用改造的路上，每个人对于微服务都有自己理解，有用k8s 就说自己是微服务，有用一些第三方框架spring cloud, dubbo ，abp, nginx,kong就说是微服务的，还有用一些第三放分布式平台去架设部署也认为它是微服务，反正微服务的架设是各种各样，没有定义哪个架构是对的，只要是集大成者，全部用docker, 满足服务发现，服务治理就是微服务。而对于以上架构选择不去评判是对是错。没有一杆称砣去评判是否满足微服务思想架构，所以这种口伐笔诛是没有意义，那么现在浅谈一下对于微服务中微是如何理解，如何架构实现。

而对于微服务，微服务一词中的前缀"微"是一个隐含体系结构最佳实践，让服务在设计阶段保持简单、傻瓜式。虽然传统上微服务仅应用于架构，但它也开始与日常中所说的服务、webapi等进行替换。

"微"是一个重要的提示词，它可以消除企业对系统过渡复杂化的架构。如果你去拆解数年业务系统，然而可以将一个大功能分解为许多小的功能模块服务，从而提供微服务给其它服务终端调用。

而每个微服务都能成为模块功能或者是API.通过微服务集成，可以轻松实现复杂的集成方案。例如，物联网的设备多终端交互，流媒体的多终端推流订阅播放，支付成功多终端消息推送，对于这些都可以分解为独立的微服务进行调用集成，如果不能满足业务需要，不能扩展实现的，只能说你只是对于现有的服务演变升级为分布式服务治理，并不是微服务，因为你还停留在以往需要找寻第三框架，工具去实现，这样还是造成架构臃肿。

而对于业务会有源源不断的需求需要实现，对于这种需求的情况下不可能重复去实现微服务，而我们要做的是对于现有的微服务进行聚合，形成新的服务以提供给其它服务终端进行调用，而surging 现有的做法是通过在服务代码中远程调用微服务数据整合的方式去实现服务聚合，这种方式有一种弊端，需要投入大量的人力去架构维护，并不能满足大型系统架构需要。那么怎么去解决这个难题呢？首先就需要通过现有的微服务进行流程化服务编排，以便实现新的业务服务，那么我们可以通过这篇文章来浅谈一下微服务编排，后面surging 将如何实现。

什么是微服务编排？

微服务编排是指把已经开发好的微服务按照一定的业务流程进行可视化编排的过程，微服务编排引擎会在内部重新聚合为一个新的服务进行发布，而这个服务我们称为聚合服务

通过微服务编排引擎可以把已经开发好的微服务无需任何代码就可以进行业务逻辑的重组与重构，可以提升微服务的复用效率实现前台业务或业务系统集成的的敏捷交付，通过微服务编排引擎也能把业务系统、数据、业务逻辑进行解藕，业务逻辑的编排交由专门的微服务编排引擎完成，而微服务只需要专注完成自已内部逻辑即可。

为什么需要微服务编排引擎

试想一下当你在没有微服务编排引擎，在已经完成微服务拆分的情况下，第三方合作商或者移动端要求你增加逻辑处理服务调用，你该怎样去实现，重新研发扩展微服务？如果是这样的话，整个系统的微服务将比较臃肿，而且违反了单一职责，完全作为独立的业务服务存在。

那么微服务编排引擎可以进行可视化的业务流程编排来降低这些重复没有技术含量的工作、提升服务调用逻辑的可视化。
 

微服务编排流程的思路

通过微服务rpc,提供的routepath，参数模型和结果模型，再通过流程编排这些微服务来实现一个新的聚合服务。

编排流程的模型

• 服务节点模型。例如（参数赋值、invoke（远程调用和本地调用））
• 控制模型。例如（顺序、分支、循环、异常抛出、并行）

微服务编排框架提供了很多的服务节点模型基础化设置，比如编排框架引擎可以支持本地调用、远程RPC调用、协议转化其它第三方服务调用等服务节点，从而在使用上更加的方便，有了这些基本的模型，我们就能方便的编排出复杂的聚合服务

基于surging 如何研发微服务编排流程引擎

首先现在只是对于需要实现服务编排流程引擎的构思，那么我们从二个方面着手

• 可视化流程编排：对于服务节点，控制模型的属性和规则进行可视化设置
• 服务编排引擎的逻辑处理：需要对于业务流程，服务节点逻辑处理调用，配置处理返回结果。

那么针对于微服务之间怎么样顺序，分支调用处理呢？我们可以抽象出需要调用的模型

比如每个服务节点都可以以routepath 作为调用标识，然后可以设计输入参数和输出参数， 输入参数是通过网关调用传入的json 类型的httpbody ,再通过httpbody 可以转为字典参数模型。就比如以下操作

可以举例通过网关传入以下参数：

{

  “name”:"fanly",

  "age":36,

  "sex":1

}

那么我们在服务节点如何设置输入参数呢？ 比如需要传入的是name,那么我们可以通过以下设置

"inputParameters": {
    "name": "${input.name}"
  }

那么我们怎么样去设置输出参数呢？比如我们需要获取服务节点名称为node1 的结果，那么我们可以通过以下进行设置

"outputParameters": {
"result": "${node1.output.entity}"
}

通过以上我们就可以这样定义业务流程的json

{
"name": "workflow_name",
"description": "测试",
"version": 1,
"services": [
{
  "name": "node1",
  "routepath": "api/user/getuser",
  "inputParameters": {
    "name": "${input.name}",
  },
  "type": "microservice",
  "metadata":{}
},
{}
...
],
"outputParameters": {
"result": "${node1.output.entity}"
}
}

而对于以上阐述，如何抽象数据模型来满足流程化调用，而对于surging 是可以通过routepath调用的，所以配置routepath,输入，输出参数完全是可以实现微服务调用，就比如可以通过以下代码routepath方式进行调用

      Dictionary<string, object> model = new Dictionary<string, object>();
            model.Add("username","name");
            string path = "api/user/getuser";
            string serviceKey = "User";

            var userProxy = ServiceLocator.GetService<IServiceProxyProvider>().Invoke<object>(model, path, serviceKey);
            var s = userProxy.Result;

总结

以上是对于低代码平台微服务编排流程引擎构思，后续会陆续实现，现在surging 能支持服务发现，服务治理，多协议扩展，缓存中间件，消息中间件，扫描引擎，并且还支持多语言版本（现支持java 和.net core 两个版本）完全可以满足企业多语言混合异构开发，后面会陆续开源至https://github.com/microsurging，建立surging 微服务引擎低代码平台