架构师

闲扯架构师

成为一名知名的架构师，想必是许多程序员的梦想，不仅仅是因为架构师拥有绚丽的光环，也是因为对技术信手拈来指点江山般的自信和笃定的一种无限向往。然而要想成为一名合格的架构师，背后却需要苦行僧的自律。好在合格与不合格目前并没有明确的界定，众生百家议论纷纷，各执一词，所以作者本人不吐不快，发表一下自己眼中架构的相关理念以及架构师应该有的样子。

文章章节

• 架构的定义理解
• 架构的演进和考量
• 微服务架构
• 架构师的职责

架构的定义和理解

什么是架构，借用维基百科给出的定义：是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。简单明了，但给人的感觉就是假大空，没有说出本质性的问题。笔者认为架构实际和项目管理的概念类似，是依托于现有的资源解决掉各个关系人的利益关注点，并对将来应对业务增长有一定的前瞻性的软件设计。所以我们可以将架构暂时分为两个部分，一个是业务功能性需求和另一个是非功能性需求。

功能性需求

对系统进行架构前，架构师的首要任务是尽最大可能找出所有的干系人，业务方、产品经理、客户/用户、开发经理，工程师、项目经理、测试人员、运维人员、产品运营人员等等都有可能是干系人，架构师要充分和干系人沟通，深入理解他们的关注点和痛点，统筹规划并出架构解决这些关注点。于此同时一定要解决掉一些潜在的冲突，不同的干系人对系统的关注点不同，比如管理层（可管理性）vs技术方(性能)，业务方(多快好省) vs 技术方（可靠稳定），这些都需要在架构时候需要考量的地方。

非功能性需求

系统的前瞻性体有一大部分是在非功能性上的考量，客户往往关注的是功能性需求，所以这时候架构师就需要在非非功能性的系统设计方面做出设计。通常要考虑的点有：

非功能性需求

上面的图基本上涵盖了系统架构设计非常重要的非功能性需求。

系统的演进和考量

好的架构是演进出来的，不是一开始设计出来的，很多架构师多多少少有完美主义情节，所以开始做架构的时候都是大而全，但是一旦出现问题，往往改动的成本就会很大。这时候我们应该采用小步快跑的形式进行架构。

迭代

可以采用最小可用产品（Minimum Viable Product， MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。

mvp

在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的风险和成本。

系统架构体系工具

微服务架构

互联网井喷式的发展，传统的单体应用已经不能很好的满足业务的发展，所以微服务大行其道。从技术角度讲，我微服务主要体现的是单一职责和关注分离的思想，从单进程模块化进一步扩展到跨进程分布式的模块化。微服务是独立的开发、测试、部署和升级单元，微服务中每个服务可以独立演变，它的cost of change比较小，整体架构比较灵活，是一种支持创新的演化式架构。
但是微服务有额外成本，需要搭建配套的框架、发布和监控等基础设施。初创和小规模团队不建议采用。主要决定因素是系统复杂性和团队规模，当到达一个点，单块架构严重影响效率才考虑引入微服务。

架构师的职责

硬技能

所以的硬技能就是主要是针对于技术层面的把控，每一项技术都有深入的理解，知道内部的实现逻辑。在这也是想描述一下架构师到底要不要写代码，其实很难一概而论，笔者认为架构师要写系统的核心代码，即便不写代码，那应该有个前提就是对各种框架已经了然于心，对问题有可预见的能力。

软技能

架构师是软件开发中比较特殊的角色，除了做系统架构和软件设计之外，还需要承担一些管理的技能，规划产品路线，估算人力资源和时间资源，安排人员职责分工，确定计划的里程碑，指导工程师工作，工程评估和控制等。这些管理事物需要对产品技术架构，功能模块划分，技术风险都熟悉才能胜任。

• 架构师在系统架构的初期要进行大量的沟通以便能够对业务和干系人关注点有深入的了解，所以沟通是架构师必须有的技能。
• 更多的关注人而非产品，所以架构师需要寻找一个共同的目标，营造一个大家都能最大限度发挥自我价值的工作氛围
• 知道是事情成就了人，而非人成就的事情，架构师应该成就他人。
• 共同参与架构，架构不是一个人的，多一种不一样的声音，可能会为架构师带来不一样的设计理念
• 架构师的目的是做成一种软件，而非是当老大的。

关注公众号架构思维干货抢先看

架构思维