实时消息驱动的面向服务的体系结构：蓬勃发展！-CSDN博客

在伦敦的Strata + Hadoop World上，MapR企业战略与架构总监Jim Scott谈到了实时Hadoop：理想的消息系统。您可以在这里观看他的演讲或阅读下面的文章以了解更多信息：

在这篇文章中，您将看到有关消息驱动的体系结构的信息。简而言之，这是面向服务的体系结构（SOA）的子集。这已经存在了很多年，并且是非常受欢迎的模型。在这篇文章中，您会发现，基本的消息驱动架构比企业服务总线（ESB）的概念更具竞争力。 ESB非常沉重和僵化，而一般的SOA实现不需要ESB。

当我们开始进入实时Hadoop时，我们在谈论什么？好吧，生活是成批的，或者至少那是您可能会听到人们谈论大数据周围一切的方式。归根结底，生活不是一成不变的。生活是指不断发生的流事件，并且必须一次处理一件事。

我们必须能够前进，继续前进，并处理发生的事情。长期以来，每个人都对批处理感到非常满意。随着人们对这些技术越来越满意，他们开始意识到自己可以做的越来越多。流技术的规模如此之大，这不足为奇。能够从批处理转换为实时并不十分复杂，这取决于您的用例。

实时

我提出的一些目标是实时的或接近实时的。需要澄清的是，了解我们真正要处理的一般语义很重要，因为实时并不总是处理刚刚发生在物理上的事件。可能是“我准备对数据进行处理，现在我需要立即进行处理。” 该事件可能是在两天前发生的，但是现在您可以执行实时处理了。无论您设置什么服务级别，这都是您要使用的服务。

微服务

当我们开始研究微服务之类的东西时，自然就会想到，微服务如何与流技术结合在一起？如果要扩展应用程序，这是自然的设计模式，如何将应用程序与通信分离？微服务确实是人们正在寻找的一种新模型，我将把它分解成更小的部分，这使人们能够以更简单，更小的块部署软件。但是，为了做到这一点并扩展这些服务，您必须使通信脱钩。

运动部件少。 消息传递和实时启用有哪些优点？我们的运动部件更少。当您开始考虑用于进程间通信的所有技术，能够扩展系统，拥有持久性存储时，当您开始将它们与消息传递平台分离时，在大多数情况下，它实际上简化了体系结构。消息驱动的体系结构和面向服务的体系结构并不是全新的。他们已经存在了很长时间，并将继续蓬勃发展。

更好地利用资源。 当我们开始研究资源利用时，这里有一个很大的好处，而且当我们跨不同的环境看时，我们就有能力创建新型的隔离模型。在开发环境中运行代码时，开发环境的外观是否与生产环境相同？可能不会。如果您在开发中有两台服务器，在生产中有两台服务器，那就太好了。那不是大多数用例。我曾经在广告技术部门工作，在那里我建立了一个每天处理600亿笔交易的平台，我们有10台服务器在开发中，有600台在生产中。

通用部署模型。 能够弄清楚如何使用您的生产环境并使用真实的实时数据进行测试是很多人都在努力的问题。当您将消息传递平台与组件分离时，就可以吸收来自生产环境的所有信息以进行开发和测试。

改进的集成测试。 当您进行集成测试之类的事情时，您可以简化它，这很重要。为了在当前环境中拥有此功能，很多人会花很多钱。问题是，大多数环境都不是为支持此类功能而构建的。将完整的数据库副本从生产环境复制到开发环境通常并不划算，或者不够及时才能产生影响。

共享文件系统。 对于您的应用程序状态，拥有一个共享的文件系统是非常重要的。消息传递是实时的一部分，但是能够提供有状态服务，在微服务世界中，您希望能够被拆除或丢弃是一件好事。

如何结合服务和打破微妙

微服务与有限的上下文松散耦合。让我们看一下微服务的概念：

具有共享模式和共享模式的共享数据库。 现在，共享数据库最大的优点是什么？这是您必须参加会议讨论如何发展架构的时候，并且在会议开始后的五分钟之内就达成了协议，因为这没有发生。那是不现实的，那不是生活。通常，当您遍历这些共享模式时，需要花费数小时的时间，而且您无法达成协议，这很痛苦。

