关于云原生:系列文章｜云原生时代下微服务架构进阶之路-Boris

1次阅读

共计 3455 个字符，预计需要花费 9 分钟才能阅读完成。

通过本篇文章您能够理解到以下内容:

回顾
Boris 历史、由来
Boris 具体实施流程
Boris 的具体例子
总结

首先让咱们做一个简略的回顾:
在上一篇文章中咱们谈到了 Event Storming，咱们理解到，Event Storming 是一个入手实际的过程，这个过程须要咱们的领域专家以及技术人员一起参加，应用简略的工具（例如贴纸、白板、笔等）通过对事件的形容，流程的梳理，咱们逐渐理解到了整个零碎的业务流程（Business Flow），随着 Event Storming 的实现，咱们也初步通晓了整个零碎包含多少个微服务。

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

每个微服务彼此交互的形式是怎么的?
微服务与内部零碎交互方式是怎么的?
整个零碎全局的拓扑图是怎么的?
那么带着这些问题让咱们来开始明天的主题 Boris。

首先咱们来看下什么是 Boris
英文:
Identify relationships between services in a complex system to reveal the notional target system architecture and record them using SNAP

中文:
确定简单零碎中服务之间的关系，以揭示概念上的指标零碎体系架构，并且应用 SNAP 进行记录。（这里提到的 SNAP 我会在下一篇文章中向大家介绍）

如果用一句绝对文言的形式去解释 Boris，能够了解为 Boris 形容了整个零碎微服务以及微服务与内部零碎的关系和交互方式。

Boris 是由 Pivotal（现曾经回归到 VMware）的 Shaun Anderson 在 2016 年创造的，下图向您展示了一个实在场景下 Boris 的样子。

大家不难看出，Boris 整个样子和蜘蛛网很类似，这也是它名字的起源，其实 Boris 的名字是以一首歌曲的名字来进行命名的，歌曲的名字叫做“Boris the Spider”。

至此置信大家对 Boris 有了一个初步的理解，接下来让咱们来看看 Boris 具体实施的流程是怎么的。

WHEN
什么时候才会进入 Boris 阶段?
Event Storming 的产出物即是若干个微服务，当咱们实现 Event Storming 当前，能够采纳 Boris 将这些微服务之间的交互进行建模和梳理。从而能够对简单的零碎进行剖析并且理解整个运作模式。

WHY
为什么要进行 Boris?
咱们通过实现 Event Storming，能够很好的拆分出微服务，然而此时对微服务之间的交互，关系等并没有一个全局的视图进行表白。通过 Boris（例如每个微服务之间是怎么交互的，是同步还是异步，内部零碎又有多少，它们与微服务之间的关系又是怎么的等）能够帮忙咱们了解零碎全局的拓扑。

WHAT
想要实现 Boris，咱们须要进行哪些筹备?

Event Storming 的产出物（若干个微服务）
会议室（较大的凋谢空间），用于技术人员、领域专家等成员之间的充沛探讨。
便签纸（各种色彩，用于代表不同意义，例如 Service、Topic 等）。
笔（最好每个人一支），用于在便签纸上书写。
白板用于贴便签纸。
不同色彩的胶带（用于展示微服务之间的交互方式，例如同步、异步）
此外在进行 Boris 过程中，咱们须要应用不同色彩的贴纸以及胶带，不同色彩代表的含意不同，如下图所示:

Service
来源于 Event Storming，当咱们实现 Event Storming 后，产出了微服务（这里的微服务并不一定是最终的微服务，咱们能够在 Boris 或者 SNAP 中对微服务进行再次拆分以及合并）

Topic/Queue
应用异步模式下的收发音讯内容。

External System
顾名思义，代表内部零碎。Boris 不仅仅展示了微服务之间的关系模型，同时也会蕴含微服务与内部零碎关系。

Sync
代表微服务之间交互的形式，这里代表的是同步，例如 REST Call。

Async
代表微服务之间交互方式，这里代表的是异步，例如应用 MQ 进行音讯的收发。

至此后期筹备都曾经实现，接下来让咱们看下整个流程是怎么的。
首先是将 Event Storming 产出的微服务进行收集，把这些微服务以新的蓝色贴纸形式进行收集，并且粘贴在当时筹备好的白板上。

