摘要：软件架构师就是这么一个让人向往，但又让人望洋兴叹的一个职位。

前言

就像建筑设计师总有成为总设计师的梦想，航天工作者总有成为总工程师的壮志，相信每一个软件工程师都有过成为软件架构师的想法。 引用维基百科里的定义，软件架构师的职责就是在软件系统研发中，负责依据需求来确定主要的技术选择、设计系统的主体框架结构，并负责搭建实施。 然而，架构师所需的技能远远不止于技术选择和系统设计。 本文主要介绍软件架构的定义，以及要成为一个软件架构师所需具备的一些技能，让你对软件架构师这一职位有一个更深的了解。

文中大部分的观点来自于《Fundamentals of Software Architecture》一书。

软件架构的定义

对于软件架构（Software Architecture），我们通常将它看成是软件系统的蓝图，但是如果要给出一个精确的定义，往往很难。 维基百科里对软件架构的定义为，有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。 但是，这种定义也是片面的，软件架构并不仅仅是系统的整体结构和组件，光有这些还不足以指导设计出好的软件系统。

Mark Richards和Neal Ford在书中，从四个维度上对软件架构进行了描述，分别是Structure、Architecture Characteristics、Architecture Decisions和Design Principles。

软件架构的描述

Structure

Structure描述的是软件系统所使用的架构风格，比如最常见的分层架构（layered architecture）、事件驱动架构（event-driven architecture）、微核架构（microkernel architecture）、微服务架构（microservices architecture）等等。 当你去问架构师一个软件系统使用什么架构时，如果他告诉你，「系统使用的是微服务架构」，那么也他仅仅阐明了系统的架构风格而已。 若想了解整个系统的软件架构，对architecture characteristics、architecture decisions和design principles都要有深入的认识。

Architecture Characteristics

Architecture Characteristics也就是我们常说的非功能需求，比如有可用性（Availability）、可扩展性（Scalability）、可靠性（Reliability）等。 Architecture characteristics往往容易被软件新手所忽略，但是它对于软件系统而言却是非常的重要。 如果说功能需求决定了一个软件系统的下限，那么非功能需求则决定了它的上限。

Architecture Decisions

Architecture Decisions描述了开发软件系统时所必须遵循的规则，比如图中例子，对于一个分层架构风格的系统而言，开发工程师需要遵循以下规则：只有业务层才能直接访问服务层，表现层不能直接访问服务层。 Architecture decisions更多的只是一种约束，违反了这种约束可能并不会对系统的功能造成影响，但是却是系统架构腐化的源头。

Design Principles

Design Principles指的是系统设计的原则，用于引导开发团队选择更符合系统特点的技术方案。 Design principles只会给出一个方向，而不是具体的实现方案。 比如图中例子给出的系统设计原则就是：微服务之间应该尽可能通过异步通讯来提升系统的性能。 至于开发团队通过REST或者RPC的方式进行异步通讯实现，设计原则并未进行限制。

成为架构师所需的技能

就像软件架构不仅仅是系统的整体结构和组件一样，要成为一个软件架构师，只会技术选型是远远不够的。 一个合格的软件架构师应该具备以下的几种技能：

1.进行架构决策

An architect is expected to define the architecture decisions and design principles used to guide technology decisions within the team, the department, or across the enterprise.

这是一个架构师所需具备的最基本的技能，需要为开发团队给出系统设计的原则和系统开发的约束。 架构师在这里的角色更多的是一个引导者，而不是具体技术方案的制定者。 比如，开发团队要进行前端框架的选型，作为架构师应该给出的建议是选择Reactive风格的前端框架（引导团队在React.js、Angular、Vue.js或者其他Reactive风格的前端框架之间进行选择），而不是直接建议选择React.js框架。 前者属于架构决策，而后者则是技术决策。

2.持续对系统架构进行分析

An architect is expected to continually analyze the architecture and current technology environment and then recommend solutions for improvement.

就像一个软件系统的生命周期并不止于开发阶段的结束，软件架构也不是一锤子买卖。 这就要求架构师能够持续对系统架构进行分析，并提出改进的建议，使得系统在面对业务和技术的双重变化时，仍然能够保持架构良好。

3.保持对技术和业界的发展趋势的敏感

An architect is expected to keep current with the latest technology and industry trends

作为一个架构师必须时刻保持对技术和业界发展趋势的敏感。 在敏捷开发的潮流下，软件的特性会频繁的发生变化，但是软件的基础架构往往是很少改变的。 架构师如果不能把握当前技术和业界发展的趋势，从而导致设计出来的软件架构不能够应付未来几年的业务和技术变化，这对于一个软件系统而言将会是灾难性的。

4.确保团队按照既定的规则进行开发

An architect is expected to ensure compliance with architecture decisions and design principles.

架构师不仅仅需要制定设计原则和开发约束，还需要确保团队能够一直按照这些规则进行软件开发。 这就要求框架员对开发人员提交的核心代码进行Code Review，否则系统的架构很容易就腐化掉了。

5.扩展知识的广度

An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.

对于一个架构师而言，他并不需要精通每一种框架、平台和语言，但至少要尽可能多的了解它们，这样才能更好的支撑架构决策。 这就要求架构师能够持续的学习新的知识，不断地跳出自己的舒适区。 最好的情况就是精通2~3种语言和框架，并且熟悉业界各种常用的语言和框架，这样的知识深度和广度的结合才能设计出更好的软件架构。

6.拥有一定的领域知识

An architect is expected to have a certain level of business domain expertise.

所有的技术都是服务于既有的业务，剥离了业务的软件技术毫无价值。 架构师无需像领域专家一样精通系统的各种业务，但至少也要有一定的业务积累。 软件是用来解决问题的，不懂业务的架构师来做软件架构设计，就相当于还没读懂题目就开始解题，结果往往适得其反。 比如一个需要低时延的业务，交给一个不懂业务的架构师来进行系统设计，可能得出来的是一个高吞吐量的架构。

7.人际交往的能力

An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership.

对于大部分的开发工程师和架构师而言，这可能是最难的一条了要求了。 他们很擅长，也很乐意去解决技术上的问题，但是对于与人相关的问题则相当的抵触。 但这对于一个合格架构师来说所必须克服的一点，因为架构师不仅仅需要制定技术规则，更重要的是领导团队按照既定规则进行开发，这不可避免地就涉及到领导力和人际交往的能力。

当一个开发工程师决定在一次需求开发中采用单例模式，可能团队里的其他人并不会有太多的关注。 但是当一个架构师决定采用微服务架构来设计系统时，可能就会受到团队内各类人员的挑战，比如版本经理可能觉得微服务架构太复杂，会不会影响交付的节奏;开发人员可能觉得分层架构更好实现。 这种情况下就要求架构师能够有很好的人际交往能力，说服各类人员，这样项目才能更好的进行下去。

总结

软件架构是一个很抽象的东西，目前对它的定义大部分都是一些很宽泛的描述。

《Fundamentals of Software Architecture》从四个维度上对软件架构进行了描述，让软件架构有了一个更加清晰的视图。 在此基础上，书中也提出了一个合格的软件架构师所需要具备的几种技能。 总的来说，就是想要设计出一个好的软件架构很难，要成为一个好的软件架构师更难。

另外，书中还提出了软件架构的两个准则，很有道理，就是有点抽象。 不过没关系，不要试图理解它，要去感受它。

1、Everything in software architecture is a trade-off.

2、Why is more important than how.