从单体到微服务的思路转变:垂直切片的烟囱式故事已经一去不复返了- ThoughtWorks


传统SOA单体架构如同下面多层蛋糕一样,虽然实现了分层架构,但是实际中人们切蛋糕时,总喜欢竖切蛋糕,这样每个人能尝到多层蛋糕中每一层味道。

在敏捷开发团队中工作时,无论是业务分析师,Scrum Master,产品负责人还是开发人员,我们所有人都已经听说过如何以及为什么必须垂直切入用户需求故事中。维基百科将垂直切片描述为: 
 “ ...穿过构成软件代码库结构的各层的横截面切片。例如,一个简单的垂直切片将包含数据访问层,业务逻辑层和用户界面层。

下面是我们使用此定义所看到的垂直切片图,需求故事被垂直切入应用程序的不同层。
几年前确实如此,当时将多个服务和UI层作为一个工件部署,并在大多数情况下是由一个团队开发。但是,随着微服务架构的发展以及API可以消费的渠道数量的增加,从持久性到UI层的垂直切入的故事是不可能的。
随着微服务平台的发展和API的增加,我们将不得不以不同的方式思考,例如分别提供蛋糕基,糖霜,鲜奶油和巧克力粉,这样我们不但可以制造出蛋糕、还能制造出冰淇淋圣代或提供全新的甜点。

假设有一个称为Binging的视频流服务示例。如果要显示视频的平均收视率,我们会写这个故事用例:作为Binging的用户,我想查看每个视频的平均收视率,这样我可以决定观看哪个视频。
这个用例故事将包括:从数据库中获取评分,计算平均值并将其显示在UI上。在传统单体架构中,通常做一个大服务实现这个用例故事,包括UI、服务逻辑和持久层,这样服务逻辑耦合了UI的可能显示格式等。但是,实际上我们不知道哪个服务使用者需要显示收视率以及在UI上显示哪种格式。

使用微服务的Binging服务的高级体系结构架构图如下所示:

团队的结构将复制上述架构:

在这种微服务架构下,不可能像以前单体SOA服务那样,专门有一个服务用于显示视频的平均收视率了,这一个大服务被分成不同的小服务:一个Rating服务和众多这个服务的消费者渠道服务了:
1. Rating服务:对于Rating服务的消费者客户端可以获得的功能:我要显示视频列表中的平均收视率,然后显示给我的用户。
2. 安卓或苹果客户端app的服务:这个服务是针对安卓苹果客户端的,这些客户端用户可以看到所有视频的平均收视率,这样他可以决定看哪个视频。
3. 网站Web服务:这个服务针对网站用户,用户可以看到某个指定视频的平均收视率,这样能与其他视频进行比较。
“安卓或苹果客户端app的服务”是“Rating服务”的消费者客户端,自己是一种渠道服务,这两种服务互为调用者和被调用者关系。同理,“网站Web服务”也是“Rating服务”的消费者客户端,自己也是一种渠道服务。
这里的Rating服务是更基础的微服务(国内俗语:中台服务?),这个Rating服务不同于传统于垂直切片烟囱式的大服务,包含了UI、业务逻辑和数据库三层的应用服务。

这里的问题是,我们是否会增加工作量和时间来提供显示平均收视率的功能? 
不是,这是因为现在UI客户端已经不同于以前单一的Web,多种UI客户端,显示收视率的渠道数量增加了,针对每个渠道能以不同格式显示收视率的灵活性。
例如,安卓或苹果app上的收视率可以与视频列表一起显示,但是,在Web网站上,收视率可以显示在视频详细信息页面上。除了显示的灵活性外,它还减少了新功能的推出时间。
此外,“Rating服务”可用于分析,报告,市场研究等。例如,我们可以回答诸如“哪些是收视率最高的视频?”,“哪些视频对哪些人群的评价最高?”之类的问题。和“哪些视频在哪个国家/地区被评为高或低?”。“Rating服务”服务可以回答这些问题,而不会影响任何渠道。

Rating服务和各个渠道消费者自己的渠道服务定位不同:“Rating服务”是从数据存储中提取所有收视率,计算平均值,并发出指定视频或视频列表的平均收视率。而渠道服务将调用“Rating服务”,并以直观且用户友好的格式显示每个视频的平均收视率。

这里要记住的一件事是,所有POD都应了解并就其产品边界达成一致。这将有助于端到端功能的优先级划分和规划。当您开始从单一应用程序迁移到微服务体系结构时,这将有些困难和挑战,但是一旦所有POD理解了各自产品的职责,它便照常营业。

 注:本文已被大幅度改写,但中心思想未变,原文点击标题。
总结:微服务 = DDD领域服务+渠道服务! Rating服务=DDD领域服务;安卓或苹果或web服务=渠道服务。