微服务与事件驱动架构开发手册带你驯服事件驱动的微服务！

对于开发人员来说，微服务是个既火爆又受追捧的话题，谁不想用上微服务架构呢。但是对于企业来说，微服务却并非银弹，在团队构建和交付软件的过程中，微服务是面临着很多挑战的，软件管理文化问题、系统一致性问题、分布式系统冗余问题等；

什么是事件驱动型微服务？

在每一个 Web 浏览器中，事件都是被用来捕获用户输入的一种处理方式。通过显式的映射函数处理连接到页面元素的事件，通常称之为动作或者命令，触发时会调用用户接口进行状态改变。除此之外，事件也在一些后端系统中被广泛使用，被用来使用领域驱动设计模式进行设计。随着微服务概念的广泛采用，关于如何在分布式后端系统中利用事件驱动技术又重新点燃了大家的兴趣。

在分布式系统中，计算打破了单一型应用程序的边界，在单一型架构中，我们可以通过使用多线程并发方式调用计算资源。但是当演进到微服务架构时，应用程序架构被切分为很多个分离的服务，通过互相之间通信以满足特定用例。事件提供了一种分布式计算方式，我们可以将事件作为消息在微服务架构内部传输。采用针对微服务的事件优先方式的一个主要原因是管理领域实体的连通性，这些实体之间通过外键关系横跨不同应用程序和数据库边界。一个微服务可能需要观察另一个微服务所产生的事件，这样做是为了维持不同应用程序所管理的不同实体之间的外键关系。

微服务倾向于使用 HTTP 协议进行通信，通过不同应用程序提供的 REST API 接口进行通信。每一个微服务的业务逻辑可以使用协议进行交互和触发动作。但是也存在异步的非阻塞通信协议，例如 AMQP。这种通信方式是基于消息的，是多个服务之间消息交换的首选方式。多个 Spring 项目支持这种工作流方式，现在这种通信方式最流行的项目是 Spring Cloud Stream，它允许客户在不用修改应用程序代码的情况下交换消息中间件。例如想要在 Apache Kafka 和 RabbitMQ 之间切换状态，可以在不修改核心代码的情况下交换后端数据。

今天推荐的这份微服务与事件驱动架构开发手册，就详细的讲解了微服务和事件驱动型微服务

目录

​

内容展示：

​

​

​

​

​

​

​

​

为什么使用事件驱动架构

事件驱动的体系结构与REST相比具有一些优势，其中包括：

• 异步 –基于事件的体系结构是异步的，没有阻塞。 这样一来，资源一旦完成其工作单元，便可以自由地移至下一个任务，而不必担心之前发生的事情或下一步将发生的事情。 它们还允许将事件排队或缓冲，以防止消费者向生产者施加压力或阻止它们。
• 松散耦合 –服务不需要（也不应该）对其他服务的了解或依赖。 使用事件时，服务独立运行，而无需了解其他服务，包括其实现细节和传输协议。 事件模型下的服务可以独立，更轻松地进行更新，测试和部署。
• 轻松扩展 –由于服务是在事件驱动的架构下解耦的，并且由于服务通常仅执行一项任务，因此跟踪瓶颈到特定服务，并且扩展该服务（仅该服务）变得容易。
• 灾后恢复支持 –具有队列的事件驱动架构可以通过“重放”过去的事件来恢复丢失的工作。 当消费者需要恢复时，这对于防止数据丢失很有用。

当然，事件驱动的体系结构也有缺点。 通过分离在紧密耦合时可能更简单的关注点，它们很容易过度设计。 可能需要大量的前期投资； 通常会导致基础架构，服务合同或架构，多语言构建系统和依赖关系图的复杂性增加。

也许最大的缺点和挑战是数据和事务管理。 由于事件驱动的模型具有异步特性，因此必须仔细处理服务之间的数据不一致，版本不兼容，监视重复事件，并且通常不支持ACID事务，而要支持可能难以跟踪或调试的最终一致性 。

即使有这些缺点，对于企业级微服务系统来说，事件驱动的体系结构通常还是更好的选择。 优点（可伸缩，松散耦合，对开发人员友好的设计）胜过缺点。

需要文中资料完整版学习的小伙伴可以点击下方的名片自取！