通过本篇文章您可以了解到以下内容：
- 回顾
- 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.fwqtg.net
