回顾微服务的边界选择

本文讲的是回顾微服务的边界选择【编者的话】本文讨论了如何定义微服务的边界,并采用机场旅客值机系统做了拆分微服务的例子,本文从模块上下文的角度对微服务进行边界定义,讨论了这种拆分方法的优劣,并引出了其他拆分依据的思考。

目前,微服务是一个热门的话题。尽管它很复杂,包括分布式事务、最终一致性、操作开销等,它依然是发展趋势,特别是它带来的优点,如跨语言架构、选择的伸缩性、强大的模块化、容错能力、实验性、敏捷性等。

微服务可能不是新鲜事物。我仍然记得,2011年我工作在一个SaaS产品,我们试图建立包含不同的上下文的架构,其中包含敏捷项目管理、问题跟踪器,和协作工具。当时我们不熟悉这个微服务概念,但我们试图实现的功能与微服务架构类似。最初,‘分发应用程序到不同模块’ 这个架构效果很好,但是我们在集成它的过程中搞砸了。我们采用直接同步调用的方式,而不是拥抱事件驱动架构的不同模块之间信息共享的机制。这使得我们距离最初的目标(独立部署、开发和运行)越来越远。

本文讨论的另一个教训来源于我最近的一个项目,它可以帮助你从不同的角度识别微服务的边界。开始讨论我们能做什么不同之前,对将要讨论的系统进行宏观了解是首要的。

背景

下一代值机系统(NGB)是一个护照管理系统的升级版本。NGB的主要目标是加快的乘客在机场的移民柜台的处理速度。该系统通过将处理时间平均从56秒减少到10秒,提高了乘客的体验。下面是该系统的处理流程图

在NGB系统中,有边界的组件用红线标示。其中一些边界组件已经被刻意去除,避免发散讨论。

NGB系统的核心是预清除过程。预清除过程通常在乘客登机前72小时开始。航空公司将预订信息发送给相关机构的乘客信息系统,将信息转发给NGB系统用于预清除。预清除期间,在移民系统的配合下,NGB检查乘客的概要文件,并将结果发送给后台校验,避免乘客因程序问题(例如黑名单)被误判有罪。乘客发现无罪是绿色标志,它需要在移民柜台花费几秒钟来处理这些乘客。

希望你现在已经对NGB系统有了一定了解,那么开始我们的回顾。

哪些变好了呢?

从按照大部分的书本上对微服务边界的定义来说,NGB被分成自动化清除、旅客出境管理和通知模块。自动化预清除部分在后台处理预订数据流并将数据传递给旅客处境控制模块,用于持久化和人工干预。这个场景包含两大类用户:当面处理手续的一线用户与需要后台操作处理手续的用户。通知模块,顾名思义,用于发送通知给系统管理员。

哪些变坏了呢?

尽管普遍用于乘客边境控制模块的语言是特定的和独特的,它仍然是不够的。随着时间的流逝,乘客边境控制模块不仅开始变得独立,也开始随着生产环境的变化而产生问题。我们在后台操作中做任何更改操作必须小心,避免任何影响前线操作。此外,任何只影响后台操作的变更,需要隔离在不影响前线部署操作的前提下进行,反之亦然。

我们可以做出哪些改变?

在进行讨论可以做出哪些改变之前,我们先快速回顾下NGB系统的商业处理流程,如下:

虚线箭头描述在不同时间线上发生的商业流程。例如,预订信息在航班出发之前72小时被提供,工作人员在航班出发前几个小时检查旅客信息,当旅客到达柜台时进行旅客护照检查。

如果你关注了上文提到的模块构成图,自动化预清除流程被拿到一个单独的模块,其中工作处理流程和前台处理被封装到单独地旅客出境控制模块。把它们放到同一个模块中的原因是符合边界定义。为了克服上一段中高亮部分提到的问题,我们可以分布边界模块如下:

再次,为了维持讨论话题的重点,上文流程图中某些有界的模块不在讨论范围内。乘客出境控制模块被进一步分割为三个不同的模块,用红色加粗的圆圈标示。

后台系统操作和前端出境控制模块将保持旅客处理模型的最小结构,共享模块的核心部分,其中完整的旅客领域模型将会在旅客出行模块中由事件构成。这三个模块都会在不同时间线发送事件到旅客出行模块,例如在自动预清除阶段、后台审核阶段、前端审核旅客出行阶段等。这种情况下,旅客旅游模块将会扮演一个无上线的微服务。并且,它将会隔离NGB系统内的读写操作。

在这种形式的分布式中,不仅降低了旅客出境控制系统中后端或者前端变更服务的影响,同时有助于独立变更。这个方法唯一的权衡之处在于我们必须维持多个旅客领域模型的镜像在不同的模块中。为了实现降低耦合,这将无法避免。

结论

从上下文边界的角度对微服务进行划分会是一个好的开始,但是仅靠上下文这一个角度来处理是不够的。其他角度确定微服务边界也至关重要,例如根据选择性扩展、可变性、可部署性、测试性、商业流程、组织结构等,也会影响微服务的边界选择。

原文链接:A Retrospective on Microservice Boundaries

===================================================
译者介绍

陈杰,BOSS直聘app的数据工程师,工作重心为基于用户行为的数据推荐,平时也乐于去实现一些突发的想法。在疲于配置系统环境时发现了Docker,跟大家一起学习、使用和研究Docker。

