写点什么

架构方法学习小结

发布于: 2020 年 06 月 10 日
架构方法学习小结

无情岁月增中减,有味诗书苦后甜。

最重要的一点

并不是如何做架构:)

而是我的架构为谁而作,说的简单点就是,我们的写的架构文档,是开发来读、运维来读、还是项目经理来读,又或是不懂技术的老板来读呢?

我想,不同的读者需要的是不同的架构文档。

为什么呢?

总得来想,我觉得是分工带来的困境。

当每个人都只关注自己的领域的时候,谁来设计全局蓝图呢——告诉大家我们要的系统的是这样的。

我想架构师就是来做这样一件是事情的,他描绘了系统的蓝图——架构。



怎么来理解这张图呢?

我想大家,一定认为这张图最重要的元素是架构吧,毕竟我们讲的就是架构师嘛。然而,相关方才是最核心的,一切都是围绕相关方来执行的。

首先架构不是凭空产生的,它是整个系统的蓝图,而系统也不是没有来由的,它是相关方的利益所在,这个系统也并不是我一个人来落地,需要团队协作,那怎么才能让团队中的每个人都理解我们的意图呢?

架构文档就是来做这样一件事的,而其中不同的视图又为不同领域职能的同事提供了指导。

至于,架构元素与架构元素之间的关系就是组成架构的关键,是狭义的如何做架构的内容,而广义的内容就是完整的这幅图。

现在我们再回到开头,怎么架构就不是这张图最重要的内容呢?

我写到这里,发现这张图说明了三个问题:

  1. 为什么要有架构

  2. 架构是长什么样的

  3. 架构如何落地

很明显,第一个问题是最关键的嘛。但是,为什么的问题,一般也轮不到我们架构师来费神:),由此说来,我们的主要工作还是在解决后两个问题。

使用UML来描述我们的架构

好了,我们现在已经知道我们的架构是为谁做的了。这件事的意义再哪里呢?我觉得课上老师讲到的一句话提醒了我。“我最不想合作的一种人,就是那种只为工作而工作的人。”一开始听确实是模糊,但细细一琢磨,这类同事只为自己负责,他人又如何与他有效合作呢?架构师的架构为谁做,就是对谁负责。因为我们需要将我们的架构意图清晰告诉每一人,他们才好开展自己的工作。事情都讲不清楚,工作的开展又怎么能顺利呢?

那么如何使用表述清楚我们的意图呢?

UML。

在工作中,我们主要使用部署图、类图、组件图、用例图和序列图、活动图、状态图来描述架构。前者属于静态图,后者是动态图。其中的重点不是如何绘制这些图,而是该如何使用这些图来描述我们的架构。

部署图

它的单位是服务器,最直观的告诉同事我们的架构是如何用服务器组织起来的,通常读者是运维工程师。

类图

顾名思义,是对代码层面的类的描述,说明了两件事情:

  1. 类是什么样子的

  2. 类和类之间的关系是如何的

当然,这一部分是开发工程是重点关注的。

组件图

我的理解是一套controller+service+dao就可以理解为一个小组件,或者一组这样的小组件合成一个大组件,就微服务来说,一个服务也可以理解为组件。读者一般也是开发工程师。

用例图

描述了一个或多个组件有哪些使用方,这些使用方又有哪些操作。从我的理解上看,我一般在产品给出需求后,会绘制这个用例图,然后和产品一起讨论,达成共识后才开展架构或者开发工作。那么用例图的读者可以是产品方了。

序列图

说了上面好几个图,都是静态图。那如何来描述功能或者一个API的流程时序呢?这就是序列图的作用了。就电商下单的逻辑来说,你可以从服务的粒度来描述整个过程——经历过那几个服务,做了哪些事情,服务之间是同步调用,还是异步调用,当然也可以关注一个服务内部的逻辑处理经过——经历过哪些service、做了什么事情。这部分主要还是开发工程师来阅读,当然测试工程师也是它的读者。

状态图

常用来描述类的状态,以及类的状态变更条件。

就像一个订单的状态,有哪些订单状态,这些订单的状态是如何转变的。如果用word来描述的话,密密麻麻的文字,看得就让人头疼,用一张图来表述就很清晰。这一部分的读者,应该有开发、测试和产品。



说到这里,首先我们架构师要对做的系统有个全局的认识,这个认识可以模糊的,也可以是明确的。如果是模糊的,那么就边画图,边梳理自己的认识;如果是明确的那就明白白清清楚楚地画图告诉大家。不知道大家看到这里,会不会有个疑惑,小结了这么多,通篇说的都是软绵绵的东西,都没有说到技术性很强的点。其实刚开始小结的时候,我也是有这样的疑惑的,但是梳理到这里,我豁然开朗。对系统要有个全局的认识,这件事本身就很有技术含量,此时我们熟知的分布式、微服务、各种中间件还有对“三高”要求,都会在这这一层次体现出来。

发布于: 2020 年 06 月 10 日阅读数: 54
用户头像

还未添加个人签名 2017.10.30 加入

半壁山房待明月,一盏清茗酬知音。

评论

发布
暂无评论
架构方法学习小结