https://developer.aliyun.com/article/772

简介： 在上两篇ATA中，第一篇讨论了平台的扩展性(《从Eclipse平台看交易平台化》)，强调微内核和扩展机制实现,第二篇讨论平台的模块化开发(《Google Guice平台模块化开发的果汁》)，强调业务隔离，松耦合。这这第三篇ATA中，想分享下平台化中另一个重要方面，平台的服务流程编排 （*备注：本文.

在上两篇ATA中，第一篇讨论了平台的扩展性(《从Eclipse平台看交易平台化》)，强调微内核和扩展机制实现,第二篇讨论平台的模块化开发(《Google Guice平台模块化开发的果汁》)，强调业务隔离，松耦合。这这第三篇ATA中，想分享下平台化中另一个重要方面，平台的服务流程编排 （备注：本文以下提到交易系统，只是举例，可以扩散为业务平台系统）

像本文标题一样，我们想象下，在舞台上，有各种角色，导演根据剧本的设计的场景，让这些角色，在他的编排下，完成不同剧情。
平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图1

这和我们的业务平台有很多共通之处。在我们的交易业务系统中，也有很多“角色”，比如各种中间件服务，各种业务系统，我们设计的各种业务，简单类比来说就是编排这些“角色”一起完成一个特定的“剧情”。产品经理就是编剧，我们平台化需要实现了一个“智能导演“，能快速响应产品经理的这个编剧的设计，编排出不同的业务场景流程。 而且我们的业务舞台里，剧情不同，但是角色都是基本一样的，其实就是用同样的演员拍不同的剧情。 每一集的生产只是需要导演实现不同的编排，而且我们希望实现业务的时间和成本尽可能的低。大家都喜欢看美剧，美剧的制作可以说是流水化工业生产，编剧、导演、演员、 摄像、剪辑师等各工种分工合作，环环相扣，高效率生产,而且大家会注意到美剧的导演不重要，经常一个剧每集可能由不同的导演来导演。这是因为美剧的运作机制本身就完成了大部分导演的功能，这个机制里有很多的规范和套路，从而不依赖导演的个人能力就从而可以快速完成各种剧集的制作，导演只需要按照规范套路来导演。

如果我们的业务系统有一套类似美剧制作体系里的“导演”机制，我们的业务系统开发就可以真正围绕业务本身快速构建，流水化生产了。
**
这个”导演”机制的功能换成我们的技术术语，就是”流程编排”的能力,是在业务系统驱动各种服务按照不同的流程完成某项业务需求。

“导演”的KPI

假设在平台中我们要实现一个“导演”机制，那对这个导演的KPI应该怎么设定呢，导演需要什么素质和功能才是业务发展需求急需的。
导演的KPI：

  1. 一个好的“导演”应该能很好的协调舞台上的各种角色，指挥他们做正确的事情。
  2. 能够根据剧情设计，将各种角色资源按一定的流程完成各自的任务。

第一个KPI反应导演和不同的角色，不同的资源打交道，对资源进行调用的能力。

第二个KPI考核需要导演能按需而变，将复杂剧情分解，流水线一样的完成各种资源的调配，生产新的剧集。
导演能做好1.2 也离不开配套机制，每个角色分工都各司其责，能够响应请求完成任务。
在我们平台化中，第一个KPI对应的就是平台能够对不同的系统，包括中间件，服务，业务系统调用的能力，在交易这种复杂系统中，平台需要把各种调用隐藏在平台内部，对外提供一个简单一致的集成模型，从而可以保证平台能和众多其他系统一致沟通，简化各种异构系统带来的复杂性，这样我们就可以说平台实现的导演具有很好的协调能力。

第二个KPI对应的是平台具有快速响应业务需求，快速调整业务处理流程，用流程抽象具体的业务处理过程，完成业务请求。

那么我们来设计这个“导演机制”的实现，我们用“集成平台”来实现这个“导演机制”。

集成平台的背景

对于交易这样的复杂业务系统，数据庞大并不是平台增长的唯一方式。业务流程也可能在复杂性方面不断增长。交易处理的信息可能会是各种数量的并且任意数量组合的传输类型、过滤、增强以及路由等。