服务之间的临时通信。 当我们摆脱了服务之间的临时通信时，我们将它们完全解耦了，突然之间，我们现在有了一种处理扩展的方法，而不必担心破坏这种“微观性”。

脆弱的协议。 拥有无法发展的协议真的很糟糕。如果您尝试在服务之间使用Java序列化，则将其视为错误的协议。 Corba是脆弱协议的另一个示例。如果您有一个宁静的服务可以交换JSON格式的数据，那么这是一个可以演进的非常好的简单协议。

协议版本控制不佳。 然后，能够对协议进行版本控制是非常重要的事情。在您使用时能够及时识别出什么，而不必怀疑格式或期望是什么。

不要做这些事！

如何解耦服务

使用自我描述的数据。 自我描述的数据很重要。我提到了JSON。 Avro很好。二进制JSON也很好。当我们考虑随时间迁移时，您想添加字段。您不想更改数据类型。我认识一些采用JSON的人，他们已经将一个字符串字段换成一个数组。你为什么要去做呢？你不想成为那个家伙。

专用数据库。 现在，归根结底，私有数据库实际上是一件好事。我们今天可能都使用相同的模式，但是如果我将其放在自己的数据库中，并且您明天需要发展自己的数据库，并且它们之间存在分歧，谁在乎？我的用例是我的用例：我有我的数据库，您不需要进入数据库。

由于规模较大，请在必要时使用共享存储。 当我们开始研究所有这些协议，并开始研究诸如共享存储之类的东西时，我们必须意识到能够将数据存储在某个地方，而您不必担心诸如容器之类的东西。爆炸，永远无法取回数据。

解耦架构

理想情况下，在类似解耦的体系结构中，您将拥有这样的图表。这是一种非常准确的表示形式，用于说明人们最终如何使用分离的体系结构构建系统。

在顶部，您可以构建一个流程来进行所有活动并将其存储在历史档案中。在底部，您最终会创建某种类型的结果，并且可能会在其顶部构建仪表板。您可以插入这些内容，并且在扩展环境时，不必担心系统瓶颈。您不必担心消息传递平台两侧的资源容量用完。

消息队列是经典的答案。 当涉及到能够处理我们想要的规模时，传统的消息队列具有固有的缺陷。当您查看确认时，我们将看到传统消息队列所伴随的这种非常繁重的事务处理特性。

关键功能/缺陷是故障确认。 出现故障确认是可能发生的。传统上，如今，人们并不是真正要考虑的事情，但是每个人都希望考虑确保自己不会丢失消息。

您为持久性付出了巨大的性能损失。 不丢失消息意味着您需要持久性。在传统消息队列中需要持久性意味着您需要承担那些事务的沉重开销。

解耦机制

卡夫卡式日志。持久性是关键特性，因此，当我们观察Kafka风格的模型时，我们获得了这种能力，可以以连续的运动有效地产生连续的IO流，并能够提取所有内容。它提高了吞吐量，获得了所需的持久性，并且能够无序地进行确认，因此您真的无法做到这一点，因为您从头到尾都掌握了所有内容。我们获得了性能，可伸缩性就在那里，我们可以在具有像Kafka这样的平台的真正的消息驱动的面向服务的体系结构的情况下实际交付。

欺诈识别

给定类似信用卡速度的主题，如果在这里发生了信用卡交易，然后在斯德哥尔摩3秒钟后发生了信用卡交易，在纽约5秒钟后发生了信用卡交易，我们可以肯定的是欺诈活动还在继续。除非他们碰巧只是互联网供应商。也许是这样，但仍然可以在5秒钟内完成3笔交易，这确实很紧张。卡实际上不能在这些位置之间足够快地进行交易，因此这是我们识别卡欺诈的一种方式。

在传统的解决方案中，我们会看到类似这种事件的出现。欺诈检测器将完成一些工作，并将最后使用的卡插入数据库中。在此模型中，我们实际上没有很好的缩放模型。最后要发生的是，如果我们想要扩展该欺诈检测器，我们可能想要对其进行版本控制，也许我们想要具有不同类型的欺诈检测，那么我们将使用此共享数据库。在此模型中具有共享数据库很容易。这可能会导致系统崩溃。

