|
|
译者 | 崔皓
策动 | 云昭
为何“基于事情”和“事情驱动”这两个词当初简直每集体都会挂在嘴边？能否使用现有的REST API来构建事情驱动的架构？本文将环抱这两个问题展开探讨。
技术改动世界，技术人始终热中于让糊口更为便捷。能够想象如下场景，快递公司1提供了包裹跟踪办事，会通知你包裹在哪一天以及甚么时间规模内抵达（有可能泛起达到时间因为运输延误不正确的状况）；快递公司2被动通知你，以后包裹离你还有多少站。你会给予哪家快递公司好评？因而可知跟着业务的不停开展，客户对实时运用和办事的需要也在不停减少。假如你的业务运用或办事是面向客户的，就需求关注客户冀望获取更间接、实时的体验。事情驱动架构就愈来愈拥有策略首要性了，因此事情驱动架构也遭到各大公司的青眼。
实时运用之美和基于事情架构的首要性
就集体而言，谁都不喜爱被动静类的通知始终狂轰滥炸。因此，大少数手机运用顺序都封闭了此功用。但在某些状况下，用户又会需求实时或最少接近实时的更新。快递就是其中之一：用户往往更喜爱在递送人员按门铃以前就禁止他，由于门铃声会让家中的宠物狗歇斯底里的乱叫。基于此，用户但愿有这样一个运用顺序，它会在快递离本人家还有一站的时分就通知我。（经过实时动静的形式通知我，而不是让用户每非常钟就反省一次动静形态）或者想象有这么一个值机的运用顺序，它会在更改登机口时向您发送实时推送通知 - 假如这类更改产生在航班腾飞前半小时，这个运用就对你十分有用，特别是你正在遭受交通拥挤，为了不早退而还不能不赶往登机口的状况下。
动静推送办事与提供信息的载体有关，而关乎于如何被动为客户提供实时的、可用的办事。这也是如今被人津津乐道的客户体验。虽然说客户体验其实不能改动商业的游戏规定，但其发生的办事差别成了选择航空公司的依据。少数状况下，运用之间的替换是经过API（一般为REST）完成的。例如，一个运用顺序有一个更新——一个包裹曾经发货，或者特定航班的登机口曾经改动——而另外一个运用顺序接纳到这个更新。问题是RESTful运用顺序和办事实质上是基于轮询的。这象征着他们以特定的时间距离获得数据，乃至仅在被要求时才要求这样做（经过刷新运用顺序获得数据）。为了晋升用户体验，并被动、实时地为用户提供信息，咱们需求一种不同凡响的机制，以便当即触发业务运用顺序、办事和零碎从而响应特定事情。这就是基于事情架构存在的意义。
构建基于事情架构所需的组件
虽然没有一种办法能够构建事情驱动的架构，并同时完成多种变体、协定和办法。但实质上，它由三个别离的组件组成——事情出产者、事情消费者以及事情代理。解耦使得异步处置事情成为可能——这确保了事情出产者和事情消费者独立任务。
事情驱动架构模式
事情出产者
事情出产者实质上是事情的发送者。在上图的例子中，能够将货物跟踪零碎或门店办理零碎作为事情出产者。
事情消费者
从逻辑上讲，事情消费者是事情的接纳者。它能够是手机上的运用顺序，也能够是公司IT生态零碎中的其余业务运用，用于反省或侦听特定事情的产生，以便做出相应的响应——例如，经过手机上的推送通知触发另外一个运用。通常，这是经过定阅特定事情的事情消费者来完成的。
事情代理
当初，事情代理是构成为了基于事情架构的首要组成部份，并完成了事情出产者和事情消费者的解耦。事情代理承受来自前者的事情，并长时间存储它们，而后将事情发送给后者。按照事情消费者的数量，事情代理还担任将事情路由到正确的消费者。在这类状况下最罕用的动静传递模式是pub/sub（公布/定阅）。异步模式可确保不会丧失任何动静。即便一个或多个事情消费者（即定阅者）在给按时刻因为某种缘故不成用，事情也会根据发生的程序排队等候消费。一旦事情消费者从新上线，将会消费排队的动静并恢复其先前的流动。
REST也能构建基于事情的架构
大少数时分，当搜寻无关如何创立事情驱动架构的资讯时，会发现诸如 “Streaming API”和“event-driven API”的术语。正如您可能知道或料想的那样，这些都属于反对事情驱动通讯的新型API。但是，理想状况是，大少数软件运用顺序供给商不提供这些类型的API，要末是由于存在其余症结业务优先级，要末他们基本没有所需的资源。这就是扩展示有API以使其合适基于事情架构乏味之处。在谈到加强已有的REST API时，能够按照API在事情驱动模式中的角色采用如下几种战略：这些API是事情出产者仍是事情消费者？
当REST API是事情出产者时，解决办法通常十分简略；咱们只需求一个反对各种API（包罗 REST）和协定的事情代理——换句话说，它能够帮忙将REST转换为AMQP或MQTT等动静协定。当REST API是事情消费者时，解决办法可能会更繁杂，需求找到机制来设置对现有REST API或事情代理的主题定阅，并教他们如何基于事情定阅。这通常能够经过由webhook、pub/sub-services和办事器发送事情组成的事情驱动层来完成。
总结一下：假如公司实行的业务软件运用顺序和零碎仅提供REST API，您依然能够环抱它们构建基于事情的架构。虽然这样做会让零碎显得繁杂，但有时需求利用所有能够利用的办法，特别是解决计划其实不那末不言而喻的时分，显然减少现有API是一种牢靠的解决办法。附注：只管流和事情驱动的API遭到如斯多的关注，但REST API不会很快隐没。由于，经过流/事情驱动的API和事情代理减少异步通讯的案例没有REST API的案例数量那末多。从这个角度而言，将会泛起更多融会了REST和流/事情驱动API的混合架构。
运用顺序集成中的事情驱动办法
基于事情的架构不只能够经过运用和办事提供杰出的客户体验。它运用集成方面也十分表示杰出——除了能够实时数据同步，还能够节俭少量资源。德国一家最大的私营啤酒厂但愿建设弱小的360度客户视图并简化其跨渠道的营销任务，旨在完成共性化动静传递并终究获取杰出的客户办事和满意度。在该名目的第一阶段，他们的专一于运用节点的链接，他们将Salesforce CRM以及Exponea的客户数据和体验平台之间的数据进行互联互通。
为了确保各种记载零碎之间的无缝衔接，该公司使用webhook和AMQP来触发集成流，只有运用和零碎反对webhook或事情总线推送数据的才能就能顺利达成。而且在Pub/Sub的帮忙下，将每个集成流程放弃在尽量小的规模内，从而完成了模块化的流程架构。另外，不只在两个零碎之间同步数据，还要将同步数据的零碎数量晋升到3-5个， Pub/Sub允许将这些流分红小块并在它们之间静态传布更新。
本文其实不打算一步步地形容如何构建基于事情的架构，由于有太多的用例需求斟酌，也有太多的反对技术需求提及，无奈将其打包成一篇文章。同时也会有太多的变量需求斟酌：例如IT 根底设施、技术堆栈的集体偏好以及可用资源等。但愿经过本篇文章环抱“如安在现有的API环境之上创立基于事情驱动的架构”这个问题的讨论，给各位敌人带来一些无意的思考。
原文链接：http://dzone.com/articles/creating-event-based-architecture-on-top-of-existi?fromrel=true
译者引见
崔皓，51CTO社区编纂，资深架构师，具有18年的软件开发和架构教训，10年散布式架构教训。曾任惠普技术专家。乐于分享，撰写了得多抢手技术文章，浏览量超过60万。《散布式架构原理与理论》作者。
来源：51CTO技术栈 |
|
注册会员