复杂的问题会在任何领域都出现，但是解决它们的总体策略通常是一样的：分而治之。我们会将问题拆分为更容易解决的子问题。然后这些方案再按照与分解相反的方式组合在一起形成整体的解决方案。

通过观察会发现这样的问题是经常发生的；借助于经验，能够识别出最优的方案。我所讨论的就是模式
这些模式被命名为企业集成模式(Enterprise Integration patterns), 由Gregor Hohpe和Bobby Woolf进行了分类和总结，他对我们进行复杂业务的解决方案提供里整套的总结，为我们对复杂业务处理流程进行最优化实践指导。
在这里我们花点时间多了解下企业集成模式(Enterprise Integration patterns)，这些企业集成模式就是我们“导演机制”里需要的套路，通过这些模式，我们可以针对复杂问题进行解耦组合，快速应对需求的变化。

企业集成模式

首先大家可以通过EIP的网站了解详细信息，EIPs对复杂业务系统开发有深远影响，IBM，TIBCO等中间件提供者利用EIP商业实现为解决复杂业务开发提供了整套解决方案，在金融等领域取得很大成功。

EIP本质上可以非常简单，通常表现为基本的操作如传输或过滤。最为重要的是，它们可以组合起来形成复杂的解决方案。这种组合本身也可以是模式。这种能力来源于所有的EAI模式具有相同的“接口（interface）”：信息可以进出模式。这样，模式就可以组合起来，这是通过接受一个模式的输出，并将这个输出作为另一个模块的输入来实现的。熟悉linux命令的人对linux的命令管道的功能便利强大印象深刻，EIP很类似linux的pipe，但是他更强大。
平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图2

首先，EIP模式背后的设计思想是基于松耦合，面向服务的架构，数据包装成消息在传递，以消息驱动的方式协调各个服务，从而达到以标准化方式实现协议和服务。

EIP覆盖以下的一些内容：

  1. Messaging system
    平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图3

  3. Messaging channel
    平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图4

  5. Messaging custruction
    平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图5
  6. Messaging routing

平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图6

  1. Messaging transformation
    平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图7
  2. Messaging endpoint
    平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图8
  3. System Management
    平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图9

广义地来说，这说明复杂业务问题就是模式的组合问题。这意味着解决问题，即便是很复杂的问题，将会简化成寻找满足需求的组合。实现自己的模式当前也会有大量的复杂性，但是这已经进行了隔离并且是可管理的。
上面的分析总结来说，就是将复杂性进行隔离和管理。通过EIPs模式，复杂的交易相关业务的实现的重点就是理解问题并识别出正确的模式，这有利于提高整体解决方案的质量。

企业集成模式或者EIPS对我们是有帮助的，因为它不仅给我们提供了问题的解决方案，并且也帮我们定义了我们所交流问题的本身。有了模式问题交流起来更容易。使用模式语言比描述需要解决的问题容易的多，就好像学习汉语比学习甲骨文要容易的多。

当我们用EIP来解决交易中涉及的复杂常见时，我们也将有一个更方便的语言在业务方，产品经理，开发团队中沟通。

然后我们就可以在对交易，业务的各种功能进行解耦并通过模块化方式接入平台基础上，利用这些功能模块形成了交易流程中各个功能节点，将他们连接起来连起来，完成真正的复杂的业务流程。

集成平台设计目标

当平台的功能已插件，模块的形式接入平台后，我们需要一组模块一起完成一些复杂的业务功能。比如在交易系统中，下单这样一个流程，就可能设计到多个模块提供的功能和服务。如何方便对这些流程以及服务进行编排是体现平台能力的重要标志。当一些业务需求需要对流程进行少量修改或者重新定制某些服务，而大部分流程功能保持不变是，平台提供简单方便的编排能力就可以满足对业务的快速响应。

首先在这样的流程体系中，一个复杂的业务流程需要和多种外部业务系统，中间件，数据库系统,连接，调用本地服务或者远程服务才能完成，如果我们希望平台能够以简洁的方式对流程进行编排，平台必须达到以下要求：

  1. 简化外部系统的连接调用方式，消除不同系统调用方式的差异，将系统的调用细节由平台完成，对调用者透明，平台提供一致的调用模式，同时该调用方式简单有效。
  2. 同时，对流程的描述提供DSL语言支持，简化流程的设计，方便通过可视化流程设计工具提高开发者流程设计能力.
  3. 提供对流程的运行监控，实时追踪业务运行情况。
  4. 对流程的生命周期进行管理，可控制流程的启动停止。
  5. 高效的流程执行引擎，能针对流程进行计算能力调配控制。
  6. 完善的流程错误处理报警机制。