为什么在这里打破？好吧，第一，它之所以会这样，是因为您正坐在会议上试图发展该模式，而您却无法达成共识，因为您需要放置一个新的欺诈检测器，而且这种检测器将会崩溃其他一切。或者，它会因为无法处理交易量而倒闭，因为您每天可能有数亿笔交易在每个欺诈检测器中运行，并且每个检测器都需要工作，而且它们都需要使用该共享数据库。

根据我在这些模型中使用关系数据库的经验，它们不一定是按比例构建的，或者它们还没有按比例扩展的准备，因此，将这些服务推出并进行扩展，可能并不是人们考虑的。我并不是说关系数据库无法扩展，但是可能没有为此考虑。

如何获得服务隔离

如果我们想实现服务隔离，那么做到这一点的一种好方法就是将这些信息分解到一个消息传递平台中。如果我们通过消息传递平台发送这些消息，则现在可以让更新程序通过并更新该私有数据库。

数据的新用途

现在，欺诈检测器拥有自己的私有数据库，更新通过，并且在我们决定扩展规模时，我们可以使用这些新的用例，并且它们都可以侦听卡的活动。现在数据库已经分离出来了，当我们继续前进时，无论如何我们都可以扩展它，而它们都没有共享数据库。

通过隔离扩展

共享数据库并不意味着我必须在某处拥有专用服务器。无论您的模型是什么，都可以使用。可能是NoSQL数据库，可能是平面文件，谁知道？无论您的数据库是什么，这对我来说都很好。我并不是要告诉您应该是哪种情况，但是在这种情况下，如果此数据库在检测所有这些信用卡交易欺诈历史的整个生命周期中最终增长到10份数据，谁在乎？您甚至无法外出购买10 GB的磁盘。您可以使用的最小磁盘大约只有600个演出。

经验教训

这里要考虑的一些事情是，当我们转向这种隔离模型时，它确实是我们真正想要的。您可以根据定义的业务需求来自主构建，部署和扩展这些服务。您不必在角落里等待，而希望在共享数据库之上或共享存储之上没有用例互相冲突的用例。交流变得更加容易。您可以传播这些事件，而不必担心表更新。

我们可以得到“极限”吗？

如果我们想在这种模式下发展，我想谈的一件事是，我们可以走到极端吗？当我谈论极端时，我通常谈论的是每天超过一万亿的事件。让我们评估一下我的其他一些要求。我希望能够有效地支持数百万个制作人，每秒数十亿个事件。从逻辑上讲，每条消息我可能都有多个使用者。那是您真正开始看到每天能够处理大量事件的地方的确可以Swift扩展，因为一旦您开始添加管道中的所有其他使用者，您现在就从根本上增加了要推送的事件总数管道。

我想确保在谈论极限时，我在谈论多个数据中心，因为多个数据中心是实现灾难恢复副本的最佳途径。我个人会选择不将其复制为“ DR”副本，而实际上使其成为具有完整功能的副本，这样，即使我必须进行故障转移，也不必担心数据在其他地方工作。

让我们尝试将其视为透视。现实是什么样的？我在这里列出了一些我认为合理的数字：

监控和应用日志

每台服务器100个指标
每分钟60个样本
每个请求50个指标
每个请求1,000个日志条目
每天一百万个请求

每天20亿个事件–一个小用例

累加起来，每天大约有20亿个事件。那是相当可观的。每天有数万亿事件吗？否，但是当您开始研究微服务模型时，便开始研究越来越多的分离式通信，这种通信很快就会散开。如果您说，我有一个处理X的服务，我做资源管理，现在我需要再增加10个，那么现在就生成的任何度量标准来说，您都变成了10倍。它可以快速扩展。

考虑消息传递平台

每秒50-100k条消息曾经是不错的。 六年前，当我曾经处理来自电话的蜂窝探测数据时，我们感到很高兴，我们正在处理这些探测点，并将其与地图进行地理匹配，以将其放置在应有的位置。当我们每秒收到50,000至100,000条消息时，我们感到非常高兴。

