使用事件流扩展微服务_编程语言分享讨论总汇吧吧_直线网

编程语言分享讨论总汇吧
已关注 | 取消 +关注
关注：10
帖子：1,222

签到

05月05日
尚未签到

看帖图片精品视频

共有回帖数 0 个

使用事件流扩展微服务
取消只看楼主收藏回复

幸福没有捷径
等级：
这是一篇来自thoughtworks微服务实战经验总结，总结了传统的点对点集成模型的问题，也就是业务流程orchestration风格的问题，展示了基于事件流的choreography风格在微服务架构中高聚合与松耦合的好处。

来自传统的orchestration业务流程
2014年参与的一个微服务项目因为代码改变使得项目变得很难维护或拓展，根本原因是在服务之间形成了异步的点对点调用模型，一个服务A调用另外一个服务B，服务A就依赖服务B，完成一个业务功能需要十多个微服务依赖，如下图，下面一个节点代码一个服务，每条线代表从一个服务到另外一个服务的直接HTTP调用。

这种方式在实现包括几个业务服务的业务事务时会引入了大量复杂性，因为业务事务跨几个服务，处理失败变得非常小心，这个服务失败会对整个业务流程事务有影响吗？如果有，那么事务就得退出，返回一个有意义的错误给调用者，另外一方面，当系统从失败中恢复时，我们需要让这个业务事务继续成功处理完成。

测试策略因为需要依赖服务变得很有戏剧性。对于更复杂的服务，需要依赖基于浏览器的客户端测试来验证集成效果，因为高度的服务耦合阻止了我们单独发布这些微服务，最终只能以传统的整体monolithic发布，所有的服务都同时部署，同时部署客户端应用程序。

使用事件流的服务Choreography
这种点对点的集成能够通过解耦服务避免，并限制业务事务的边际，choreography编舞风格能够限制业务事务的边界，上游服务发送事件，而下游服务订阅这些事件，这就提供足够的隔离，如下图通过这种事件流方式实现微服务集成：

Email服务订阅了客户创建的事件。这种choreography模型实际是一种发布/订阅publish/subscriber模型。

在点对点模型中处理端点错误需要非常小心，因为使用消息模型实现，这样围绕一个组件的服务编排choreography需要对这些错误失败非常小心。

如果一个服务在短时间内当机，事件存储会在订阅者重新运行时重新发送丢失事件，如果一个服务当机很长时间，服务必须重新加载过去事件的历史记录，检查曾经错过丢失事件，如下：

为了能跟踪错误以便处理错误，一个通用模式是使用事件ID作为聚合ID，横跨这个事件经过的所有流程，这样当事件被发布，它由上游服务使用唯一ID作为日志记录，比如，客户服务会记录customer_created，其event_id是2987，那么在下游服务将使用指向原始事件的方式记录自己事件日志，比如loyalty服务会使用transaction_id =2987.0987来记录add_status_point 这个事件。

如果下游服务记录它的事务和上游一个被触发的事件有关，通过聚合所有微服务的日志，就可以画出下游对于这个事件的一个所有下游事务流程，确保它们能成功执行。

在一个数据库为中心（ database-centric）应用中，专用视图（专门用于显示的数据表）用于实现不同展示目标而进行定制，而在事件驱动世界中，它只是创建一个特定服务用来订阅相关事件，以便汇聚和暴露汇总结果给消费者或调用者。

服务之间通过事件协调会更加具有可伸缩性，降低复杂性，提高处理和分析数据的能力。

原文：
Scaling Microservices with an Event Stream | Thoug

完整基于事件流的微服务源码：Github

参考：为什么微服务应该是事件驱动？

全新角度总结Twitter Facebook和LinkedIn业务模型与架构

楼主 2016-07-24 16:16 回复

共有回帖数 0 个

发表

登录直线网账号

本吧信息

查看详情

禾木

本吧公告
好好学习，天天向上！

我常逛的吧

我管理的吧