目前交易系统涉及的业务和流程也变得越来越复杂，正向交易流程，逆向交易流程，生活服务预约流程等等。设计到多个交易系统之间的交互，一个订单从生成到完成，需要多个系统合作，不同类型的业务订单设计的流程也很不相同，集成模式为我们解决这些业务的复杂性提供了很好的问题解决方案，让我们对于业务和流程能更清晰的管理。

集成平台设计的目的就是引入企业集成模式解决方案，为平台提供对复杂业务的流程的隔离和编排。

集成平台的实现

企业集成模式的实现有很多，大型中间件厂商如TIBCO，IBM都有自己企业集成模式实现，在开源领域，Spring Integration， Apache Camel都是其中的佼佼者。 这两者对比中，本人更倾向Apache Camel，更成熟，有众多的应用，活跃的社区和完备的官方文档支持

平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图10

Camel是什么

Apache Camel是Apache基金会下的一个开源项目,它是一个基于规则路由和处理的引擎，提供企业集成模式的Java对象的实现，通过应用程序接口 或称为陈述式的Java领域特定语言(DSL)来配置路由和处理的规则。其核心的思想就是从一个from源头得到数据,通过processor处理,再发 到一个to目的的.

Camel框架的核心是一个路由引擎，它允许你定义自己的路由规则，决定接受哪些消息，做出决定如何处理，发送这些消息给其他目标。Camel用这种集成语言允许你定义复杂的路由规则。

Camel的基本原则之一是不会假设任何你需要处理的数据，这是很重要的一点，因为它给你们开发者一个集成任何系统的一个机会，不需要转换你的数据为另外的一种公认格式。

Camel 提供了高水平的抽象，它允许你根据相同的api协议或者系统的数据类型集成各种各样的系统。Camel的组件提供了特殊实现的接口api，其目的是给不同的协议和数据类型服务。Camel打破了传统模式，它支持190多种不同的协议和数据类型，它的扩展性和模块性允许你实现你自己专有协议的无缝插件。这些体系结构的选择淘汰没有必要的转换，从而使camel更加的高效，易学。结果证明，camel是适合嵌入到其他项目中的，因为它提供了充足的处理能力。其他开源的项目，例如Apache ServiceMix和ActiveMQ已经使用camel作为企业集成的一种处理方式。

我们应该提问camel不是什么，camel不是ESB，有些人称camel是个轻量级的ESB，因为它支持路由、事务、监控、编制等。Camel 没有一个容器或者一个可靠的消息总线，但是它可以依赖例如开源的ESB或者前面提到的ServiceMix，由于以上原因，我们更喜欢把camel称作超越一个ESB的集成框架。

Apache Camel的基本概念

