微服务边界

在这篇文章中,作者讨论了他最近学到的关于从不同的角度识别微服务边界的一个教训。

微服务架构是当今的热门话题。 尽管它的复杂性(分布式事务,最终的一致性,操作开销),这些都是不可避免的,但是它提供了许多好处(多边形架构,选择性可扩展性,强模块化,容错,实验,敏捷等)。

微服务可能不是新东西。 我仍然记得,回到2011,我研究了一个SaaS产品,其中我们试图构建包含不同有界上下文的类似架构,包括敏捷项目管理,问题跟踪和协作。当时我们不熟悉这种奇特的微服务术语,但我们试图实现的好处有助于微服务架构的实现。

最初,在各种模块中分发应用程序的设计工作得很好,但我们在集成期间搞砸了。并不是通过采用事件驱动架构在不同模块之间共享信息,而是直接同步调用。这使我们远离了独立部署,开发和运行时的原始动机。

本文讨论的是从我最近的一个项目中学到的另一个教训,帮助您从不同的角度识别微服务边界。

背景
下一代边境(NGB)系统是护照控制系统的改进版本。NGB的主要目标是加快机场移民柜台接待处理乘客的过程。 通过将处理时间从平均56秒减少到10秒来改善乘客体验。下面是一个上下文映射流程。

航空公司旅客销售服务系统(PSS) --> 高级旅客信息系统 --->自动入境预检上下文 --->旅客边境控制上下文 --->通知上下文

NGB系统的核心是入境预检处理(preclearance process)。入境预检过程通常在乘客登机前72小时开始。 航空公司将预订信息发送到入境预检旅客信息系统,该信息系统将信息转发给NGB系统进行入境检查。 在入检期间,NGB在移民系统的帮助下对旅客的资料执行各种检查,并将结果发送到后台进行审查,以便在乘客因任何问题(即黑名单)被认定有罪时进行审查。 发现无罪的乘客标记为绿色,在入境柜台处理此类乘客需要几秒钟。


什么是好?
由于大多数文献指出在根据语言边界作为有界上下文来定义微服务边界,NGB被划分为自动入境预检,乘客边境控制和通知有界上下文。 自动入境预检上下文在后台处理预留数据流,并将其传递到用于持久性和人工干预的乘客边境控制上下文。 该上下文具有两个主要类别的用户:前台用户,其是面向乘客的用户,以及后台用户,其在没有任何问题的情况下处理乘客。通知上下文,如其名称所暗示的,用于向系统用户发送通知。

什么地方出了错?
虽然通用语言在旅客边境控制上下文中是显而易见的,但是这仍然不够。 随着时间的推移,旅客边境管制的情况不仅开始变成铁板一块monolithic,而且进入生产运作变更时开始出现麻烦。 我们对后台运营所做的任何更改都必须仔细进行,以避免对前台运营造成任何影响。此外,任何影响后勤办公操作的更改都不能在不影响前线操作前提下单独部署,反之亦然。

我们能做点什么?
在讨论我们可以做点什么之前,让我们快速看一下NGB系统的业务流程视图,如下所示:

后台处理:自动入境预检 ---> 后台办公处理:乘客名单审查 ---->前台处理:旅客边境控制

箭头表示业务流程发生在不同的时间线。 例如,入境预检信息通常在航班起飞前72小时收到,后台办公室用户在出发前几个小时审查乘客,而乘客到达柜台时将进行乘客护照控制。

如果您注意到前面的上下文映射,后台处理:自动入境预检过程已经被划出一个单独的有界上下文中,而后台进程和前台过程被捕获在单一的旅客边境控制上下文中。他们被放入同一有界上下文的原因是因为语言边界。

现在让我们做点不同的,将旅客边境控制上下文进一步分为三个不同的上下文,后台办公室和前台边境控制上下文将保持乘客领域模型作为上下文共享内核的最小结构,而完整的旅客领域模型将在旅客出行上下文中作为event-sourced。 三个上下文将在各种时间点发送事件,例如自动入境的开始,后台的审查,前台的乘客旅行记录等等,这些事件发送到旅客出行上下文。这样旅客出行上下文将像一个无头的微服务。 此外,这也将分离的读取和写入的责任( CQRS NGB系统内)。

在这种分配方式中,旅客边境控制上下文不仅会降低因后台和前台的变更影响,而且还将有助于独立地发生自己的变更。 这种方法的唯一权衡是我们必须在多个上下文中保留旅客领域模型的多个副本。 为实现凝聚这是不可避免的。

最后的想法
从有界上下文视点确定微服务边界可能是一个好的开始。仅依赖有界上下文视点可能不总是足够的。 其他观点对于确定微服务边界也是至关重要的。像选择扩展性,可更改性,可部署性,可测性,业务流程和组织结构的通信(康威定律 )也影响微服务边界。

A Retrospective on Microservice Boundaries - DZone