平台化三部曲之三流程编排-平台化是舞台，流程编排就是导
演⼀场戏
在上两篇ATA中，第⼀篇讨论了平台的扩展性()，强调微内核和扩展机制实现，第⼆篇讨论平台的模块化开发()，强调业务隔离，松耦合。这这第三篇ATA中，想分享下平台化中另⼀个重要⽅⾯，平台的服务流程编排 （备注：本⽂以下提到交易系统，只是举例，可以扩散为业务平台系统）
像本⽂标题⼀样，我们想象下，在舞台上，有各种⾓⾊，导演根据剧本的设计的场景，让这些⾓⾊，在他的编排下，完成不同剧情。
这和我们的业务平台有很多共通之处。在我们的交易业务系统中，也有很多“⾓⾊”，⽐如各种中间件服务，各种业务系统，我们设计的各种业务，简单类⽐来说就是编排这些“⾓⾊”⼀起完成⼀个特定的“剧情”。
产品经理就是编剧，我们平台化需要实现了⼀个“智能导
演“，能快速响应产品经理的这个编剧的设计，编排出不同的业务场景流程。 ⽽且我们的业务舞台⾥，剧情不同，但是⾓⾊都是基本⼀样的，其实就是⽤同样的演员拍不同的剧情。 每⼀集的⽣产只是需要导演实现不同的编排，⽽且我们希望实现业务的时间和成本尽可能的低。⼤家都喜欢看美剧，美剧的制作可以说是流⽔化⼯业⽣产，编剧、导演、演员、 摄像、剪辑师等各⼯种分⼯合作，环环相扣，⾼效率⽣产,⽽且⼤家会注意到美剧的导演不重要，经常⼀个剧每集可能由不同的导演来导演。这是因为美剧的运作机制本⾝就完成了⼤部分导演的功能，这个机制⾥有很多的规范和套路，从⽽不依赖导演的个⼈能⼒就从⽽可以快速完成各种剧集的制作，导演只需要按照规范套路来导演。
如果我们的业务系统有⼀套类似美剧制作体系⾥的“导演”机制，我们的业务系统开发就可以真正围绕业务本⾝快速构建，流⽔化⽣产了。
这个"导演"机制的功能换成我们的技术术语，就是"流程编排"的能⼒，是在业务系统驱动各种服务按照不同的流程完成某项业务需求。
"导演"的KPI
假设在平台中我们要实现⼀个“导演”机制，那对这个导演的KPI应该怎么设定呢，导演需要什么素质和功能才是业务发展需求急需的。
导演的KPI：
1. ⼀个好的“导演”应该能很好的协调舞台上的各种⾓⾊，指挥他们做正确的事情。
2. 能够根据剧情设计，将各种⾓⾊资源按⼀定的流程完成各⾃的任务。
第⼀个KPI反应导演和不同的⾓⾊，不同的资源打交道，对资源进⾏调⽤的能⼒。
第⼆个KPI考核需要导演能按需⽽变，将复杂剧情分解，流⽔线⼀样的完成各种资源的调配，⽣产新的剧集。
导演能做好1.2 也离不开配套机制，每个⾓⾊分⼯都各司其责，能够响应请求完成任务。
在我们平台化中，第⼀个KPI对应的就是平台能够对不同的系统，包括中间件，服务，业务系统调⽤的能⼒，在交易这种复杂系统中，平台需要把各种调⽤隐藏在平台内部，对外提供⼀个简单⼀致的集成模型，从⽽可以保证平台能和众多其他系统⼀致沟通，简化各种异构系统带来的复杂性，这样我们就可以说平台实现的导演具有很好的协调能⼒。
第⼆个KPI对应的是平台具有快速响应业务需求，快速调整业务处理流程，⽤流程抽象具体的业务处理过程，完成业务请求。
那么我们来设计这个“导演机制”的实现，我们⽤“集成平台”来实现这个“导演机制”。
集成平台的背景
对于交易这样的复杂业务系统，数据庞⼤并不是平台增长的唯⼀⽅式。业务流程也可能在复杂性⽅⾯不断增长。交易处理的信息可能会是各种数量的并且任意数量组合的传输类型、过滤、增强以及路由等。
复杂的问题会在任何领域都出现，但是解决它们的总体策略通常是⼀样的：分⽽治之。我们会将问题拆分为更容易解决的⼦问题。然后这些⽅案再按照与分解相反的⽅式组合在⼀起形成整体的解决⽅案。
通过观察会发现这样的问题是经常发⽣的；借助于经验，能够识别出最优的⽅案。我所讨论的就是模式
这些模式被命名为企业集成模式(Enterprise Integration patterns), 由Gregor Hohpe和Bobby Woolf进⾏了分类和总结，他对我们进⾏复杂业务的解决⽅案提供⾥整套的总结，为我们对复杂业务处理流程进⾏最优化实践指导。
在这⾥我们花点时间多了解下企业集成模式(Enterprise Integration patterns)，这些企业集成模式就是
我们“导演机制”⾥需要的套路，通过这些模式，我们可以针对复杂问题进⾏解耦组合，快速应对需求的变化。
企业集成模式
⾸先⼤家可以通过了解详细信息，EIPs对复杂业务系统开发有深远影响，IBM，TIBCO等中间件提供者利⽤EIP商业实现为解决复杂业务开发提供了整套解决⽅案，在⾦融等领域取得很⼤成功。
EIP本质上可以⾮常简单，通常表现为基本的操作如传输或过滤。最为重要的是，它们可以组合起来形成复杂的解决⽅案。这种组合本⾝也可以是模式。这种能⼒来源于所有的EAI模式具有相同的“接⼝（interface）”：信息可以进出模式。这样，模式就可以组合起来，这是通过接受⼀个模式的输出，并将这个输出作为另⼀个模块的输⼊来实现的。熟悉linux命令的⼈对linux的命令管道的功能便利强⼤印象深
刻，EIP很类似linux的pipe，但是他更强⼤。
⾸先，EIP模式背后的设计思想是基于松耦合，⾯向服务的架构，数据包装成消息在传递，以消息驱动的⽅式协调各个服务，从⽽达到以标准化⽅式实现协议和服务。
EIP覆盖以下的⼀些内容：
1. Messaging system
2. Messaging channel
3. Messaging custruction
4. Messaging routing
5. Messaging transformation
6. Messaging endpoint
7. System Management
⼴义地来说，这说明复杂业务问题就是模式的组合问题。这意味着解决问题，即便是很复杂的问题，将会简化成寻满⾜需求的组合。实现⾃⼰的模式当前也会有⼤量的复杂性，但是这已经进⾏了隔离并且是可管理的。
上⾯的分析总结来说，就是将复杂性进⾏隔离和管理。通过EIPs模式，复杂的交易相关业务的实现的重点就是理解问题并识别出正确的模式，这有利于提⾼整体解决⽅案的质量。
企业集成模式或者EIPS对我们是有帮助的，因为它不仅给我们提供了问题的解决⽅案，并且也帮我们定义了我们所交流问题的本⾝。有了模式问题交流起来更容易。使⽤模式语⾔⽐描述需要解决的问题容易的多，就好像学习汉语⽐学习甲⾻⽂要容易的多。scala不是内部或外部命令
当我们⽤EIP来解决交易中涉及的复杂常见时，我们也将有⼀个更⽅便的语⾔在业务⽅，产品经理，开发团队中沟通。
然后我们就可以在对交易，业务的各种功能进⾏解耦并通过模块化⽅式接⼊平台基础上，利⽤这些功能模块形成了交易流程中各个功能节点，将他们连接起来连起来，完成真正的复杂的业务流程。
集成平台设计⽬标
当平台的功能已插件，模块的形式接⼊平台后，我们需要⼀组模块⼀起完成⼀些复杂的业务功能。⽐如在交易系统中，下单这样⼀个流程，就可能设计到多个模块提供的功能和服务。如何⽅便对这些流程以及服务进⾏编排是体现平台能⼒的重要标志。当⼀些业务需求需要对流程进⾏少量修改或者重新定制某些服务，⽽⼤部分流程功能保持不变是，平台提供简单⽅便的编排能⼒就可以满⾜对业务的快速响应。
⾸先在这样的流程体系中，⼀个复杂的业务流程需要和多种外部业务系统，中间件，数据库系统，连接，调⽤本地服务或者远程服务才能完成，如果我们希望平台能够以简洁的⽅式对流程进⾏编排，平台必须达到以下要求：
1. 简化外部系统的连接调⽤⽅式，消除不同系统调⽤⽅式的差异，将系统的调⽤细节由平台完成，对调⽤者透明，平台提供⼀致的调⽤
模式，同时该调⽤⽅式简单有效。
2. 同时，对流程的描述提供DSL语⾔⽀持，简化流程的设计，⽅便通过可视化流程设计⼯具提⾼开发者流程设计能⼒.
3. 提供对流程的运⾏监控，实时追踪业务运⾏情况。
4. 对流程的⽣命周期进⾏管理，可控制流程的启动停⽌。
5. ⾼效的流程执⾏引擎，能针对流程进⾏计算能⼒调配控制。
6. 完善的流程错误处理报警机制。
⽬前交易系统涉及的业务和流程也变得越来越复杂，正向交易流程，逆向交易流程，⽣活服务预约流程等等。设计到多个交易系统之间的交互，⼀个订单从⽣成到完成，需要多个系统合作，不同类型的业务订单设计的流程也很不相同，集成模式为我们解决这些业务的复杂性提供了很好的问题解决⽅案，让我们对于业务和流程能更清晰的管理。
集成平台设计的⽬的就是引⼊企业集成模式解决⽅案，为平台提供对复杂业务的流程的隔离和编排。
集成平台的实现
企业集成模式的实现有很多，⼤型中间件⼚商如TIBCO，IBM都有⾃⼰企业集成模式实现，在开源领域，Spring Integration， Apache Camel都是其中的佼佼者。 这两者对⽐中，本⼈更倾向Apache Camel，更成熟，有众多的应⽤，活跃的社区和完备的官⽅⽂档⽀持
Camel是什么
Apache Camel是Apache基⾦会下的⼀个开源项⽬，它是⼀个基于规则路由和处理的引擎，提供企业集成模式的Java对象的实现，通过应⽤程序接⼝ 或称为陈述式的Java领域特定语⾔(DSL)来配置路由
和处理的规则。其核⼼的思想就是从⼀个from源头得到数据，通过processor处理，再发 到⼀个to⽬的的.
Camel框架的核⼼是⼀个路由引擎，它允许你定义⾃⼰的路由规则，决定接受哪些消息，做出决定如何处理，发送这些消息给其他⽬标。Camel⽤这种集成语⾔允许你定义复杂的路由规则。
Camel的基本原则之⼀是不会假设任何你需要处理的数据，这是很重要的⼀点，因为它给你们开发者⼀个集成任何系统的⼀个机会，不需要转换你的数据为另外的⼀种公认格式。

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