架构师修炼之道(二)——架构?设计?架构师?

Part.1 什么是架构?

简单来说,架构就是一个考察对象的内部结构。

这个内部结构是【以组件为视角】来进行考虑的,架构的含义包括了【组件以及组件之间的关系】。

另一方面,架构的含义还包括考察对象内部的【关键机制】。

什么是组件?

组件通常是开发或部署的一个单元。

根据考察对象的大小,组件的粒度也有所区别。

如我们现在常说的大数据平台,其系统内部由很多子系统组成,如权限系统、数据采集系统、数据处理系统、数据分析系统、数据存储系统、数据管理系统、数据展示系统,这一个个子系统便可称为大数据平台的组件。

而将组件视角再下沉,如数据采集系统中又分为爬虫组件、数据清洗转换组件,其中又可能用到了横贯整个大数据平台的日志管理组件。

这是开发系统内部的一个结构,而从部署上来说,大数据平台一般是由3台及以上的多点系统部署而组成。

在对内或对外开放大数据计算资源时,又由权限系统进行资源分配。其中的单例大数据平台又可以作为一个单独的组件。

组件与组件间的关系

这是架构要考虑的重要因素。

来自系统外部的请求通常是由多个组件协作完成的。

系统内部的结构是否良好,很大程度上取决于组件之间的关系。

关键机制

所谓关键机制,是指影响到系统可用性、安全性、性能等重要非功能特性的一些技术方案,如技术选型、关键设计、处理流程等等。

Part.2 什么是架构设计?

那什么是架构设计?

我们先看这样一段定义,是指【以需求分析为输入,通过架构师的分析,产出架构设计资料,用于指导后续概要设计、详细设计、开发、测试、部署、上线运行】。

架构设计是不是就是概要设计?

架构设计是以组件视角来思考系统如何分解,并定义分解出来的组件之间的关系。

而概要设计则是从功能模块视角对系统进行分解,并定义这些功能模块之间的关系。

所有的功能模块都要有归属的组件,因此应先做架构设计,再做概要设计。

它与代码设计又有什么区别?

代码设计有一张表的模型就可以开始做了,类似于在一面墙上定位一幅画,挂歪了再修正很容易。

架构设计则是造一个房子。移动一幅画很容易,移动一面墙则是一个完全不同性质的事了。

三个砖瓦匠的故事想必不少人都听过。

有一个人去采访三个砖瓦匠,他问:“你们是在做什么?”

第一个人答:“砌砖,混口饭吃”。

第二个人答:“砌墙啊,赚钱”。

第三个人答:“盖房子,建设漂亮的大楼”。

做架构设计便是盖楼。

开发一间房子,房子中有各种各样的组件,画好房间的图纸,将窗户、梁柱、墙、水电燃气通道等按照既定的位置组装起来。就如我们的一个单例系统。这已经可以说是一次架构设计了。

而盖楼,则需要将组件的视角再上升一层。每个房子都是一个组件,要考虑地基、水管连接、上下层承重。

甚至再上升到小区,我们还要考虑绿化、容积、车位等等。

架构设计是不容易更改的,犹如地基,想盖更高的楼,就要打更深的地基,所以在设计时,一定要考虑可扩展、可兼容性。

但是,架构真的是设计出来的吗?我们回头再说说,架构的设计与演进之旅。

而谁来做这些架构设计的事呢?接下来说说什么是架构师吧。

Part3.谁能称为架构师?

架构师就是在其领域内能够全局把握的人,能够给出其负责范围内的总体设计,并能解决关键问题、指导其他人员落实设计。

架构师又分为:

系统架构师、数据架构师、基础设施架构师、应用架构师。

系统架构师是系统或产品线的负责人,是一个负责理解和管理并最终确认和评估非功能性系统需求(性能、安全、可用性、可扩展性、可移植性),给出开发规范,搭建系统实现的核心架构,对整个软件架构、关键构件、接口进行总体设计并澄清关键技术的高级技术人员。

【在没有架构师这个岗位的公司,一般会由项目经理或技术经理、研发负责人等人员负责其全部或部分职责。】

架构师也都不是凭空而来的,一般会由团队中的【技术高手】进化而来。

在《架构师修炼之道(一)技术高手的困惑与发展》中,我们也说了技术人的几个发展方向。

那么架构师应该有些什么具体的能力呢?

架构师应该有什么能力呢?

  1. 认清自己,认识岗位,理解工作内容。

架构师应当对架构师岗位有着清晰的认识,对架构工作的内容有着深刻的理解。

知道自己能做什么。

知道自己在做什么。

知道自己怎么做。

  1. 承上启下,掌控全局。

架构设计上接需求分析、下接概要设计,是整个软件工程中非常重要的一环,将决定整个系统实现的质量,架构设计对后续所有工程环节都有影响。

  1. 输入需求,输出设计。

运用规范的架构设计方法论,产出标准的架构设计资料。不要随意发挥,弄一些毫无章法的产物出来。

如果公司当前没有相关标准,可以自行设计一套,然后要求大家共同遵守。

  1. 知识广泛,兼具深度。

需要具备广泛的知识面,并在某些方面具有一定深度。例如数据库设计、多线程并发、负载均衡等。

对系统相关的技术栈有全面清晰的认识,并可以解决疑难杂症或给出药方(方向)。

  1. 架构复用。

掌握常见的架构模式,在遇到类似问题时,可直接复用。

  1. 软技能。

架构所涉及的方方面面较多,因此需要有良好的沟通能力。

  1. keep learning,保持学习,饱含热情。

技术不断发展,业务不断变化,需要保持学习热情,立于不败之地。

Part4.总结

我们现在对以上的架构部分简单做一个总结:一个系统的架构就是指在系统运行期间的实际内部架构,它是各种组件的一个组成,架构设计就是对这种组件间关系的书面描述,而架构师就是负责描述这种关系的人。

怎样成为一个优秀的架构师?

我个人的定义是:格局要大,做事要沉。视野要远,脚下要实。

具体的做法便是在做决策的时候,不只是做一个技术架构,需要关心业务实际要解决的问题,但是又不能头疼医头脚疼医脚,眼光要关注未来。

在成本、技术实现、未来演化之间,我们需要不断做平衡。

最后,在个人而言,我们应当对于新生的事务应当有所了解,对于需要用到的新技术能随时沉下心去钻研,对接触的业务应能抓住核心目标,强力推进系统的落地与演化。


本文内容参考《软件体系结构》、《领域设计模型》。


如果你对我的文章有什么想法,欢迎评论。

如果你想及时看到我的最新文章,请关注我的公众号。
架构师修炼之道(二)——架构?设计?架构师?_第1张图片

如果你想跟我一起探讨,围观我的学习日常,欢迎加入我的星球。
架构师修炼之道(二)——架构?设计?架构师?_第2张图片

你可能感兴趣的:(架构师修炼之道(二)——架构?设计?架构师?)