服务编排
⼀. 背景
1. 应⽤系统的架构演变随着业务的越来越复杂，需要更多的思考、更⾼维度的抽象。
2. 将组织逻辑与业务实现分离，使业务应⽤更关注⾃⾝的领域内容。
⼆. ⽬标
  将业务流程可视化、最终展现出全局业务视图，并可以动态调整业务链路。结尾附上⽰例代码。
  ⼤部分现⾏的系统都是通过繁荣的代码来实现业务逻辑的拼装，当业务变得极其复杂的时候会变得可读性极差，可维护性降低。
  服务编排的理想⽬标是开发⼈员只注重简单接⼝（⾏为）的开发，业务⼈员可以通过编排系统实现应⽤及系统的组装和运维。简单⼀点理解的话就是讲服务化衍进为⼯具化（理想状态，现实很难）。
三. 产出
1. ⼀个中⼼化的流程配置站点，效果如图（引⽤zeebe的系统图）
2. ⼀个轻量级的编排⽹关，使⽤⽹关模式(中⼼化)、业务接⼝将不直接暴露服务，所有请求由⽹关组织，类似总线模式。优点在于对于新的应⽤，开发者只需关
注⾃⼰的原⼦功能实现，缺点在于对于旧的应⽤，部分业务接⼝需要拆解改造。
3. ⼀个客户端代理，使⽤代理模式（⾮中⼼化）、中⼼化的配置站点根据版本下发规则⽂件，需要在各
⾃应⽤系统中引⽤代理组件，可以⾃动/按需进⾏服务组织
调⽤与上下⽂适配。
    ps：对于⽹关模式和代理模式⼀般只需要采取1种，具体根据⾃⼰的实际场景选择。
四. 与⼯作流区别
1. 从实现⽅向上来说，⼯作流引擎的核⼼实现是⼀种状态机、可以理解成⼀套中⼼化的服务；服务编排的核⼼是⼀套开发框架，它依赖接⼊应⽤的具体场景。
2. 从业务⽅向来说，⼯作流引擎侧重构建定义执⾏过程，强调规范、快速开发；服务编排侧重业务建模、组装、部署及管理。
3. 从使⽤场景来说，⼯作流引擎⼀室现在最⼤的使⽤场景为办公⾃动化；服务编排可以理解成SOA的产物。
五. 应⽤场景分析
  简单的来说，这种场景对应⽹关模式，⽆需代码侵⼊，由编排⽹关统筹管理服务调度，粒度可以⾜够
的细，⼀次db操作，⼀次⽂件操作，⼀次接⼝调⽤都可以作为调度的基本单元。端点的概念在后⾯实现⾥会讲。
这种场景为代理模式，需要少量的代码侵⼊，侵⼊部分为编排的组件代理，这种模式可以解决中⼼化的问题，各⾃应⽤⾃⼰治理。
  宏观的概念为企业应⽤模式，通过编排引擎将应⽤系统、数据资源和互联⽹资源组成⼀个统⼀的整体。
看起来是不是和ESB有点像，很快我们会总结和ESB的差异。
  核⼼模块参考Netflix conductor 、Zeebe、Apache Camel等成熟产品结合我们⾃⼰业务特性，⽬标为轻量级、可扩展、组件化的设计模式。
  黄⾊的部分就是服务编排组件和ESB产品重叠的内容，服务编排组件相当于是ESB产品成熟架构之上的⼀些功能拆解，并逐渐衍⽣为更贴合互联⽹主流技术（例如微服务）的替代⽅案。
  上⾯我们聊了2种模式，我们通过管道与业务域的关系来解释部署⽅案的差异
  管道是消息传递的载体。由于编排引擎的核⼼为组件化的实现⽅式，其部署的⽅式相对灵活。
  1. 管道的范围决定了业务域的⼤⼩⾼纬度能以整个团队业务为维度，低纬度能以个别应⽤为维度。
  2. 中⼼化部署好处是可以避免下层应⽤代码的侵⼊并集中管理
微服务网关和注册中心区别  3.⾮中⼼化部署⾮中⼼化部署有2种⽅式
    i）第⼀种为代码植⼊，这种⽅式不依赖管道作为消息载体，每⼀个植⼊应⽤都属于消息载体，并直接管理上下⽂。
    ii）第⼆种为ServiceMesh的边车模式，将控制与业务分离。好处是⽆需进⾏代码侵⼊，缺点是当前环境该模式并不成熟，容易带⼊运维成本。
  除了路由可视化，还可以利⽤JMX实现扩展管理，Mbean中包含了所有可更新对象。消息管道中按每笔事件定义通信ID，通信ID在⼀次传递过程中不会变化，其中包含版本信息。新版本的产⽣不会影响到旧的事件。
六. 核⼼组件实现
重点参考开源产品Apache Camel。最核⼼的是DSL语⾔、端点、组件、路由、注册表、格式转化。
DSL 其实是 Domain Specific Language 的缩写，相对DSL的定义就是 GPL(General Purpose Language)
常见的DSL有SQL、Regex ，常见的GPL有Objective-C、
DSL 最⼤的设计原则就是简单，通过简化语⾔中的元素，降低使⽤者的负担设计语法和语义。Camel组件中设计DSL语法和语义，定义 DSL 中的元素并实现parser，对 DSL 解析，最终通过解释器来执⾏。⽬前⽀持Java DSL和XML DSL。其核⼼定义就是描述了⼀次路由⾏为的上下⽂、内容、类型、依赖、逻辑等等。运⾏时编排系统就会载⼊实现定义的DSL⽂件，会按照DSL⽂件中定义的路由⾏为来执⾏。
回到上⾯提出的问题，什么是端点(Endpoint)。端点是camel的抽象概念。可以理解成信道末端模型，系统可以利⽤信道收发消息。更通俗⼀点来讲，你可以将端点理解成⼀次通信⾏为的⽀撑/⽬标⽀点。这个⽀点可以⽀持⾮常多的协议，例如http、ftp、rpc等等等等。这从基础上就决定了我们的通信信道不仅仅可以⽀撑现在常⽤的服务/微服务场景，更能从更多底层元素来运作编排⾏为。
但是端点需要满⾜⼀定的规则要求，⾸先是路由Url，⽰例中的file代表Scheme，定义了端点的协议类型。
Context path定义通信的路径及端⼝等。Options定外额外的⼀些扩展信息，根据协议和场景的特殊性可以⾃定义逻辑和内容。
端点还关联着⽣产者、消费者、交换机等概念，这些内容的设计和实现和RabbitMq同源，RabbitMq的底层设计就是使⽤了Camel的框架。
关于这些概念可以参与我之前的⽂章
组件的概念如下图
组件的实现⽅式为监控指定⽬录中的⽂件。此⽬录中的⽂件描述了组件的名称、组件类的全路径名。⼤部分组件的java代码模块都与模块核⼼模块做了分离，因为他们常常依赖第三⽅的包，如果不分离，将会使核⼼包过度膨胀。
整个端点实现的类图可以参考下图

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。