写点什么

【变与不变】架构中的边界划定

用户头像
soolaugust
关注
发布于: 2020 年 12 月 17 日
【变与不变】架构中的边界划定

【将原则纳入到架构的生命中】中简单了谈了些原则的重要性,但是原则只能作为我们衡量和评估我们架构的工具。在实际设计一个模块或者系统时,我们又该怎么做呢?那么今天就让我们来看一下架构中的边界划定。


我们在设计一个系统或者模块时,我们知道是我们最终需要实现什么功能,但是我们实现功能的方式后很多中,我们最简单的就是直接编码,自顶向下的编写我们的代码。但是我们都知道这样带来的后果是我们的代码耦合度会非常高,一旦后面有任何改动,都可能牵一发而动全身。所以我们架构设计中的一个重点就是解耦



解耦就意味着要将我们的代码分开,分成各个模块。这种我们又称为边界划定。模块划分的越细,耦合度就会越低。但是同时导致代码的复杂度变高。可以说这是一把双刃剑,具体划分到什么层次就变成了架构中的一道关键问题。


这个问题在我看来就是区分代码中变和不变的情况,这里的“变”是指两个模块之间是否同步改变,如果同步改变,也就意味我们没有必要将两个模块分开(至少暂时不要),这样我们可以进一步降低代码的复杂度。而如果一个模块的两个部分可能出现不同步改变的情况,那么我们就要考虑是否要将模块拆开,进一步降低两者的耦合度。


这个“变和不变”的判定并不是一蹴而就的,会随着我们对于业务和代码等多方面的理解进一步加深。这里我来谈谈我的理解:


一般来说,当我们拿到需求或者任务的时候,我们首先知道的是我们要实现什么功能。这个时候我们可以根据功能来划分边界。可以粗略,可以详细。不用担心设计不合理或者过度设计,我们需要的就是锚定一个大致的范围。



当我们按照需求划分模块结束后,我们得到了一堆模块。那么接下里我们就要评估各个模块了,评估一个系统或者一个项目,一般采用三个角度,即“可靠性,可拓展性和可维护性”。那么我们就先说一下如何用这三个方面来改进我们的架构。


可靠性意味着系统的健壮性,也就是即使我们的系统发生故障,也能正常工作。这听起来很厉害,但是实现上我们简单考虑这两种方式:监控和防护,监控就要求我们尽量增加一些模块来帮助我们理解运行的情况。防护包括安全设置和状态恢复。这也需要增加额外的模块。


接下来是可拓展性,也就是代码适应以后的变化,这个是门大学问,也值得我们单独来说。不过在这里我简单说一下,所谓的适应以后的变化,我们简单考虑这两种方式:降级,拓展(水平拓展和垂直拓展)。降级就要求我们模块划分时要考虑多级服务,当资源不足时,那些服务需要保证,那些可以舍弃。这个角度就可以将模块做进一步的划分或者组合。拓展我们这里主要考虑水平拓展,也就是俗称的加机器。垂直拓展是指部署在更高性能的机器上,这个不需要服务有什么要求。那么水平拓展就要求我们考虑我们的模块哪些可能是瓶颈,我们尽量将瓶颈变成可以水平拓展的,也就一般所说的无状态。这要求我们对模块进行进一步的拆分。如果我们有多个模块会一起出现瓶颈,那么我们就可以将服务进行组合。



可维护性意味着代码要足够简单。因为简单就意味着以后无论修改还是修补成本都会很低。那么如何让代码变得简单呢?我们一般可以思考这样几种手段:第一是抽象,这个可能要求我们增加一些不同于需求模块的模块,这些模块存在的意义就是屏蔽我们的具体实现,而提供一个统一的接口供上层使用。另外一个就是统一标准,也就是在同一层我们采用的规则或者结构尽量一致。第三就是说明要详细,如果我们的模块无法从表面看出是什么作用,那么就一共要增加相应的辅助模块,即使不是代码也可以。


当我们从这三点评估完后,我们得到了一个需求和技术相结合产生的架构。可以说架构的基本范围已经划定,接下来就是用设计原则来评估我们每个模块是否划分正确。但更为重要的是我们需要配合其他人一起评估我们的方案,因为自身的思维局限,所以我们更需要从别人的观点来完善我们的架构。


发布于: 2020 年 12 月 17 日阅读数: 50
用户头像

soolaugust

关注

公众号:雨夜随笔 2018.09.21 加入

公众号:雨夜随笔

评论

发布
暂无评论
【变与不变】架构中的边界划定