原文发布时间为:2017-02-08

本文作者:陈杰

原文标题:回顾微服务的边界选择

时间: 2024-08-05 03:52:46

回顾微服务的边界选择的相关文章

微服务的框架选择

从微服务说起 微服务架构(MSA)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦.你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则. 用通俗的话来讲,就是为了高度解耦软件之间的依赖性,使每个独立的模块都能够单独测试,单独运维,最大限度的提高软件的开发流程.从下图可以看一下微服务的软件生命周期. 软件从需求分析就可以适配模块,也就是说需求分析的过程就可以加入设计,从新的角度来说就是在哪个模块中进行升级开发,开发人员在开发完成后,通过持续集成,将开发的结

微服务间如何选择推送和拉取数据

在现在的系统架构中,服务间会大量采用消息来进行通信.在消息系统中,一般有两种消费模式:生产端推送和消费端拉取.那么在什么情况下,我们采用生产端推送,什么情况下换为消费端拉取呢?今天本篇文章就针对这个话题谈谈我个人的想法,希望对大家有用. 简单来说,是由实际业务决定.包括通信间的双方系统的技术实现.双方系统的架构和性能,看日后是否此业务会经常修改等多方面决定的.   数据是动态的且实时性强,宜采用生产端推送 订单系统有一些订单数据,供应链系统需要订单系统的订单数据,并做后续处理.例如, 订单系统的

从 Spring Cloud 开始,聊聊微服务架构实践之路

本文讲的是从 Spring Cloud 开始,聊聊微服务架构实践之路[编者的话]随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为 .NET SQL Server: 表示层:位于最外层(最上层),最接近用户.用于显示数

[译] 模块化 vs. 微服务

本文讲的是[译] 模块化 vs. 微服务, 原文地址:Modules vs. microservices 原文作者:Sander Mak 译文出自:掘金翻译计划 译者:lsvih 校对者:steinliber,DeadLion 模块化 vs. 微服务 使用模块化系统设计原则来避免微服务的复杂性. 从单体式应用向微服务架构迁移已经是老生常谈的话题了.除了过过嘴瘾,似乎真的动手将单体式应用拆分成微服务也不是什么很困难的事.但是这种做法真的是你们团队的最佳选择吗?维护一个凌乱的单体式应用的确很伤脑筋,

微服务概览、误解和误用

本文讲的是微服务概览.误解和误用[编者的话] 本文从对微服务的误解误用切入,探讨什么是微服务,如何切分微服务.提出了结合传统的DDD,领域驱动设计的理念来帮助定义微服务的边界,值得一读. [3 天烧脑式基于Docker的CI/CD实战训练营 | 北京站]本次培训围绕基于Docker的CI/CD实战展开,具体内容包括:持续集成与持续交付(CI/CD)概览:持续集成系统介绍:客户端与服务端的 CI/CD 实践:开发流程中引入 CI.CD:Gitlab 和 CI.CD 工具:Gitlab CI.Dro

微服务架构设计(五):获取微服务数据, 生成报表

架构师在设计从多个微服务取数据, 而生成报表的架构设计方案时, 往往面临著需在边界上下文 (Bounded Context), 数据的时效性, 性能, 可靠性与开发的复杂度间作取舍. 从多个微服务取数据, 而生成报表的设计方案, 主要是参考: Enterprise Integration Patterns; Hohpe and Woolf. A. Database Pull Model (Shared DataIntegration Style): 直接至各微服务所拥有的数据库中获取数据, 并写

使用Ratpack与Spring Boot构建高性能JVM微服务

在微服务天堂中Ratpack和Spring Boot是天造地设的一对.它们都是以开发者为中心的运行于JVM之上的web框架,侧重于生产率.效率以及轻量级部署.他们在服务程序的开发中带来了各自的好处.Ratpack通过一个高吞吐量.非阻塞式的web层提供了一个反应式编程模型,而且对应用程序结构的定义和HTTP请求过程提供了一个便利的处理程序链:Spring Boot集成了整个Spring生态系统,为应用程序提供了一种简单的方式来配置和启用组件.Ratpack和Spring Boot是构建原生支持计

微服务架构设计 (一): 核心概念

微服务设计是架构设计. 所以, 微服务设计不应是一个讲求标准答案, 简单粗暴的设计过程.而应该是一个考量各方因素下的一个决策的过程. 所以, 在探讨微服务设计前, 我们先来探讨下, 所谓的微服务具体应包含哪些核心的概念? I. 分布式 (Distributed): 微服务与微服务间分布式调用最主要的概念便是: protocol-aware heterogeneous interoperability; 各微服务可各自拥有自身的 platform (Java,C#, Scala-等等), 但, 各

翻译-使用Ratpack和Spring Boot打造高性能的JVM微服务应用

这是我为InfoQ翻译的文章,原文地址:Build High Performance JVM Microservices with Ratpack & Spring Boot,InfoQ上的中文地址:使用Ratpack与Spring Boot构建高性能JVM微服务. 在微服务天堂中Ratpack和Spring Boot是天造地设的一对.它们都是以开发者为中心的运行于JVM之上的web框架,侧重于生产率.效率以及轻量级部署.他们在服务程序的开发中带来了各自的好处.Ratpack通过一个高吞吐量.非