从质量的视角理解架构师的工作

在最近一段时间一直有几个问题缠绕着我，架构师该做什么？如何成为一个名副其实的架构师？带着这个问题我查阅了很多资料，请教了很多人，但依然没有找到我需要的答案。

请教猛哥，他告诉我，就把你对质量的知识迁移到质量运营就好了，当时不得其解。后来一次和周老师讨论这个问题，他说你就别管架构师这高深的名词，就从你擅长的角度思考这个问题，作为一个质量负责人，你需要关注产品的那些方面？我很快的告诉了他以下六个词。

可用、可靠、易用、效率、可配置（可维护）、兼容（可移植）

然后他很认真的对我说，架构本身就是为软件质量服务的，你就从你刚才理解的这六个词重新思考下什么是架构，然后你就明白该如何做了。

回到工位把那六个词写下来，并认真思考，在某个瞬间恍然大悟，这六个词不就是ISO9126中关于质量模型的六大特性么？有了这个启发，我重新从质量的视角思考架构师的工作。

1.架构师分类

从质量模型的上图从左往右前三个是对用户来说可以感知的属，后三个主要是质量内建相关的属性，系统运维运营需要关注的点。这样来看，功能性、可靠性和易用性，其实不就是应用架构师的职责么；效率、维护性和可移植性不就是系统架构师职责么？

应用架构师：负责构建一个以解决特定业务问题为目标的软件应用，一般以满足各种功能性需求以及维护性需求为设计考虑目标；从应用程序的维度，偏业务系统，从用户的角度关注业务理解，负责某个应用的技术架构，梳理模型，设计模式，接口，数据交互等方面。

系统架构师：以企业的持续经营目标为考虑要素来构建企业所需要的内在结构设计；提供运营支撑软件应用的信息系统的结构设计。从系统的维度，负责整体系统的架构设计，主要是基础服务和各系统间协调上，着眼全局不太注重某个应用本身架构，比如关注服务器负载，可靠性，伸缩，扩展，数据库切分，缓存应用等方面的基础架构设计。

当然，现实中的架构师往往会身兼数职，而不仅仅是构思架构本身。比如，大部分软件架构师也会组织软件团队、进行一些相关研究，甚至担负一些行政管理的工作，在此不再延伸赘述。

2.架构师应该关注点重点

1. 从功能的角度需要思考：

用户真正想要什么？这些是用户想要的么？是否准确的实现和解决了用户的需求和痛点？系统的边界在哪里？确定系统干什么不干什么？流程是否合理？系统产品之间数据流转过程合理？系统安全可靠，允许经过授权的用户和系统能够正常的访问相应的数据和信息，禁止未授权的用户访问.......

2.从可靠性的角度需要思考：

系统是否成熟可靠，设计时是否考虑系统内部错误，导致软件失效的各种异常流程和错误的兼容性处理；软件出现故障，是否能够快速修复，甚至自我修复；失效情况下的如何恢复并正常运行？

3.从易用性的角度需要思考：

设计的产品是否符合心理学和行为学，是否能够很方便快速的被操作者使用和理解，就像iPhone手机Home键设计，一两岁的孩子只要探索一两遍，便能够很容易操作并使用，作为架构师也需要从业务领域相关的背景知识中抽取和提练业务流程，并结合用户的特点给产品设计提出指导性原则和积极的建议。

4.从效率性的角度需要思考：

需要关注用户操作端到端的系统响应时间，实现这个目标，架构师从纵向分解和横向分解，纵向分解是将整个系统分层，从而将整体系统分解成下一级的子系统与组件；横向分解是在系统分解成不同的逻辑层或服务后，对逻辑层进行分块，确定层与层之间的关系，从中选择最优的一种方案。

并且关注系统前端到后台、系统之间业务数据交互的时间及效率，如业务响应时间，吞吐率、TPS（每秒事务数）等业务指标；以及系统资源的利用率，CPU 内存 磁盘 IO 网络带宽、队列、共享内存。

5.从软件维护性的角度需要思考：

主要从运营的角度思考软件架构如何设计，如何能够快速分析定位问题；软件产品出现的失效可以通过外部修改修复，同时又能防止意外修改导致程序失效，确保已修改软件能被正确的运行的能力。

6.从软件可移植性的角度需要思考：

软件的可移植性就是需要考虑，软件从一种环境迁移到另一种环境的能力，是否可以在不同的硬件服务器、操作系统或者中间件产品上不需要修改就能够被部署和搭建；并且能够很方便快速的被安装的能力。

3.架构师能力要求

架构师到底有哪些能力要求呢？网上有张关于架构师能力要求调研报告，其中37%的人认为架构师的设计能力最重要，技术实力重要度排在第二占了24%，沟通能力则排在第三占比14%，此次，我们详细分析排在前三的能力。

1.设计能力－擅长整合分析

架构是过程，并非结果。架构是架构师洞察内在结构、原则、规律与逻辑的过程，架构师要做到清晰理解系统，以及简洁描述，这是分析整合的能力。

一个架构师必须具备极强的分析能力，要做到根据产品宗旨和目标，分析清楚产品定位以及产品业务，再整合利用现有的技术领域，找出最佳方案，实现产品概念。

2.技术实力－实现产品规划

能够在业务需求清楚的前提下，能够将一个完整的业务系统从功能模块和系统架构的角度进行分解，从技术的角度给予技术选型提供建议，前端到底用瘦客户端还是富客户端呢？数据库是用MySQL还是MSSQL又或是Oracle呢？等等，架构师还应该深入一线解决和攻克技术难点。

3.沟通能力－能够横向沟通

架构师参与项目开发全过程，包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段，在这一系列过程中，架构师会与各部门沟通交流。

一个产品会有多部门合作，架构师在其中的沟通极为重要，直接影响产品进度与质量。架构师不仅要与开发人员沟通，也要和项目经理、分析人员甚至用户沟通，来实现产品的各种可能性。所以，对于架构师来讲，不仅有技术方面的要求，还有能够横向沟通的要求。

从以上综合来看，架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。架构师不是一个人，他需要建立高效的体系，带领团队去攻城略地，在规定的时间内完成项目。

以上知识笔者希望从既往工作中，快速复制和迁移其能力的一些思考，并未经过真是检验。希望有相关经验的同学一起思考并给予建议和指导。

特别说明：本文第三部分内容，部分内容来源于网络