系列文章|云原生时代下微服务架构进阶之路 - Snap-E

2023年3月29日

通过本篇文章您可以了解到以下内容:

  • 回顾
  • Snap-E 简介
  • Snap-E 具体实施流程
  • Snap-E 的具体例子
  • 总结

回顾

首先让我们做一个简单的回顾:

在上一篇文章中我们谈到了 Boris,我们了解到,Boris 是一个动手实践的过程,这个过程需要我们的领域专家以及技术人员一同参与,使用简单的工具(例如贴纸、白板、笔等)

通过对微服务彼此以及微服务与外部系统交互的梳理,我们可以很清晰的了解到每个微服务彼此是怎样交互的,以及交互方式。

至此,进一步思考,我们可能会面临以下问题:

  • 怎么展现每个微服务的具体信息呢?(例如有多少个 APIs,数据实体又是怎样的?)
  • 针对于第一点,这些信息又是怎么获取的呢?

那么带着这些问题让我们来开始今天的主题 Snap-E。

Snap-E 简介

Snap-E 是英文的缩写,全称为: Snap Not Analysis Paralysis - Enhanced.

简单的理解,我们可以通过 Snap-E 清楚的了解某个具体微服务内部结构信息,比如这个微服务内部包含多少个 APIs、数据实体,是否存在 UI 界面,是否与外部系统交互等。

Snap-E 具体实施流程

WHEN

什么时候才会进入 Snap-E 阶段?

通过 Boris 我们将微服务之间的交互进行建模和梳理。在 Boris 过程中,我们可以同时进行 Snap-E,从而实时的记录下微服务的元素。

WHY

为什么要进行 Snap-E?

Boris 只是从微服务这个层面进行系统梳理分析,那么针对于每一个微服务内部的构造我们需要进行剖析,通过 Snap-E 可以使我们很清晰的看到每一个微服务内部的构造。

WHAT

想要完成 Snap-E,我们需要进行哪些准备?

  • 在进行 Boris 的同时,SNAP-E 模版被实时的进行填写。
  • 会议室(较大的开放空间),用于技术人员、领域专家等成员之间的充分讨论。
  • 便签纸(各种颜色,用于代表不同意义,例如 API、DATA 等)。
  • 笔 (最好每个人一支),用于在便签纸上书写。
  • 白板 用于贴便签纸。

整个 Snap-E 阶段就是根据 Boris 结果进行对每一个微服务分析,在 Snap-E 模版中包含了若干元素,那么这些元素又代表了什么意思呢?接下会和大家详细说明下, 如下图所示:


ServiceA

对应的是 Boris 中微服务的名字,此例子可以理解为,有一个 serviceA 的微服务,通常针对每一个微服务我们使用一页 Snap-E 进行表示。

API

根据 Boris 中的约定,例如使用 REST Call 方式进行交互,此时 APIs 代表的是该服务对外暴露出的服务接口。

DATA

顾名思义,代表的是该服务所涉及到的数据实体 Entity。

PUB/SUB

顾名思义,某些微服务可能会存在使用异步消息的情况,这里面分别指的是接收亦或发送消息。

EXT

代表该微服务是否存在与外围系统联系,这里我们可以标注外围系统的名字。

STORIES

来源于 Boris 中的命令(这个命令可以理解为 GET、UPDATE、DELETE 等操作), 这里将命令进行简单的描述封装。

UI

代表该服务是否存在 UI 界面。

RISK

代表可以遇见的一些风险。

至此,我们已经知晓了完成 Snap-E 需要的准备,以及 Snap-E 模版中元素具体的含义,那么接下来我需要知道的是模版元素的来源,答案就是 Boris。

换而言之,在进行 Boris 过程中,会对微服务之间的调用关系,命令越来越清晰,在这个过程中,我们可以实时的快速记录所需要的元素并将这些元素填充到 Snap-E 的模版当中。如下图所示:

Snap-E 的具体例子

