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

架构师修炼之道（二）——架构？设计？架构师？

 

Part.1 什么是架构？

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

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

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

什么是组件？

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

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

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

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

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

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

组件与组件间的关系

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

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

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

关键机制

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

Part.2 什么是架构设计？

那什么是架构设计？

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

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

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

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

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

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

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

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

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

有一个人去采访三个砖瓦匠，他问：“你们是在做什么？”

第一个人答：“砌砖，混口饭吃”。

第二个人答：“砌墙啊，赚钱”。

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

做架构设计便是盖楼。

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

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

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

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

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

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

Part3.谁能称为架构师？

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

架构师又分为：

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

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

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

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

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

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

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

认清自己，认识岗位，理解工作内容。

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

知道自己能做什么。

知道自己在做什么。

知道自己怎么做。

承上启下，掌控全局。

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

输入需求，输出设计。

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

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

知识广泛，兼具深度。

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

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

架构复用。

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

软技能。

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

keep learning，保持学习，饱含热情。

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

Part4.总结

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

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

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

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

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

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