独立自治 微服务_为什么微服务应该由事件驱动：自治与权威

独立自治 微服务

我一直在撰写一系列文章，展示如何使用事件驱动的方法（IMHO是构建微服务的唯一真正方法：）或任何复杂的分布式体系结构来构建微服务。 我将探讨DDD ， CQRS ， 事件源 ， 事件流 ， 复杂事件处理等。 我正在使用一个基于Java EE的参考整体应用程序，该应用程序使用所有典型的Java EE技术，并深入研究它的特点，缺点以及如何将其发展为微服务体系结构。

我将展示从容器（Docker，Kubernetes）到JVM层（Spring Boot和WildFly Swarm）到应用程序体系结构（事件，命令，流，原始事件，聚合，聚合根，事务，CQRS，等等）。 希望它将为我六月在旧金山举行的Red Hat Summit演讲做好准备！ 在Twitter @christianposta上关注我，了解该项目的更新。

大事记

我想快速描绘一下有关分布式系统的图片（也许是草率的图片，但是尽管如此）。 当我们谈论微服务时，我们谈论的是将微服务用作构建业务敏捷 IT系统的工具：使企业能够更快地进行更改，构建新功能，进行试验并在其颠覆者和竞争者（初创企业等）方面领先的系统。

作为相互协作以提供业务敏捷性的自治系统的一部分，我们还需要考虑当这些系统的某些部分发生故障时会发生什么，以及系统如何克服故障。 自治是构建敏捷，容错系统的核心先决条件。 自治系统可以彼此独立地发展，因为它们倾向于摆脱对其他系统，团队和流程的依赖。 对服务A的更改不应强迫系统B进行更改，也不应强迫其他任何连锁React。 如果服务 B所依赖的 服务A发生故障，则服务B不应只是崩溃。

在微服务之外的其他系统中，哪里有这种自治的示例？ 好吧，如果您遵循微服务成功的真正原因，那么您就会知道，使全世界的Netflixes和Amazon在微服务方面取得成功的并不是技术本身，而是组织系统结构。

这些相同类型的敏捷系统的一些示例包括开放源代码社区，城市，股票市场，蚂蚁殖民地，成群的鸟类以及无数其他物种。 它们可以在发生巨大故障时不断发展，做出React，甚至继续前进。）实际上，它们是复杂自适应系统理论领域中经过深入研究的一堆。 这些系统之间潜在的共同主题？ 目的，自主权及其对环境的React 。 这些自主主体对“事件”做出“React”

当某些事情发生时，自治代理（蚂蚁，人，服务）可以“做某事”或“什么都不做”，但正是这些事件驱动了复杂的自适应系统中的行为。 考虑一下您（作为一个自主的人）如何全天做事。 醒来，根据温度打扮（一个事件或事实），上车开车去上班（在停车灯处停车（事件），避免人们不规律地驾驶（事件）等）。

这些都是对事件的响应。 您在收件箱中收到电子邮件，然后回复。 您会从妻子那里收到短信，以在回家等途中享用晚餐。我们一生都在响应事件。 可以使基于事件的IT系统具有同等的自治性，可伸缩性和对故障的适应性。

从权威走向自主，拥抱最终的一致性

在我所看到的大多数分布式系统实现中，我们倾向于将在单个地址空间内构建系统的概念扩展为跨不可靠的网络构建。 由于许多原因，这是一个坏主意，但很多时候它似乎是更简单的方法。 我们倾向于调用远程对象来促使它们做某事。 或者我们称远程服务为“查找”数据。 也许“税收”服务是与税收计算有关的规范位置。 如果我们是购物车服务，我们需要在结帐期间计算购物车中商品的最终价格。 因此，购物车服务称为定价服务。

