通过本篇文章您可以了解到以下内容:
-
回顾
-
Boris历史、由来
-
Boris具体实施流程
-
Boris的具体例子
-
总结
回顾
首先让我们做一个简单的回顾:
在上一篇文章中我们谈到了Event Storming，我们了解到，Event Storming是一个动手实践的过程，这个过程需要我们的领域专家以及技术人员一同参与，使用简单的工具（例如贴纸、白板、笔等）通过对事件的描述，流程的梳理，我们逐步了解到了整个系统的业务流程（Business Flow），随着Event Storming的完成，我们也初步知晓了整个系统包括多少个微服务。
至此，进一步思考，我们可能会面临以下问题:
-
每个微服务彼此交互的方式是怎样的?
-
微服务与外部系统交互方式是怎样的?
-
整个系统全局的拓扑图是怎样的?
那么带着这些问题让我们来开始今天的主题Boris。
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具体实施的流程是怎样的。
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/developer/practices/boris/
Boris的具体例子
通过上一章节的介绍，相信大家对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? 它是实践流程又是怎样的? 对于上述问题，在下期的文章中会继续和大家进行交流分享，敬请期待!
参考链接:
作者简介
李刚，VMware 大中华区应用现代化部门高级系统架构师，资深企业级软件开发和软件系统架构师。Spring Cloud开源社区项目贡献者、Netflix开源社区贡献者。近几年，参与并主导了许多大型企业客户的应用现代化数字转型项目，涉及物流、制造、金融等诸多领域。特别对微服务实现方法、现代化应用架构设计、云原生实施落地、开源软件技术等方面有着丰富经验。
来源｜公众号：VMwareTanzu云原生
{{o.name}}
{{m.name}}