一个好的架构
总结下来,一个好的架构可以从下面几个方面去评估:
包括:形式,效果和实施三个维度。
形式
评价一个架构形式,第一个原则就是:高内聚,低耦合。这里面的关键在于:内聚的边界在哪儿?耦合的边界在哪儿?,什么样的内聚才算高内聚?什么样的耦合才是低耦合?有点难以把握,所以,我加了一点:职责明确,关系清晰,跟高内聚,低耦合配合起来一起看一个架构形式。
职责明确
分析一个架构的时候,首先看每个模块的职责,那怎么才算一个“职责”呢?
职责:业务上不可分割的原子操作
在判断是不是高内聚,是不是职责明确的时候,第一步就是先分析职责。我把职责定义为上面的形式,在业务上不可分割的原子操作。例如,共享单车的开始订单操作是一个职责,包括了:创建订单,开始计费,开锁等操作,他们在业务上是一个整体,其中只拿出一项而言,对业务都没有意义。另外,这个地方的业务,不一定是面向用户的业务,像一些中间件系统,这个时候的业务就是对系统功能而言。
接下来,就是把模块的这些职责列出来,看看是不是明确的,进而看看是不是内聚的。其实,这几个词还是没法客观的给一个标准,就像计算1 1一样,如果等于2就是对的。这里面很大程度还是依赖于一个主管的判断。这个主管的判断我觉得可以借助于费曼学习法,就是:把这个系统的职责,讲给一个不熟悉这个系统的人听,看看能不能用最简洁的语言描述清楚。另外,还可以从另外一个视角去看,内聚的背后驱动力其实是领域化和分工的不同,所以,如果一个人要掌握这个系统,需要具备不同领域的知识,那么就一定是内聚了太多的职责。
关系清晰
如果职责明确,高内聚不好客观的评价,但是,关系清晰和低耦合确实有办法来衡量:那就是画关系依赖图。,所以,一个好的架构师,一定能够对整个系统的职责有明确的认知,然后画出一张清晰的关系依赖图,然后从这张图里面,发现问题,找出优化的方向。
看一个最简单的例子,在关系1中,是比较好也是比较理想的情况:模块A单向依赖模块B,如果一个系统所以的模块都是单向依赖,并且不存在循环依赖的话,整个系统就是分层的树,层次清晰。
然后,往往存在大量如关系2中的依赖关系,造成这种关系基本上都是职责不明确所致:要么把依赖的职责抽离出来放到模块C或者模块D上,要么单独抽取一个底层模块,供上层C和D使用。
总的来说,从形式上,本质上关注职责明确和职责内聚,但是,往往有的时候我们很难给一个客观的标准去衡量,所以,更多的时候,我们要梳理清楚依赖关系,把关系理顺,发现模块之间的问题,降低耦合,进行抽取或者内聚,整体上实现分层的树状结构。
效果
一个架构,不管如何设计,都可以当作黑盒,从效果上去评估:
首要的是,能够解决问题
这里面隐含了一个前提,就是识别问题。其实我在很长的一段时间内,以为识别问题是架构师的难点,但根据最近的实践发现,其实问题还是比较容易识别的,因为现在基本上不是从0到1,或者是你一个人在工作,基本上一个团队已经折腾了一段时间,这个时候,痛点,问题大家都知道。只是缺少解决的方案。甚至有的时候解决的方案大家也都知道的大概,只是缺少实施的方案。
其次,能够提效降本。
解决问题只是第一步,接下来就是体现一个好的架构师的能力:提效降本,提高解决问题的效率,降低解决问题的成本。要实现提效降本,难点不在于如何衡量:毕竟这一点还是很容易衡量的,就看投入的资源有多少就好了;难点在于设计出一套提效降本的方案,本文重点不是讲设计,所以大概列一些点:
- 模型设计和优化
- 技术引进
- 技术创新:很难。
其实,架构从直接效果上看是增加了负责度,就好比盖楼,盖一座大厦肯定比盖一间草屋复杂度高,但是,前者却能住更多的人。所以,好的架构一定是平衡了复杂度和收益,最大化提高效率降低成本。
实施
一个架构,如果不能落地就不算架构,所以在评价的时候,还需要评价实施方案,这一块的标准也好制定,主要从两个方面:
- 时间/人力成本:就看要投入多久,多少人来实现
- 维护成本:好不容拉一票人开放完成,结构后面很难维护,也算一个失败的架构。
总结
这么看,整体上除了内聚和职责明确,这一块不好衡量之外,其他的都是可以衡量的:
- 依赖关系清晰:画一个系统依赖关系图,越细越好,另外,既然是关系,就要有强弱依赖,也要理清楚
- 效果也可以衡量:给别人清楚你设计这套架构能带来的收益,要讲清楚不要模模糊糊
- 实施成本也尽可能衡量:有的时候实施成本不能一下评估准确,而是在开发的过程中发现一些问题,这个时候要主动拉更多的人讨论,看看有没有潜在的坑,尤其是对遗留系统的重构。
source: https://lishoubo.github.io/2019/05/03/如何评价一个架构的好坏?/