通过上一章节的介绍,相信大家对 Snap-E 中的概念,以及实施流程有了较为清晰的理解。接下来我们以用户注册为例子,再次来回顾下整个流程。此处会结合之前文章 Event Storming 以及 Boris 中提及的部分内容。

第一步,我们需要进行 Event Storming,也就是对于有关用户的 Event 进行聚合,并形成了对应的微服务,我们称之为 USER。另外将所有关于订单的 Event 进行聚合,形成另一个微服务 ORDER。

第二步,我们利用 Boris 对 USER 和 ORDER 这两个微服务之间的调用关系进行分析,建模。同时这里面会涉及到外部系统。结合业务流程,比如 USER 可能会发起一些验证消息,用于客户注册时的验证、订单服务获取用户信息等。从而进一步我们会逐步发现若干个命令(此处的命令可以理解为服务之间的 GET、UPDATE、DELETE 等操作)。


第三步,Snap-E 模版的填写,以 USER 微服务为例,此时我们根据上一步骤 Boris 产出的结果作为输入,我们知道的是 ORDER 微服务会向 USER 微服务发起一个 REST Call,所以此时 USER 微服务应该对外提供一个服务,也就是暴露出一个 API,另外,ORDER 需要从 USER 中获取用户信息,那么 USER 服务中应该保存一个关于用户数据的实体。映射到 Snap-E 中就是 API 以及 DATA 元素。

第四步,另一方面,我们可以看到,USER 服务在完成用户信息注册的业务流程中,需要和外部系统进行交互,这里面指的分别是身份校验系统以及短信通知系统。所以映射到 Snap-E 中就是 Ext 元素。

第五步,结合第四步,我们知道 USER 服务与两个外部系统进行了交互,而且与短信通知服务采用的是异步操作,即可以理解为 USER 向外部系统发送了一个注册成功的短信通知消息,与身份校验服务采用的是同步调用,即获取身份信息校验结果。而对于异步发送消息的操作映射到 Snap-E 中就是 PUB 元素。

第六步, 在上面 Boris 中存在三个命令,分别是获取用户信息、身份信息获取验证结果、注册成功发送短信。我们可以将这三个命令进行相对较为详细的描述,例如,针对于获取用户信息,我们可以描述成,USER 服务接收到了一个获取 User 信息的请求,来自于 ORDER 服务。而对于这种命令的描述封装,就是 STORIES 元素。


以此类推我们用这种方式,就可以完成整个系统微服务的 Snap-E 建模。

总结

回顾全篇内容,整体包括以下内容:

  • 首先在开篇我们了解到了 Snap-E 的含义。
  • 其次介绍了 Snap-E 的整个实施流程,在实施流程的章节中,阐述了为什么要进行 Snap-E、Snap-E 的准备工作等内容,同时宏观的阐述了整个 Snap-E 的流程。
  • 最后结合例子进行再次说明 Snap-E整个实施过程。

至此微服务拆分的三把利器 Event Storming、Boris、Snap-E 已经全部向大家介绍完了,我们可以看出,Event Storming 是将现有的业务流程进行梳理,也可以说它的输入就是业务流程,输出是微服务;Boris 是将微服务之间的交互进行建模,形成全局的拓扑图,这里的输入是 Event Storming 的输出即微服务,而 Boris 的输出是全局系统交互方式,微服务彼此交互(这里的交互指的是 Boris 中的 command)。Snap-E 则更进一步,是将每一个微服务具体化(包括哪些 API、DATA、UI 等),它的输入正是 Boris 的输出。

虽然我们使用了这三把拆分的利器完成微服务的拆分,但是接下来我们需要的是有一个强有力的、高效并且开箱即用的技术框架支持我们开发落地工作,作为 JAVA 世界最受欢迎的 Spring 这时候登场了,在下期的文章中我会继续和大家就 Spring 进行交流分享,敬请期待!

参考链接:https://tanzu.vmware.com/developer/practices/swift-method//swift-method/

内容来源|公众号:VMwareTanzu 云原生

服务器托管,北京服务器托管,服务器租用 http://www.hhisp.net

hackdl

咨询热线/微信 13051898268