平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图11

  • 端点(Endpoint)

    1. 是Camel中的一个基本概念，Endpoint作为Camel系统中一个通道的端点，可以发送或者接受消息。在Camel中Endpoint使用URI来配置。在运行时Camel通过URI来查找端点。端点的功能强大、全面而且又可维护。

  • 组件(Component)

    1. Component是一些Endpoints URI的集合。他们通过Schema来连接（例如file:,jms:），而且作为一个endpoint的工厂。

  • 路由(Route)

    1. 顾名思义，Route，就是路由，它定义了Message如何在一个系统中传输的真实路径或者通道。路由引擎自身并不暴露给开发者，但是开发者可以 自己定义路由，并且需要信任引擎可以完成复杂的传输工作。每个路由都有一个唯一的标识符，用来记录日志、调试、监控，以及启动或者停止路由。路由也有一个输入的Message，因此他们也有效的链接到一个输入端点。路由定义了一种领域特有的语言（DSL）。Camel提供了java、scala和基于XM的Route-DSL, 路由可以使用过滤器、多播、接收列表、并行处理来定义，从而变得非常灵活。

  • 处理器(Processor)

    1. Processor是router中的一个组成元素，用来消息转换和处理。

    Apache Camel的主要功能

  • 路由引擎

    1. 路由引擎是camel的核心功能。路由引擎基于路由配置有选择的对消息进行路由。

  • 企业集成模式

    1. 针对复杂业务处理，Gregor Hohpe 和Bobby Woolf 发现了很多问题，并给出了响应的解决方案。他们编写一本《Enterprise Integration Patterns》书，这本书对那些专业集成的人来说是必读的书。接下来，它将帮助你理解又快又容易地理解camel。。

  • Domain-speclfic language（DSL）

    1. Camel的domain-specific language（DSL） 对集成领域来说是一个主要的贡献。Camel提供了多种DSLs。例如java、Scala，Groovy，它还允许以XML特定方式的路由规则。

  • 可拓展组件库

    1. Camle提供了超过190个组件的拓展库。这些组件使camel用APIs连接传送和理解数据的格式。

  • 模块化、组件式体系结构

    1. Camel 有一个模块化体系结构，它允许任何组件加载到camel中对camel的功能进行扩展开发。

  • 数据类型自动转换

    1. Camel已经嵌入了150多种自动转换的机制。你不在需要配置类型转换规则，例如把byte arrays 转换为 Strings。如果你需要一种camel没有的转换类型，你可以自己去创建属于自己的Converter。

  • 轻量核心

    1. Camel核心被认为是轻量级的，总共自由包加起来大约也就1.6MB，它只依赖Apache Commons Logging，资源的通用管理。这样使camel更容易在你喜欢的任何地方嵌入或者部署。例如在标准的应用、web应用、spring应用、J2EE应用、JBI容器、OSGI bundle、java web start或者Google Appengine。Camel没有被设计成一个server或者ESB，取而代之的是可以嵌入到你选择的任何平台中。

  • 测试驱动

    1. Camel提供了测试工具箱，使测试你自己的camel应用更容易。这些测试工具在测试camel本身中广泛应用。例如他们可以帮助你虚拟真正的endpoints。

    在Camel提供的功能基础上，我们可以打造一个基于阿里技术体系和业务系统的集成平台，为复杂业务提供更高效的解决方案。

期望的集成平台功能

目前阿里内部有众多系统为整个交易相关提供各种服务，整个交易就是讲这些系统联合起来，
平台化三部曲之三流程编排 - 平台化是舞台，流程编排就是导演一场戏 - 图12

提供统一的集成模型

当集成平台就绪时，我们期望他能够将各个业务系统通过集成方式连接起来，作为平台的能力扩展对外输出。从这个平台出发，业务开发者将不需要直接面对各种复杂的业务系统，然后开发对这些系统的服务调用代码，平台会完成这些基础部分，然后提供一个抽象的一致的访问形式，完全消除系统之间的差异。