定价服务还可以调用税收服务，以根据运送位置（国家，州，城市等）对价格进行其他一些调整。 税收服务可能会调用目录服务（税收可能因产品而异）。 运输服务也可能会调用库存服务，等等。我们可能会遇到这些冗长的调用字符串（在所有这些对象都位于同一地址空间等的整体式应用程序中可能没问题）。 我们遵循的是访问数据的“权限”模式：我们称对数据具有权限的服务。 在我看来，这有点像共享的全局状态以及大量的互斥量和同步点。 它对一系列要求授权的“交易性”或“酸性”也具有令人讨厌的含义。

这可能会导致瓶颈。 如果链中的某些服务不可用，也可能导致服务挂起和级联失败。 这也可能导致奇怪的依赖关系，在这种情况下，库存服务之类的东西现在必须以某种方式公开数据以供税务服务使用，而某些东西则需要运输服务才能使用。 或者，它以一种单一格式公开数据，其中包含许多服务都不在乎的额外细节。

如果我们以不同的方式看待这个模型怎么办？ 如果我们反转模型怎么办。 在某些服务甚至没有被调用之前，我们依赖时间和事件（就像我们在现实世界中所做的那样）来了解和了解我们环境的上下文，而不是在某些事务上依赖和调用服务来获得他们的权限。 如果我们能够聆听我们的环境并发现从美国到古巴的运输刚刚征收了曾经较低的税款，该怎么办。 这是我们可以观察并作出React的事实。 否则我们可以忽略它而什么也不做。

如果我们可以知道现在运往古巴的税费降低了并捕获了该数据，以便我们在显示购物车页面时可以在以后查询有关运往古巴的情况时知道该怎么办？ 然后，我们可能会对我们的数据和服务有更多的权限。 我们可以将该信息或该信息的派生存储在我们自己的数据库中，该数据库将针对我们提供的服务类型进行优化。 如果我们必须更改服务的版本，我们可以只关注版本化我们自己的模式和数据的含义，而不必担心其他从属服务发生更改时会发生什么。

最终的一致性如何？

响应事件而不是“及时”查询权限，使我们的服务更具自治性，容错性和弹性。 但是，实际上会影响自主复杂的自适应系统并且也会影响自主事件驱动的系统的一件事是“延迟”

如果您立即收到事件通知，则可以立即做出React。 例如，如果有一辆汽车驶入您的车道，但您看到了这一点，则可以快速突破或调整驾驶以免发生碰撞。 但是，如果在观察此事件时有某种延迟，那么您的React可能会很慢（可能是驾驶不便??或在手机上玩游戏？还是为了做某事而对孩子大喊大叫等等）……好吧，请不要寄给我有关如何成为父母的邮件:)）。 这也可能在IT​​系统中发生。 假设我在亚马逊上订购了东西。

这会将事件或事实发布到其他自治服务（例如订单处理，开票，库存等）。 这些系统可以观察到此事件，但是如果库存系统从网络断开几分钟/几小时/什么时间，怎么办？ 当他们回来时，他们最终将看到该事件并继续检查库存等，并发布它认为必要的任何事件（即做出React），例如“ InventoryReserved”事件或“ InadequateInventory”事件。 这是一组自治系统“最终”变得一致的简单示例。

这里有什么技术在起作用？

关于事件，延迟和自治的最后一句话。 事件只有在我们可以捕获它们并按它们发生的顺序对其进行观察时才有用。 也就是说，必须保留一组事件的总排序，以使我们的系统对如何应对这些事件有信心。 如果您开始斜视，您会发现“排序”在我们如何构建跨系统的“事务性”的过程中也起着作用（稍后会详细介绍）。

如果我们开始看到事件混乱，那么如果没有某种手动干预，我们将永远无法声称达到最终的一致性。 马丁·克莱普曼（Martin Kleppmann）将此称为“永久不一致” 。 在下一篇文章中，我将介绍我在Summit演示/演示中使用的一些技术，这些技术有助于延误，订购和微服务。 敬请关注@christianposta！

翻译自: https://www.javacodegeeks.com/2016/05/microservices-event-driven-autonomy-vs-authority.html

独立自治 微服务