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

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

  • 回顾
  • 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

扫描二维码关注公众号,回复: 14526177 查看本文章

什么时候才会进入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云原生

{{o.name}}
{{m.name}}

猜你喜欢

转载自my.oschina.net/u/4238514/blog/5581800