所有的外部系统成为了平台的服务。平台对这些集成的系统提供了更简化的访问形式，方便流程脚本的设计编写。比如利用Camel的component功能，实现对业务系统，中间件系统的集成封装，从而使每个服务，每个业务都可以以URI寻址的方式完成调用，举例来说：对TOC增加超时可能就是将数据传给如下的地址：
.to(“toc://insertTimeout?type=13”)

这样，所有外部系统，都可以用URI这个简单格式表达出来，所有复杂的细节实现都由集成平台自身完成。
这种在http中广泛使用的URL形式将极大的简化我们队服务的调用形式,从而为DSL化流程提供可能。
集成平台期望能够对阿里内部所有的系统提供这种标注化的URI访问形式。

这样对开发的好处显而易见：

  1. 每一个开发新人在阿里开发都要去熟悉各种中间件系统，这些都有一定的学习成本。及时在熟悉后，开发人员也会碰到各种问题，比如HSF调用ar包依赖，需要维护版本升级等因素。
  2. 各个业务系统之间由于架构不同，提供服务的形式多种多样，用一个标准的规范去统一起来，对后续的业务开发效率极有好处。
  3. 更明确的分工，中间件，业务系统能跟规范自己的能力透出，实现面向服务的架构，系统之间更加解耦。开发团队可以分为提供基础设计，提供业务能力和开发业务等不同维度，协作开发，避免各自缺乏沟通或者深度耦合。
  4. 简化后的服务URI可以为DSL形式的流程脚本设计提供基础，形成业务人员，产品经理和开发人员都能够沟通的逻辑。

    DSL快速流程设计

对流程的设计和实现可以很好的体现软件的现代化程度，从编程语言的发展趋势来看，都是为了能跟高效的完成流程的实现，比如目前我们是用java等编程语言来实现一个业务流程，最近领域语言的发展可以更高效抽象，贴近自然语言的方式来实现逻辑。我们经常在真正编写程序写一些伪代码，这些伪代码跟接近问题本身，处理业务逻辑。 将流程以DSL语言的方式来设计和实现，可以快速的响应需求变化。 以前要编写大量代码的业务逻辑可以转化成用DSL设计一些子流程，并将子流程组合起来形成一个大的流程。

Camel的DSL语言为我们的流程设计提供了很好的工具。 让我们对流程编排有一个语言级别的支持。 我们只需要描述流程从开始到结束需要执行的路径。 同时这种DSL语言可以很好的以图形化的实现表现和设计，我们可以让非程序开发人员有可能成为流程的开发着。

我们来看一个DSL流程的例子：

  1. from("direct:buyNow")
  2.         .split().method("orderSplitter").to("direct:orderAssigment");
  4.     from("direct:orderAssignment").recipientList().method("orderRouter");
  6.     from("seda:bizType_200?concurrentConsumers=80")
  7.      .to("bean:biztype200Handler?method=prepareOrder").to("direct:orderCreated");
  8.     from("seda:biztype_1001?concurrentConsumers=3")
  9.     .to("bean:bieztype1001handler?method=prepareOrder").to("direct:orderCreated");
  11.     from("direct:orderCreated")
  12.         .aggregate(new OrderAggregationStrategy())
  13.    .method("orderPayment", "oderPay").completionTimeout(5 * 1000L);

这段DSL有一些功能，根据业务类型进行识别路由，对每个业务类型，执行不同的流程，然后都执行到订单创建成功。 每个业务流程需要的机选能力也可以调配。 订单创建成功后，可以继续驱动走向订单付款的流程。
从这段例子可以看到，业务逻辑的实现被极大的简化，业务开发人员根本就不需要了解什么是HSF等该如何调用。

如果这样一段DSL基本可以完成一个下单的流程，那么我们维护和开发新的业务的代价也就可想而知有极大的提高。 DSL的学习成本很低，新的业务开发只需要参考老的业务DSL实现，做一些更改即可。

业务开发辅助工具

当集成平台通过EIP模式建立起来，同时具有DSL流程描述语言，那么我们就而已通过开发一些业务辅助工具更高效的开发业务。 比如：

  1. 可视化业务流程设计工具
    提供给业务和开发人员类似Visio的辅助可视化开发工具，让业务设计人员能够可视化的设计业务流程。
  2. 业务流程模拟测试工具
    流程设计完成后，可以对流程的输入和输出进行mock测试，输入不同的条件，检测不同的结果，从而保证流程开发的质量。
  3. 集成平台运行监控工具
    集成平台完成了一个数据接入，数据处理，数据流出的数据网，就像铁路网一样，数据通过设计好的流程路径被处理分流，这些标准的方式为我们的实施可视化监控提供了可能。我们可以实施的跟踪数据处理过程，当有错误，某些点压力增大时能及时调整（比如限流，引流等），为业务稳健运行提供了更高层的保障。

    总结

    目前阿里的电商系统已经形成了一个庞大的生态，各种新老系统，中间件在一起完成业务功能。 我们在维护系统，开发新业务的过程中，感受到了越来越大的压力。旧的系统必须维护改造，新的系统业务能够快速发展，新旧系统之间都需要互联互通，同时我们又期望维护和开发成本都可以降低，企业集成模式为我们提供一种解决方案，如果我们能有效的在阿里实施EIP，将会对我们系统的架构升级，服务能力，业务快速发展提供保障。

最后期望发起一个项目，对apache camel做阿里相关技术的扩展开发，然后contribute回到apache社区，希望有兴趣的团队可以一起合作, Let’s ride the camel。