为什么微服务应该是事件驱动？(微服务)

作者:xinwang_m@163.com
发布时间: 2020-07-21 04:51:59 (3年前)
关键词: 微服务驱动
摘要:

                              
                                     建立微服务的真正道路是事件驱动，这是一个有着DDD, CQRS, Event-sourcing, event streaming, complex-event processing(CEP) 等背景以及丰富JavaEE技术经验的架构师的认识，他经历了从传统整体型monolith到微服务架构之转变，细节技术涉及从容器技术 (Docker, Kubernetes) 到JVM层 (Spring Boot 和 WildFly Swarm)到应用架构(事件, 命令, 流streaming, 原始事件, 聚合, 聚合根, 事务, CQRS, 等等)，他会在六月的Red Hat Summit演讲上详细陈述

建立微服务的真正道路是事件驱动，这是一个有着DDD, CQRS, Event-sourcing, event streaming, complex-event processing(CEP) 等背景以及丰富JavaEE技术经验的架构师的认识，他经历了从传统整体型monolith到微服务架构之转变，细节技术涉及从容器技术 (Docker, Kubernetes) 到JVM层 (Spring Boot 和 WildFly Swarm)到应用架构(事件, 命令, 流streaming, 原始事件, 聚合, 聚合根, 事务, CQRS, 等等)，他会在六月的Red Hat Summit演讲上详细陈述。这里他从自主性与权威性的比较角度来谈论微服务为什么应该是事件驱动，原文见：Why Microservices Should Be Event Driven: Autonomy首先，我们使用微服务是为了构建一个业务敏捷的IT系统，也就是能跟随业务快速变化的IT系统，这样才能保证我们的业务能力始终保持竞争力。而自治系统是能够相互交互提供业务敏捷，包括如果系统发生问题怎么办？系统如何克服问题？提供业务敏捷和失败容错的系统就是自治autonomy。自治系统能够独立于彼此演进，因为他们本质上是彼此没有依赖的，改变一个服务A不会强迫系统B改变，包括引起任何其他涟漪影响，如果服务A是服务B依赖的，服务A死了，那么服务B也会死期不远。那么自治性除了微服务以外，其他方面还需要什么？如果你阅读过http://blog.christianposta.com/microservices/the-real-success-story-of-microservices-architectures/，你会知道不是技术让Netflix和亚马逊的微服务获得成功，而是组织系统结构。与敏捷系统的相同类型的一些例子包括：开源社区、城市、股票市场、蚂蚁群、成群的鸟类和其他的。它们可以进化，响应react环境，甚至持续在面对巨大的失败，事实上，它们都是属于复杂自适应系统的理论研究领域。这些系统之间的共同点是什么？目标，自治性和对环境的反应。自治意味着 对“事件”的“反应react” 。当有什么事情发生时，自治者（蚂蚁 人或服务）会做某些事或不做某些事，但是总体来说，是这些发生事情的事件驱动了它们的行为，想想你（作为一个独立自主与自治的人）在一天中做的事情：你醒过来，基于温度穿衣服（事件或事实），你开车和去工作（在停车灯停下来（事件），避免驾驶人发生不正常事件等）。这些都是对事件的回应。你会收到收件箱里的电子邮件，你会回应。你会从你妻子提供的文本中挑选一篇关于家庭的晚餐，等等，我们生活在对事件的反应中。建立在事件的IT系统也可以是同样拥有自主性，可扩展性和弹性应对失败。从权限到自治自主并拥抱最终一致性在大多数分布式系统实现中，我们倾向于在一个单一地理空间建立跨不可靠网络的系统，这在很多方面都是坏主意，我们倾向于调用远程对象，驱动它们做某些事情，或者我们调用一个远程服务进行数据查找，如果是购物车服务，我们需要计算购物车中所有商品的最终价格以便支付，这样购物车服务会调用计价服务，计价服务也许会调用计税服务以基于价格根据不同洲税调整最终价格，计税服务也许会调用产品目录服务，货运服务也许会调用库存服务等等，最后也许需要经过一长段调用才会结束，我们正在遵循“authority权限”模式进行数据访问，我们调用那些对数据拥有权限的服务，这有点像共享全局状态，它们也有另外一个理由，因为事务性或ACID需要这样整合在一起调用。这可能会导致瓶颈。如果服务链中的某些服务不可用，它也会导致其他服务挂起以及级联崩溃性故障。它也可能导致一些奇怪的依赖关系，比如库存服务暴露给税务服务的出数据和航运服务使用的数据会不同。或者它公开了一个单一格式的数据，但其中有很多额外的细节是这两个服务都不真正关心的。如果我们以不同方式来看这个模型？如果我们颠倒这个模型，我们不再依赖和调用那些对数据拥有权限的服务，而是依赖时间和事件（如同我们现实世界一样）重新理解上下文场景和环境。我们刚刚从周围环境发现从美国到古巴的航运刚刚推出了一个较低的税收，这是一个发生的事实，我们可以观察和反应，或者忽视不做任何事。如果我们能了解到对运送到古巴的税收现在已经降低了，那么在我们展示购物车页面时，我们就可以捕捉这样的数据以便未来可能的查询，然后我们可以有更多的自主权，我们可以在我们自己的数据库中存储该信息息或该信息的衍生物，这将为我们提供的服务类型进行优化。如果我们必须对我们的服务进行版本的修改，我们就可以把重点放在我们自己的架构和数据上，而不必担心更改时其他相关服务会发生什么。什么是最终一致性？响应事件而不是“及时”查询权限系统会让我们更具有自主性，更有容错能力和弹性，但也有一点其他影响，会影响自治事件驱动系统的是“延迟”。如果你立即注意到某一事件，你可以立即做出反应。例如，如果一辆车转弯进入你的车道，你看到这个，你可以很快刹车或者调整驾驶避免不发生碰撞。但是，如果有一些延迟，在观察到这个事件后，你的反应可能是缓慢的（也许有驾驶障碍？或者你在玩手机？或是在你的孩子们做某事，等等）。这也可能发生在IT系统。比如在亚马逊订购商品。这会对其他自主服务（如订单处理，帐单，库存等）发布一个事件或事实。这些系统可以观察到这一事件，但如果此时库存系统从网络断开几分钟/小时？当他们重新恢复正常运行后，他们最终会看到这个事件并继续检查库存，发布任何它认为必要的事件（即反应）像“inventoryreserved事件”或“inadequateinventory”事件。这是一组自主系统“最终”变得一致的一个简单例子。最后一件事是关于事件，延迟和自主权。如果我们能够捕捉到它们并观察它们的顺序，事件就是有用的。也就是说，在我们的系统中必须保留一组事件的总排序，这样我们才能如何对它们做出反应有信心。现在你已经明白：事件的顺序在分布式系统中构建事务是如何的重要，如果事件变得无序，那么我们就无从获得最终一致性，除非再次需要人工介入。,建立微服务的真正道路是事件驱动，这是一个有着DDD, CQRS, Event-sourcing, event streaming, complex-event processing(CEP) 等背景以及丰富JavaEE技术经验的架构师的认识，他经历了从传统整体型monolith到微服务架构之转变，细节技术涉及从容器技术 (Docker, Kubernetes) 到JVM层 (Spring Boot 和 WildFly Swarm)到应用架构(事件, 命令, 流streaming, 原始事件, 聚合, 聚合根, 事务, CQRS, 等等)，他会在六月的Red Hat Summit演讲上详细陈述。这里他从自主性与权威性的比较角度来谈论微服务为什么应该是事件驱动，原文见：Why Microservices Should Be Event Driven: Autonomy首先，我们使用微服务是为了构建一个业务敏捷的IT系统，也就是能跟随业务快速变化的IT系统，这样才能保证我们的业务能力始终保持竞争力。而自治系统是能够相互交互提供业务敏捷，包括如果系统发生问题怎么办？系统如何克服问题？提供业务敏捷和失败容错的系统就是自治autonomy。自治系统能够独立于彼此演进，因为他们本质上是彼此没有依赖的，改变一个服务A不会强迫系统B改变，包括引起任何其他涟漪影响，如果服务A是服务B依赖的，服务A死了，那么服务B也会死期不远。那么自治性除了微服务以外，其他方面还需要什么？如果你阅读过http://blog.christianposta.com/microservices/the-real-success-story-of-microservices-architectures/，你会知道不是技术让Netflix和亚马逊的微服务获得成功，而是组织系统结构。与敏捷系统的相同类型的一些例子包括：开源社区、城市、股票市场、蚂蚁群、成群的鸟类和其他的。它们可以进化，响应react环境，甚至持续在面对巨大的失败，事实上，它们都是属于复杂自适应系统的理论研究领域。这些系统之间的共同点是什么？目标，自治性和对环境的反应。自治意味着 对“事件”的“反应react” 。当有什么事情发生时，自治者（蚂蚁 人或服务）会做某些事或不做某些事，但是总体来说，是这些发生事情的事件驱动了它们的行为，想想你（作为一个独立自主与自治的人）在一天中做的事情：你醒过来，基于温度穿衣服（事件或事实），你开车和去工作（在停车灯停下来（事件），避免驾驶人发生不正常事件等）。这些都是对事件的回应。你会收到收件箱里的电子邮件，你会回应。你会从你妻子提供的文本中挑选一篇关于家庭的晚餐，等等，我们生活在对事件的反应中。建立在事件的IT系统也可以是同样拥有自主性，可扩展性和弹性应对失败。从权限到自治自主并拥抱最终一致性在大多数分布式系统实现中，我们倾向于在一个单一地理空间建立跨不可靠网络的系统，这在很多方面都是坏主意，我们倾向于调用远程对象，驱动它们做某些事情，或者我们调用一个远程服务进行数据查找，如果是购物车服务，我们需要计算购物车中所有商品的最终价格以便支付，这样购物车服务会调用计价服务，计价服务也许会调用计税服务以基于价格根据不同洲税调整最终价格，计税服务也许会调用产品目录服务，货运服务也许会调用库存服务等等，最后也许需要经过一长段调用才会结束，我们正在遵循“authority权限”模式进行数据访问，我们调用那些对数据拥有权限的服务，这有点像共享全局状态，它们也有另外一个理由，因为事务性或ACID需要这样整合在一起调用。这可能会导致瓶颈。如果服务链中的某些服务不可用，它也会导致其他服务挂起以及级联崩溃性故障。它也可能导致一些奇怪的依赖关系，比如库存服务暴露给税务服务的出数据和航运服务使用的数据会不同。或者它公开了一个单一格式的数据，但其中有很多额外的细节是这两个服务都不真正关心的。如果我们以不同方式来看这个模型？如果我们颠倒这个模型，我们不再依赖和调用那些对数据拥有权限的服务，而是依赖时间和事件（如同我们现实世界一样）重新理解上下文场景和环境。我们刚刚从周围环境发现从美国到古巴的航运刚刚推出了一个较低的税收，这是一个发生的事实，我们可以观察和反应，或者忽视不做任何事。如果我们能了解到对运送到古巴的税收现在已经降低了，那么在我们展示购物车页面时，我们就可以捕捉这样的数据以便未来可能的查询，然后我们可以有更多的自主权，我们可以在我们自己的数据库中存储该信息息或该信息的衍生物，这将为我们提供的服务类型进行优化。如果我们必须对我们的服务进行版本的修改，我们就可以把重点放在我们自己的架构和数据上，而不必担心更改时其他相关服务会发生什么。什么是最终一致性？响应事件而不是“及时”查询权限系统会让我们更具有自主性，更有容错能力和弹性，但也有一点其他影响，会影响自治事件驱动系统的是“延迟”。如果你立即注意到某一事件，你可以立即做出反应。例如，如果一辆车转弯进入你的车道，你看到这个，你可以很快刹车或者调整驾驶避免不发生碰撞。但是，如果有一些延迟，在观察到这个事件后，你的反应可能是缓慢的（也许有驾驶障碍？或者你在玩手机？或是在你的孩子们做某事，等等）。这也可能发生在IT系统。比如在亚马逊订购商品。这会对其他自主服务（如订单处理，帐单，库存等）发布一个事件或事实。这些系统可以观察到这一事件，但如果此时库存系统从网络断开几分钟/小时？当他们重新恢复正常运行后，他们最终会看到这个事件并继续检查库存，发布任何它认为必要的事件（即反应）像“inventoryreserved事件”或“inadequateinventory”事件。这是一组自主系统“最终”变得一致的一个简单例子。最后一件事是关于事件，延迟和自主权。如果我们能够捕捉到它们并观察它们的顺序，事件就是有用的。也就是说，在我们的系统中必须保留一组事件的总排序，这样我们才能如何对它们做出反应有信心。现在你已经明白：事件的顺序在分布式系统中构建事务是如何的重要，如果事件变得无序，那么我们就无从获得最终一致性，除非再次需要人工介入。

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论