在收集完所有微服务之后，咱们能够在此基础上进一步摸索。接下来要思考的是每个微服务之间亦或微服务与内部零碎的交互方式（同步的 REST Call 还是异步的 MQ 音讯告诉），并且用不同色彩的胶带进行连贯。

在确定微服务之间的交互方式后，例如服务 A 和服务 B 的交互方式为 REST Call 即同步，咱们还须要在此形式上增加对应的命令，对于命令的了解能够认为是 GET、UPDATE、DELETE 等操作，比方服务 A 想从服务 B 获取订单信息，那么对应的命令就是 Get Order，咱们能够用贴纸记录下来。须要留神的是，这种命令是存在方向的，因为是服务 A 从服务 B 获取，所以对应箭头的形式应该是从 A 到 B。

当咱们实现了下面的三个步骤后，最终造成 Boris 的样子如下图所示:

https://tanzu.vmware.com/deve…

通过上一章节的介绍，置信大家对 Boris 中的概念，以及施行流程有了较为清晰的了解。
可能有些概念较为艰涩形象，同时 Boris 自身是以入手实际为主的模式，所以为了更好的加深咱们对整个流程的了解和认知，接下来咱们以上一篇文章中介绍 Event Storming 例子为根底，即用户注册，再次来回顾下整个流程。

第一步，通过 Event Storming 的产出咱们失去了无关用户的所有 Event，并且聚合成了对应的微服务，联合例子此时微服务咱们能够称之为 USER。此外咱们把无关订单的 Event 聚合成另外一个微服务，咱们这里称之为 ORDER。咱们把这两个微服务从新书写到新的蓝色贴纸上，并贴在当时筹备好的白板上。

第二步，依照业务流程，USER 微服务会在用户注册的时候向内部零碎发动用户信息的校验，比方姓名和有效证件是否真实有效，所以这里咱们减少一个黄色的贴纸，它代表着内部零碎即身份校验，同理，在实现用户注册后，咱们可能会向相干用户发动短信告诉，这里会存在另外一个内部零碎，咱们称之为短信告诉服务。

第三步，依照理论业务状况，USER 服务会发动同步的一个申请给身份校验内部零碎，这个申请附带着用户对应的相干信息，所以咱们用蓝色的胶带代表着这是一个同步申请（REST Call），这次申请咱们会失去验证通过或者不通过的信息，所以箭头的方向是 USER 服务到身份验证服务。

第四步，同理第三步，当验证通过后，咱们须要向短信告诉的内部服务发送一次申请，用来给对应用户发送用户注册胜利的短信提醒，此时能够是异步的操作，行将对应短信的内容，模版等信息以音讯队列 MQ 的形式发送进来，所以咱们能够采纳红色的胶带进行示意，同时箭头的方向是 USER 服务到短信告诉服务。

第五步，用于 订单零碎 在解决订单的时候须要用到对应客户的相干信息，即订单服务会向 USER 发动一个同步调用（REST Call），所以咱们用蓝色胶带进行示意，同时箭头的形式是从 ORDER 服务到 USER 服务。

以此类推咱们用这种形式，就能够实现整个零碎微服务之间的交互模型。

回顾全篇内容，整体包含以下内容:
首先在开篇咱们理解到了 Boris 的定义，以及 Boris 的历史、由来。
其次介绍了 Boris 的整个施行流程，在施行流程的章节中，论述了为什么要进行 Boris、Boris 的筹备工作等内容，以及 Boris 过程中应用不同贴纸、胶带代表的含意。同时宏观的论述了整个 Boris 的流程。
最初联合例子进行再次阐明 Boris 整个施行过程。

当咱们实现 Event Storming 以及 Boris，微服务拆分的三把利器曾经实现了三分之二，作为最初一步的 Snap- E 也应该退场了，那么什么是 Snap-E? 它是实际流程又是怎么的? 对于上述问题，在下期的文章中会持续和大家进行交换分享，敬请期待!

参考链接:
1.https://tanzu.vmware.com/deve…

李刚，VMware 大中华区利用现代化部门高级零碎架构师，资深企业级软件开发和软件系统架构师。Spring Cloud 开源社区我的项目贡献者、Netflix 开源社区贡献者。近几年，参加并主导了许多大型企业客户的利用现代化数字转型我的项目，波及物流、制作、金融等诸多畛域。特地对微服务实现办法、现代化利用架构设计、云原生施行落地、开源软件技术等方面有着丰盛教训。

起源|公众号：VMwareTanzu 云原生

正文完