要构建适当的消息驱动的，面向服务的体系结构，您就不能真正有效地利用如此之低的数字进行有效扩展，因为扇出越多，您将需要添加到消息传递平台中的内容越多。能够处理秤。如果您将所有成本重新投入到消息传递平台的扩展中，则必须提出一个问题，即您是否把钱花在了正确的位置。

Kafka模型快速地闪耀。 现在，当我说Kafka模型时，空间中有一些产品，但是特别是对于MapR Streams，我们对其进行了基准测试：

Kafka 0.9 API，消息大小为200字节
5节点群集上的MapR流可持续1800万个事件/秒
每天3.5GB / s的吞吐量和超过1.5万亿个事件

我们在讨论哪些产品？

具体来说，属于该类别的产品-我个人没有其他产品可以做到这一点-MapR Streams和Apache Kafka。从根本上说，这里的区别是它们都支持相同的API，MapR Streams是在MapR之上的API实现。这是不同的实现。它遵循该模型，但是它是不同的实现，因此存在API。它实际上是一个零管理消息传递模型。

我们如何使用MapR做到这一点

MapR Streams是Kafka API的C ++重新实现

可预测性，性能，规模方面的优势
整个MapR融合数据平台的通用安全性和权限

语义扩展

集群包含卷，文件，表和现在的流
流包含主题
通过路径名访问流

保留核心MapR功能

一致的快照，镜像，多主复制

MapR Streams工作原理的基础是相同的，但是由于我们拥有底层平台，因此我们编写了自己的平台。该模型在那里，并且提供了所有这些功能，例如能够将数据从数据中心A镜像到B。只需单击一下，然后将副本发送到此处。安排它，每小时做一个镜像，只是字节已更改。它不是完整的文件副本。如果您有一个10 GB的文件，并且在HDFS中更改了一个字节，则必须重新复制整个10 GB。在MapR中，一个字节的更改将产生8k的传输，因为8k是我们移动的最小块大小。这是一个相当不错的比较。我要移动8k，还是要移动10 GB？我喜欢。能够执行快照的文件系统，表，流都可以使用快照，因此您可以同时获得所有快照的一致时间点视图。

和更多…

流也以B分支的形式实现

主题和消费者补偿保持在流中，而不是ZooKeeper
与MapR-DB表类似的拆分技术
一致的权限，安全性，数据复制

所有这些都是在B树的幕后实现的。所有数据都通过B树进行排序和组织。我们没有在Kafka中看到的ZooKeeper瓶颈。我们已经从管理MapR流中花费了很多精力。我们也将其从MapR-DB中删除。好处是，您将获得想要让生活变得更轻松的一切。功能和功能就在那里，您不必担心如何来回移动。

通用API的重要性

通用性和互操作性至关重要

比较Hadoop生态系统和NoSQL世界

表赌注

坚持不懈
性能
多态性

到目前为止，主要趋势是采用Kafka API

0.9 API及更高版本消除了重大的抽象泄漏
所有主要的Hadoop供应商都支持Kafka API

通用API非常重要。当开始分离事物时，您要确保可以交谈。微服务的脆弱性是一回事。您不希望有一个容易破解的协议。您不想拥有无法正确版本化的协议。

这里的课程是：

API比实现更重要。
在社区之前有大量的创新空间。 社区是关于进化的。它正在缓慢创建新功能并添加更多功能。能够采用这些API并以不同的方式重新实现它们的原因是引起革命的原因。能够使您的生活更轻松。这与少量的增量更改无关，而在于大范围的更改，即“我将重新执行此操作。我将使其变得如此，以便您的程序仍能正常工作，并使您的生活更轻松。”
POSIX，HDFS，HBase都定义了有用的API。 当您查看POSIX，NFS，HDFS和HBase时，会看到所有这些API。它们是相当广泛接受的API，甚至以HBase为例。甚至Google都采用了HBase API并开始在Google Bigtable上支持它。
Kafka 0.9+也是如此。