一周技术学习笔记(第58期)-如何突破第四章障碍

2022-04-26 20:59:05 浏览数 (1)

你平时有没有过这样的经历,如果有个问题搞不懂,看一本书里面某块内容不能完全消化,就会堵得慌,而且这种堵不会因为你不去想它,就消失。

我这次就遇到了。

《微服务实战》这本书,一共13章节,除了第4章,其余内容我全消化了,却唯独第4章内容,不能被我完全消化。

TIP:章节之间没有太多强关联性。

都说熟能生巧,我一直想写关于这块的内容,但是那个巧一直长不出来,却无从落笔。

今天,这个小长假第一天,我想再试试。

微服务最难的是什么?

1、何时开发一个新服务。

2、何时扩展已有服务。

3、如何划定服务之间的边界。

非这3个莫属,而且干这3件事,不仅是个技术活,还是个艺术活

书中介绍了3种方法。

1、按照业务能力和限界上下文。

2、按用例。

3、按易变性。

我们这篇学习笔记,重点尝试突破第1种方法:按照业务能力和限界上下文

什么是业务能力?

组织为了创造价值和实现业务目标所做的事情。

其实还有个”链条“-业务需求-业务功能-业务能力-服务,所以在谈到业务能力之前,还要有需求分析、识别业务功能,然后提炼能力,再由我们的服务来承载能力,进行输出。

TIP:每个服务都会为其它上下文提供API,同时将内部操作封装起来。

我们先来了解这次的业务需求。

开发一个在线投资工具,以前是用户自己找投资标的,比如股票、基金等金融资产进行交易,现在来优化升级这个在线投资工具,增加一个策略投资功能。由在线投资工具平台来生成投资策略,然后用户来选择这些策略,进而向市场进行交易。

TIP:一个简单的投资策略包含两部分:资产名称和一组按百分比分配的资产(债券、股票、基金等)。在线投资平台的管理者来负责创建策略。他们有专业的金融人员,这些资产的比例是根据风险水平和投资时间来设计的。

好了,我们可以看出来,需求明确了。

核心业务需求:创建投资策略,来进行策略投资,帮助没有经验的用户规避一定的风险。

嗯,产品同学也已经画好了原型图。

核心的业务功能,也明确了,梳理下来有如下业务功能。

核心业务功能:创建策略、获取策略数据;获取资产数据、查找资产;获取用户信息。

现在,到了最最关键的时候,如何划定业务能力,以及最终的服务,实际上往往能力和服务是放在一起考虑的

按照业务能力来划分微服务,最常使用的,最好使用的,就是从一个领域模型开始了。

TIP:领域模型就是对限界上下文中业务所要执行的功能以及所涉及的实体的描述。

你在看到这个领域模型的时候,方法应该是这样。

先不要盯着阴影部分看,也就是那三块**服务。不要。

要先从资产配置那里开始看,我们这次需求的最大核心就是资产配置。正因为有了资产配置,才会让用户有可以自主选择的投资策略,所有红色部分用户需要创建投资策略。

再从资产配置那里开始看,资产配置需要资产实体,比如股票、债券这些。也就是一种聚合关系,资产配置不在了,资产实体会一直存在。

还从资产配置那里开始看,有了资产配置,才有投资策略,我要选用什么样的资产配置来组成我的投资策略。这里是一种组合关系,资产配置不在了,投资策略也不会存在。

最后从阴影部分开始看,这个时候就形成了领域能力,也对应了领域服务,分别是投资策略服务、用户管理服务和资产信息服务

TIP:关于聚合和组合的定义及描述,这么多年来我常常弄混,每每使用的时候都要确定一遍定义。

---插曲 STAR--

参考出处:https://design-patterns.readthedocs.io/zh_CN/latest/read_uml.html

有同学给支了个招,挺好。

TIP:如果你也想加入群学习,可以文后加联系方式。

---插曲 END--

最后,还记得那个产品原型么,现在再来看开始的那个需求,它们已经有服务能力来承接实现了。

后记 |

我们的研发人员一般会习惯性的将新的大功能添加到已有的服务中,而不是投入更多的精力和时间去设计和开发一个新的服务,或者是将原有的服务响应地合理的拆分也不太愿意。

TIP:要实现的需求用例如果非常复杂,将其放到现有的服务中会违背单一职责的原则。

放入现有服务的理由是:省事。

研发人员有时候确实需要结合实际情况做一些务实的决定,但是他们仍然需要不断鞭策自己,以尽可能地减少这种形式的技术债务。

按照业务能力来划分服务,实际上也就是我们常说的从领域模型开始,这中间会有一个很大很大的挑战,需要非常非常熟悉业务,熟悉大量的业务知识。

如果信息了解不充分——或者做出了错误的假设的话——我们就无法百分之百确定所做的设计决策是否正确。不管是了解哪个领域的业务需求,这都是一个复杂、耗时、需要反复迭代的过程。

这并不是微服务独有的问题,但是如果对业务范围的理解出现偏差,然后又错误地将其体现到服务上,就可能导致在进行架构重构时付出更大的代价,因为将数据和功能从一个服务迁移到另一个服务内是需要耗费大量时间的。

声明:本文文字内容大部分为个人学习心得感悟,本文所有图片来自《微服务实战》,且仅作为学习交流使用,不涉及任何商业和任何收费行为,欲要学习更多书中精彩内容,欢迎大家积极购买阅读原书。

----END----

0 人点赞